[FFmpeg-soc] [QUESTION] Force more data to decode_frame()

[Martin Storsjö]

On Sun, 11 Jul 2010, Michael Niedermayer wrote:

> On Sun, Jul 11, 2010 at 09:53:07PM +0300, Martin Storsjö wrote:
> > On Sun, 11 Jul 2010, Mohamed Naufal wrote:
> > 
> > > On 11 July 2010 23:16, Mohamed Naufal <naufal11 at gmail.com> 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.
> 
> Think about remuxing (-acodec copy) and what you would store for each of
> the cases above in a container that does require a integral number of frames
> at a time

For that case, I guess only the two first suggestions are viable 
alternatives. For the parser solution suggestion, I'm not totally sure 
where one would signal that it is needed. Normally, this is set with a 
flag in the demuxer, right? Mohamed, is the file format you're reading 
this for any standard file format that one finds in practice when dealing 
with this codec, or is it only something that you're using for testing? If 
it's a full proper file format in itself, a demuxer probably is the better 
choice, otherwise a parser may be more useful when dealing with the same 
data format in other containers.

// Martin