[FFmpeg-devel] h264_annexbtomp4 filter ideas, was: Collection of patches
Fri Apr 25 17:23:33 CEST 2008
On Fri, Apr 25, 2008 at 02:33:28PM +0200, Benoit Fouet wrote:
> 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, 184.108.40.206. 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.
Yes, ive also (yesterday?) first thought that there are global SEIs but
after a quick look over the SEIs in H.264 none looked global. User data
should in principle be global in some cases but i dont see how that
could be decided in a parser/(de)muxer. Its ironic that with all the
complexity in H.264 such quite important things like to what user data
applies are not clear (that is sequence, gop, frame, slice, ...)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel