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

[Thorsten Jordan]

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:
>>>> [...]
>>> Which brings up the question if there should be never SEI units in
>>> global headers. I found nothing near the SPS/PPS description that
>>> mentions SEI, so they are not used as header extension?
> 
> IIRC libx264 wrapper puts SEI in extradata.
yes it does, but the SEI it puts is not needed for decoding as it seems

>> The global headers (extradata) of MP4 should contain SPS and PPS only,
>> but it can contain multiple SPS/PPS afaics.
>>
>> This means the bitstream filter has to scan the whole h264 elementary
>> stream, rip out every SPS+PPS inside, and collect them in one global
>> block. For every SPS/PPS in the stream it must compare it to the last
>> found ones to avoid storing the same SPS/PPS twice. I suppose there is a
>> limit on the number of SPS/PPS, as they need to be given to the decoder
>> all at once on decoding - but if there are more than one SPS/PPS each
>> the reverse filter mp4toannexb wouldn't work...
>>
>> This means the extradata (global headers) are not ready before the full
>> stream has been filtered. I don't know if that is a problem for the mp4
>> muxer.
> 
> 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...

-- 
Regards, Thorsten