2017-04-11 23:29 GMT+08:00 Andy Furniss <adf.li...@gmail.com>: > 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 >
Thanks Andy, let me try to fix it. i'm moving house these days, maybe some days later update a new patch. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
