10bit quicktime sample requested v210 format

[jmac698]

Hello,
In order to test and complete my Deep Color Tools, I need a sample Quicktime movie in v210, yuv format.
Ideally, I just need a few frames of real 10bit colorbars, also a short clip of real video would be nice.

Better yet, how can I create such files with free software. I have no way to acquire such video, so I'd have to export colorbars or some kind of 10bit yuv paintprogram.

[poisondeathray]

Here are a few frames:

For both samples, I exported AJA v210 mov using "trillions of colors" (which indicates 10bit+)

Sample 1: 1280x720p29.97 Belle Nuit Test Chart
Method used: imported 8-bit RGB TIFF into After Effects in 32-bit float mode
http://www.mediafire.com/?m2nc3n920kui5ws#1

Sample 2: 1920x1080p50 Park Joy
Method used: imported 3840x2160,16-bit RGB SGI sequence into AE, scaled to 1920x1080p50 in 32-bit float mode
http://www.mediafire.com/?by46kau3h677e9j



PS. You can encode to v210 in avi or mov container using ffmpeg, but I'm not sure of the precision or if it's a 10-bit+ workflow for RGB<=>Y'CbCr conversions

e.g
ffmpeg -i input.avi -vcodec v210 -an output.mov



Let me know if you have other requests

Cheers

[jmac698]

That's great, thanks! Of course if you have After Effects, it's not a big deal, but I'm making a free program. What sorts of filters do you think would be useful in Avisynth that you can't do in your tools?
I was thinking of some of the cleanup you do in old film restoration.

[poisondeathray]

That's great, thanks! Of course if you have After Effects, it's not a big deal, but I'm making a free program. What sorts of filters do you think would be useful in Avisynth that you can't do in your tools?
I was thinking of some of the cleanup you do in old film restoration.

there are many things avisynth does better than many other retail tools! e.g. quality deinterlacing, telecine/cadence manipulation, some denoising / dirt removal tools ....many more

but regarding your deep color tools - any sort of color or levels adjustments in 8-bit will introduce more banding than when used in 10-bit+ mode, even if the final output was intended to be 8-bit Y'CbCr

so something like curves (hard to do in avisynth in a user friendly manner) , levels , etc...

[jmac698]

If you were following this thread, I've made working 48bit levels management in my deep color utilities, and also was able to write a new file importer for v210 files - thanks to your samples!
And yes, I could use more samples, specifically made ones for testing. I need these: 480p, 480i, and then all resolutions with sound. Really, it's up to you - what files would you use in production?
And some colorbars like these http://avisynth.org/mediawiki/HDColorBars

I can soon let you use many avisynth plugins with full 48bit processing - for example IVTC can be done on upper 8 bits as a proxy and then applied to 48bits. I can easily do blur/sharpen/gamma correct resize/color conversion etc. I think this is exciting :)

And where did that parkjoy come from? It's definitely using all the bits.

[poisondeathray]

And yes, I could use more samples, specifically made ones for testing. I need these: 480p, 480i, and then all resolutions with sound. Really, it's up to you - what files would you use in production?
And some colorbars like these http://avisynth.org/mediawiki/HDColorBars


ok, I'll try to whip some stuff up in the next few days.

if it's generated from avisynth, you can encode with ffmpeg (accepts avs)

e.g.

ffmpeg -i input.avs -vcodec v210 -an output.mov

But HDColorBars returns YV12 according to info() , so I'm not sure how good the v210 sample will be.

I think you would want a 10-bit or higher Y'CbCr source, or at least 8-bit RGB => 10-bit v210 Y'CbCr 4:2:2




I can soon let you use many avisynth plugins with full 48bit processing - for example IVTC can be done on upper 8 bits as a proxy and then applied to 48bits. I can easily do blur/sharpen/gamma correct resize/color conversion etc. I think this is exciting :)


This is good news. I don't understand the programming behind it of course :) I always thought as soon as anything touched avisynth, it gets truncated


And where did that parkjoy come from? It's definitely using all the bits.
This is from the free SVT testing sequences

You can find lower res versions here
http://media.xiph.org/video/derf/

But the original SGI scans can be found here
http://www.its.bldrdoc.gov/vqeg/

[jmac698]

Yes, avisynth only uses 8bit, but I invented a pseudo-format which stores 16bits as two video clips, then functions to treat them as one.
And I didn't explaiin, I'm wondering if you have software that creates 10bit color bars originally. Any pro equipment should send this over SDI and you can just cap it. Actually SD ones are good too. Just helps me verify if I generate it in script in 10bit someday, or use as is for now.

Even with ffmpeg, I have no way to generate real 10bit files. I can transcode 8bit source to 10bit files, but where is my 10bit source generator? ffmpeg gives you a color generating function but it's only specified in RGB.

Update: very cool! I've seen those images many times, never knew where they came from. Great link! I can use that rgb2yuv program, but how to create 16bit SGI files? Even so, I still can't create YUV directly (but should be enough for 10bit yuv). If there's an output plugin for povray, that's pretty easy to script in. Hmm...

Update2: yep, povray can create 16bit linear rgb in PNG and PPM. With some conversions I could finally get 10bit yuv, what a pain though.

[poisondeathray]

The 16-bit SGI files were scanned from film , you can use other utilities to manipulate them e.g. xnview

You can generate RGB test patterns in software in 16 or 32bit mode, export using 16-bit tiff of png, or 32bit openexr . Then do the conversion to v210 in 32-bit linear light. I'm not familiar with povray, but if it can't do this then I'll generate some SMPTE bars for you

[jmac698]

In povray it looks like it will be something like this:

texture {
pigment {
color rgb<0, 0.5, 0.5>
}
}

So the color is an rgb float. It's not really easy to draw in 2d in this...

[poisondeathray]

How do you know it's a "valid" 10bit source? The answer is you don't know unless you have something like a gradient to look at. Color bars , SMPTE bars , etc... are less useful for this testing , because there are no gradients - they show discrete solid uniform colors (ie. already quantized, so 8bit will look the same as 10bit). While you can get gradients in live footage (like skies, shadows), it's easier to see with computer generated ramps, and you can more easily start with higher precision (like a 16 or 32bit RGB format). Not all cameras output a 10bit signal through HDMI or HD-SDI (many are actually output 8bit even though the A/D signal processing upstream may be higher)

v210 derived from a true 10-bit or higher source should show a smooth histogram for gradients, not quantized values or banding. (if you try to generate a v210 sample from an 8bit greyscale ramp for example, many programs will warn you that the bit depth is exceeded. If you do it anyways, and re-import, you will notice banding and aberations in the histogram)

So even if you're working in a 16 or 32-bit workspace with 10-bit v210, if that asset was derived from an 8-bit source (computer generated or not), you may show banding. The higher precision workspace will help to reduce new banding during manipuations, but not help "baked in" values from an 8-bit source. For example , in 16bpc , RGB values can be 0-32768 in 16bit instead of 0-255 in 8bit mode. But the values are already quantized as soon as it touches avisynth, even before you do any adjustments or color corrections.



v210 decoded properly
http://i53.tinypic.com/2ik5awy.png


same v210 clip decoded in avisynth ffms2, direct avs importer
http://i51.tinypic.com/35ksuts.png


But ffmpeg does support 10-bit input and output directly;
-if you feed true v210 source , encode v210 => no banding
-if you feed true v210 source through .avs, encode v210 => banding (and ffmpeg give warning source does not equal 10-bit)
So it appears avisynth is indeed the culprit

I would recommend making testclips derived from 16bit RGB generated ramps, where defects can be more easily seen. Any curves or levels adjustments made will be very sensitive to show breaking up in the histogram, even if the visual change is subtle in the actual image (for example a 6-bit LCD panel might display differently than a 10-bit panel, but the histogram will be sensitive to the banding eitherway)

I'll test your "deep color tools" when I get a chance , if 9bits were salvaged or it was dithered as you mentioned in the other thread, it should make a difference



For now here are some other clips:


Radial Ramps, Computer generated 16bit RGB ramps => v210
http://www.mediafire.com/?cxc8bmw5haceclo



SMPTE NTSC Bars 10bit RGB => v210
http://www.mediafire.com/?bclge7uam81a787


5sec clip shot with Arri Alexa in ProRes422 => v210
(mediafire only accepts 200MB clips, so this is split rar archive)
http://www.mediafire.com/?fzxi5p7f6kikg74
http://www.mediafire.com/?pqrydie75vmv9bv

[Didée]

In povray ... It's not really easy to draw in 2d in this...
Ah, POV-Ray! Haven't worked with it for many years, but oh yeah, how I love(d) it!
(This scenery (http://img715.imageshack.us/i/scene3e.jpg/) I did back in 1999(!) - and so is the used hardware. The original task was to build a room-fitting table in realworld. It's a tragedy the script got lost in a HD crash.)
(The table, however, still does serve well.)

You know, for "2D drawing" in POV-Ray, you need to switch to another camera model:

camera {
orthographic
location <0,0,0>
direction <0,0,1>
right 1.33*x
up y
sky <0,1,0>
}
With an orthographic camera, you're not plagued by problems related to "perspective".

[kolak]

v210 decoded properly
http://i53.tinypic.com/2ik5awy.png




What are these lines?


Andrew

[poisondeathray]

What are these lines?


Andrew


If you're referring to the "little spikes" on the histogram, I think they are rounding errors from 16bit RGB => 10bit Y'CbCr . You don't see as many "little spikes" in 16bit RGB => 10bit RGB for example (and of course none when going 16bit RGB=>16bit RGB)

The "little spikes" don't show up on watching the footage, only the "big banding" in the histogram correlates with perceived "banding", on live action (real) footage. I suspect you would see the "little spikes" on the histogram even with a 16bit Y'CbCr format too (if there was such a thing), because Y'CbCr doesn't overlap RGB completely

The real difference is when you grade or make adjustments like curves, levels; 8bit just falls apart

[Gavino]

I think what's going on is this.
There are only 256 histogram bins, each covering a range of 128 32-bit values.
The V210 input has (I think) 880 (220*4) different values, ie the usual [16, 235] expanded from 8 bits to 10.
So some of the histogram bins will cover 3 input values and some (roughly 7 in 16) will cover 4. Hence the spikes.

In the other histogram, there are only 220 input values, so we get 35 missing RGB values, ie the black gaps in the histogram.

[kolak]

Thanks poisondeathray and Gavino.
This is what I expected.
When I export your 16btr RGB ramp file to 10bit 4:4:4 BM codec all spikes gets soften- AE show smooth histogram, so I think you're right :) Does it mean codec is 4:4:4 capable? New Canopus HQX 10bit (4:2:2) codec also smooth them, so does it mean it's actually 4:4:4 capable?

Is this histogram test 100% accurate to say if converted video is 10bit or not (eg. for codec, workflow testing)?

Yes- 8bit falls very quickly during grading.

Thanks,
Andrew

[poisondeathray]

kolak - the ramps I uploaded were all v210 , but derived from 16bit RGB (so the name might be misleading) - so none of them were 4:4:4 (I don't think the sampling would matter much for greyscale anyway) . If you want I can upload some other patterns for testing, like color ramps with 10-bit 4:4:4 RGB. If you have AE, this is pretty simple to make also

I'm not sure what you mean by "Does it mean codec is 4:4:4 capable? " - can you explain ?

There are 10-bit 4:4:4 Y'CbCr and RGB variants, I think BM has both




Is this histogram test 100% accurate to say if converted video is 10bit or not (eg. for codec, workflow testing)?

No, because you need a nice gradient . If you use a regular live action footage (e.g. from a film scan, cinema camera etc....) , you won't necessarily detect it. You need a shot with a pure gradient, and that might be hard to find, unless you shot it on purpose .

Even if you convert 8-bit Y'CbCr footage to v210 , and work in a 16-bit or 32-bit workspace - there are benefits over working in an 8-bit workspace with native 8-bit footage. You can apply 2 instances of levels filter (the 2nd one is to monitor changes in the histogram) , If you make adjustments to the 1st instance, you will see much more banding than if you used native 8-bit footage (instead of transcoding to v210)

But the avisynth import definitely indicates a problem - because there is quantization even before you 've made any manipulations. Even if you started out with 8bit gradient, it wouldn't be that bad as in that screenshot

What gavino says above is also true when any Y'CbCr is exported from AE - it's not using full range






<a bit off topic here>
If we were to use "full range" Y'CbCr in 8-bit distribution format , there would be a lot less banding (a lot of the banding can be attributed to the truncated range) , but of course this isn't feasible for stuff like blu-ray , dvd

e.g. Flash supports full range flag . Here are 2 examples, one is full range, one is standard range (both Y'CbCr data, and "flagged" using x264)
So the full range is decoded to RGB for display properly

(blip.tv hosts original file, so you couldn't do this with youtube for example, which would re-encode and display as Rec.709)

ConvertToYV12() No flags
http://www.blip.tv/file/4409086

http://i51.tinypic.com/2qwk6qa.png



ConvertToYV12(matrix="PC.709") Fullrange flag
http://www.blip.tv/file/4409087

http://i51.tinypic.com/xenccj.png

[kolak]

I know about avisynth being 8bit- wish for more :)

I know that your file is 10bit 4:2:2 (just converted form 16bit RGB), but once exported through BM 4:4:4 codec all spikes are gone- gradient is smooth.
Based on you explanation, I assume that when codec is capable of 4:4:4 there won't be spikes or there will be much less. This seams to be true- any 4:4:4 codec smooths spikes during my tests. Any 4:2:2 kept them or make even more.
The only problem was with HQX codec (oficially 4:2:2), but it also removes spikes- so maybe it's internally 4:4:4. This was my question- are removed spikes prove that codec is 4:4:4?

With full range you have 255 levels with YUV 220- not?

Thx,
Andrew

[poisondeathray]

I see spikes with BM4:4:4 if the source is v210 (i.e. taken from that sample) - it won't "fix" the spikes or fill in the missing data . I tested with BM 10bit 4:4:4 RGB fourcc is "r210" . Can you upload sample where "spikes" are fixed ? I can't replicate your results

4:4:4 shouldn't be much different than 4:2:0 for a greyscale image . I think the difference is Y'CbCr <=>RGB conversions not in full range and colorspaces not overlapping completely, not an issue sampling . For example if you use sheervideo, it has a 10-bit 4:4:4 Y'CbCr format, and you still see "spikes"


With full range you have 255 levels with YUV 220- not?

For 8-bit , 2^8 = 256 ; and 10-bit would be 2^10 = 1024 for full range values

BTW, I'm not worried about the "spikes", the banding is the real problem that manifests as real banding when viewed normally

[Gavino]

4:4:4 shouldn't be much different than 4:2:0 for a greyscale image . I think the difference is Y'CbCr <=>RGB conversions not in full range and colorspaces not overlapping completely, not an issue sampling.
I agree.
As I said, the spikes come from the reduced range in Y'CbCr, and the chroma sampling is irrelevant for grayscale.

[kolak]

Hmmm- after exporting to BM 4:4:4 (with AE set to 16bit) spikes are gone.

http://img40.imageshack.us/img40/1417/17330029.jpg

Source:

http://img541.imageshack.us/img541/2297/source.jpg


Andrew

[Gavino]

Have you posted the wrong image for BM 4:4:4?
Those two are the same.

Edit: OK, I see you've fixed it.

[poisondeathray]

You're using that v210 as source input ?

I cannot reproduce your results... with BM 444 RGB (r210)

Can you upload that sample?

[poisondeathray]

oh I think I know what you have done - you used BM in AVI container in "millions" of colors. This is 8-bit only

Have a look at the project panel when you highlight the clip in the clip bin - it will say "millons" of colors instead of "trillions"

256x256x256 =~ 16.7M for 8-bit

If you need convincing, do the 2 levels test described earlier - the 8-bit sample will fall apart, but the true 10-bit won't

The "true test" is seeing how it reacts to changes in levels, curves etc.... you will see it break up and band (not just "spikes")

[kolak]

oh I think I know what you have done - you used BM in AVI container in "millions" of colors. This is 8-bit only

Have a look at the project panel when you highlight the clip in the clip bin - it will say "millons" of colors instead of "trillions"

If you need convincing, do the 2 levels test described earlier - the 8-bit sample will fall apart, but the true 10-bit won't

The "true test" is seeing how it reacts to changes in levels, curves etc.... you will see it break up and band (not just "spikes")

Yes- AVI and AE says Milion Colors, but I thought it's AE bug.

Here is sample anyway:

http://www.mediafire.com/?5ms8stfsks8adfa

I'm testing on laptop, so can't judge by look :)

This is what I noticed- if you just import it looks fine, but after any color operation falls :)
Importing tells nothing:) !

So AE is correct- if it says Trilion colors than it will have access to 10bit, but can footage be 10bit, but AE not see it?

Andrew

[poisondeathray]

Actually you can't export in "trillions" using BM codec for AVI container (I think it's BM bug, not AE bug). You need MOV container, and it will "unlock" those settings in the export dialog

[kolak]

I'm still confused :)

I can't see any difference after applying curves effect. Your v210 and my BM looks the same ??
It's not clear- not easy to tell, but I think I found nice curve shape, so it show more clear :)

Andrew

[poisondeathray]

Importing tells nothing:) !


So AE is correct- if it says Trilion colors than it will have access to 10bit, but can footage be 10bit, but AE not see it?



Importing does tell you something - if banding is there (not spikes) , like it is in avisynth import - then it has already been quantized

Just because it says "trillions" doesn't mean anything. It will say "trillions" to any v210 encoded sample - even if the source was 8-bit

AE in 16-bit (or 32-bit) mode will interpolate those values and reduce banding for the intermediate calculations, but not reduce the banding that has already been "baked in". (i.e. it will help to reduce new banding from your manipulations)

[poisondeathray]

I'm still confused :)

I can't see any difference after applying curves effect. Your v210 and my BM looks the same ??


Andrew


You need 2 instances of levels

or

1 curves plus 1 levels

The 2nd instance of levels is just for monitoring puposes (don't touch the controls)

There should be big difference

[kolak]

The 2nd instance of levels is just for monitoring puposes (don't touch the controls)

There should be big difference

This is what I have done, but it's not obvious at all.


Andrew

[kolak]

Importing does tell you something - if banding is there (not spikes) , like it is in avisynth import - then it has already been quantized

Just because it says "trillions" doesn't mean anything. It will say "trillions" to any v210 encoded sample - even if the source was 8-bit

AE in 16-bit (or 32-bit) mode will interpolate those values and reduce banding for the intermediate calculations, but not reduce the banding that has already been "baked in". (i.e. it will help to reduce new banding from your manipulations)

Yes- but can it say milion and still be able to use 10bit (if codec is really 10bit)?


Andrew

[poisondeathray]

This is what I have done, but it's not obvious at all.



http://i52.tinypic.com/hv8fhz.jpg


http://i55.tinypic.com/2yo9y81.jpg


apply the change to the 1st instance , copy & paste the exact filters to the other layer or sequence (if you're not using a different comp, then solo the layer)

[poisondeathray]

Yes- but can it say milion and still be able to use 10bit (if codec is really 10bit)?





Not in my testing. It will "break apart" . See the screenshots above

But if it says "trillion" that still doesn't mean much, it just means it was encoded with 10-bit format , but the content can still be from 8-bit source

[kolak]

http://i52.tinypic.com/hv8fhz.jpg


http://i55.tinypic.com/2yo9y81.jpg


apply the change to the 1st instance , copy & paste the exact filters to the other layer or sequence (if you're not using a different comp, then solo the layer)

Yes- it works, just my laptop screen is very bad and these spikes make it less clear.

Andrew

[kolak]

Not in my testing. It will "break apart" . See the screenshots above

But if it says "trillion" that still doesn't mean much, it just means it was encoded with 10-bit format , but the content can still be from 8-bit source

Yes- it can say 10bit, but what is inside is other problem :)
There is some AVI header tweak to enable 10bit- is this what is missing for AE to some files at 10bit? I know that eg. Canopus HQX codec is 10bit, but AE sees only 8 :(


Andrew

[poisondeathray]

these spikes make it less clear.


less clear ? can you see the difference between the 2 screeenshots ?

the "banding" is the real problem - because that correlates with percieved banding on the screen when you're watching it. The "little spikes" have little to no value IMO.

Please differentiate these 2. The "banding" splits the histogram into quantized values (the splits go from the base of the histogram all the way up) , but when using 10bit (trillions) source, there is no quantization, when the same adjustments are made

[poisondeathray]

Yes- but can say 10bit, but what is inside is other problem :)
There is some AVI header tweak to enable 10bit- is this what is missing for AE to some files at 10bit? I know that eg. Canopus HQX codec is 10bit, but AE sees only 8 :(



Not sure; would have to do some testing

I don't have canopus lossless on this computer, but I think I have it with another computer that has edius installed - I'll get back to you on that

It seems only v210 is the only "AVI" wrapped format that works as 10-bit? But I think cineform works ok too (but this isn't lossless)

[kolak]

Not sure; would have to do some testing

I don't have canopus lossless on this computer, but I think I have it with another computer that has edius installed - I'll get back to you on that

It seems only v210 is the only "AVI" wrapped format that works as 10-bit? But I think cineform works ok too, and DNxHD (but these aren't lossless)

Yes- v210 and Cineform. Cineform use to have special importer for AE, which was designed to read 10bit AVIs.

Read this (from creativecow forum):


AVI is just a Container, as well as Quicktime is. The bitcount of a frame is stored in the "Video Stream Format"(strf) a part of the AVI header.
Indeed in Microsoft's AVI standard only specific values for bitCount are defined namely: 0, 1, 4, 8, 16, 24 and 32 bit per pixel.
(msdn.microsoft.com:BITMAPINFOHEADER)

But it is also true that the length of the biBitCount variable in the struct BITMAPINFOHEADER is WORD which means 2 bytes or
16 bits unsigned integer values form 0 to 2^(16)-1=65535. So even files with 30 bit (3 * 10bit for R+G+B) per pixel or even more can be stored.
The pixel organisation of the 10bit 4:2:2 YUV codec of Decklink HD is shown here http://developer.apple.com/quicktime/icefloe/dispatch019.html#v210
And if you say this is only Quicktime then I can tell you that the "mplayer for windows" (a port of "mplayer for linux") can display 10bit Mov files by using the Video for Windows library BMDCodecLib.dll the AVI codec of the Decklink HD.
As I said before AVI is just a container.

You said "... adds code to Premiere Pro, which in part rewrites the AVI (the wrapper) to allow it to use 10 bit"
In principle the only thing that has to be changed in the AVI header itself is a single number to move from 8bit to 10bit per color component.
If the Decklink render engine would be better then 10bit export would be possible for this codec as well, but unfortunately it is not.



Andrew

[poisondeathray]

Just don't use AVI container :)

Plenty of other options. Image formats are usually better (OpenEXR, TIFF, PNG, DPX) for compositing apps like shake, nuke , AE, etc... You can use render farm that way. You can't with AVI.

[kolak]

Heheh :)
I would prefer AVI- don't do grading, but would like to have 10bit workflow.


Andrew

[kolak]

It's v210 FOURCC what tells AE to decode files as 10bit- I don't think that there is anything else.
It's enough to change header in 8bit file to v210 and AE reports Trillion colors, so it's quite bad, because even if you have 10bit codec AE will see only 8bit.


Andrew

[madshi]

Hey guys,

I'm working on adding direct v210 rendering support to madVR. The samples in this thread are quite useful for that - so thanks! Does anybody happen to have samples for other QuickTime uncompressed video FourCCs, too? Would like to add support for those, too. Samples for any of the following would be much appreciated:

YCbCr: v308, v408, v216, v410, v416
RGB: ABGR, RGBA, b48r, b64a

[poisondeathray]

Hey guys,

I'm working on adding direct v210 rendering support to madVR. The samples in this thread are quite useful for that - so thanks! Does anybody happen to have samples for other QuickTime uncompressed video FourCCs, too? Would like to add support for those, too. Samples for any of the following would be much appreciated:

YCbCr: v308, v408, v216, v410, v416
RGB: ABGR, RGBA, b48r, b64a

Besides RGBA, these are not commonly used formats

I included a single frame of ABGR and RGBA here
http://www.mediafire.com/?081ujc8hpl8hp9c

Some versions of FFMPEG or FFMBC have support for other pixel formats like yuv444p and yuv444p16le - which I think should correspond to v308 and v410, respectively, but I'm not sure how valid they are yet.

If you are linux user, libquicktime can encode/decode v308, v408, v410 (I tried compling for PC, but apparently it's Nix only)

http://libquicktime.sourceforge.net/

[kieranrk]

I'm working on adding direct v210 rendering support to madVR.

When I get round to sending it for review, there will be some SSE2 SIMD in ffmpeg/libav for unpacking v210. If I remember rightly it was about 30% faster. I'm pretty sure there's more that could be squeezed out of it mind you.

[madshi]

Besides RGBA, these are not commonly used formats

I included a single frame of ABGR and RGBA here
http://www.mediafire.com/?081ujc8hpl8hp9c
Thanks a lot! I've confirmed that these already work well with my work in progress madVR version.

I know that these formats are not very commonly used. I was just trying to find standards for accepting 8bit, 10bit and 16bit formats with 4:2:0, 4:2:2, 4:4:4 and RGB for my renderer, and then ended up trying to support all of them I could find specs for. It seems that any format other than the typical 8bit 4:2:0, 4:2:2 and RGB formats are rarely used at this point in time. So I'm having a hard time collecting samples for testing...

If you are linux user, libquicktime can encode/decode v308, v408, v410 (I tried compling for PC, but apparently it's Nix only)
Unfortunately I'm a Windows user with zero Linux experience.

When I get round to sending it for review, there will be some SSE2 SIMD in ffmpeg/libav for unpacking v210. If I remember rightly it was about 30% faster. I'm pretty sure there's more that could be squeezed out of it mind you.
Oh, thanks for the note. Currently I'm using simple C++ code. I guess I could speed up many of my internal reorderings by making use of ffmpeg/libav.