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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
