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

[Steven Liu]

2017-04-11 23:29 GMT+08:00 Andy Furniss <adf.lists at gmail.com>:

> 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.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Thanks Andy, let me try to fix it. i'm moving house these days, maybe some
days later update a new patch.