[FFmpeg-devel] Video codec design for very low-end decoder
Paul B Mahol
onemda at gmail.com
Sun Jan 13 18:45:04 EET 2019
On 1/13/19, Lauri Kasanen <cand at gmx.com> wrote:
> On Mon, 7 Jan 2019 12:37:01 -0500
> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
>> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen <cand at gmx.com> wrote:
>> > "Ronald S. Bultje" <rsbultje at 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
> (tune=fastdecode disables deblocking, the result file confirms all
> heavy options are off)
Just use mencoder, it is good business decision.
More information about the ffmpeg-devel