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

Tomas Härdin tjoppen at acc.umu.se
Thu Jan 10 11:53:16 EET 2019

mån 2019-01-07 klockan 15:38 +0200 skrev Lauri Kasanen:
> On Mon, 7 Jan 2019 13:44:56 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > The modern approaches, DCT, FFT, wavelets and such transforms,
> > > are all
> > > likely too slow to decode.
> > 
> > you said it can do mpeg1 and xvid, these are DCT based
> > have you tried H.264 ? (i imagine that might with asm optimizations
> > and avoidance of more complex features like CABAC and the loop
> > filter
> > work maybe, maybe not)
> > also if h.264 with everything disabled works maybe some features
> > can
> > be turned on sometimes like the loop filter for key frames, that 
> > might then help compression ...
> > 
> > and beating an existing codec, while certainly possible might be
> > hard
> According to a 2010 comparison
> https://keyj.emphy.de/video-encoder-comparison/
> x264 constrained baseline (everything off) takes something like 30%
> longer to decode vs xvid at the same rate. Probably more because that
> site used xvid's full features, while I used it "everything off".
> The issue with xvid simple and mpeg1 were that they were slightly too
> slow, and looked too bad. The platform does not have any SIMD, so I
> doubt asm optimizations will help much.
> Cinepak is almost 30 years old, surely it should be possible to match
> the decoding & quality, but at a 5x lower bitrate :P

You could always work yourself up from cinepak, svq*, h261 and all the
other ancient codecs, assuming you've got an ffmpeg build going on your

There might be one or two wavelet based codecs out there worth looking
at. Anything based on the Haar wavelet should decode cheaply, plus you
get dat blocky aesthetic (sentence sponsored by the cinepak gang)


More information about the ffmpeg-devel mailing list