PDA

View Full Version : YV24 in x264 ?


bugsan
9th July 2006, 18:03
Hello,

Is there any chance that x264 will support YV24 ? i think this feature does not need a lot of work.

imho YV12 sux :(

thx

dbzgundam
9th July 2006, 19:11
It would be awesome, but the biggest reason it's not is simply because there's so little material (if any) that actually has such colorspace.

Any DVDs, or HD formats for that matter, would be YV12. You'd have to pretty much render your own video to use this.

Awatef
9th July 2006, 19:21
Hmm... strange request... I mean DVD-streams use the YV12 color space, capture software usually use YUY2 or RGB, DV-video uses YUV 4:1:1, and most important, the MPEG-4 standard prescribes YV12.

I don't see any room for YV24 here.

foxyshadis
9th July 2006, 21:02
YV16/24 are part of high profile and aimed at pro encoding where YV12 has too much bleeding. I don't think 16-bit YUV is part of the specs at all though, and that would be much more useful.

Awatef
10th July 2006, 10:08
Afaik, YV24 si not part of the spec anymore, it was experimental.

GodofaGap
10th July 2006, 11:03
4:4:4 sampling is possible with h264. It is in the standard.

http://forum.doom9.org/showthread.php?t=96059

Of course, besides screen captures there is hardly any material where this would be useful right now.

Awatef
10th July 2006, 14:57
Being "possible" is not a reason to implement it, since it is NOT OFFICIAL anymore. The 4:4:4 support has been DEPRECATED!

GodofaGap
10th July 2006, 15:03
What do you mean? It is still in the standard.

check
10th July 2006, 15:04
Is there any chance that x264 will support YV24 ? i think this feature does not need a lot of work.
imho YV12 sux
What exactly did you have that was in YV24? If you have any videos in this format I'd be very interested in getting a copy if they are free :)

akupenguin
10th July 2006, 16:58
H.264 supports 4:4:4 with up to 12 bits per sample. This is an official feature, and is not deprecated in any way.
However, x264 will not do it in the foreseeable future, because it would require much work, and merely supporting it would slow down encoding in normal yv12, and I don't have any 4:4:4 or 12bit footage aside from downscaling HD and a few game captures.

Edit: see below
(2 years old? FRext was only finalized in 2005, and the version of the standard I'm working from was updated in september.)

Awatef
10th July 2006, 20:00
OK, seems like everybody is sticking to a 2 years old description.
YV24 is NOT in the standard anymore.

This can be read on Wikipedia:
* High 4:4:4 Profile (Hi444P) [deprecated]: This profile builds on top of the High 4:2:2 Profile supporting up to 4:4:4 chroma sampling, up to 12 bits per sample, and additionally supporting efficient lossless region coding and an integer residual color transform for coding RGB video while avoiding color-space transformation error. Note: The High 4:4:4 Profile is being removed from the standard in favor of developing a new improved 4:4:4 profile.

foxyshadis
10th July 2006, 21:15
No offence, but I trust Aku over wikipedia without a more authorative source. And that doesn't even sound like YV24 is being removed, it's obvious that they mean a new profile is being defined to supercede the current YV24 with a new YV24, presumably including some new features, but decoders should still be able to read the old format.

I realize that 10 or 12 bit would require extensive replumbing, but is YV16/YV24 more than just a few tweaks to stop assuming uvpitch=ypitch/2, and signal the new profile? (Not that avisynth supports either yet, but avs3 is still making progress.)

akupenguin
10th July 2006, 21:42
I realize that 10 or 12 bit would require extensive replumbing, but is YV16/YV24 more than just a few tweaks to stop assuming uvpitch=ypitch/2, and signal the new profile? (Not that avisynth supports either yet, but avs3 is still making progress.)
It requires modifying everywhere that touches chroma. Memory allocation, cache load/store, motion estimation, motion compensation, rd, dct, entropy coding, deblock, ... all assume 4:2:0. Also, supporting 4:2:2 requires new motion compensation and comparison functions for 16x4 and 8x2 blocks, and a 4x2 hadamard. And that's just the stuff I can think of without referring to the standard, there might be some misdesigns too.

akupenguin
10th July 2006, 22:53
I just read the April JVT proceedings. Awatef is correct.

Official sources:
The standard itself (http://www.itu.int/rec/T-REC-H.264/en) does in fact no longer contain the original High444 profile, though a replacement has not been finalized. And the ammendment making that change has not been published, even though it is in force. (Oh well, FRext also took several months between finalization and publishing.)

Summary of stuff being discussed for future versions of AVC and SVC standards: http://ftp3.itu.ch/av-arch/jvt-site/2006_04_Geneva/AgendaWithNotes_d8.doc

And if JVT-S014 (http://ftp3.itu.ch/av-arch/jvt-site/2006_04_Geneva/JVT-S014.zip) (slice-level independent coding) is chosen as part of the new 444 profile, then I might even implement it.


PS, the Advanced Video Codec will soon have an Advanced Profile too. They're running into naming inflation sooner than I expected.

dma_k
26th May 2010, 14:11
I agree that there is no material in YV24 format, but for example I would like to use per-pixel cropping in AVS script. In YV24 space I can make cropping like Crop(1,0,1,0) (I still have width/height as a multiple of 2). So I believe that conversion from DVD'd YV12 into YV24 is lossless, but what happens to this video in x264? Will the resulting output video stream be larger (as there is "more" information about the colour in the input)? Or is it advised to convert back to YV12 before feeding to x264 (if someone please could confirm, if this will anyway more efficient, than conversion to RGB)?
Any other solution is welcomed.

J_Darnley
26th May 2010, 14:52
You can't give yv24 input to x264 through avisynth. x264 will try to change it to yv12 using ConvertToYV12() and if the width and height are not even then avisynth will return an error.

kemuri-_9
27th May 2010, 00:29
You can't give yv24 input to x264 through avisynth. x264 will try to change it to yv12 using ConvertToYV12() and if the width and height are not even then avisynth will return an error.

technically the avs demuxer specifically errors out if the width or height are not even before the ConvertToYV12() is called....

@dma_k:
stay in YUV space if you can, else you'll be faced with color degradation in YUV <-> RGB conversions.

CruNcher
27th May 2010, 03:40
Ateme and Elecard i think are 2 of the few that support 4:4:4 though it's really impractical as only their own Decoders currently can decode it :P

Mug Funky
27th May 2010, 13:42
HDCAM SR supports 10-bit 4:4:4, but only in RGB.

some telecine chains can output 4:4:4 YUV, but there's a lack of capture interfaces that support it (example - the old Ursa Gold i used for years worked in 4:4:4 yuv, via some archaic dual-link parallel interface, but only one other device in the chain supported it, then it was required to convert to 4:2:2 on the output, or nothing could capture it.

i see room for 4:2:2 YUV or 4:4:4 RGB, but i don't think x264's strength lies there. there are faster and better solutions for handling crazy high quality video - like lossless, or DNxHD, or apple's DNxHD ripoff "ProRes". x264 would be too slow to be useful compared to these purpose built alternatives.

kieranrk
27th May 2010, 14:07
i see room for 4:2:2 YUV or 4:4:4 RGB, but i don't think x264's strength lies there. there are faster and better solutions for handling crazy high quality video - like lossless, or DNxHD, or apple's DNxHD ripoff "ProRes". x264 would be too slow to be useful compared to these purpose built alternatives.

Personally, I think x264 intra with speedcontrol would be fine to do that. It's just that the industry likes to create artificial market segmentation by using a whole set of "pro" codecs for production and H.264 for distribution. This is in spite of the fact that H.264 could compete perfectly well with those formats. In the early days the argument was H.264 required too much CPU power but in the era of quad cores this is not the case. Perhaps this is why Final Cut pro and the likes have a crappy H.264 decoder and encoder in order to lead people towards the "pro" codecs.

Biggiesized
27th May 2010, 18:35
HDCAM SR supports 10-bit 4:4:4, but only in RGB.

HDCAM-SR uses MPEG-4 SStP (Simple Studio Profile), which is of part 2 of the visual coding standard.

Blue_MiSfit
27th May 2010, 23:26
Indeed, and is intra-only IIRC.

I think we are in an era where there's enough CPU power to easily handle real-time, high bitrate capture and editing with intra-only or short GOP H.264 - certainly with better results than ProRes or DNxHD. The problem is decoding / transcoding performance in the editors (I'm looking at YOU, APPLE!!!).

For example, I routinely capture from HDCAM-SR to x264 using Digital Rapids in VFW mode. Okay it's not the most elegant solution (and only does 8 bit 4:2:0 obviously), but I can capture to CRF15 1080p using about half the power of the box, which is an older 8 core xeon. Results usually come out between 30 and 60mbps, and are quite excellent. They definitely have visual transparency to the source.

Compare that to ProRes which needs about 150mbps, and decodes slower than shite on Windows.

Digital Rapids does a decent 10->8 dither and 4:2:0 downconversion (and decent 60i -> 30p deinterlacing), and I'm using these captures as a mezz file for multiple H.264 outputs ranging from 480p @ 500kbps to 1080p @ 10mbps.

Personally, x264 is a fantastic capture codec for this application. It may not be for other folks, but I'm quite happy!

~MiSfit

kieranrk
27th May 2010, 23:53
Compare that to ProRes which needs about 150mbps, and decodes slower than shite on Windows.


Suprisingly the ProRes decoder has SIMD but I guess it must still be crap nonetheless.

Blue_MiSfit
27th May 2010, 23:57
Yep. I can't get more than ~30fps out of it... and it's single threaded on windows :devil:

mariush
28th May 2010, 01:18
So how come there's no smart guy out there capable of disassembling and doing a better open source version of that decoder ?

Dark Shikari
28th May 2010, 01:22
So how come there's no smart guy out there capable of disassembling and doing a better open source version of that decoder ?Because you haven't paid him yet ;)

dma_k
28th May 2010, 09:30
technically the avs demuxer specifically errors out if the width or height are not even before the ConvertToYV12() is called....

@dma_k:
stay in YUV space if you can, else you'll be faced with color degradation in YUV <-> RGB conversions.

I am a bit confused about who calls ConvertToYV12(): x264 (implicitly internally) or should I put it to the end of AVS script explicitly?

Anyway I have made the output filesize measurements: it does not matter if x264 is fed YV12 or YV24 as input, in both cases the output file was (almost) the same size. So I make a conclusion, that internally x264 works only with one colour space (presumably YV12).

kemuri-_9
28th May 2010, 13:17
I am a bit confused about who calls ConvertToYV12(): x264 (implicitly internally) or should I put it to the end of AVS script explicitly?

x264 will explicitly call ConvertToYV12() if the script given to it is not already YV12 (however, for avs 2.6 there's a stipulation that will always call it)
so you can either do it explicitly in your script or not, either way is fine.

x264 only supports 4:2:0/YV12 at the moment.

Biggiesized
29th May 2010, 04:39
I'm using these captures as a mezz file for multiple H.264 outputs ranging from 480p @ 500kbps to 1080p @ 10mbps.
Is your HDCAM-SR tape already the master or are you ingesting to create a mezzanine file for offline editing --> encoding?

Blue_MiSfit
29th May 2010, 09:10
@Biggiesized:

The SR is the master. We're just ingesting for transcodes, and then archiving the mezz file.

Mug Funky
31st May 2010, 14:04
blue_misfit:

i'm impressed at your getting digital rapids that fast! i used an older card with the included Stream software and it ran like poo.

prores on the other hand i honestly haven't had any trouble with, though i mostly used it on macs where it's nicely threaded, or from USB drives where i put the speed issues down to bandwidth. on the scratch machine (a pc) there were no speed problems going off prores that i observed, but the most we ever got out of that from quicktime was realtime anyway (and renders had to happen in uncompressed due to apple's flat refusal to allow encoding on a pc)

Blue_MiSfit
1st June 2010, 07:35
@Mug: You nailed it! On Mac OS, ProRes is wonderful. On Windows, it's terrible, and you can't encode to it.

Our Digital Rapids box is a turnkey system that somebody bought about 4 years ago. It's an 8 core system running Windows XP. It's a champ, if pretty old. We'll be getting some newer boxes soon, I think. As it stands, capture to very stripped down x264 uses about 40% of the CPU time, at CRF15 1080p24, a little higher when interlaced. Heck, I could probably do a parallel SD encode with the Digital Rapids' hardware downconverter, but x264vfw only remembers one configuration.

Derek

ifb
1st June 2010, 12:59
Heck, I could probably do a parallel SD encode with the Digital Rapids' hardware downconverter, but x264vfw only remembers one configuration.You can do two configurations, it just appears like you can't. Whenever you open the VfW config dialog you always see the last saved config. Very annoying, especially when the two configurations are very different, because you have to change everything every time.

MasterNobody
1st June 2010, 21:02
*Mostly all* VFW-codecs have support for ICM_GETSTATE (http://msdn.microsoft.com/en-us/library/dd756956%28VS.85%29.aspx)/ICM_SETSTATE (http://msdn.microsoft.com/en-us/library/dd756958%28VS.85%29.aspx) messages (x264vfw is not exception). So it is the task of encoding application to have the option to save the current state of encoder (for example in VirtualDub it can be saved/loaded by "Save processing settings"/"Load processing settings" respectively). x264vfw load settings from Windows registry (only one version of which exist) only during codec load or when sending ICM_SETSTATE with wParam==NULL.