On 1/13/19, Lauri Kasanen <c...@gmx.com> wrote: > On Mon, 7 Jan 2019 12:37:01 -0500 > "Ronald S. Bultje" <rsbul...@gmail.com> wrote: > >> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen <c...@gmx.com> wrote: >> > "Ronald S. Bultje" <rsbul...@gmail.com> wrote: >> > >> > > Have you considered vp8? It may sound weird but this is basically what >> > > vp8 was great at: being really simple to decode. >> > >> > VP8 has a reputation of being slow, so I didn't consider it. Benchmarks >> > show it as decoding slower than h264. >> >> It is faster than h264 when comparing ffh264 vs. ffvp8 > > I tried VP8 on the target platform (libvpx 1.7.0). It took 32% longer > to decode the test vid than xvid, and given xvid was already a bit > under realtime, VP8 is out. > > Curiously, VP8 also added very objectionable artifacts. Some blocks > *moved* around in frames. That looked very bad, neither xvid nor h264 > caused that, they were just blocky or blurry. VP8 also looked worst of > the three, by eye. > > x264 "everything disabled AFAICT" actually looks very good for the > bitrate. Too bad I can't use H.264 due to the patent situation, so not > going to spend time benching it either. > > Settings used: > > vpxenc -p 2 --profile=3 --target-bitrate=250 --best --end-usage=vbr > --codec=vp8 --min-q=0 --max-q=60 --ivf > > mencoder -ovc x264 -x264encopts > preset=veryslow:pass=2:bitrate=250:tune=fastdecode:profile=baseline > > (tune=fastdecode disables deblocking, the result file confirms all > heavy options are off)
Just use mencoder, it is good business decision. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
