[FFmpeg-devel] Video codec design for very low-end decoder

Carl Eugen Hoyos ceffmpeg at gmail.com
Sat Jan 12 17:09:32 EET 2019


2019-01-12 1:46 GMT+01:00, Ronald S. Bultje <rsbultje at gmail.com>:
> Hi,
>
> On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
>> 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje <rsbultje at gmail.com>:
>> > Hi,
>> >
>> > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen <cand at gmx.com> wrote:
>> >
>> >> On Mon, 7 Jan 2019 12:02:58 -0500
>> >> "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:
>> >
>> > https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png
>>
>> Are the relations identical without asm optimizations?
>>
>
> I believe so, yes. The theory behind it would be that lack of per-symbol
> probability adaptations in CABAC and bidirectional prediction were missing
> in VP8, both of which incur a significant runtime overhead. Then, if you
> start disabling tools (e.g. CABAC -> CAVLC) this difference would probably
> diminish quite quickly.

Thank you for the clarification!

Carl Eugen


More information about the ffmpeg-devel mailing list