Hi, On 03.11.2016 11:18, Anssi Hannula wrote: > Andreas Cadhalpun kirjoitti 2016-11-03 02:12: >> This fixes probing dts/eac3/mp2 in hls. >> >> The problem was introduced in commit >> 04964ac311abe670fb3b60290a330f2067544b13. >> >> Also update the fate reference for the fate-segment-mp4-to-ts test. > > Thanks. > > Can you point me to some example streams with this issue? (or how to generate > one)
ffmpeg creates these, as I've mentioned in [1], e.g.: $ ./ffmpeg -f lavfi -i sine=d=0.1 -strict -2 -c:a dca -f hls dca.hls -y &> /dev/null $ ./ffmpeg -f lavfi -i sine=d=0.1 -strict -2 -c:a eac3 -f hls eac3.hls -y &> /dev/null $ ./ffmpeg -f lavfi -i sine=d=0.1 -strict -2 -c:a mp2 -f hls mp2.hls -y &> /dev/null Then run ffprobe on the created hls files to see the problems. > Unfortunately calling avformat_find_stream_info() for sub-mpegts streams is > quite > bandwidth-heavy (especially if there are many stream variants and/or > alternative > renditions, and especially now that we no longer clear mpegts > AVFMTCTX_NOHEADER > flag so that streams like #4930 work) so I tried to avoid that. > It is better than doing nothing, though, if we can't find an alternative > solution > (better slow than not working). > > I'd first like to try to understand what is happening, though. OK. A better solution is always welcome. Best regards, Andreas 1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201870.html _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel