-
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
Transmux TS to fMP4 #887
Comments
https://github.com/videojs/mux.js is another library you could look at (I may be biased). |
@forbesjo, thank you for the suggestion. We will look into it! |
We have decided to use https://github.com/videojs/mux.js as the basis of our transmuxing feature. Here's a rough outline: Today
With transmuxing
If the application developer is not interested in transmuxing, no changes are required. If the application developer wants TS transmuxing, they merely have to upgrade Shaka Player to v2.3+ and load mux.js in parallel with Shaka. @forbesjo, how does mux.js manage API changes? If we ask our users to load mux.js, and we have tested with v4.1.5, will there be any breaking API changes in v4.2? Should we advise them only to use specific versions? What's the best way to stay informed of important changes to mux.js? |
mux.js follows semver so there will only be breaking changes in major versions. I would only advise users to use specific versions if they prefer certainty or reproducible builds over automatic updates. Right now updates aren't communicated beyond watching the repo but we plan on announcing updates in the #announcements channel in http://slack.videojs.com/ as well as posting change log notes to Github releases. |
@forbesjo, thanks! |
Users can also be directed to the video.js #playback channel for questions/information that doesn't fit in a Github issue. |
mux.js is probably a really good choice! great to hear that, looking forward to TS-based HLS support in Shaka! Do you see the need to run the transmuxing inside a worker script? This is how it was done in Hls.js and also in videojs-contrib-hls. So in my experience transmuxing, parsing the TS, and building/writing the fMp4 is rather effortless task (it's not like decoding anything or so, "just" read/writing container data). We have been doing this for audio streams, but of course with video it will generally be a higher data throughput. But it's probably better to not do this on the UI thread still :) I have been building a library for transmuxing, that currently supports output of MP4, but the usecase it was tested with was only MP3 (for HLS with MP3 elementary streams playback on Firefox, that only accepts MP3 when contained as fMP4, Chrome does support Mp3 "elementary" btw). It is a general pipelining framework with parsers, demuxers, muxers, etc.. It's a bit GStreamer inspired :) See: https://github.com/tchakabam/multimedia.js There is also another great library for reading & building MP4 data: https://github.com/madebyhiro/codem-isoboxer and here is a node-based Transport-Stream parser which even seems to be DVB-T compliant: https://github.com/mkrufky/node-dvbtee |
@joeyparrish If you are still looking for Hls.js know-how, I have been contributing a bit to it :) So you can shoot me your questions if you have any. |
Because Safari's support for TS via MSE is broken, reject all TS content in Safari. Transmuxing (#887) will compensate. https://bugs.webkit.org/show_bug.cgi?id=165342 Closes #743 Change-Id: Iff8a6a7c159e48a4f388d99396915752e649c6ac
Just a quick status update: we are making good progress on transmuxing with mux.js, and we hope to publish something soon. |
Because Safari's support for TS via MSE is broken, reject all TS content in Safari. Transmuxing (#887) will compensate. https://bugs.webkit.org/show_bug.cgi?id=165342 Closes #743 Change-Id: Iff8a6a7c159e48a4f388d99396915752e649c6ac
Supporting Transport Stream by transmuxing it to MP4, with mux.js library. Issue #887 Change-Id: I70361bb364721fc5e72cba7d0fabc311ce0ba8b5
I just tested the functionality in the master branch, but it's not working with all TS playlists. Tested in: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36" Samples:
|
It seems that https://content.jwplatform.com/manifests/vM7nH0Kl.m3u8 contains raw AAC (no container), which we don't support in our parser yet. I filed #1083 to improve this. The other stream (http://vod.izzitv.mx/Content/HLS/VOD/IRIS_DLVY5849991423000097/ATEME_HLS_P_DLVY5849991423000097.m3u8) fails with an HTTP 403 error, even with mixed content restriccions disabled. |
Sorry, I forget the geoblocking... You need use a query string parameter in master and media playlist (?vu=12345) http://vod.izzitv.mx/Content/HLS/VOD/IRIS_DLVY5849991423000097/ATEME_HLS_P_DLVY5849991423000097.m3u8?vu=12345 Master playlist (http://vod.izzitv.mx/Content/HLS/VOD/IRIS_DLVY5849991423000097/ATEME_HLS_P_DLVY5849991423000097.m3u8?vu=12345)
Media playlist (http://vod.izzitv.mx/Content/HLS/VOD/IRIS_DLVY5849991423000097/ATEME_HLS_P_DLVY5849991423000097_video_4.3Mbps.m3u8?vu=12345)
I think that the problem is related to mime type or content extension with query params. |
Yes, that's probably the issue. We aren't doing proper URI parsing in the HLS parser when we use extensions to guess at MIME types. Shouldn't be hard to fix, but it's a shame HLS can't just provide MIME types in the first place. |
Filed #1085 to track the extension parsing issue. |
Hello! Could you tell if you already support TS-based HLS? The issue is closed but your FAQ still suggests to subscribe to it: https://github.com/google/shaka-player/blob/master/docs/tutorials/faq.md |
Yes, we do, in the master branch and in the upcoming v2.3 release. If the browser does not support TS, your application will need to load mux.js for transmuxing. If mux.js is in the environment, Shaka Player will detect that and use it to transmux TS content automatically. No other integration work is required. And you are right that our FAQ is out-of-date. Thank you for bringing that to our attention. I have filed #1183 to track updating the docs. |
On platforms that support Transport Stream via MediaSource, we are able to play TS content. Currently, that is just Edge and Chromecast. (Safari is not working due to #743.)
This is consistently surprising to developers, and not everyone can transmux their content to fMP4 ahead of time. Developers expect that working content will work everywhere.
To meet this expectation, we should start offering transmuxing of TS content in the browser. We should optimize this, if needed, to reduce impact on CPU and battery life. If the process is too expensive, we should warn developers and provide guidance on transmuxing content en masse on the server, to reduce the burden on clients.
We should examine the transmuxing implementation of hls.js (which is also Apache-licensed) before we begin work. There may be a way to collaborate with hls.js to reuse their transmuxer rather than build a new one.
The text was updated successfully, but these errors were encountered: