On Fri, Sep 9, 2011 at 10:47 AM, Jason Garrett-Glaser <ja...@x264.com> wrote: > On Fri, Sep 9, 2011 at 8:29 AM, Alex Converse <alex.conve...@gmail.com> wrote: >> On Fri, Sep 9, 2011 at 6:09 AM, Janne Grunau <janne-li...@jannau.net> wrote: >>> On Fri, Sep 09, 2011 at 11:04:59AM +0100, Måns Rullgård wrote: >>>> Alex Converse <alex.conve...@gmail.com> writes: >>>> >>>> > i.e. Please turn this feature on for the Indeos and the Sorensons and >>>> > the like, but let's fix the individual bugs in the H.264s and VP8s. >>>> > Turning this on for them is overkill. >>>> >>>> Agree. This will annihilate performance, so if we're going to do this, >>>> we might as well stop altogether. >>> >>> could we please wait for benchmarks before making bold statements. I start >>> with one, currently on 3G without higher resolution samples. >>> >>> ./avconv -benchmark -v 0 -i >>> ~/Downloads/cathedral-beta2-400extra-crop-avc.mp4 -f null /dev/null >>> Stream #0.2(eng): Video: h264 (Main), yuv420p, 640x352, 401 kb/s, 23.98 fps >>> Stream #0.3(eng): Audio: aac, 44100 Hz, stereo, s16, 95 kb/s >>> >>> current master: bench: utime=20.569s maxrss=9628kB >>> witt Laurent's patch: bench: utime=20.835s maxrss=9552kB >>> >>> fasted out of three runs. >>> >>> Slowdown of 1.3% far away from annihilating performance. >>> >> >> If a proposal saved 1.3% overall we'd agree to let it contort the code >> in all sorts of hideous ways. > > If this patch is committed, I promise to speed up H.264 by 1.3%. >
okay with me I guess (Which does NOT mean the patch itself is OK, fate still needs to be fixed) --Alex _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
