PDA

View Full Version : Need a good 4:4:4 codec


Dark Shikari
26th May 2007, 16:07
All the codecs I'm finding have 4:2:2 or 4:1:1 or 4:2:0 or similar chroma subsampling.

x264 can get my video (losslessly!) down to 15MB due to the low motion and graphics used, but it converts it to 4:2:0, which causes annoying color bleeding. The YV12 is also annoying--there's tons of banding in the gradients because of the conversion from RGB.

What's a good, modern encoder/codec that supports 4:4:4 subsampling and works well for zero-noise RGB graphics? I tried the MSU screencapture codec and that got it down to 26MB, but it seems to be very CPU-intensive on playback (100% of one of my cores). Additionally most people probably won't have the codec.

morsa
26th May 2007, 16:18
Have you tried Huffyuv in RGB mode or Lagarith in RGB mode ?
They are both lossless in that Mode.

If you video/graphics is so low motion and noise free (which let me think it is from synthetic origin) you could also try some screen capture codec or even some simple RLE one.

Dark Shikari
26th May 2007, 17:03
Have you tried Huffyuv in RGB mode or Lagarith in RGB mode ?
They are both lossless in that Mode.

If you video/graphics is so low motion and noise free (which let me think it is from synthetic origin) you could also try some screen capture codec or even some simple RLE one.
I'm looking for a codec that has both inter and intra-frame compression, something I can use for distribution--Lagarith and HuffyUV are far too large because they only have intra-frame compression.

The graphics are of synthetic origin. What's a good screen capture codec? MSU seems extremely effective and can detect fades, but its too slow on playback to be useful.

Awatef
26th May 2007, 17:17
@ Dark
You're doing something wrong somewhere.
Downsampling to YUY2 or YV12 should be (almost) transparent to the human eye.


Check this out:

Original 24-bit RGB picture:
http://img502.imageshack.us/img502/6256/rgbft8.th.png (http://img502.imageshack.us/my.php?image=rgbft8.png)

Downsampled to YV12:
http://img502.imageshack.us/img502/9447/yv12sl6.th.png (http://img502.imageshack.us/my.php?image=yv12sl6.png)

Dark Shikari
26th May 2007, 17:21
@ Dark
You're doing something wrong somewhere.
Downsampling to YUY2 or YV12 should be transparent to the human eye.


Check this out:

Original 24-bit RGB picture:
http://img502.imageshack.us/img502/6256/rgbft8.th.png (http://img502.imageshack.us/my.php?image=rgbft8.png)

Downsampled to YV12:
http://img502.imageshack.us/img502/9447/yv12sl6.th.png (http://img502.imageshack.us/my.php?image=yv12sl6.png)

http://i11.tinypic.com/68cihr9.png

Right = original (mild banding)
Left = ConvertToYV12() in Avisynth (tons of banding)

The banding isn't *that* much worse but its a lot more obvious.

Awatef
26th May 2007, 18:28
Well, I had a hard time telling the difference (putting my LCD under weird viewing angles and stuff), so I don't think it's dramatic.

Either way, I don't know any "main stream" codec that supports 4:4:4, sorry

Taktaal
27th May 2007, 02:54
First: YUV is notoriously bad at encoding green. Unfortunately your image is mostly green, and that's where the banding happens.

Second: You're encoding a screenshot in a DCT based format. Much like you wouldn't compress a screenshot of a web page in JPG (use PNG instead) you shouldn't do this here either. If your movie consists only of images like your sample, you should use a Flash animation instead.

Third: you're judging the quality of an encode by a still image. If you want any possible screenshot to look as best as possible the only way to do that is to use a codec that only uses intra frames.

As soon as the codec has to save more space by using p-frames it will throw away information that won't be visible in a movie. Pausing the movie and making a screenshot sabotages all that work and will make errors visible that wouldn't be in a realistic environment.

Mug Funky
27th May 2007, 03:28
First: YUV is notoriously bad at encoding green. Unfortunately your image is mostly green, and that's where the banding happens.

source on that? green actually gets priority in all flavours of YUV.

reds have issues because of their relatively high luminance, and blues have it very bad but usually it's not noticable as the eye sucks at picking up blue.

FWIW, on my CRT i didn't see any banding, only mild pixelliness in coloured edges. that doesn't solve your problem, but it implies that it can vary from computer to computer.

give corePNG a try, but it's not a common codec, and is quite slow.

also, bink video might work, as they say there's special consideration given to RGB.

*.mp4 guy
27th May 2007, 10:34
Try using the deband filter in ffdshow on it, and see if that makes it look better on playback.

J_Darnley
27th May 2007, 11:48
You could try FFmpeg and it's ZLIB lossess compression. It will compress RGB video so there is no (minute) loss from the colourspace change. I used for storing some movie dumps from ZSNES and it managed 2830 kbit/s for 256x224 50Hz video which I thought wasn't too bad coming from a raw pipe. The raw video was 68 Mbit/s