[FFmpeg-devel] h264_annexbtomp4 filter ideas, was: Collection of patches

[Thorsten Jordan]

Thorsten Jordan schrieb:
> Baptiste Coudurier schrieb:
>> Hi,
>>
>> Thorsten Jordan wrote:
>>> Thorsten Jordan schrieb:
>>>> Michael Niedermayer schrieb:
>>>>> On Wed, Apr 23, 2008 at 09:15:40AM +0200, Thorsten Jordan wrote:
>>>>> [...]
>> No, mp4 muxer use a "trailer" and therefore computes atom when all
>> frames have been muxed. However, this might be a problem when stream
>> copying and using fragmented muxing, but we will see when somebody will
>> try to implement it.
> yes i saw this in the code too, so it would work, but the issue remains
> when multiple SPS/PPS are in the stream that are not the same. This
> could be ignored for a first version though...

Thinking about possible implementation, there is a problem if the data
given to the filter() function would not start with a start code. Since
in MP4 format each NALU must have its length stored before it, we can
compute the length only, if every data chunk given to filter() consists
of complete NALUs. This should be the case though.

So the filter context would hold memory for SPS and PPS, that is filled
while parsing. SPS/PPS from stream data is ripped out and the first of
each sort are stored in the filter context. Beside that every startcode
is replaced by the length value (32bit). On filter_close() the global
extradata is compiled by writing the 6 lead bytes, then SPS+PPS like in
ff_isom_write_avcc(). That should do it...

Such a filter would need code like libavformat/avc.c to find startcodes
and parse NALUs, but it would be stored in libavcodec/. To avoid code
duplication, some functions need to be moved thus. Here someone with
more SVN knowledge than me has to take some action :/

-- 
Regards, Thorsten