Re: [FFmpeg-devel] Video codec design for very low-end decoder
On 1/13/19, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 12:37:01 -0500 > "Ronald S. Bultje" wrote: > >> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: >> > "Ronald S. Bultje" 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 > > I tried VP8 on the target platform (libvpx 1.7.0). It took 32% longer > to decode the test vid than xvid, and given xvid was already a bit > under realtime, VP8 is out. > > Curiously, VP8 also added very objectionable artifacts. Some blocks > *moved* around in frames. That looked very bad, neither xvid nor h264 > caused that, they were just blocky or blurry. VP8 also looked worst of > the three, by eye. > > x264 "everything disabled AFAICT" actually looks very good for the > bitrate. Too bad I can't use H.264 due to the patent situation, so not > going to spend time benching it either. > > Settings used: > > vpxenc -p 2 --profile=3 --target-bitrate=250 --best --end-usage=vbr > --codec=vp8 --min-q=0 --max-q=60 --ivf > > mencoder -ovc x264 -x264encopts > preset=veryslow:pass=2:bitrate=250:tune=fastdecode:profile=baseline > > (tune=fastdecode disables deblocking, the result file confirms all > heavy options are off) Just use mencoder, it is good business decision. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, 7 Jan 2019 12:37:01 -0500 "Ronald S. Bultje" wrote: > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > > "Ronald S. Bultje" 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 I tried VP8 on the target platform (libvpx 1.7.0). It took 32% longer to decode the test vid than xvid, and given xvid was already a bit under realtime, VP8 is out. Curiously, VP8 also added very objectionable artifacts. Some blocks *moved* around in frames. That looked very bad, neither xvid nor h264 caused that, they were just blocky or blurry. VP8 also looked worst of the three, by eye. x264 "everything disabled AFAICT" actually looks very good for the bitrate. Too bad I can't use H.264 due to the patent situation, so not going to spend time benching it either. Settings used: vpxenc -p 2 --profile=3 --target-bitrate=250 --best --end-usage=vbr --codec=vp8 --min-q=0 --max-q=60 --ivf mencoder -ovc x264 -x264encopts preset=veryslow:pass=2:bitrate=250:tune=fastdecode:profile=baseline (tune=fastdecode disables deblocking, the result file confirms all heavy options are off) - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
2019-01-12 1:46 GMT+01:00, Ronald S. Bultje : > Hi, > > On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos wrote: > >> 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje : >> > Hi, >> > >> > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: >> > >> >> On Mon, 7 Jan 2019 12:02:58 -0500 >> >> "Ronald S. Bultje" 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
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos wrote: > 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje : > > Hi, > > > > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > > > >> On Mon, 7 Jan 2019 12:02:58 -0500 > >> "Ronald S. Bultje" 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. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
2019-01-07 18:37 GMT+01:00, Ronald S. Bultje : > Hi, > > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > >> On Mon, 7 Jan 2019 12:02:58 -0500 >> "Ronald S. Bultje" 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? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
mån 2019-01-07 klockan 15:38 +0200 skrev Lauri Kasanen: > On Mon, 7 Jan 2019 13:44:56 +0100 > Michael Niedermayer 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 platform 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) /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 07:24:53PM +0200, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 17:42:58 +0100 > Michael Niedermayer wrote: > > > > 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". > > > > constrained baseline is not "everything off" > > Wikipedia's table shows CBP as "all off", but perhaps it doesn't list > every option. It lists CABAC etc, but not deblocking. Do you think the > unlisted options could account for 30%? deblocking is complex, if everything else is turned off relatively speaking Also if h264 is still too slow after this try intra only h264. same thing for mpeg4 ASP (what you call xvid) and mpeg1, intra only might be fast enough > > > > 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. > > > > I would guess that with rare or odd architectures > > compilers are not so good when it comes to generating efficient code. > > > > I would not be surprised if someone who knows the target CPUs pipeline > > and timings could beat the compiler by quite some amount. > > This is one part where the amount of man hours needed is significant > > of course. Would that be worth it, well its your project you have > > to know what amount of work you are willing to do for this, > > i wouldnt do that work ;) > > > > besides, why this low end chip ? > > Just for fun ;) > > MIPS does not have any timings, all instructions complete in the same > amount of cycles (except floating point, cache misses, interrupts, > etc). This makes it fairly suitable for a compiler I think, limiting > what could be gotten from hand-writing asm. have you ever looked at asm code generated by gcc ? you should instead of assuming it is good code. Ive seen really crappy code generated by compilers and i speak of x86 here. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > On Mon, 7 Jan 2019 12:02:58 -0500 > "Ronald S. Bultje" 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 Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, 7 Jan 2019 17:42:58 +0100 Michael Niedermayer wrote: > > 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". > > constrained baseline is not "everything off" Wikipedia's table shows CBP as "all off", but perhaps it doesn't list every option. It lists CABAC etc, but not deblocking. Do you think the unlisted options could account for 30%? > > 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. > > I would guess that with rare or odd architectures > compilers are not so good when it comes to generating efficient code. > > I would not be surprised if someone who knows the target CPUs pipeline > and timings could beat the compiler by quite some amount. > This is one part where the amount of man hours needed is significant > of course. Would that be worth it, well its your project you have > to know what amount of work you are willing to do for this, > i wouldnt do that work ;) > > besides, why this low end chip ? Just for fun ;) MIPS does not have any timings, all instructions complete in the same amount of cycles (except floating point, cache misses, interrupts, etc). This makes it fairly suitable for a compiler I think, limiting what could be gotten from hand-writing asm. On Mon, 7 Jan 2019 12:02:58 -0500 "Ronald S. Bultje" 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. Perhaps it too has features that can be disabled? - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi Lauri, On Mon, Jan 7, 2019 at 3:15 AM Lauri Kasanen wrote: > If you were to design a video codec for a very low-end decoder, what > would it look like? > Have you considered vp8? It may sound weird but this is basically what vp8 was great at: being really simple to decode. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 03:38:35PM +0200, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 13:44:56 +0100 > Michael Niedermayer 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". constrained baseline is not "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. I would guess that with rare or odd architectures compilers are not so good when it comes to generating efficient code. I would not be surprised if someone who knows the target CPUs pipeline and timings could beat the compiler by quite some amount. This is one part where the amount of man hours needed is significant of course. Would that be worth it, well its your project you have to know what amount of work you are willing to do for this, i wouldnt do that work ;) besides, why this low end chip ? > > Cinepak is almost 30 years old, surely it should be possible to match > the decoding & quality, but at a 5x lower bitrate :P > > - Lauri > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, 7 Jan 2019 13:44:56 +0100 Michael Niedermayer 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 - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
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
Re: [FFmpeg-devel] Video codec design for very low-end decoder
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@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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Video codec design for very low-end decoder
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. 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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
