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

[Thorsten Jordan]

Baptiste Coudurier schrieb:
> Thorsten Jordan wrote:
>> 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.
> 
> ?? annexbtomp4 filter will search for starcodes...
yes but what if a NALU would be given in two parts with two subsequent
calls to avfilter_filter() ? That means data is streamed to filter() so
some NALU got split. The length of that NAL could be computed only when
we got the second filter() call. If we would solve that by buffering the
last NALU of a filter() call, we never can give the last buffered NAL
out on end of the stream.
However as it seems there are always full frames given to the filter()
function, which consist of complete NALUs always.

-- 
Regards, Thorsten