On 9/22/23, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Fri, Sep 22, 2023 at 11:30:37PM +0200, Paul B Mahol wrote: >> On 9/22/23, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> > On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote: >> >> On 9/22/23, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> >> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote: >> >> >> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> >> >> --- >> >> >> libavcodec/rtv1.c | 6 +++++- >> >> >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> > >> >> > will apply 1-3 of this patchset >> >> >> >> Are you sure this does not break decoding? >> > >> > Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum >> > check looks correct. >> > There are 2 end of bitstream checks for early exit but they look like >> > error handling not some normal exit as they leave the frame >> > uninitialized >> > >> >> FFmpeg default initialization code for AVFrame's buffers does it >> twice, so they are always zeroed or previous values of previous >> buffers in pool. > > its rare that correct frame decoding depends on internal AVFrame buffer > ordering >
Users are supposed to use error checking. And I think decoder returns error on missing frame data. When we lost interest in preserving all decoded frame pixels as much as possible? > >> >> > Do you have some files so i can double check this is not breaking >> > anything >> >> Search trac tickets. > > thanks, found a zip with 2 video files > ill check it > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "I am not trying to be anyone's saviour, I'm trying to think about the > future and not be sad" - Elon Musk > > _______________________________________________ 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".
