[FFmpeg-devel] [PATCH 31/36] fftools/ffmpeg_dec: restructure audio/video decoding loop

[Anton Khirnov]

Quoting Michael Niedermayer (2023-05-17 22:04:09)
> On Wed, May 17, 2023 at 12:20:24PM +0200, Anton Khirnov wrote:
> > It currently emulates the long-removed
> > avcodec_decode_audio4/avcodec_decode_video2 APIs, which obfuscates the
> > actual decoding flow. Restructure the decoding calls so that they
> > naturally follow the new avcodec_send_packet()/avcodec_receive_frame()
> > design.
> > 
> > This is not only significantly easier to read, but also shorter.
> 
> with this:
> ./ffmpeg -y -threads:a 1 -i tickets/1208/702121h264-TTA.mkvtest82.mkv -bitexact -vn file1208.mp3
> 
> Both before and afterwards the output is empty and we see
> 
> Finishing stream without any data written to it.
> Output file is empty, nothing was encoded
> 
> after this patch while the output is not any better, now ffmpeg proclaims
> success with its return code
> 
> just to be sure i try reading the output
> 
> [mp3 @ 0x5635bab17900] Format mp3 detected only with low score of 1, misdetection possible!
> [mp3 @ 0x5635bab17900] Failed to read frame size: Could not seek to 1026.
> [in#0 @ 0x5635bab177c0] Error opening input: Invalid argument
> 
> I dont think that convertion was successfull

Your original failure has nothing to do with the output file being
empty, as that is not considered an error unless you specify
 -abort_on empty_output

Rather the failure comes from the default maximum error rate of 2/3
being exceeded, since no frame could be decoded successfully. The reason
was that the patch did not count avcodec_send_packet() errors into error
rate, I've fixed that in a new version. I've also updated the
-max_error_rate patch to make the situation clearer.

-- 
Anton Khirnov