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

[Michael Niedermayer]

On Mon, Jan 07, 2019 at 01:44:56PM +0100, Michael Niedermayer wrote:
> 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

beating the best existing codec that works for you, while certainly
possible might be hard

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/1695c54c/attachment.sig>