[FFmpeg-devel] H264: mp4toannexb BSF and streaming

[Alexandre Ferrieux]

On 18/08/2010 14:47, Luca Abeni wrote:
> On 08/18/2010 02:42 PM, Alexandre Ferrieux wrote:
>> Hi,
>>
>> I'm in a (n admittedly suboptimal) situation where I'm receving a
>> 3GP/H264 video file in streaming (over a TCP socket, yes...).
>>
>> I would like to transcode it on-the-fly without waiting for the full 3GP
>> file to be received. I know that the 3GP format is not AT ALL designed
>> for that, and that even the first chunks will be invalid since the
>> 3GP-writer application does a seek() back to the beginning to fill the
>> header, etc. In short, 3GP is utterly non-streamable, but I need to do
>> something with it nevertheless :/
>>
>> What I've come up with so far, is to detect the beginning of the 'mdat'
>> chunk, which comes quickly in the stream, since it contains the bulk of
>> the bitstream (in AVC format).
>>
>> Now, I know that this AVC bitstream is not suitable for input by ffmpeg,
>> who is expecting annex B. I also know of the mp4toannexb BSF, but I can
>> see in its code that it is relying on extradata coming from the
>> container (in other chunks, coming at the end), which it will convert
>> and interleave between the annex B NALUs it will spit out.
>>
>> Hence, I conclude that mp4toannexb cannot work on a "pure" AVC bitstream
>> without extradata.
>
> As far as I know "AVC" always has extradata, and is not decodable without
> it (I think the extradata contain the SPS and PPS NALs, which are needed
> for decoding the H.264 stream). So, I think "pure AVC" without extradata
> does not exist (or is not usable).

OK, so the contents of the 'mdat' chunk of a 3GP/H264 are not in themselves sufficient for decoding, right ?
So this means that an application *building* a 3GP/H264 file must accumulate those extradata in memory and write them 
afterwards in a separate block... What's the rationale ?

-Alex