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

Benoit Fouet benoit.fouet
Fri Apr 25 14:33:28 CEST 2008


Thorsten Jordan wrote:
> Thorsten Jordan schrieb:
>> Loren Merritt schrieb:
>>> On Thu, 24 Apr 2008, Thorsten Jordan wrote:
>>>> Baptiste Coudurier schrieb:
>>>>> Thorsten Jordan wrote:
>>>>>> Thorsten Jordan schrieb:
> [...]
>> To fix all this, one needs to know:
>> * which SEI messages apply to the whole stream and only keep them (there
>> are 22 types of SEI messages according to spec - do you know which one
>> are global?)
>> * should they get stored after SPS/PPS in extra data or keep their
>> possibly mixed order
>> * How the split API could be modified to do all this (see my other mail
>> in reply to Michael)
> Ok, to summarize:
> - a h264_annexbtomp4 bitstream filter is desired.
> - parts of it are similar to what a h264-parser-split() function would do
> - it has to be researched which SEI messages may be stored in global headers

should there be any for MP4 ?
quoting ISO/IEC 14496-15:2004(E) 5.2.2 (by hand, as I only have a paper
SEI message NAL Units: All SEI message NAL units shall be contained in
the sample whose decoding time is that before which the SEI messages
come into effect instantaneously. The order of SEI messages within a
sample is as defined in ISO/IEC 14496-10, This means that the
SEI messages for a picture shall be included in the sample containing
that picture and that SEI messages pertaining to a sequence of pictures
shall be included in the sample containing the first picture of the
sequence to which the SEI message pertains.

and extradata (that's to say avc1 box) doesn't have room for SEI data.

> - it has to be researched how the order has to be for MP4: SPS, PPS and
> then any SEI or if SPS-SEI-PPS would be ok (obviously not, or the
> curretn mp4toannexb filter wouldn't work correct). Also
> SEI-SPS-PPS-order for global headers seems bad as well.
> - After this is know the splitter API has to be changed, for h264 it
> seems that it does no simple split anymore, but rather some extracting
> of stream parts as headers, leaving some blocks as rest that need to be
> made contigous.
> This may be some base for discussion or hint for anyone trying to write
> the parts.

Benoit Fouet
Purple Labs S.A.

More information about the ffmpeg-devel mailing list