On Sun, 11 Jul 2010, Mohamed Naufal wrote: > On 11 July 2010 23:16, Mohamed Naufal <[email protected]> wrote: > > Hi > > > > Is there any way to force more data to be passed to decode_frame() of > > a decoder? G.723.1 has 4 frame types, each of size 24, 20, 10 and 1 > > byte. For a particular frame of type 0, only 16B of data is being > > passed to decode_frame() when obviously 24B are needed. Is using a > > parser the only solution? > > > > Also, the input is being read from a file. In the above case, EOF has > not been reached.
To add to the description of the issue, as I understood it from Mohamed on irc, he's reading the data from a file, using the raw demuxer, and since the frames have varying sizes, it may return an AVPacket containing an incomplete frame at the end. Generally, as far as I understand the issue, it can be solved in four ways: - Implement a demuxer that doesn't return packets with incomplete frames, thus more or less implementing a parser - Implement a proper parser and use it for properly splitting the packets returned from the raw demuxer into individual frames - Make the decoder store the incomplete frame internally, return no decoded data but no error code either, and prepend this data to the data fed in the next decode call. This matches the way the mpegaudio decoder worked earlier (more or less) - api-example.c relied on this behaviour earlier, when it read 4 KB from the source file at a time and fed the whole block to the decoder, which consumed all of it. - When the amount of raw data to decode drops below a certain threshold, refill the buffer - in the same way as we do in api-example.c now. I'm not sure how this design fits in ffmpeg.c, though. // Martin _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
