[Mplayer-cvslog] CVS: main/libmpcodecs vd_ffmpeg.c,1.129,1.130

[Roberto Togni]

On 2004.08.31 00:43, Michael Niedermayer wrote:
> Hi
> 
> On Sunday 29 August 2004 15:52, Roberto Togni CVS wrote:
> > CVS change done by Roberto Togni CVS
> >
> > Update of /cvsroot/mplayer/main/libmpcodecs
> > In directory mail:/var2/tmp/cvs-serv30754/libmpcodecs
> >
> > Modified Files:
> > 	vd_ffmpeg.c
> > Log Message:
> > AVC (fourcc avc1) in mp4 support
> why do u malloc+memcpy+free everything constantly ?!
To keep thing simple. Since i had to add the sync in front of the data  
before passing it to lavc, i had to copy the packet anyway. Else you  
have to scan all the packets, compute the total lenght, and copy data  
only once; surely that will be more efficient. Also with this second  
method buffer from the previous can probably be reused, if new data  
doesn't require a bigger buffer, to limit the number of free and  
malloc.

> IMHO vd_ffmpeg.c shouldnt do any codec specific format translation,
> especially
> not if it requires the whole bitstream to be copied around, instead
vd_ffmpeg was the only pratical place to do it (the only alternative  
being the mov demuxer), and that was the way vlc did it (i took  
inspiration for this code from their packetizer).

> h264.c
> should be changed to support this directly
I'm doing it now. i have two choices:
1- change decode_nal_units to accept nals with length instead of sync  
(looking at the code it should be possible); the avcC parsing will be  
in decode_frame or decoder_init (now extradata is processed in  
decode_frame)
2- do the "add sync" stuff like i do now in MPlayer (with optimizations  
explained above).

i'll go for 1, with 2 as a fallback if 1 get too messy.

i'll send patch to ff-dev as soon as i got it working.

Ciao,
 Roberto