Allow playback of single files through src=

[jamescahall]

• 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]

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]

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]

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?

[joeyparrish]

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]

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.

[joeyparrish]

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]

Great to hear. Thank you.

Regards,

James Cahall

On Aug 28, 2017, at 11:50 PM, Joey Parrish notifications@github.com 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.

[shabab11]

we are using Opentext for DAM, can shaka player be used to retrieve or play files (video or audio) from opentext.

[vaage]

@shabab11 Since you comment does not relate to this issue, please file a separate issue.

[avelad]

@vaage , Do you have any updates about it?

[vaage]

@avelad Thank you for checking in. Your interest is appreciated.

We have designed a foundation that will allow us to support both src= and media source while improving how we handle the player's internal state. We built a proof of concept to test the idea and now are currently refining the key components and putting them through our normal code review process.

Our goal is to first rebuild the current loading system with our new foundation (resolving #1570) and then add the new load path (which should be much easier after the rebuild).

[dmunozpolo]

Hi,

Looking into #1570 it seems that you has been put that one into the backlog. Does it mean that you are now working in this ticket, #816?

Thanks.

[vaage]

Hello @dmunozpolo, as explained by @joeyparrish in issue #1570, it will be fixed by the work being done for #816. We moved #1570 to the backlog so that it would not be assigned dedicated resources.

[dmunozpolo]

Thanks. Do you have some tentative ETA to have #816 solved?

[vaage]

Work on #816 is my main priority, it is requiring large changes to how the player works and is requiring a lot of design, implementation, test, and review time. Before of that, it is hard to commit to a specific ETA.

The design and implementation of the underlying framework is finished. Right now it is going through review and testing. The integration between the framework and the player is where we are spending most of our time now. Some parts are in review while others are still being planned. The part that is holding up the integration is all the little details that we did not anticipate.

With the current velocity, we look to be wrapping this up end of Q1 start of Q2. As in the past, we thank everyone for their patience while we tackle this massive change.

[dmunozpolo]

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]

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.

[avelad]

Hi @vaage , I saw that the commit https://github.com/google/shaka-player/commit/040ecf69784610eec6b92c720ad27553bbc27c55#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]

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

[joeyparrish]

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