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) - Lauri _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
