-
Notifications
You must be signed in to change notification settings - Fork 516
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
Order of variants in HLS master playlist - can this be customized? #560
Comments
@fuzing I am glad that you like Shaka Packager! Unfortunately the order cannot be customized right now. And yes, it is something we need to support in Shaka Packager. Thanks for raising the issue! I'll add it to our next milestone. |
Awesome - thank you!
…On Mon, Feb 25, 2019 at 10:02 AM Kongqun Yang ***@***.***> wrote:
@fuzing <https://github.com/fuzing> I am glad that you like Shaka
Packager!
Unfortunately the order cannot be customized right now. And yes, it is
something we need to support in Shaka Packager. I'll add it to our next
milestone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#560 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALHBFUff0o_NisTiyPgCwhHEJYNqLAmDks5vRBcVgaJpZM4bNOGQ>
.
|
Hi I am also having trouble with EXT-X-STREAM-INF variant order. My command:
Playlist output:
Manual order or order by bitrate would be great because native iOS player seems to have problem with random variant order. |
Sorry for the delay - ordering by bitrate won't work for us, as we want to be able to select a middle of the road bitrate as the first stream in the playlist - this is the stream that the IOS player will start playing before adapting (in the case of playback over wifi at least, but read on for cellular). Apple's HLS requirements demand (in 9.18) a 192 Kb/s stream for video played over cellular. They also suggest (in 1.32a) that the default bitrate for wifi should be a 2mb/s stream, and that this should appear first in the playlist - they don't demand this, but they have good reason for suggesting it, i.e. it's a compromise "intermediate" bitrate to start playing before determining actual data-rate prior to adapting. They do also suggest a default bitrate of 730kb/s for cellular connections (1.32b), but our tests of the IOS player seem to suggest that it will initially target the adaptation with bitrate around the 730kb/s mark, no matter where it appears in the playlist when it detects that it's playing over cellular (vs. wifi where it will select the first). For the case of WIFI, starting with the lowest bitrate stream (i.e. 192kb/s) for the first segment when a user has a 1gb/s connection translates to a very poor user experience (we use Apple's recommended 6 second segment duration, per 7.5 of the spec, meaning the user will get 6 seconds of 192kb/s before transitioning to our 3mb/s 1080 stream, which is nasty). Hence, our preference would be to see some way of ordering the variants as opposed to sorting by bandwidth (order of input would be fine for us but we'd defer to any other suggestions). We've tested nixon197's assertion that random ordering of the playlists causes problems with the IOS player and we cannot reproduce in recent versions of IOS across a number of devices (nixon197, can you expound more on the problems you're having when the playlist ordering is randomized). Hope this makes sense! |
@fuzing Thanks for the detail explanations. That is very helpful. We'll see if we can simply order the variants according to the input order (stream descriptor order) then. |
No worries @kqyang - thanks for all your hard work on this. Ordering per the order of our input will work great! |
An option to order by bitrate would be very helpful too. |
The random order of audio tracks is for me especially problematic when I have multiple tracks with the same language (but different versions such as different mixes or channel configurations). If I understood correctly, it is not reliably possible to generate a manifest where the default track is the one I want it to be (i.e. the first which I pass as input with the defined default language):
|
@kqyang I wish I had the skills to implement these changes, but I'm afraid I simply can't. Hope this issue is important enough for others to give it a try! |
Hey @kqyang , |
No, we do not have resources to work on it ourselves right now. If anyone wants to help on this issue, it will be really appreciated! |
This is also an important feature that I am waiting for, thanks again for your work :) |
For information: I started a branch for this (https://github.com/xavierlaffargue/shaka-packager/tree/hls-order-track) Note: I started from the cosmin:cmake-all-the-things branch which should be merged into shaka-packager:cmake. |
@xavierlaffargue is your branch usable? I'm happy to spend some time testing it. I'm running into problems right now because the order is effectively random. Not only does usability suffer, but so does debuggability because my inputs do not equal my outputs. How does your branch work? Does it preserve the input order (my personal preference for default behavior)? |
Would it be feasible to preserve the input order? I would find that most intuitive, and it would be a benefit that existing users get for free without changing commands. You could keep the order_number field internally, but default it to the index from the input arguments. |
@xavierlaffargue how do I build your branch? I tried the following commands but they are failing:
If it makes a difference I'm using Ubuntu 22.04 and trying to follow the build directions from this pull request: #1270 |
I figured out the error I posted in the previous comment. I'm running these build commands instead:
I'm getting much father, but the build is failing with the following:
|
For anybody else following up after me, I'm able to get just the packager binary built (skipping other build artifacts such as the broken tests) on @xavierlaffargue's branch with the following commands:
|
On a side note |
@xavierlaffargue I have a video that is not respecting the order_number flag when I try it: Here is the command I'm running:
And here's an example output m3u8:
Here is the console output:
I've run this multiple times and the order is still completely random. |
@joeyparrish yeah we have been working on something like this internally on shaka packager fork and got it working. If you would like to take a look , I or my teammate can open a PR for that. However our stuff is not on the cmake branch since we started working on this quite a while back. But we can open a PR and take it from there or rebase against a certain branch you prefer. |
Indeed I ordering only video!, I'm adding the audio :) |
@bmurphy1976 can you pull the last commit and retry? |
Yes, good idea, I will preserve the input order :) |
@xavierlaffargue I pulled, but I'm getting a new set of build errors now:
|
@bmurphy1976 Sorry, fixed, now it will be ok :) |
@xavierlaffargue I was able to build the tool but it's failing with this error now:
I did a full clean checkout just to be sure I didn't have something lingering from a previous build, no luck.
|
Ho yes sorry, I deleted this field :D Now I preserve the input order! like propose @joeyparrish |
Ah, I understand! I just ran a quick test and it looks like it is working. I'm going to be bulk testing a lot of videos this week, I'll test it out and if I run into anything I'll let you know. |
I ran a bunch of tests, but I had to switch back to the release build. The ordering code appears to be working as expected, but I'm running into a bunch of other issues which I think are related to the underlying branch not being fully baked yet. I have other priorities right now so I can't spend any more time on it, but I'll revisit it in the future. I have a lot of messy post-shaka-processing code to keep the track orders in check that I would love to remove some day. |
Fixed shaka-project#560 with suggested implementation: shaka-project#560 (comment)
Hi, #1280 is my implementation of this issue for reference, based on the @kqyang's suggestion at #560 (comment) |
Fixed shaka-project#560 with suggested implementation: shaka-project#560 (comment)
This will force the muxer to order streams in the order given on the command-line. Closes #560 Closes #1280 Closes #1313 --------- Co-authored-by: Joey Parrish <[email protected]> Co-authored-by: Cosmin Stejerean <[email protected]>
The Apple HLS authoring spec says:
1.32. The default video variant(s) SHOULD be the 2000 kb/s (average bit rate) variant. (Defaults are the first variant listed in the master playlist within a group of variants having compatible audio.)
I'm trying to set the order for the EXT-X-STREAM-INF's in the master.m3u8 so that my 2000 kb/s appears first but no matter what I try I cannot manipulate it so it appears in the top spot. I've tried reordering my inputs, different naming (noting the std::sort()) in packager.cc, and various other ploys to try to trick shaka packager into ordering things the way I want - but to no avail. Shaka packager always puts my lowest resolution and bandwidth stream first in the hls master playlist.
I'm probably missing something obvious but could someone point me in the right direction as to how I can manipulate the ordering.
Thank you for your help (and amazing product!).
The text was updated successfully, but these errors were encountered: