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

[Thorsten Jordan]

Michael Niedermayer schrieb:
> On Thu, Apr 24, 2008 at 04:26:15PM +0200, Baptiste Coudurier wrote:
>> Thorsten Jordan wrote:
>>> Michael Niedermayer schrieb:
>>>> wOn Thu, Apr 24, 2008 at 09:10:50AM +0200, 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?
>>>>> If one would solve this by writing a h264_annexbtomp4 bitstream filter,
>>>>> there are some issues:
>>>> The problem is the parser_split() API not h264_annexbtomp4. The world
>>>> is not just .mp4 and .h264, there are other containers needing the headers
>>>> seperated but in annex B format. 
>>>> Besides this the decoder needs the headers as well, they can occur later
>>>> then the first IDR frame the common code will read ahead until the split
>>>> function has filled them in. Your suggested hack of doing this in 
>>>> h264_annexbtomp4 will break decoding of such streams.
>>> ok, if I understood you correctly, you want no annexbtomp4 filter, but a
> 
> I want the split API to be fixed!
> So that the code in libavformat/utils.c:
[...]
> Still works
> 
> requirements for teh new API are:
> 1. it must not require a copy in cases where both "extradata" and the "frame"
>    are continous (this is currently working fine)
> 2. it must (with a memcpy somewhere) be able to extract the "extradata" even
>    if they are not continous (like in the H264s discussed in this thread)
>    (this does not work currently)
> 3. it must still be used automatically in the code quoted above, the code
>    of course can be change as needed ...

to fix that it isn't sufficient to just return a split offset as it is
know, split rather has to return a data block (pointer, length)
containing the headers, this can be done without memcpy if SPS+PPS are
contiguous in the stream. Additionally it has to rearrange the rest of
the data as well.
All uses of split and all split implementations would need to get
adapted, a major task.
I am not sure how do you want the split API to be in detail, how the
returning of the values should be done etc. If one wants to solve that,
the code using split needs to be changed as well.


> Simply writing a new bitstream filter is half of the work, you need to change
> the split api so it uses bitstream filters as well.
I don't know how you would want the split API to make use of bitstream
filters. Would that make sense? A better h264 splitting can be coded
without bsf usage though

>> I do want an annexbtomp4 which will be used instead of doing it in mp4
>> muxer though :>
> 
> I want this as well of course :)
that would be much easier to have than an improved splitter, yes

-- 
Regards, Thorsten