[FFmpeg-devel] [PATCH] avcodec/internal: improve min_size documentation for ff_alloc_packet2()

[Michael Niedermayer]

On Mon, Aug 03, 2015 at 11:45:51PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 03, 2015 at 10:45:52PM +0200, wm4 wrote:
> > On Mon, 3 Aug 2015 17:33:15 -0300
> > James Almer <jamrial at gmail.com> wrote:
> > 
> > > On 03/08/15 5:05 PM, wm4 wrote:
> > > > - we'll probably see a flood of commits changing random encoders to
> > > >   this new function, for no reason (I'm looking forward to be proven
> > > >   wrong)
> > > 
> > > ff_alloc_packet() is marked as deprecated. I wouldn't find it odd at
> > > all if maintainers for different encoders make the switch if only to
> > > silence the warning.
> > > So if anyone does it, it most likely wont be "for no reason".
> > 
> > OK, but why was ff_alloc_packet2() introduced?
> 
> because it was faster in the tests i did back then.
> it certainly is not faster for all encoders, and id like to find out
> for which encoders its better and for which its not and adjust them
> accordingly.
> Or if it turns out not to be usefull for any encoders anymore then
> it could also be dropped, or rather we could drop min_size and
> the "static" buffer alloc code but leave the context for av_log

heres a test with jpegls:
time ./ffmpeg  -i matrixbench_mpeg2.mpg -vcodec jpegls -an -t 100 -strict -2  -f null -

ff_alloc_packet2()
real    0m8.267s
real    0m8.289s
real    0m8.270s
real    0m8.307s

vs.
ff_alloc_packet()
real    0m8.285s
real    0m8.289s
real    0m8.284s
real    0m8.313s

i did remember bigger differences

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150803/be0a168f/attachment.sig>