Sane ProRes 422 to RAW 10-bit YUV?

[Daemon404]

Okay, so, I have a 10-bit 4:2:2 clip in ProRes format. My goal is to IVTC it without converting to 8-bit at any point.

Currently, I'm simply trying to get raw 10-bit YUV from the ProRes file (v210 is acceptable, and so is p210). Once I get that, I can write my own app and/or plugin to apply IVTC based on e.g. a fieldhints override file, while still working in a 10-bit colorspace.

Keep in mind I do not have a Mac, so I cannot use Final Cut Pro to do this. Adobe After Effects can work in a 32 bpc colorspace internally, and render to v210... however it also only works in RGB internally, so there is an unnecessary conversion to RGB in between. Premier claims to support high bit depth YUV internally, but when I've tried in practice, it always seems to convert to 8-bit internally anyway, even with "Max Dit Depth" enabled. (I confirmed this by comparing histograms).

Then there is QTInput, but that seems to ALWAYS output ProRes as 8-bit YUV, even if I want to just dump the raw YUV by modifying its sources.

My question is... is there any possible way to get ANY form of raw 10-bit YUV out of a ProRes encoded file on Windows? I know it IS possible, using the QuickTime API, but I do not know if anything at all is able to do this without adding any other unnecessary conversions (e.g. to RGB) in between.

I do not have enough knowledge of the QuickTime API to patch QTInput to dump, e.g. v210 from a ProRes input.

Sorry if this is in the wrong forum... the problem is a bit ambiguous.

Help is much appreciated :).

[jmac698]

That's why I wrote Deepcolor Utilities. Now Sashimi supports it as well, I believe.
http://avisynth.org/mediawiki/High_bit-depth_Support_with_Avisynth
Interesting, I forgot to mention my own script on the wiki...

[poisondeathray]

That's why I wrote Deepcolor Utilities. Now Sashimi supports it as well, I believe.
http://avisynth.org/mediawiki/High_bit-depth_Support_with_Avisynth
Interesting, I forgot to mention my own script on the wiki...


Can you export 10bit now without truncating? The last time I tested , only import worked - has something changed ?

@Daemon404 - Quicktime Pro on the PC can convert prores422 => v210, keeping 10bit YUV

[mp3dom]

Is it also actually possible to:
1) Import a v210 (AVI or MOV) as a true 10bit
2) Add additional debanding in 16bit
3) Dither down the 16bit clip to a final 8bit clip?

[Daemon404]

Can you export 10bit now without truncating? The last time I tested , only import worked - has something changed ?

@Daemon404 - Quicktime Pro on the PC can convert prores422 => v210, keeping 10bit YUV

You cannot import prores422 with deepcolor utils, as far as I can see. Only v210.. and even that gets truncated to 9-bit. In fact, QTInput doesn't even seem capable of returning 10-bit from prores.

Also, Quicktime Pro cannot seem to export v210... easily anyway on PC? I looked and all I could find was "None", which is RGB. v210 isn't even listed as an option. Is it perhaps hidden somewhere?

Edit: In fact, QuickTime on Windows (the player) can't even play v210. (I'm trying to play your ramp clips).

[poisondeathray]

You cannot import prores422 with deepcolor utils, as far as I can see. Only v210.. and even that gets truncated to 9-bit. In fact, QTInput doesn't even seem capable of returning 10-bit from prores.


That's what I mean . You can open it up, but cannot get 10bit out . As soon as it touches avisynth it's no longer 10-bit


Also, Quicktime Pro cannot seem to export v210... easily anyway on PC? I looked and all I could find was "None", which is RGB. v210 isn't even listed as an option. Is it perhaps hidden somewhere?

You need exteral library e.g. aja codecs, blackmagic codecs, drastic codecs. v210 will show up in export menu of QTPro

Prores is closed proprietary format. The only way to decode it 10bit is through Apple software. But supposedly there is a patch for mplayer / mencoder floating around for Prores support, but I've found nothing as of yet



Edit: In fact, QuickTime on Windows (the player) can't even play v210. (I'm trying to play your ramp clips).


Do you have "Pro" installed and/or one of the v210 codecs listed above?

[Daemon404]

You need exteral library e.g. aja codecs, blackmagic codecs, drastic codecs. v210 will show up in export menu of QTPro

Where should I go looking for this?

Prores is closed proprietary format. The only way to decode it 10bit is through Apple software. But supposedly there is a patch for mplayer / mencoder floating around for Prores support, but I've found nothing as of yet

Yes, and it is annoying as hell.

Do you have "Pro" installed and/or one of the v210 codecs listed above?

I do have QuickTime Pro (yes, pro) installed.

[poisondeathray]

Where should I go looking for this?


They come with capture card hardware, but I think you can you can download the codecs for free off the manufacturer's site

[Daemon404]

They come with capture card hardware, but I think you can you can download the codecs for free off the manufacturer's site

I found BlackMagic's free codec install, however, when trying to export a sample prores file as blakcmagic 10-bit, I get:

Error -8961: an unknown error occurred

The sample in question is here: http://samples.mplayerhq.hu/V-codecs/HCPA/AppleProRes422.mov

Google says perhaps it has to do with res/framerate?

[ganymede]

Prores is closed proprietary format. The only way to decode it 10bit is through Apple software. But supposedly there is a patch for mplayer / mencoder floating around for Prores support, but I've found nothing as of yetYes, and it is annoying as hell.The ProRes decoder for mplayer can be downloaded from here : http://samples.mplayerhq.hu/drivers32/new/AppleProResDecoder.qtx. It must be copied in the "codecs" folder.

[poisondeathray]

The ProRes decoder for mplayer can be downloaded from here : http://samples.mplayerhq.hu/drivers32/new/AppleProResDecoder.qtx. It must be copied in the "codecs" folder.



Thanks!

I not that familiar with mplayer, does this prores decoder work on PC ?



I'm fiddling with mplayer and -vf help lists some IVTC filters, but I don't know if /how well they work . Anybody have experience with them ?

ivtc inverse telecine
detc de-telecine filter
divtc inverse telecine for deinterlaced video

[Daemon404]

Thanks!

I not that familiar with mplayer, does this prores decoder work on PC ?

I'm fiddling with mplayer and -vf help lists some IVTC filters, but I don't know if /how well they work . Anybody have experience with them ?

ivtc inverse telecine
detc de-telecine filter
divtc inverse telecine for deinterlaced video

I haven't really been able to get it to work / or get much useful out of it, personally. All of its filters work in 8-bit afaik, and I'm not sure mplayer would ever even see the 10-bit video.

Now back to stabbign quicktime to work...

[poisondeathray]

I found BlackMagic's free codec install, however, when trying to export a sample prores file as blakcmagic 10-bit, I get:

Error -8961: an unknown error occurred

The sample in question is here: http://samples.mplayerhq.hu/V-codecs/HCPA/AppleProRes422.mov

Google says perhaps it has to do with res/framerate?


Conversion is not working for me either. Other prores files (straight from camera, aja ki pro, fcp work fine) . I suspect something is "different" in that sample causing QTPro on windows to not like it

EDIT: in fact other formats don't export either like animation, png - I suspect it's the Windows Prores decoder implementation or something peculiar about that file

[Daemon404]

Conversion is not working for me either. Other prores files (straight from camera, aja ki pro, fcp work fine) . I suspect something is "different" in that sample causing QTPro on windows to not like it

EDIT: in fact other formats don't export either like animation, png - I suspect it's the Windows Prores decoder implementation

The strange part is that I can export to None.

Update: I can indeed export to PNG and Animation here.

[poisondeathray]

The strange part is that I can export to None.


Yeah, I just tried that "none" and it's hanging too



Then I tried other Prores files and it works.

Not sure what's going on...

[Daemon404]

Yeah, I just tried that "none" and it's hanging too

Then I tried other Prores files and it works.

Not sure what's going on...

Have you tried any BFF/TFF files? Files with non-square pixels?

I don't have an abundance of samples with me at this very moment.

Either way, thank you.

[poisondeathray]

Have you tried any BFF/TFF files? Files with non-square pixels?

I don't have an abundance of samples with me at this very moment.



Not really, everything I deal with is usally HD, progressive

If you think it's BM causing the issue on your end, you can try one of the other v210 codecs

[Daemon404]

Not really, everything I deal with is usally HD, progressive

If you think it's BM causing the issue on your end, you can try one of the other v210 codecs

Sure. Im not sure who else makes QT-compatible v210 codecs though. Adobe wrote their own, but it is only accessibly from within their apps.

[poisondeathray]

Sure. Im not sure who else makes QT-compatible v210 codecs though. Adobe wrote their own, but it is only accessibly from within their apps.

Drastic is free too
http://www.drastictech.com/download_codec.html

[Daemon404]

Drastic is free too
http://www.drastictech.com/download_codec.html

That one works with the problem clip, but ironically fails on stuff that worked with BM. lol.

[jmac698]

kona 4.2.1, blackmagic design 7.9, cineform 3.2.2.185, dtcodecs3.0.0, drastic
ffvideosource() will open v210 in mov or avi , but it will become 8-bit
if you have drastic codecs installed, avisource() will open v210 in avi
qtinput, can also dither to 8 bit
qtsource, it'll open v210 in mov or avi
Virtualdub reads v210 directly
Sashimi reads v210 and output in 16bit within avisynth
http://www.videohelp.com/tools/ffmbc#features
support decoding or encoding v210

ffmpeg encodes v210 or more - this is recent. need to check.


Is it also actually possible to:
1) Import a v210 (AVI or MOV) as a true 10bit
2) Add additional debanding in 16bit
3) Dither down the 16bit clip to a final 8bit clip?

Yes, dither or flash3kyuu_deband does the processing, encode to 10bit with this, for example:

avs2yuv -raw "script.avs" -o - | x264-10bit --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24 --output "out.mp4"

The script itself needs to return a special stacked 16bit video format, the function for this included in the plugins/scripts.

Give me a sample in v210 at least (even some simple animation in 24->30fps) to IVTC and I can work it out.

ps the actual script to read v210 to high bit depth is here
http://forum.doom9.org/showthread.php?p=1486552
It returns an 8 bit image by default, a few lines of code would be necessary to put it into the proper stacked 16bit format. Looks like a little bit of work and testing. Also the link to download sashimi is dead :(

[mp3dom]

Sashimi can be downloaded from here: https://sites.google.com/site/ourenthusiasmsasham/open-source-software#TOC-Sashimi
The latest version is 0.81b. By the way I've tried the ReadV210 function posted in the same thread but the result is a pure green/pink image (I've tried on a 23.98p v210 source with true 10bit informations).
My needs are not to encode 10bit AVC but to postprocess a v210 file at 16bit level (to have the max precision) and dither to 8bit at the very end to encode at 8bit AVC.
Strangely I have found that if I have a 10bit video with bands and I dither to 8bit with Floyd-Steinberg + random noise, the final 8bit clip will keep the banding (this is normal, as the bands is on the source) but makes successive dithering (with dither or flash3kyuu) ineffective (the dither is not applied, probably due to the random noise). Ironically I'm getting better results with truncating 10bit to 8bit and then applying dither or flash. So my idea was now to deband at 16bit level prior of bit-depth dithering (or try to dither without random noise)

[kolak]

If you have ProRes or DNxHD 10bit you will be better using After Effect and converting it to v210 QT or AVI. AE does see 10bit in both and can output common v210. From here it my be easier to get somewhere with avisynth.

Episode from TeleStream (500$, Winodws version) can convert v210 to ProRes keeping 10bit- at least this what I have been told by their support just few days ago. I assume it can do opposite also.

Free DaVinci Lite should be also able to convert ProRes to v210 QT keeping 10bit, but you need MAC.

Andrew

[kolak]

Strangely I have found that if I have a 10bit video with bands and I dither to 8bit with Floyd-Steinberg + random noise, the final 8bit clip will keep the banding (this is normal, as the bands is on the source) but makes successive dithering (with dither or flash3kyuu) ineffective (the dither is not applied, probably due to the random noise). Ironically I'm getting better results with truncating 10bit to 8bit and then applying dither or flash. So my idea was now to deband at 16bit level prior of bit-depth dithering (or try to dither without random noise)

It means your 10bit source file is crap and has nothing to do with 10bit :) It already went through 8bit chain and you need tools to mask banding (as you found out).
MS XScaler filter does nice job on real 10bit sources when going to 8bit.
It was/is part of PEP encoder, which was given for free some time ago. You could try contacting MS (Ben?)- maybe you can get it for free.

Andrew

[Daemon404]

If you have ProRes or DNxHD 10bit you will be better using After Effect and converting it to v210 QT or AVI. Ae does see 10bit in both and can output common v210. From here it my be easier to get somewhere with avisynth.

Episode from TeleStream (500$, Winodws version) can convert v210 to ProRes keeping 10bit- at least this what I have been told by their support just few days ago. I assume it can do opposite also.

Free DaVinci Lite should be also able to convert ProRes to v210 QT keeping 10bit, but you need MAC.

Andrew

As I mentioned earlier in this thread, using AE isn't really a good idea, since it works internally with RGB, so you are introducing an unnecessary colorspace conversion. I ended up using QT Pro + BM v210, then writing my own code to apply IVTC (worked btw!).

[kolak]

You can set working colorspace in AE and than even if it goes to RGB mode it won't matter (AE works in very high precision).
Your final files will be fine- as far as remember I've tried it and everything was fine. It's also quite fast- real time or faster on good PC.

Does conversion in QT Pro preserves 10bit? I'm not sure about it.

I have some DNxHD 10bit file which I need to convert to v210- can I simply use QT PRO?


Andrew

[jmac698]

So where does that leave us? Is the main problem just reading in a 10bit file? If you post a sample I will update my deepcolor tools to work with it, and also make it more compatible with dither etc.

[kolak]

YES- reading is the main issue!
We have few filters which could do something with 10bit source, but we can't read 10bit source :)
I can create some samples- eg. v210, DNxHD, ProRes movs.

[poisondeathray]

Does conversion in QT Pro preserves 10bit? I'm not sure about it.


yes it does


I have some DNxHD 10bit file which I need to convert to v210- can I simply use QT PRO?


You can, but QT treats DNxHD as RGB, and you will get gamma shift as well



YES- reading is the main issue!
We have few filters which could do something with 10bit source, but we can't read 10bit source :)
I can create some samples- eg. v210, DNxHD, ProRes movs.

You can read 10bit sources right now, I think the problem is keeping 10bit and not truncating the data

right now:
10bit => 8bit maybe 9bit? => 16 bit => final format

ideal:
10bit => 16 bit => final format

[Daemon404]

You can set working colorspace in AE and than even if it goes to RGB mode it won't matter (AE works in very high precision).

The fact that AE can work in 32 bpc RGB is not relevant. It is still doing and unnecessary conversion from YUV -> RGB -> YUV. That is not acceptable in many cases. :)

[Mug Funky]

@ Kolak: the conversion from 4:2:2 to RGB and back again introduces horizontal blur. there's not really a way around that.

[mp3dom]

It means your 10bit source file is crap and has nothing to do with 10bit :) It already went through 8bit chain and you need tools to mask banding (as you found out).

Quite possible :)
It's animation so while it contains true (verified) 10bit informations, they probably have switched back and forth using different color space or bit-depth prior to finally output the data to HDCAM-SR. So now I have a 10bit data with banding present on source.


MS XScaler filter does nice job on real 10bit sources when going to 8bit.

It's exactly the tool I've used :)

[jmac698]

I assure you you can read true 10bit, there was some mention in the description of Deepcolor Utils of 9 bit, but there is a mode to work around that. It's because I'm reading the file raw, and have to guess the header size. If you want fully automatic reading, the best I can do is 9bit for now (though I know a way around that).
I only need a sample of a v210 file that you can't read.

Conversion of 'rgb safe' colors to/from yuv is lossless with 2 extra bits. I know this because I derived the SMTPE colors bars for avisynth 2.56, and I noticed the color yellow needed 10 bits. For 10bit yuv I'd assume you need 12bits rgb. What does 'rgb safe' mean? The color -I (a kind of purple, from YIQ) gives negative red which can't be displayed, we picked the same tint with reduced saturation to represent it.

If there's a problem in the conversion, it's in the implementation. If there's an attempt to upscale the chroma in converting to RGB, it won't be mathematically accurate anymore to convert back. So yes, I'd avoid conversions unless you know what it's doing.

[kolak]

The fact that AE can work in 32 bpc RGB is not relevant. It is still doing and unnecessary conversion from YUV -> RGB -> YUV. That is not acceptable in many cases. :)

Yes- I would prefer direct conversion in YUV, but if I can't see any difference on 4x zoomed frame than for me it's fine.

[kolak]

@ Kolak: the conversion from 4:2:2 to RGB and back again introduces horizontal blur. there's not really a way around that.

I'm going to check it today- all grading software works in RGB (not?).
I think I have seen in in QT conversions, but not AE.

I think I already checked it in AE and I have not seen any blur- I zoom frames 4x. If there is some change below this than I don't really care- it will became 4:2:0 on BD anyway.

[kolak]

yes it does



You can, but QT treats DNxHD as RGB, and you will get gamma shift as well



Hmmm- DNxHD imported to Edius does not introduce any shifts, even if Edius sees RGB data coming (I also compared it to QT read by avisynth qtinput in YUY). Some time ago there were shifts- latest DNxHD decoder seams to be different.

[kolak]

Actually nothing works properly- nightmare :)
Can't convert to v210 in any way which would keep colors/gamma intact.

[Daemon404]

Actually nothing works properly- nightmare :)
Can't convert to v210 in any way which would keep colors/gamma intact.

Have you tried ffmbc?

Link: http://code.google.com/p/ffmbc/

[kolak]

I don't know how to compile it. If someone can provide exe file that would be nice.

I think I managed to do it with Premiere (surprise:) ), but need to check it properly.

Thanks,
Andrew

[mp3dom]

FFmbc 0.6 x86: http://www.mediafire.com/?z5g7ez123o9k5qh
FFmbc 0.6 x64: http://www.mediafire.com/?wu5w2cwqmimqjum

Let me know how it perform with v210. Thanks.

[kolak]

OK- thanks.

Nope- DNxHD in ffmbc is only 8bit currently- decoding and encoding:(

Mainconcept has VC-3 decoder with v210 output pin- going to try this (even if it's a demo version). It also supports DNxHD in MXF.


Andrew

[Gser]

Sounds like it would just be more easier to dual boot windows and OSX or just use it as a virtual OS.

[smok3]

FFmbc 0.6 x86: http://www.mediafire.com/?z5g7ez123o9k5qh
FFmbc 0.6 x64: http://www.mediafire.com/?wu5w2cwqmimqjum

Let me know how it perform with v210. Thanks.

interesting projects, but with the lack of any realy documentation/'give me 35 examples' also utterly useless (yes i know about the -h switch).

[Yellow_]

MpegStreamclip?

Out of interest when AE & Premiere are discussed is this version 5 or 5.5 or earlier?

[kolak]

Yes- CS 5 (correction from CS5.5)

I converted with Compressor (and FCP) and v210 was not real V210 (just 8bit in v210) and also problems with colors in case of FCP- real nightmare :)

[kolak]

Looks like my DNxHD file at home was 8bit.

Tried different one and have some message that DNxHD is 10bit, but conversion does not happen- video pixel format is unknown error.

Any suggestion?

Andrew

[kolak]

Ok- after 3 days of testing/trying I managed to convert DNxHD to v210 preserving 10bit/colors/gamma. Only one way which I found to work is AE, but.....don't use latest AVID 2.3.4 codecs. There seams to be bug in this version- as far as 8bit works fine, after switching AE to 16/32bit there is small color shift (at least with AE CS5). Going to Avid codecs ver. 2.2.1 solves issue. Conversion is quite slow, but seams to work fine- I don't see any blur or even smallest color difference even at 400% zoom.
I also got an update about Telestream's Episode- version 6.2 will expand 10bit possibility and will preserve 10bit between DNxHD, ProRes, v210 conversion.

Another bad news is that Mainconcept MXF demuxer (ver 9) is not working anymore with AVID MXF DNxHD streams. It was working after Mainconcept fixed it some time ago, but it looks like AVID has changed something again.

FFmbc does not work with AVID MXF DNxHD files neither (neither with 1:1x codec even if this is just simple 2vuy stream).

What a pain in the xxxx :)

Andrew

[jmac698]

Great, now if you can post a sample I can IVTC it...

[kolak]

??

I'm talking about something different, but ProRes should work fine in AE. I had 10bit DNxHD file, which I needed to dither to 8bit.


Andrew

[jmac698]

Your first post,

Once I get that, I can write my own app and/or plugin to apply IVTC based on e.g. a fieldhints override file, while still working in a 10-bit colorspace.

I thought you still needed to process in Avisynth. But if you have this v210 file and it works in other pro tools, I'm sure they can IVTC and dither?

[kolak]

It's not my post :)

I just needed 10bit image from DNxHD to feed my dithering tool, but.....it's not easy :) As I said- it looks like only one software, which can see 10bit in DNxHD (except AVID) is AE. I rendered v210 in AE and feed this to get dithered 8bit file for encoding. It's just so much time and work- wish it would be simpler :)
It's RED footage and simple conversion to 8bit shows so much banding in many scenes, so it needs dithering.

In this case Cineform is very good- it has nice decoder, which can output many 10bit pins, including v210. I wish more people use Cineform:)

[jmac698]

Oh, well there's the r3dsource import filter, I just asked the author to update it to support 16bit depth. http://arenafilm.hu/alsog/avisynthr3d/
If you are on red forums, could you also ask? http://reduser.net/forum/showthread.php?25398

@daemon404: redirect what I said ;)

[kolak]

Soure is DNxHD file and this is what I have to work with:)

[Daemon404]

Awesome update... FFmpeg now supports prores decoding!

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5554de13b29b9bb812ee5cfd606349873ddf0945

problems = solved, for me.

[kolak]

In 10bit???


Andrew

[Daemon404]

In 10bit???


Andrew

Yes. It decodes to 10-bit properly.

[kolak]

Great!!

Speed?

Andrew

[poisondeathray]

wow that's good news

did anyone catch this:



author: Elvis Presley



:)

[mp3dom]

The only unsupported ProRes seems the 4:4:4:4 which is anyway very rare. It also support the ProRes Proxy.

[kolak]

Where can I download latest build?

[mp3dom]

Latest binary Win builds are here: http://ffmpeg.zeranoe.com/builds/ but I don't know if the ProRes decoder git is already builtin

Edit: Yes, it should already contains the ProRes decoder

[kolak]

It does not work- invalid pixel format -1

??? :(

[tateu]

Having ProRes support in ffmpeg and ffmpegsource is great, especially for those who refuse to install Quicktime and/or need 10 bit.

I compiled my own ffmpeg version and ffmpegsource plugin with ProRes support for testing but I haven't checked anything with 10 bit because I don't know if any of my ProRes files actually are 10 bit.

ffmpegsource decoded my test files to 8 bit data almost identically to qtinput in YUY2 mode. I had to create a histogram of both and zoom into them 400% to even see any differences. However, ffmpeg/ffmpegsource decodes about 3 times slower than qtinput.

Hopefully official builds off ffmpeg/ffmpegsource with 10 bit ProRes support get released soon.

[TheFluff]

Having ProRes support in ffmpeg and ffmpegsource is great, especially for those who refuse to install Quicktime and/or need 10 bit.

I compiled my own ffmpeg version and ffmpegsource plugin with ProRes support for testing but I haven't checked anything with 10 bit because I don't know if any of my ProRes files actually are 10 bit.

ffmpegsource decoded my test files to 8 bit data almost identically to qtinput in YUY2 mode. I had to create a histogram of both and zoom into them 400% to even see any differences. However, ffmpeg/ffmpegsource decodes about 3 times slower than qtinput.

Hopefully official builds off ffmpeg/ffmpegsource with 10 bit ProRes support get released soon.

If the ffmpeg decoder supports decoding 10-bit ProRes, ffms2 will support opening that as well. Output will be 8-bit only though, because no currently existing version of Avisynth supports high bitdepth YUV (the existing hacks that use various trickery to store 10-bit and up as something else do not count, and I am not particularly eager to implement such things in FFMS2).

[kolak]

Shame, because very soon we should have stable way of importing 10bit (or more) to avisynth. There is big progress and interest- all look very promising.

[TheFluff]

Shame, because very soon we should have stable way of importing 10bit (or more) to avisynth. There is big progress and interest- all look very promising.

Avisynth is already more than messy enough; especially the crazy MT extensions. Adding even more "interesting" hacks is not the Right Thing. If Avisynth is to continue being an useful tool, it needs a major overhaul, and the current state of 2.6 is not anywhere near enough.

[kolak]

So, the only thing left are hacks.
Maybe people are asking for to much for free- give us new avisynth 3, which will do everything- who is going to make it?
10bit support hack is quite simple (as far as I understand it) and already working properly- nothing like MT extension.

Andrew

[jmac698]

As I see it, if you insist on the one way and it's too big a job, it's not gonna get done by the volunteers. We live in an imperfect world. I'm perfectly fine coding to the 16bit standards, and there is a lot of support for it already. This support has meant that professionals are now able to use Avisynth in their work. It *is* a useful tool and becoming more so all the time.
I agree though, I'd like to see it redesigned someday *in an ideal world*.

[TheFluff]

As I see it, if you insist on the one way and it's too big a job, it's not gonna get done by the volunteers. We live in an imperfect world. I'm perfectly fine coding to the 16bit standards, and there is a lot of support for it already. This support has meant that professionals are now able to use Avisynth in their work. It *is* a useful tool and becoming more so all the time.
I agree though, I'd like to see it redesigned someday *in an ideal world*.

Just as you say, I'm an unpaid volounteer, and I don't want to work on code that makes me cringe.

On the other hand, FFMS2 is open source and if you want to add hacks to output high bitdepth YUV to the Avisynth plugin, feel free. It shouldn't be particularly hard; the FFMS2 API is clean and well documented and the Avisynth plugin is only a few hundred lines of code. If you do it well, you can even have your own branch on the main repository if you want it. I don't want it in the official plugin, though.

[jmac698]

The requested URL /ffmpegsource.googlecode.com/files/ffms-2.16-src.tar.bz2 was not found on this server. That’s all we know.

Make your source available and I'll look into it.

[TheFluff]

The requested URL /ffmpegsource.googlecode.com/files/ffms-2.16-src.tar.bz2 was not found on this server. That’s all we know.

Make your source available and I'll look into it.

The .tar.bz2 is right there and the download link works fine for me. I suggest you use the SVN repository (http://code.google.com/p/ffmpegsource/source/checkout), though.

[jmac698]

My bad.
I don't see where I can change things. I see that each output frame is blitted from the decoded copy made by ffmpeg, I don't see any codec source code here, so I need the source to ffmpeg too? I'm thinking you have to dig deep to get stuff to start passing high-bit data. Btw, VFW has the same problem, it's designed for 8bit, and v210 packs 10bit into an existing structure, probably a hack as you'd call it. Anyhow, there is someone writing an extension to avisynth to directly pass high-bit data. It already works, would you use it?

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

Here's how you would adapt ffms2:

PVideoFrame __stdcall hqas::ConvertHQ16ToRGB24::GetFrame(int n, IScriptEnvironment* env)
22 {
23 PVideoFrame src = child->GetFrame(n, env);
24 frame_info const &srcfi = get_info(*env, src);
25
26 PVideoFrame dst = new_frame(*env, vi);
27
28 bitmap<uint8_t, 3> out = bitmap<uint8_t, 3>(dst->GetWritePtr(), dst->GetRowSize() / 3, dst->GetHeight(), dst->GetPitch());
29
30 bitmap<uint16_t const> r = get_read_bitmap<uint16_t>(src, srcfi, planes::r);
31 bitmap<uint16_t const> g = get_read_bitmap<uint16_t>(src, srcfi, planes::g);
32 bitmap<uint16_t const> b = get_read_bitmap<uint16_t>(src, srcfi, planes::b);
33
34 for(int y = 0; y < out.height(); ++y)
35 {
36 uint8_t *outbgr = out.get_row(y);
37 uint16_t const *inr = r.get_row(y), *ing = g.get_row(y), *inb = b.get_row(y);
38
39 for(int x = 0; x < out.width(); ++x)
40 {
41 *outbgr++ = uint8_t(*inb++ >> 8);
42 *outbgr++ = uint8_t(*ing++ >> 8);
43 *outbgr++ = uint8_t(*inr++ >> 8);
44 }
45 }
46
47 return dst;
48 }

Here's hoping that didn't make you cringe :)

[surfdog]

I understand that once a video comes out of avisynth that it is 8-bit. What I'm wondering is: at what point, inside avisynth, does a 10-bit video get converted to 8-bit? Is it by the input filters (such as qtinput or rawinput) or is it by the use of other "non 10 bit" filters? I'm sure those here know that the person doing the dithering filter has a way of operating on more than 8 bits(http://forum.doom9.org/showthread.php?t=153589). Does qtinput, for prores, (or any input filter for that matter) preserve all 10-bits of each color channel when it opens the video? Thanks.

[jmac698]

qtinput has access to the 10bit video, but two bits are just discarded and 8 bits are sent to avisynth. Avisynth normally only allows to pass 8bit video internally. We get around this by using an extra large height video, stuffing the extra bits into the bottom half. Avisynth still thinks it's 8bit, but we process the bottom half separately to preserve the data. When it's time to output, we again arrange it in a special way to feed to avs2yuv and to x264.

[TheFluff]

My bad.
I don't see where I can change things. I see that each output frame is blitted from the decoded copy made by ffmpeg, I don't see any codec source code here, so I need the source to ffmpeg too?
You need the ffmpeg source code if you intend to compile FFMS2 yourself, yes.

I'm thinking you have to dig deep to get stuff to start passing high-bit data.
No. I don't think you've understood how the FFMS2 Avisynth plugin works at all.

What you need to do:

First you need to get 10-bit raw video frames from the FFMS2 API. You can do this by first getting the appropriate constant (either by calling FFMS_GetPixFmt (http://code.google.com/p/ffmpegsource/source/browse/trunk/src/avisynth/avssources.cpp#196) or by looking at libavutil/pixfmt.h directly) and then passing it to FFMS_SetOutputFormatV2 (http://code.google.com/p/ffmpegsource/source/browse/trunk/src/avisynth/avssources.cpp#222). The appropriate pixel format in this case is probably PIX_FMT_YUV420P10LE.
Next you need to decide under what circumstances the Avisynth plugin should output this pixel format. Since it is decidedly nonstandard, I'd say it's a bad idea to output it by default. You should probably make up a name for it and add it to CSNameToPIXFMT (http://code.google.com/p/ffmpegsource/source/browse/trunk/src/avisynth/avsutils.cpp#42), so the user can request it via the colorspace parameter to FFVideoSource.
Finally you need to add support for copying this new output format into an Avisynth frame in whatever funny way the other plugins supporting this hack wants.


Taking a closer look at the wiki page about high bitdepth makes me even more negative to the entire thing. Why on earth would you split each sample into two parts and store them in different halves of the frame? Seems like a recipe for a big performance hit to me. It also makes it harder to implement support for it in FFMS2. You can't blit the frames delivered from FFmpeg directly, since YUV420P10LE stores each sample as a 16-bit unsigned little-endian integer, so if you want to implement this I hope you like pointer arithmetics and bit shifts.

I'm not 100% sure what that code you posted does, but I don't think it does what you think it does and I don't think it's relevant to adding 10-bit support to FFMS2.

[poisondeathray]

The appropriate pixel format in this case is probably PIX_FMT_YUV420P10LE.

Wouldn't it be 422 subsampled instead of 420 ?

Does this follow ffmpeg naming conventions?

If so, the pix fmt for v210 in ffmpeg is "yuv422p10le"

[cretindesalpes]

Why on earth would you split each sample into two parts and store them in different halves of the frame?
I am responsible for this monstrosity ^^. It's absolutely disgusting on a programming point of view and terribly inefficient, but it was very convenient when I started the experiment with simple Masktools hacking. Anyway, I fear we'll have to live with it for a while. I clearly don't have time to add a well-designed high bitdepth support to the Avisynth code base, moreover it's not planned (http://forum.doom9.org/showpost.php?p=1179134&postcount=33) in v2.6.

[TheFluff]

Wouldn't it be 422 subsampled instead of 420 ?

Does this follow ffmpeg naming conventions?

If so, the pix fmt for v210 in ffmpeg is "yuv422p10le"

Well yeah, if the input is v210 that'd be the correct pixel format. I just sorta assumed 4:2:0 for some reason.

Anyway, I fear we'll have to live with it for a while. I clearly don't have time to add a well-designed high bitdepth support to the Avisynth code base, moreover it's not planned (http://forum.doom9.org/showpost.php?p=1179134&postcount=33) in v2.6.

That's exactly the problem. Avisynth 2.6 really doesn't add very much. At this point I'd almost say it's time to start something new from scratch, because hacking on Avisynth doesn't seem to cut it at all, but I also think that down that road lies madness.


Anyway, to contribute, I give you a quick and dirty example patch (http://privatepaste.com/c1ab0c40fa) to get any interested parties started on hacking the support into FFMS2. It's obviously not complete and I have not even tested if it compiles at all, but it should give you an idea of where to start modifying things.

[jmac698]

We can change the standard to exactly the one ffmpeg uses. It is efficient for 16bit plugins, and can be used in script too. It's not even a hack; there's only one problem that the width reported will be double, but that's easy to work around.

I'm trying to tell you there is already true high-bit depth support internally for plugins for avisynth, and there's working code. What I posted showed reference to true 16bit integers as they were converted down to 8bit rgb. In fact, simply adding the video type without changing anything else is enough to do a lot.

[TheFluff]

I'm trying to tell you there is already true high-bit depth support internally for plugins for avisynth, and there's working code. What I posted showed reference to true 16bit integers as they were converted down to 8bit rgb.
You said "here's how to adapt FFMS2" and posted code that converts 16-bit samples to 8-bit ones. FFMS2 already does that internally and the discussion was about how to add >8-bit output to FFMS2, so I don't see how the code was relevant at all.

In fact, simply adding the video type without changing anything else is enough to do a lot.
What?

edit: if you want to change the standard to storing samples together (doubling the width instead of the height), adding support for that to FFMS2 would be absolutely trivial, at least for 4:2:0. Unfortunately 4:2:2 won't be as easy, since Avisynth only supports packed 4:2:2 (YUY2) while FFmpeg only supports planar 4:2:2 when using >8 bits per component.

[jmac698]

Hey.. thanks for contributing an example! And yes, the trivial support for 4:2:0 would immediately make a huge difference to the practical application of high bit-depth support.

Yes, I know the code doesn't do anything useful in itself, I simply wanted to point out the fact that 16bit integer video was now an internal video type. What that code for a plugin did was take avisynth's new internal high-bit video type and convert it to an 8 bit avisynth internal type. Anyhow, I've invited PhrostByte (the author) here to explain it to you.

If you could make your example do the "trivial" thing you mentioned, that would be great! Really, it's almost all we need.

>simply adding the video type
What I mean is just having a clip that can be 16bit (yuv) and being able to read the correct properties from it, set interlace, etc. even if no internal filters work with it.. is enough to do practical and *clean* scripting with it. For example I could write a script function that checks for 16bit video and uses masktools or 16bit plugins to do some very simple operations on it, including converting back to 8bit, or simply leaving it as it is and encoding directly to 10bit with avs2yuv.

[TheFluff]

If you could make your example do the "trivial" thing you mentioned, that would be great! Really, it's almost all we need.

Something like this (http://privatepaste.com/bcc541cb3a) maybe? Not tested at all, haven't even tested if it compiles.

>simply adding the video type
What I mean is just having a clip that can be 16bit (yuv) and being able to read the correct properties from it, set interlace, etc. even if no internal filters work with it.. is enough to do practical and *clean* scripting with it. For example I could write a script function that checks for 16bit video and uses masktools or 16bit plugins to do some very simple operations on it, including converting back to 8bit, or simply leaving it as it is and encoding directly to 10bit with avs2yuv.

This can't be done without patching Avisynth itself.
I mean, it's certainly possible to treat env->NewVideoFrame() as if it was malloc() and just put random data into the frame buffer, and even make filters use that, but until someone modifies Avisynth itself it'll be impossible to tell such random data apart from ordinary video, so you'll have to trust the user to tell filters what to expect. At least unless you do something even more hackish like hiding metadata outside the active image area or in the LSB of certain pixels like telecide does with its hinting, but even then you probably can't detect it within a script.

[Wilbert]

Unfortunately 4:2:2 won't be as easy, since Avisynth only supports packed 4:2:2 (YUY2)
planar YUY2: YV16.

[TheFluff]

planar YUY2: YV16.

Well, Avisynth 2.5 then. If you want to use Avisynth 2.6's new features you'll need to use the C plugin though, because the native one doesn't support those yet.

[Wilbert]

If you want to use Avisynth 2.6's new features you'll need to use the C plugin though, because the native one doesn't support those yet.
I'm sure IanB will incorperate your modifications of the header file if you send it to him. I guess it's this one?

http://code.google.com/p/ffmpegsource/source/browse/branches/c_plugin/src/avisynth_c/avisynth_c.h

[TheFluff]

I'm sure IanB will incorperate your modifications of the header file if you send it to him. I guess it's this one?

http://code.google.com/p/ffmpegsource/source/browse/branches/c_plugin/src/avisynth_c/avisynth_c.h

No, I meant the native FFMS2 plugin cannot be built as an Avisynth 2.6 plugin yet.

The modded avisynth_c.h is kemuri_-9's department and I leave any comments regarding it to him.

[jmac698]

>until someone modifies Avisynth itself
Yep,
http://svn.int64.org/viewvc/int64/hqas/hqas/avisynth.h?view=log
It's a modded version of avisynth 2.58.

[surfdog]

qtinput has access to the 10bit video, but two bits are just discarded and 8 bits are sent to avisynth. Avisynth normally only allows to pass 8bit video internally. We get around this by using an extra large height video, stuffing the extra bits into the bottom half. Avisynth still thinks it's 8bit, but we process the bottom half separately to preserve the data. When it's time to output, we again arrange it in a special way to feed to avs2yuv and to x264.

Thanks for the response jmac, I've tried out your deep color tools before too. Yes I get what you're saying , what I'm really wondering is with the following line of avisynth code:
videoHolder = qtinput(10bit_yuy2_proresVideo.mov,color=2,audio=true,mode=1,raw="v210")
Once avisynth passes this line of code, does the variable 'videoHolder' hold the true 10-bit version of the video or just a 8-bit version?

[jmac698]

qtiinput by itself only returns 8 bit. There's two ways to get the rest; one is an option in qtinput that can round up. By comparing the roundup and normal you can tell what is the extra bit. The other way is to use sashimi, this lets me read the raw file. In this case I get a video that looks like garbage but happens to have the 10bit data. I unscramble the garbage into 16bits with masktools. Then I have the true 10 bits in way way I want, but some other tools use vertically stacked msb/lsb for further processing.

[surfdog]

qtiinput by itself only returns 8 bit. There's two ways to get the rest; one is an option in qtinput that can round up. By comparing the roundup and normal you can tell what is the extra bit. The other way is to use sashimi, this lets me read the raw file. In this case I get a video that looks like garbage but happens to have the 10bit data. I unscramble the garbage into 16bits with masktools. Then I have the true 10 bits in way way I want, but some other tools use vertically stacked msb/lsb for further processing.

Yes I have tried the roundup method with little success (dither =1). Do you mind sharing the script in which you open a 10-bit .mov file (preferably prores format) using the sashimi plugin method you mentioned above?

[jmac698]

Just setting dither to 1 doesn't show much difference, I actually take dither=1 and subtract dither=0, this leaves *only* the low bits (which looks black with some noise). Anyhow, I wrote a script to read 9 bit video from any quicktime file include prores http://forum.doom9.org/showthread.php?p=1467907#post1467907
I haven't tested prores, only uncompressed 10 bit as v210 in .mov.

There is also readv210, ffvideosource(fn) and qtinput(fn) also work but they are only 8bit, in the case of qtinput you can fudge 9bit with a trick. With this script you can access the full 10bits in script.
The latest version:
ReadV210 - http://forum.doom9.org/archive/index.php/t-158985.html Can read uncompressed v210 in .mov container as greyscale.

Readv210mod - http://forum.doom9.org/showthread.php?p=1526131#post1526131 Can read uncompressed v210 in .mov container as color. Both need some manual tweaking to skip the file header. Update: link fixed

[surfdog]

Just setting dither to 1 doesn't show much difference, I actually take dither=1 and subtract dither=0, this leaves *only* the low bits (which looks black with some noise). Anyhow, I wrote a script to read 9 bit video from any quicktime file include prores http://forum.doom9.org/showthread.php?p=1467907#post1467907
I haven't tested prores, only uncompressed 10 bit as v210 in .mov.

There is also readv210, ffvideosource(fn) and qtinput(fn) also work but they are only 8bit, in the case of qtinput you can fudge 9bit with a trick. With this script you can access the full 10bits in script.
The latest version:
OK. Ya I've tried you're deep color script before and stopped when I realized i was only getting 9 out of the 10 bits from qtinput (that's not to say that you're script is at fault or anything). I'm wondering if your last post was submitted the way you meant it to be. The last sentence says "With this script you can access the full 10bits in script.
The latest version:" and then there is no link. Is this what you meant to put?
edit: oh I see that you changed it. thanks.

edit:
I tried the Readv210mod link and it doesn't seem to be working.

[jmac698]

Fixed.

[kolak]

There are new ffmpeg builds, but still no ProRes decoding :(

[jmac698]

http://www.videohelp.com/tools/ffmbc

FFmbc-0.7:
- Sync on FFmpeg git 7cbb856efe6ccab7485bb96ad3887472a6519ffa
- AVCIntra decoding is now supported.
- Parallel frame multi-threaded decoding is now enabled.
- Prores 422 and Prores 4444 decoding.
- When writing MXF files, use more correct key for KLV Fill packets.
- Fix detection of some DVCAM files.
- Fix decoding artefact in bottom rows of Quantel DVCPROHD 1080i files.

[kolak]

Cool :)
Where can I get compiled version?
I assume 8bit only?

[jmac698]

I dunno, I'll see what I get it compiled :)
Btw, if you're looking for a guide to compile ffmbc, it's probably the same as a guide to compiile ffmpeg.

[smok3]

has anyone get the prores decoding to work? (with ffmpeg & friends)? (on any os)

[the_weirdo]

AFAIK, libavcodec's ProRes decoder is licensed under GPLv2, so you would need to compile ffmpeg/libav as GPLv2 (use options --enable-gpl --enable-version2 for configure). Many ffmpeg/libav builds are compiled as GPLv3 so ProRes decoder doesn't work.

[jmac698]

Wow, good tip, I'd never think of that. Oh, and it just finished compiling. But I had passed --enable-version3 before and it said it didn't recognize that option?
Hey, there's an exe here! And... I'm missing pthreadGC2.dll :(

[the_weirdo]

You could try this build: http://www.mediafire.com/?lc6oj1s7silsqrt

EDIT: My previous build seems to be borked. Replaced with new build.

RE-EDIT: You can get new build here: http://www.mediafire.com/?58wteseii003v

[kolak]

Thanks- it works and it looks like 10bit decoding is supported :)
ProRes file from Alexa decoded to v210- looks fine.
Sounds good :)

Andrew

[jmac698]

My build of ffmbc:
http://www.sendspace.com/file/qvmjqj
The other link above is for a recent ffmpeg version.
Mine lists prores as a decoding format, also supports 10bit rgb and yuv.
Test and let me know if it works.

[kolak]

Big file- lots of goods ?- hehe

Alexa ProRes files are here:

http://www.blackmagic-design.com/support/detail/?sid=3948&pid=4448&os=mac&leg=0&cp=True

Works fine- looks like it's faster than other build.

Decoded to raw v210 and read by v210reader- all fine :)

Andrew

[jmac698]

Wow, that's great to know! Do I need those other exe's, the big ones?
I think a lot of people in forums will be happy to hear this, it's a rare exe

ffmbc compile binary build win32 exe ffmbc.exe working prores prores422 decode windows

[kolak]

Never seen these big exe, have no clue what they are :)
(both ffmbc and ffmbc_g work)


Andrew

[jmac698]

I don't know what ffmbc_g.exe is for, it's the big one (30mb) as opposed to the smaller ffmbc.exe (7mb). I guess I should strip the big ones.
Thanks for your report, I was worried that some dll or something might be missing.

Btw, for my next project I should compile ffms2 with suppport for 10bit direct into avisynth :)

Edit: oh duh, I bet it's the debug version...

[smok3]

weeehee, gpl2 was the key on osx as well, now how do i compile this with that new android AAC encoder? (the guide i'am following is using faac), or should i just use -strict experimental at encode time?

edit:
seems to be working with:
ffmpeg -i prores.mov -vcodec libx264 -preset fast -tune film -crf 21 -threads 0 -strict experimental out.mp4

[jmac698]

Do you wanna post your osx build?

[smok3]

jmac698, here: https://sourceforge.net/projects/resizecalc/files/osxFFmpeg/

compiled with
./configure --prefix=${SOURCE} --enable-gpl --enable-pthreads --enable-version2 --enable-version3 --enable-nonfree --enable-libx264 --enable-avfilter --enable-filters --arch=x86 --enable-runtime-cpudetect && make -j 4 && make install

and
./x264 --version
x264 0.118.2085 8a62835
built on Sep 23 2011, gcc: 4.2.1 (Apple Inc. build 5646)
configuration: --bit-depth=8
x264 license: GPL version 2 or later

(only tested on snow leopard)

[kolak]

I don't know what ffmbc_g.exe is for, it's the big one (30mb) as opposed to the smaller ffmbc.exe (7mb). I guess I should strip the big ones.
Thanks for your report, I was worried that some dll or something might be missing.

Btw, for my next project I should compile ffms2 with suppport for 10bit direct into avisynth :)

Edit: oh duh, I bet it's the debug version...

Cool- I've tested readv210 on proper machine (i7 990x overclocked to 4.2GHz) and it works at 3fps for full HD. I think it's all due to reading file bit, so it would be nice to have different (faster) v210 importer.

[kolak]

Yet another surprise (at least for me).

jmac698- I'm 90% sure that your build of ffmbc does decode/encode DNxHD at 10bit- thanks a lot for compiling it- great feature!
Nice work ffmbc team!

update: I'm 99% sure DNxHD with fmbc 0.7 supports 10bit :) I also was able to see dithering going from v210 to DNxHD (8bit) with old ffmbc 0.6- looks like it uses simple error diffusion or something like that. Very good news :)


Going to verify it on Monday :)

[jmac698]

I need to update readv210, it can be much faster.. much more high bit-depth stuff coming...

[Yellow_]

Does ffmbc offer direct avisynth script handling like ffmpeg does? It'll be a compile option if it does.

[jmac698]

D avs AVISynth

[Yellow_]

Ok, useful.

A bit much to ask but any chance of a shared build as .dll's, like swscale, libavformat etc

[jmac698]

Finally, I confirm the *_g versions are debug:

4.7 Why are the ffmpeg programs devoid of debugging symbols?

The build process creates ffmpeg_g, ffplay_g, etc. which contain full debug information. Those binaries are stripped to create ffmpeg, ffplay, etc. If you need the debug information, use the *_g versions.

from http://ffmpeg.org/faq.html

I'm checking out the compile options...

[jmac698]

You can compile any options you want yourself now, guide at http://forum.doom9.org/showthread.php?p=1528421#post1528421

[kolak]

:)

It looks like ProRes, DNxHD decoding works nice- tried few samples and only once got some error (some free stock footage):

[prores @ 0134aac0] ac tex damaged 2050, 2048
[prores @ 0134aac0] ac tex damaged 1612, 1024
[prores @ 0134aac0] ac tex damaged 1043, 1024
[prores @ 0134aac0] ac tex damaged 2468, 2048
[prores @ 0134aac0] ac tex damaged 1025, 1024
[prores @ 0134aac0] ac tex damaged 1031, 1024
[prores @ 0134aac0] invalid plane data size
[prores @ 0134aac0] error decoding picture
Error while decoding stream #0.0

File looked fine thought.

10fps from ProRes to v210 for full HD on my 1.4GHz low voltage CPU.

[jmac698]

Ok, compiled to *.dll. Had to do a bit of extra work, to strip the dll's. Also made a slight change to remove the dependancy on pthreads (as to which is better, pthreads or win32 threads, I don't know).
Link coming (check back in a bit for an edit).

Most of the binary size comes from avcodec (7MB).

Update:
And here it is:
http://www.sendspace.com/file/ck4n0u
configure --enable-gpl --enable-memalign-hack --enable-runtime-cpudetect --enable-avisynth --enable-shared --disable-static

These seem to be the minimum options. gpl2 is default and is required for ffmbc, libx264, libxavs, libxvid, x11grab
gpl3 is needed for libfaac (which isn't included here).
pthreads is used.
---
build guide at
http://forum.doom9.org/showthread.php?p=1528421

[TheFluff]

Ok, compiled to *.dll. Had to do a bit of extra work, to strip the dll's. Also made a slight change to remove the dependancy on pthreads (as to which is better, pthreads or win32 threads, I don't know).
Link coming (check back in a bit for an edit).

Most of the binary size comes from avcodec (7MB).

pthreads is better, threading basically doesn't work with win32threads.

[TheFluff]

http://forum.doom9.org/showthread.php?p=1528494#post1528494
I made a thing

if you want 4:2:2 support you need to port the avs plugin to 2.6 first but that seems like effort so I didn't do that. patch for how I did 4:2:0 is included though so it should be trivial to do 4:2:2 based on that.

[kolak]

Compared latest 3 ways of passing 10bit to avisynth:

readv210 script, 16bit through rawsource and ffvideosource with 10bit hack.

First 2 produce the same output after f3kdb_dither, 3rd one output is different- there is more banding visible. No 10bit passed to dither, 4:2:0 only?

In the same time readv210 is 7x slower on my laptop compared to 16bit+rawsource (not taking into count time to convert v210to 16bit).

readv210/16bit+rawsource:

http://img402.imageshack.us/img402/983/readv210.png

videosource mod:

http://img823.imageshack.us/img823/4344/videospw.png
Andrew

[Yellow_]

jmac698, many thanks for the .dll's and the build guide.

[jmac698]

More good news, lavf supports ProRes directly now, all you need is a directshowsource. 10bit support is still the problem.

LAV Video
- Integrated NVIDIA CUVID Hardware decoder
- Performance enhancements in 10bit decoding
- Support for Flash Screen Video (FSV1)
- Support for Apple ProRes

[kolak]

I found a bug in 10bit DNxHD decoder.
In high contrast areas it produces artefacts.
Where should I report it?