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 <jamr...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel