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

[Michael Niedermayer]

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:
        if(st->parser && st->parser->parser->split && !st->codec->extradata)
            break;
...
        if(st->parser && st->parser->parser->split && !st->codec->extradata){
            int i= st->parser->parser->split(st->codec, pkt->data, pkt->size);
            if(i){
                st->codec->extradata_size= i;
                st->codec->extradata= av_malloc(st->codec->extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
                memcpy(st->codec->extradata, pkt->data, st->codec->extradata_size);
                memset(st->codec->extradata + i, 0, FF_INPUT_BUFFER_PADDING_SIZE);
            }
        }

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

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 do want an annexbtomp4 which will be used instead of doing it in mp4
> muxer though :>

I want this as well of course :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20080424/54eeb886/attachment.pgp>