[FFmpeg-devel] [PATCH v14] avformat/dashdec: add dash demuxer base version

[Andy Furniss]

Steven Liu wrote:
> 2017-04-11 22:27 GMT+08:00 Andy Furniss <adf.lists at gmail.com>:
>
>> Steven Liu wrote:
>>
>>> ffmpeg need a dash demuxer for demux the dash formats base on
>>> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/mas
>>> ter/tmp/ffmpeg/patches/3.2.2/000001_add_dash_demux.patch
>>>
>>> TODO: 1. support multi bitrate dash
>>>
>>
>> v14 fixed: 1. fix bug: TLS connection was non-properly terminated
>> 2.
>>> fix bug: No trailing CRLF found in HTTP header
>>>
>>
>> Thanks.
>>
>> They are pretty much gone now, though I did see one TLS out of
>> about 3 hours running (3.84s chunks)
>>
>> Another user who is testing the same live stream saw eight TLS @
>> 0xae75700" referring to TLS packets of unexpected length. over a 3
>> hour run.
>>
>> One issue that I guess is not really a bug, but on a live stream
>> you really need to have your clock either spot on or slow.
>>
>> Ok, so maybe I should run ntpd "properly" - though not running it
>> does offer a workaround of setting clock back a bit (the stream mpd
>> below has a 10 minute buffer).
>>
>> This issue = even if set my clock with ntpd -q only a small amount
>> of too fast drift will lead to (after a couple of hours)
>>
>> [https @ 0x365e580] HTTP error 404 Not Found [dash @ 0x3657360]
>> Failed to open fragment of playlist 0
>>
>> ntpd -q showed I was 0.2 sec fast at that point - for the purpose
>> of testing just setting one sec fast will quickly start getting
>> 404s which are not retried, so break the stream.
>>
>> I notice there is a time url in the mpd - but even if that were
>> used initially vs clock, I still think drift would break things.
>>
>>
>> Here's the .mpd (same as link I gave before - pasting as I suspect
>> it's geo restricted).
>>
>
> The result is: you want to say: use the UTCTimeing's value, if it
> show in mpd file, do i misunderstand you?

Not really - though it seems to be what firefox does.

As things stand it could be bad in the sense that I couldn't work around
clock drift if that were used vs system time.

Whatever clock is used to calculate initial filename, maybe it would be
safer if ffmpeg either backed away a bit from getting the very latest
chunk, or if it could react to getting a 404 on a live stream in a way
that didn't loose the chunk - which in this case would likely be there a
fraction of a second later.