Log in

View Full Version : Reasons for 4:4:4


Redsandro
6th January 2009, 16:18
I saw people occasionally throw a 4:4:4 ball which raised questions concerning why one would need 4:4:4 as no known source is not subsampled anymore.

Is "why do we need it" the only problem, or will nothing be able to play it back?

Because if you're rendering compositions or animations in stead of transcoding published video and you want to store it without knowing the eventual release target resolution, a 4:4:4 option would make H.264 a welcome option for intermediate storage because it would convert much less brutal to other subsampled resolutions.

Ofcourse if it cannot be read by most software, it makes no sense.

x264 is an awesome tool for final output. But every once in a while I wonder if something can substitute my intermediate Lagarith footage mess and I check the forum to see what people say about 444 in x264 and it's usually "why".

Dark Shikari
6th January 2009, 16:33
no known source is not subsampled anymoreI have plenty of sources which aren't subsampled, and 4:2:2/4:4:4 support in x264 would be welcome.

Patches welcome ;)

Redsandro
6th January 2009, 16:42
I A to the Gree.

My great knowledge pretty much ends with MSX-Basic so my use is less, but I thought I'd let people know that 4:4:4 is not.

Sagekilla
6th January 2009, 21:46
@DS: What would it take for allowing input of 4:4:4 content? Is it some fundamental change (i.e. reworking the entire system) or just patching a few sections so it will work properly?

Dark Shikari
6th January 2009, 22:18
@DS: What would it take for allowing input of 4:4:4 content? Is it some fundamental change (i.e. reworking the entire system) or just patching a few sections so it will work properly?Its a change that would require adding some new functions (different chroma transform, slightly different deblocking logic, etc), but primarily would just mean "patching a few sections".... in an enormous number of places.

Inventive Software
6th January 2009, 22:18
From what I can gather, it's a major re-write of the colourspace internals of x264, and AviSynth too.

Redsandro
6th January 2009, 22:33
That's too bad. I was hoping it would be easy enough.
Out of curiousity, is part of AviSynth's code shared with x264? Or is it a side note?

Because I haven't found what software implements 4:4:4 supporting code (like Vanguard AVC Solution Pack) at the moment, but if it was in one of the packages I am using, I would use it, being unaware that software like AviSynth (which I also use a lot) would choke on it.

JohnnyMalaria
6th January 2009, 23:57
How about scanned film or raw 4:4:4 from seriously pro Hollywood-style digital cameras?

kemuri-_9
7th January 2009, 01:06
x264 and avisynth are completely different projects
they just manage to work together with x264 having support for avisynth in windows-oriented builds.

avisynth 2.6 series adds in support for new color spaces (or so the docs say):
Y8 (4:0:0), YV411, YV16 (4:2:2), and YV24 (4:4:4)

2.6 has no official builds atm, but you can try experimenting by compiling it from svn.

roozhou
7th January 2009, 11:30
You can pipe YUV 4:2:2 / 4:4:4 from mplayer/mencoder/ffmpeg to x264. Avisynth is not the only source that x264 cli accepts.