On Thu, Nov 30, 2017 at 12:19:10PM -0800, Dale Curtis wrote: > On Wed, Nov 29, 2017 at 5:58 PM, Michael Niedermayer <mich...@niedermayer.cc > > wrote: > > > > > AV_EF_EXPLODE appears to be a possibility, yes > > in general demuxers should try to extract as much as possible from a > > file and not give up if some broken packet is found > > > > I don't think this is a good idea; some of these errors seem fairly fatal > to the overall process. I think instead it's better to write off the sample > you have as being invalid. That said, I defer to your judgement here, so > I've produced both versions of the patch and leave it to your decision. > Chrome is now always using AV_EF_EXPLODE, so either works for our usage.
Ive taken a deeper look as this doesnt sound right I dont see anything really wrong with the file it seems what happens is that theres a data packet in one stream that preceeds the headers on the other streams, technically that data packet likely contains the video headers so its kind of a header too. The demuxer stops header parsing prematurly due to this. from there on it gets confused reading the same header twice while it determines the duration of the file which triggers the error There are a few differnt ways to fix this, iam not sure which is the simplest but i dont think the demuxer should fail in this case [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
