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

Michael Niedermayer michaelni
Fri Apr 25 17:27:43 CEST 2008

On Fri, Apr 25, 2008 at 08:48:35AM +0200, Thorsten Jordan wrote:
> 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.

well this is a huge exageration, there are not many split functions and
most are just 3 lines of code or so.

> 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.

It would b nice if the same API as the bitstream filters could be used.

> > 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

You misunderstand, this is not an alterantive. Its a unrelated cleanup
that is moving the code currently in the mp4 muxer into a bitstream filter.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080425/6565df83/attachment.pgp>

More information about the ffmpeg-devel mailing list