Two ways to put an Eagle 3D Streaming stream in your page. They reach the same platform, run the same applications, and — since both demos were brought level — offer the same controls. What differs is who holds the video element, and who decides whether a session may start at all.
| iframe | Web SDK | |
|---|---|---|
| To embed | one <iframe> tag |
a script, a token, and a main() call |
| A Streaming API key | not needed | needed, to create session tokens |
| The video element | inside the frame, on the Eagle 3D Streaming website | in your page, yours |
| Who may start a session | anyone with the link | whoever your server gives a token |
| Talking to the application | postMessage at the frame |
direct calls on e3ds_controller |
| Hearing back | a message event |
a callback you assigned |
| Your own loading / ended screens | yes | yes |
| Fixes and new features | arrive on their own | when you update the bundle yourself |
| Styling around the video | around the frame | anywhere, including over it |
An iframe is quicker to embed. The SDK gives you control over who streams and what the page around the video can do.
This one is easy to miss when you are choosing, and it keeps mattering for as long as the integration exists.
An iframe loads the player from Eagle 3D Streaming. When a bug is fixed, stream recovery improved, or a feature added, it is live on your site as soon as Eagle 3D Streaming deploys it. You change nothing. You do not redeploy, you do not test a new version, and you cannot be left behind on an old one.
An iframe needs nothing from you, not even a redeploy. A visitor reloading the page is already getting the current player. There is no version of the player pinned inside your site, so there is nothing that can fall behind.
The Web SDK is a file you host. The version on your site is the version you last copied there, and it stays that version until you replace it. A fix does not reach your visitors when Eagle 3D Streaming deploys it — it reaches them at the end of a chain:
Every step is somebody making time for it, and in practice that is usually not the same week. A fix that took an afternoon can sit unused on a live site for months — not because anything went wrong, but because nothing in that chain happens by itself.
Neither is automatically better. Automatic updates are the whole point for a team that does not want to maintain an integration — and exactly what a team with a release process and a change-approval step does not want. Pinning a version means nothing changes under you before you have tested it.
If you take the SDK, treat updating it as a routine you actually schedule rather than something you do when something breaks. The gap between the version on your page and the current one only ever grows, and the longer it gets the more of a job the update becomes.
With an iframe, the URL is the access. You can put a password in front of it, but you cannot revoke it for one person, and the address sitting in your page source is a working link for anyone who reads it.
With the Web SDK, your backend decides who gets a token, when, and for which application. A token is single use and expires in the time you set, so a leaked one is harmless. That is a different kind of control, and it is the one thing an iframe cannot be configured into doing.
Every control in one demo exists in the other — with the exceptions marked below, which are in the next platform release. What changes when you move a page across is how you say it, and the pattern is mechanical:
| iframe | Web SDK |
|---|---|
{ cmd: "setVideoDetailLevel", value: "high" } |
setVideoDetailLevel("high") |
{ cmd: "freezeResolutionAt", x: 1920, y: 1080 } |
setResolution(w, h) |
{ cmd: "useViewportResolution" } * |
useViewportResolution() |
{ cmd: "setVolume", value: 0.5 } * |
setVolume(0.5) |
{ cmd: "captureScreenShot" } * |
captureScreenShot() |
{ cmd: "sendConsoleCommandToUE", value: "stat fps" } |
sendConsoleCommandToUE("stat fps") |
{ cmd: "sendDataToUE", value: {…} } |
sendDataToUE({…}) |
{ cmd: "emulateKeyboardKeyPress", value: "W" } |
emulateKeyboardKeyPress("W") * |
{ cmd: "ForceEndSession" } * |
terminate() |
* In the next platform release. The current production player ignores it without an error.
Events follow the same rule. When the stream is ready for messages the iframe receives
{ type: "readyToReceiveMessage" }; the SDK calls
callbacks.onDataChannelOpen. The session ending is
{ type: "sessionEnding" } on one side and
callbacks.onSessionEnding on the other.
| Live | Source | |
|---|---|---|
| iframe | e3ds.github.io/E3DS-Iframe-Demo | github.com/e3ds/E3DS-Iframe-Demo |
| Web SDK | demo-sdk.eaglepixelstreaming.com | github.com/e3ds/pixelstreaming-sdk |
Open both. The panels are the same on purpose — same controls, same groups, same log — so what you are comparing is the thing that actually differs.
Last updated