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

Michael Niedermayer michael at niedermayer.cc
Mon Jan 7 14:44:56 EET 2019

On Mon, Jan 07, 2019 at 10:17:48AM +0200, Lauri Kasanen wrote:
> Hi,
> If you were to design a video codec for a very low-end decoder, what
> would it look like?
> My target is MIPS 100MHz, and it should decode 320x240x30 in full speed
> in software, with headroom for audio too. Seems all the codec research
> in last 20 years has been more quality with more overhead, nobody
> looking into "improve quality without more overhead".
> Currently I'm thinking it would have to be a variant of vector
> quantization, like Cinepak. The target bitrates however are ~250 kbps
> or lower, where Cinepak targeted 1200 or higher. Are there any tricks
> that would improve quality with only encoder-side effort? What is the
> current top-of-the-line interframe prediction, that is still fast to
> decode?
> The platform is fast enough to play back mpeg1, and xvid simple
> profile L3 barely. Cinepak should also work, but I'd like the quality
> to be higher than these three.
> The last relevant VQ paper I found was 
> https://arxiv.org/abs/1710.05311 which used a genetic algorithm to seed
> the codebook generation, improving PSNR by a few db over previous
> approaches. I've implemented that (for a single grayscale frame), but it
> looks too bad at reasonable bitrates.

> 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

> Not sure if this would be better off on other MLs, didn't seem to apply
> to ffmpeg-user really.
> - Lauri
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190107/f2c03045/attachment.sig>

More information about the ffmpeg-devel mailing list