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

Attachment: signature.asc
Description: Digital signature

ffmpeg-devel mailing list

Reply via email to