Add ZMBV and/or Lagarith as supported codecs

[andoruB]

Would it be possible to add those two codecs in the list of supported output codecs? There are currently no lossless codecs that can capture in RGB in that list (that I know of), which I find it to be odd.

Or is this dependant on the libav used during compile? I'm on Debian Sid, and I've compiled SSR myself from the latest commit of this git repo.

[MaartenBaert]

ZMBV expects RGB24 whereas SSR only offers BGRA and BGR24. It shouldn't be difficult to add though. FFmpeg has no Lagarith encoder, only decoder, so that won't work.

I think you can already do lossless with libx264rgb, have you tried that?

[andoruB]

I thought ZMBV was expecting RGBA (RGB32?) or RGB565...?
I really wish Lagarith would be available as an encoder... I achieved quite some great results with it in my screen captures.

Is libx264rgb easily available under Windows (vfw), perhaps as a stand-alone codec?

[MaartenBaert]

RGB24 and BGR24 are not identical, the values are stored in a different order. I need to add conversion code for this.

Why do you need libx264rgb on Windows? SSR doesn't run there. If it's for editing, then what you need is an RGB-capable H.264 decoder, not encoder. I think ffdshow supports this but I never tested it. Also I don't know whether the software you intend to use is using DirectShow (which is the interface that ffdshow uses).

[andoruB]

I'm intending to edit the video with avisynth and VirtualDub, and both of those use DirectShow. What I wanted to avoid is to install the whole ffdshow package just for one encoder/decoder I would need.

I'm still not quite sure that ZMBV works in the RGB24 colourspace, from what I know out of VirtualDub, it requires that the source video/data to be in either RGBA or RGB565/555.

[MaartenBaert]

I checked the ffmpeg source, it seems the ZMBV encoder in ffmpeg only supports PAL8 (256 color palette), this is definitely not what you want. So I recommend libx264rgb instead. I know it works, I've used it before. Try the options preset=veryfast,crf=0,keyint=1. This gives you lossless compression without motion predition. You can drop keyint=1 to enable motion prediction, this gives you better compression at the expense of speed and ease of editing.

These settings can generate absurd bitrates depending on what you are recording, in my tests I'm seeing ~500Mbps for 720p60. So I typically don't use 'real' lossless, it's just not worth it. Instead I use YUV444 with crf=15, this is visually indistinguishable (at least for me) and much faster and smaller. This reduces the bitrate from ~500Mbps down to ~30 Mbps in the same test. CPU usage is also ~6 times lower. Also this doesn't require special codec support, any decent video editor should be able to handle H.264 with YUV444.

To summarize:

• True lossless: codec libx264rgb, options preset=veryfast,crf=0,keyint=1, result ~500 Mbps.
• Near lossless: codec libx264, options preset=veryfast,crf=15,keyint=1,pixelformat=yuv444, result ~30 Mbps.

[mia-0]

This is a rather old issue now but I’ll just leave this here:

Utvideo and ffvhuff should both support RGB (pixelformat=bgra works with the latter), and then there’s libx264rgb (pixelformat=bgr). Another option would be ffv1, but that tends to be way too slow in practice. I believe Ut Video has a VfW codec. But you should really consider using a different NLE/VFX software if yours still depends on this decades old crap. Do give Blender a try, it’s pretty damn good once you know how to use the sequence editor and node compositor.

Lagarith is bad because it uses floating point math in an entropy coder (which is why FFmpeg basically has to emulate x86 FP operations in the decoder).

[countingpine]

Hi. Just found this issue, and thought I'd mention that I recently had a patch accepted to FFMPEG for encoding RGB video in ZMBV. Supported formats are RGB555LE, RGB565LE, and BGR0. https://github.com/FFmpeg/FFmpeg/commit/0321370601833

[countingpine]

Actually.. That said, I should add a major caveat that the worst-case performance of ZMBV in FFmpeg is very poor. A simple desktop might be OK, but anything else - including any real camera footage - will see the performance (and compression efficiency) plummet. This will probably be a dealbreaker for real-time video recording.

[andoruB]

@countingpine Thanks! Will make sure to check it out if it works in SSR. I mostly intend to record raster/pixelated stuff with ZMBV anyway. It makes no sense to use the codec real-life footage anyway.

[MaartenBaert]

SSR currently doesn't support any of those pixel formats though, but it should be quite easy to convert from BGRA (the default format) to BGR0 just by clearing the alpha channel. Is there any reason why the encoder can't accept BGRA though?

[andoruB]

From what I know, ZMBV is meant to record from DOSBox directly (although it's perfect for recording raster graphics/UI stuff), and since most games didn't use more than 24-bit RGB colours, they did away with that format. I would assume it would increase encoding/filesize if they kept it. It's a wild guess though.