Steven Liu wrote:
2017-04-11 22:27 GMT+08:00 Andy Furniss <adf.li...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
