Skip to content
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

Closed
jamescahall opened this issue May 17, 2017 · 20 comments

Comments

@jamescahall
Copy link

commented May 17, 2017

  • What version of Shaka Player are you using?

2.1.1

  • Can you reproduce the issue with our latest release version?

Yes

  • Can you reproduce the issue with the latest code from master?

Yes

  • Are you using the demo app or your own custom app?

Both

  • If custom app, can you reproduce the issue using our demo app?

Yes

  • What browser and OS are you using?

Safari

  • What did you do?

Attempted to load unprotected MP4 (advertisement) in player.

  • What did you expect to happen?

Allow load of unprotected MP4 content from outside server.

  • What actually happened?
  1. ShakaPlayer doesn't recognize .mp4 extension automatically. Requires adding feature "mp4".
  2. ShakaPlayer doesn't play content. Throws 1002 Error from CORS issue. CORS issue not present in standard video HTML5 tag playback.

@joeyparrish joeyparrish self-assigned this May 17, 2017

@joeyparrish

This comment has been minimized.

Copy link
Member

commented May 17, 2017

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 video.src = 'foo.mp4'. You don't need Shaka Player for that.

@joeyparrish

This comment has been minimized.

Copy link
Member

commented May 17, 2017

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.

@jamescahall

This comment has been minimized.

Copy link
Author

commented May 17, 2017

@joeyparrish

This comment has been minimized.

Copy link
Member

commented May 17, 2017

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 MediaSource, the application fetches content and feeds it into a SourceBuffer to be consumed by the browser's media stack. This is fundamental to Shaka's v2 design.

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 src= playback, so it is definitely possible for one player to do both. We removed that mechanism in v2 because it complicated our design, it was hard to maintain, and it was only rarely used.

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):

  1. Shaka's networking and streaming logic would be out of the picture, because the browser would be fetching the content
  2. Shaka's MediaSource engine would be out of the picture, too, because the browser's media stack would be fed internally
  3. Shaka's manifest parsers would be out of the picture, because there's no manifest
  4. Shaka's DRM engine would be out of the picture, because the content is unencrypted
  5. Shaka already does not have any APIs for seeking, pausing, etc, because those things happen on the video element

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?

@jamescahall

This comment has been minimized.

Copy link
Author

commented May 18, 2017

@joeyparrish

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

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.

@jamescahall

This comment has been minimized.

Copy link
Author

commented Aug 29, 2017

@joeyparrish joeyparrish changed the title Unprotected MP4 Playback Allow playback of single files through src= Aug 29, 2017

@joeyparrish joeyparrish modified the milestones: v2.3.0, v2.4.0 Oct 3, 2017

@joeyparrish joeyparrish modified the milestones: v2.4.0, Backlog Dec 4, 2017

shaka-bot pushed a commit that referenced this issue Feb 20, 2018

Move MediaSource setup to MediaSourceEngine
This isolates MediaSource code without changing the early
initialization of MediaSource, which was designed for low-latency
startup.

Prerequisite for #1087, #880, #997, #816

Change-Id: I61acedd95d73610d3e67436d9c7767d643fe2d29

@joeyparrish joeyparrish modified the milestones: v2.4, v2.5 Mar 4, 2018

shaka-bot pushed a commit that referenced this issue Mar 12, 2019

Add Drm Node to Load Graph
This change moves drm engine initialization out of the load node and
into its own drm node. This allows the load path to be interrupted
between initializing drm and initializing the rest of the player
components.

Issue #816
Issue #997

Change-Id: I2e5dbbe3e2bd1fd93fbde211cbbaa0fdd01a1632

shaka-bot pushed a commit that referenced this issue Mar 12, 2019

Correct oversights in the player's load graph
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

shaka-bot pushed a commit that referenced this issue Mar 12, 2019

Refine Load Graph Interruption Tests
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

shaka-bot pushed a commit that referenced this issue Mar 19, 2019

Move "loading" event
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

shaka-bot pushed a commit that referenced this issue Mar 20, 2019

Create Playhead Interface
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

shaka-bot pushed a commit that referenced this issue Mar 21, 2019

Surface "idling" event from walker
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

shaka-bot pushed a commit that referenced this issue Mar 21, 2019

Return to Attach After Error
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
@dmunozpolo

This comment has been minimized.

Copy link

commented Mar 24, 2019

Hi @vaage

I am interested in having #382 fixed. It seems it is blocked by this topic, #816. Do you have an updated ETA for having this #816 fixed?

Thanks for you help.

Regards,
David.

@vaage

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

Hello @dmunozpolo thank you for checking on the progress of #816. Currently we have src= working on an internal branch and it is making its way through code review. The part that is preventing us from finishing the work is vetting all the public methods on shaka.Player.

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 src=. To ensure these methods behave as we expect, we need to define src= versions of them. This is the focus on my work now.

Because of src=, we've had to expand our test coverage, and while we have tests to cover much of what we need, they are still not ideal (e.g. requiring actual network requests for assets). So even after we get the above work finished, our tests will not be done.

Once the public-method work is done, the src= work will be submitted into master. Once we refine the tests, @joeyparrish will re-evaluate what is left for the 2.5 release.

shaka-bot pushed a commit that referenced this issue Mar 29, 2019

Have MediaSourceEngine fill in buffering info
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

shaka-bot pushed a commit that referenced this issue Apr 1, 2019

Create src= node
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

shaka-bot pushed a commit that referenced this issue Apr 1, 2019

Add Load Modes
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

shaka-bot pushed a commit that referenced this issue Apr 2, 2019

Fix Src= Build Issue after Bad Merge
Two changes around src= went in around the same time and they merged
poorly, resulting in a broken build. This change corrects that.

Issue #816
Issue #997

Change-Id: I1c84e56c06de0b80c11933144b453907f3e75786

shaka-bot pushed a commit that referenced this issue Apr 10, 2019

Fix Buffering Failure with src=
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

shaka-bot pushed a commit that referenced this issue Apr 10, 2019

Set src= Load Mode
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

shaka-bot pushed a commit that referenced this issue Apr 11, 2019

Move Trick Play Out of Video Wrapper
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

shaka-bot pushed a commit that referenced this issue Apr 11, 2019

Define Player Api src= Tests
Define an initial set of tests to ensure that the public player api
behaves correctly when the player has loaded content with src=.

Issue #816
Issue #997

Change-Id: Ie40bc926d1e56d37318f0ba7711903cdf8e6aa3e
@avelad

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

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 ?

@vaage

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

@avelad, @joeyparrish will need to answer that question. I am no longer with Shaka Player.

@joeyparrish

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

@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.

@joeyparrish joeyparrish self-assigned this Apr 11, 2019

shaka-bot pushed a commit that referenced this issue Apr 16, 2019

Fix src= tests
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

@shaka-bot shaka-bot closed this in 133f161 Apr 16, 2019

Media & streaming refactor automation moved this from Actionable to Done Apr 16, 2019

shaka-bot pushed a commit that referenced this issue Apr 30, 2019

Consider src= fully loaded only after first frame
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

shaka-bot pushed a commit that referenced this issue May 2, 2019

Fix src= test expectations for Edge & Safari
The test expecatations were not flexible enough to cover differences
in browser implementations.

Issue #816
Issue #997

Change-Id: I918c4d08f5b195046834ee534e84f4b8787487d5

@shaka-bot shaka-bot added the archived label Jun 15, 2019

@google google locked and limited conversation to collaborators Jun 15, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.