[FFmpeg-devel] [PATCH] split mpegvideo.c

Michael Niedermayer michaelni
Mon Jul 2 17:40:36 CEST 2007


Hi

On Mon, Jul 02, 2007 at 05:30:34PM +0200, Benoit Fouet wrote:
> Michael Niedermayer wrote:
> > Hi
> >
> > On Mon, Jul 02, 2007 at 12:18:21PM +0200, Benoit Fouet wrote:
> >   
> >> Hi,
> >>
> >> Michael Niedermayer wrote:
> >>     
> >>> Hi
> >>>
> >>> On Thu, Jun 28, 2007 at 01:38:23PM +0200, Benoit Fouet wrote:
> >>>   
> >>>       
> >>>> Benoit Fouet wrote:
> >>>>     
> >>>>         
> >>>>> M?ns Rullg?rd wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> Benoit Fouet <benoit.fouet at purplelabs.com> writes:
> >>>>>>   
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> here is a first attempt to $subj
> >>>>>>>
> >>>>>>> what is done:
> >>>>>>>  - remove everything flagged under CONFIG_ENCODERS from mpegvideo.c
> >>>>>>> (apart from the DCT_common_init() part)
> >>>>>>>  - put those parts in mpegvideo_enc.c
> >>>>>>>     
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>> Does this in any way affect performance?  I can imagine calls from
> >>>>>> encoding functions to common functions no longer being inlined due to
> >>>>>> the split.  Then again, there might not be any relevant such calls.
> >>>>>>
> >>>>>>   
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> i didn't check performances yet. but this is a problem we might have, i
> >>>>> guess...
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> anyway, what would be the proper way to do such a benchmark.
> >>>> As it is something i never did in ffmpeg, any pointer on how to do it
> >>>> would be very welcome !
> >>>>     
> >>>>         
> >>> nm anychangedobject.o
> >>>
> >>> and checking if new function names appear (simply cleaning the output of nm
> >>> with sed and diffing them works well), if so they are no longer inlined
> >>> (this will tell us what needs benchmarking)
> >>>
> >>>   
> >>>       
> >> ok, i did that.
> >> it seems the only differences are the following ones:
> >>  - copy_picture is now defined
> >>  - MPV_common_defaults too
> >>
> >> the two of them were implicitely inlined by the compiler actually.
> >> i think copy_picture could be moved to the common header file to make it
> >> inlined again, but this should not be necessary for
> >> MPV_commmon_defaults, which is only called at initialization of codec.
> >>     
> >
> > neither of the 2 should be inlined, so theres no need to move them into
> > header
> >
> > [...]
> >   
> ok
> 
> does that mean i have to benchmark calls to copy_picture or that the
> patch can be applied ?

no sense in benchmarking copy_picture()
though a "time ffmpeg -i foobar barfoo" cant hurt

if theres no slowdown then apply it

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070702/c104d2e5/attachment.pgp>



More information about the ffmpeg-devel mailing list