Low latency dash support #3
Conversation
…ger LL-DASH streaming within Packager
| rebufferingGoal: 0.01, | ||
| } | ||
| }); | ||
| await player.load(manifestUrl); |
There was a problem hiding this comment.
This await is never resolved causing the test to fail :(
There was a problem hiding this comment.
You can debug in the http server in the python script that runs the tests to see what requests the player is making. That might give us a clue as to what's wrong.
There was a problem hiding this comment.
Thank you for this insight! I will check it out.
There was a problem hiding this comment.
Ah, I figured out the issue! The run_end_to_end_tests.py process will sleep until the DASH or HLS stream is ready for playout. The readiness for the DASH case is determined by the function dashStreamsReady(). This function uses regex to check the MPD for the presence of a segment tag <S>, which indicates that a segment is available. LL-DASH MPDs do not contain <S>, so the LL-DASH stream was never able to trigger the ready state.
To fix this, I added a check for the availableTimeOffset attribute in the LL-DASH case. This attribute is equal to the segment duration minus the chunk duration. The availableTimeOffset value indicates to the player the earliest time that a segment can be played out, since, in the LL-DASH case, the segment can be downloaded and played before it is fully written.
|
I'm going to be out of town soon. Will it be too late to help when I return on the 23rd? |
Have a wonderful holiday! When will you be leaving? |
| rebufferingGoal: 0.01, | ||
| } | ||
| }); | ||
| await player.load(manifestUrl); |
| 'is_low_latency_dash': true, | ||
| 'utc_timings': [ | ||
| { | ||
| 'scheme_id_uri':'urn:mpeg:dash:utc:http-xsdate:2014', |
There was a problem hiding this comment.
I think I might prefer replacing the scheme ID with a more readable enum, in the name of making the config files easier to write, but I don't think it's worth holding up this PR. Something to consider for later, though, if you have time.
I think we would restrict that enum to values equivalent to the "xsdate" and "head" schemes.
There was a problem hiding this comment.
Ohhh, I like the idea of using an enum - I'll make sure to add it later.
The UTCTiming information is funky to format and very easy to mess up. The standard lists the following as the possible options.
https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html
There was a problem hiding this comment.
True, but we wouldn't have to offer all of those. I think xsdate and head are the simplest and easiest to explain in docs, and should cover most people's needs. For Streamer, I would tend to err on the side of "easy" and add power later if people request it.
streamer/pipeline_configuration.py
Outdated
| @@ -309,6 +319,19 @@ class PipelineConfig(configuration.Base): | |||
| default=EncryptionConfig({})).cast() | |||
| """Encryption settings.""" | |||
|
|
|||
| is_low_latency_dash = configuration.Field(bool, default=False).cast() | |||
There was a problem hiding this comment.
design nit: I tend to think that "is" belongs on boolean getters, to see the state of a thing. For a declaration like this to instruct the pipeline to do something, I would call it something like "low_latency_mode". I would also make it apply to both DASH & HLS.
There was a problem hiding this comment.
Good point, I totally agree. I'll change it to "low_latency_dash_mode" for now since my Packager fork supports only LL-DASH. HOWEVER! :D I was tinkering this weekend and made promising progress for LL-HLS support! 🥳 I'll finish that up, and once LL-HLS is working, I'll comb over the naming/comments/logic to make sure everything is changed to general "low latency" rather than LL-DASH specific.
|
Update: The failing test that was holding up this PR has been fixed! See here: #3 (comment) Other style / formating / wording fixes were applied. The following TODOs were also added:
|
Overview