New patch implements the other half of James suggestion (stop parsing headers after data) and does not include the AVERROR_INVALIDDATA returns. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245502.html
On Sun, Jun 16, 2019 at 6:16 AM Reimar Döffinger <reimar.doeffin...@gmx.de> wrote: > On 14.06.2019, at 17:01, James Almer <jamr...@gmail.com> wrote: > > > On 6/14/2019 11:52 AM, Reimar Döffinger wrote: > >> > >> > >> On 14.06.2019, at 03:15, Chris Cunningham <chcunning...@chromium.org> > wrote: > >> > >>> Only "succeed" to read a header if the codec is valid. Otherwise > >>> return AVERROR_INVALIDDATA. > >> > >> That doesn't sound right to me, an unknown codec in (possibly) a single > stream is not an error. > >> I understood the discussion more to say the if it's an unknown codec, > we should not try to override valid codec configuration with a broken one. > > > > I did request this change, seeing that returning codec_id none in this > > scenario results in a crash at a later point due to conflicting > parameters. > > > > Do you suggest we should limit the change to only reject any duplicate > > header that may show up after the first one (and before the first data > > packet)? > > I don't know or understand the details, but I understood the suggestion as > "do not override a valid codec ID to NONE". > Either way, I would have suggested only skipping the affected stream - but > I admit I have not checked how far-reaching it is to return an error here. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
