2019-01-12 1:46 GMT+01:00, Ronald S. Bultje <rsbul...@gmail.com>: > Hi, > > On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje <rsbul...@gmail.com>: >> > Hi, >> > >> > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen <c...@gmx.com> wrote: >> > >> >> On Mon, 7 Jan 2019 12:02:58 -0500 >> >> "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: >> > >> > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
