-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow playback of single files through src= #816
Comments
Shaka Player does not support playing an mp4 directly. We do support unprotected mp4, but only through some manifest, like DASH or HLS. For direct playback of mp4, just set |
Plain HTML5 playback sounds like the best solution for your problem. I'm not sure Shaka Player could add any value. If there's no encryption, no adaptive streaming, and no manifest, there's nothing left for Shaka to do. If you disagree, I would be happy to discuss it further. |
The use case is using the same player for the main video as pre-roll, mid-roll, and post-roll MP4 video ads. Having to switch players complicates things. If the ShakaPlayer can support it, why prevent it?
|
It can't, though, with the current architecture. I promise, it's not just stubbornness on my part. :-) Shaka Player today is a MediaSource-based player. With What you can do, if you want to use Shaka Player for some playbacks and not others, is switch off: var player = new shaka.Player(video);
player.load(manifestUri);
// ... time passes ...
player.destroy()
video.src = directPlaybackUri;
video.load();
// ... time passes ...
player = new shaka.Player(video);
player.load(anotherManifestUri); If you want to avoid destroying and recreating the player, another solution would be to have multiple video tags. Not all platforms support multiple video tags, but some bolt-on ad SDKs do something like this: var player = new shaka.Player(video1);
player.load(manifestUri);
// ... time passes ...
// Switch!
player.unload(); // Or video1.pause(), if you want to resume the same content later
video1.style.display = 'none';
video2.style.display = 'inline';
video.src = directPlaybackUri;
video.load();
// ... time passes ...
// Switch!
video1.style.display = 'inline';
video2.style.display = 'none';
player.load(anotherManifestUri); // Or video1.play(), if you want to resume Finally, you could consider serving ads via DASH. Shaka Player supports multi-period DASH content, which is (as far as I can tell) perfect for ads. Shaka uses MediaSource to stitch the ads together with the main content into a seamless presentation. Do any of these suggestions help? Shaka Player v1 had a mechanism for If we were to add something like that back, we would need a better design and a strong justification for the effort. If I understand you correctly, you want to use the same player for DASH and direct MP4 playback. For direct MP4 playback (hypothetically):
Looking at the architecture diagram, I don't see what's left for us to do for you in such a scenario. What am I missing? How can Shaka Player make things any easier for you in this case? |
Ok. This is essentially what we are doing already for our project with this integration to ensure support for devices that ShakaPlayer does not run well on. My comment was more in the vein of creating a fully inclusive player that a developer could use for any task. Typically ads are coming in via VAST and require a bunch of extra tracking mechanisms and will arrive in whatever format the ad provider provides (typically MP4). Ad stitching would require the ShakaPlayer to support VAST solely in itself and keep track of ad tracking ping backs as it is played. Handling this server side causes black listing in many cases from Google DFP and others.
|
We've decided to work on src= support in v2.3. This will involve a fair amount of refactoring, and using src= to directly play a media file will mean that most of Shaka Player's configuration will have no effect. The browser will be responsible for streaming, buffering, etc. Side-loaded captions would also fail (because we would not be streaming text, either). Shaka Player would only be able to control DRM for src= playback. So, with all those caveats, we are scheduling this for v2.3. |
Great to hear. Thank you.
Regards,
James Cahall
… On Aug 28, 2017, at 11:50 PM, Joey Parrish ***@***.***> wrote:
We've decided to work on src= support in v2.3. This will involve a fair amount of refactoring, and using src= to directly play a media file will mean that most of Shaka Player's configuration will have no effect. The browser will be responsible for streaming, buffering, etc. Side-loaded captions would also fail (because we would not be streaming text, either). Shaka Player would only be able to control DRM for src= playback.
So, with all those caveats, we are scheduling this for v2.3.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
There were some oversights when moving code out of Player.onLoad_. The method header needed to be updated to better reflect the actions of the method and some data no longer needed to be moved from |wants| to |has|. The largest offender was asserts. The assert messages were not updated when copied to new nodes. Issue #816 Issue #997 Change-Id: I1e3e8a7c883af6a665c2223b1b2fcab330438e4e
To make it easier to read and verify, this change updates all the interruption tests to use a single structure. The naming of the tests was updated to make it easier to understand what they were testing, which showed that a test case did not previously get update (it has been updated now). Issue #816 Issue #997 Change-Id: Ibbb70a39a5e9ea13687804448a10b24c789e03cc
The "loading" event should be fired when the user has signalled their intent to load content. For us, this means when |Player.load| is called. During the work on the load graph, the event was not moved, and was being fired near the end of the load process. This change moves the event to be fired in |Player.load|. Issue #816 Issue #997 Change-Id: I69db702a79b70716dfd31c0e4302b5fa9f41c370
We need to have a playhead for media source and src=, however the current playhead implementation is tied very tightly to manifests. Rather than working to refactor playhead, this change defines an interface and makes the old playhead the Media Source implementation of the interface. In a later change the src= version will be introduced to allow playhead functionality when we don't have a manifest. Issue #816 Issue #997 Change-Id: Ie74e50839c79c3cd3acf14000849e3d5fa71a42f
The walker knows when it is about to go idle. This even can be useful to our tests and cast receiver. This change takes the first step and surfaces the event from |shaka.routing.Walker| through |shaka.Player|. Some tests were updated to make use of the state-idle-event and state-change-event. Issue #816 Issue #997 Issue #1843 Change-Id: I809a6963f49c569883ab58d4ed8e8f5898726ef4
If the player sees an error and we are attached to a media element, we should return to the attach state because we assume that the media element is still usable after an error. If we keep throwing away the media element, it means that after each error, an app would need to re-attach to the media element. This will break backwards-compatibility. This CL restores backwards-compatibility by resetting the walker to be at the attached-state if it has a media element. Issue #816 Issue #997 Close #1843 Change-Id: Idaa70d9fcc01cd9af06ff8967812a4051f8c6e53
Hello @dmunozpolo thank you for checking on the progress of #816. Currently we have You see, all the public methods on player previously assumed that content loaded from a manifest and is played with media source. This means the public methods often assume we should have something that we don't when using Because of Once the public-method work is done, the |
To make the getBufferedInfo method simpler for when we have three different ways of responding (not loaded, loaded with media source, and loaded with src=), this changes media source to fill-in a buffered info object rather than return one. Issue #816 Issue #997 Change-Id: If9e4558ca324808a1b94e3c235f4bfb42a5df8ce
This CL creates the "loaded with src=" node and its initial implementation. Adding this node required some changed to the routing logic as a new destination was created. We will use src= when given mp4 content or media source is unavailable. We detect mp4 content via the mimeType in |load| and/or the file extension. When media source is not available on a platform, we fall back to using src=. To do this, we check if media source is available whenever |load| is called, and will route to the src= branch if media source is not found. To avoid pre-initializing media source (when it is not available) we modify the |initializeMediaSource| flag in |attach| and |unload| when media source is not available. Doing this showed that we had inconsistent behaviour between |attach| and |unload|. |attach| would default to initializing media source whereas |unload| would not. This has been fixed. Issue #816 Issue #997 Change-Id: I00599832b49c9079e273e65a4b827fee736479cc
Add the idea of load modes. These are low resolution state flags that allow us to know what state we are in. These flags work with the load graph, being set strategically during the load progress to enable and disable public method behaviour. In the grand-scheme of things, this solution is meant to be revisited, but is meant to unblock the work for src=. Issue #816 Issue #997 Change-Id: I28660d5d5ef2d746d63988b488f5d15a10ee75a4
Because of the lack of tests (tests are coming) we did not see that the buffering system was failing to find media source to check if it had buffered to the end of the presentation. This change adds the logic needed to know if it has buffered to the end for each type of loaded content. Issue #816 Issue #997 Change-Id: Ief9d4bdc94f3121f889a0efa24a8b3d78377bb9f
Create the src= load branches for the remaining public methods. This should ensure that it is now safe to call the public methods when playing src= content and expect to get the intended return values. The tests to verify this are in a follow-up CL. Issue #816 Issue #997 Change-Id: I088b6bbd2489b3960457030846debae07fd86d16
This change moves the trick play logic out of the video wrapper so that it will be more available to the src= code. By doing this, I hope that we can make it clearer how we are working with the playback rate and ensure a tighter integration with it. Issue #816 Issue #997 Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
Hi @vaage , I saw that the commit 040ecf6#diff-3ba6443b4313aa886513e61dfd8c7564R998 that allow use mp4 as src. It is possible add more types or use https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType ? |
@avelad, @joeyparrish will need to answer that question. I am no longer with Shaka Player. |
@avelad, yes, I think that canPlayType would be helpful in general, and fits nicely with the native HLS work for iOS. I'll follow-up on that very soon. |
The integration tests for src= failed almost universally on Tizen, but a few failed on other platforms, as well. The issue was the fixed delays in those tests. This replaces those fixed delays with an event-based utility that solved the same problem in other Player integration tests. Issue #816 Issue #997 Change-Id: Ib43cbb139ef77be1219e60d1fd5009aa403cc4cb
This fixes the definition of load() to wait for a frame before resolving the load() Promise for src= playbacks. Now methods like isAudioOnly can be trusted as soon as load() resolves. This also allows load() to fail for src= playbacks if an error event fires from the media element. Issue #816 Issue #997 Change-Id: I0f6120d1334bbebcb78efdbbca65c7981f3ef265
2.1.1
Yes
master
?Yes
Both
Yes
Safari
Attempted to load unprotected MP4 (advertisement) in player.
Allow load of unprotected MP4 content from outside server.
The text was updated successfully, but these errors were encountered: