Quoting Marton Balint (2020-05-10 19:45:04)
> 
> 
> On Sun, 10 May 2020, Anton Khirnov wrote:
> 
> > Quoting Andreas Rheinhardt (2020-05-08 00:55:00)
> >> This commit fixes two recent regressions both of which are about using
> >> pkt->stream_index as index in an AVFormatContext's streams array before
> >> actually comparing the value with the count of streams in said array.
> >> 96e5e6abb9851d7a26ba21703955d5826ac857c0 did this in
> >> prepare_input_packet() and 64063512227c4c87a7d16a1076481dc6baf19841 did
> >> likewise in write_packets_common().
> >> 
> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com>
> >> ---
> >> The same error in the same file applied on the same day by two different
> >> people. How unlikely.
> >
> > How is it a regression? Isn't it rather invalid API use?
> 
> Fun fact: 7b03b65bf0d02519c86750d2da33f413e11cf0c6
> 
> Yes, it is kind of invalid API use, but since the check is already there, 
> we should make it actually worthwile.

lol

I agree that checking for it is a good idea, obviously, but I wouldn't
call it a regression.

> 
> >
> > Not that I object to having a check. But then why is check_packet()
> > called so deep and not immediately on entry to the muxer?
> 
> I guess it is not that deep, but recent factorization efforts hidden it a 
> bit.

You can see in my original commit it is the very first thing done after
entering the muxer. Right now it's several function calls deep.

-- 
Anton Khirnov
_______________________________________________
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".

Reply via email to