Question re: 10&12 bit color

Erhm... AVISynth uses either 12, 16, 24 or 32 bit color. The colorspaces using those bpps would be: 12: YV12 16: YUY2 24: RGB24 32: RGB32 What colorspace uses 10 bit and why do you think AVISynth should support it?

Wow, that was quick! Sorry, what I mean is 10+10+10 =30bit w/o alpha. I have seen RGB24 refered to as 8 bit color because each of the primary colors gets 8 bits. JVC's very new(apparently not yet for sale) CMOS based HD box camera outputs raw HD-SDI at 10 bits per color channel. I would like to use a PCI based encoder card to caputure in MPEG2 at about 100Mb/sec. More about this here:

While I'm at it, here is a real curiosity question: How hard would it be to compile/produce a native 64 bit version of AVISynth to take advantage of the new Athlon64?

Is there a standard for mpeg2 using 10 bit/color/pixel colorspace? I thought all mpeg2 was yv12, effectively "8 bit" (or less) color.

Mpeg2 supports YUV2 and 10 bit per color channel. Think about it now that Radeon supports also 10 bit per color channel and a 10 bpcc has been proposed for the DVCPRO format.Also BetaDigi works in 10 bit and the new HDCAM SR.Everything is going to 10 bits per color channel. The new big format TFT also supports 10 bit color channel because the bigger you go the more you notice 8 bit per color channel banding arctifacts.

About color depth : 10 bits allows to pack a pixel in an int (thus restoring RGB24 lacking alignment). But in the order hand, its processing is likely to be quite slow, since it needs constant bit manipulations... So there won't be 10 bits depth ever, but you may have 16 (15 to avoid int overflow issues) someday. Actually I just need someone to state he will make filter code for RGB48 and/or YV888 (just invented the names) and I will make the colorspace available. About AMD64: I guess I could have 3.0 support it, branching filters to specific subclasses as needed. But all the asm code needing to be rewritten still need to be rewritten... About Python: The point is not to make Avisynth all python (impossible), but to allow filter chain creation/manipulation through Python. That would be an entry point to avisynth for apps without having to directly interface with it. Anyway it's far from being on the TODO list at the time being. About portability: Avisynth does not care how OSes handle video, since avisynth handles video as avisynth does, and not as they does. Avisynth is not tightly bound to Windows, it imports/exports video through VFW/COM but it only affects AVISource/DirectShowSource (and the trick so .avs pass in mplayer) It will probablt not that hard to have the equivalent done for Linux or others... What it is bound to is VC++, since there are hundreds and hundreds of lines of inline asm which he is the only one able to compile.

is the best troll I've read in quite a while! Cheers!

As I already stated, if you (or anybody else) feel like coding 15 bits depth (15, not 16) versions of filters, please do so. And I will include it in 3.0.

15-bit bpc, what does the free bit do?

If I understodd sh0dan explanations correctly, MMX DO want the 16th bit to be a sign bit (when we don't). So we just have to give up this one. (or not use MMX)