CCCP 2011-07-10 Beta

[thylacine]

CCCP 2011-07-10 Beta

http://www.cccp-project.net/beta/

http://www.cccp-project.net/beta/Combined-Community-Codec-Pack-BETA-2011-07-10.exe

Dear ladies and gentlemen, it is here. Our hero of the workforce, Lord, has hacked 10bit H.264 support into FFDShow-tryouts.

This went priority-wise way over implementing LAVSplitter (and possibly LAVAudio) into CCCP (mostly because I never got to really implementing this yet because of busyness, sorry), thus as soon as I got some free time and after doing some testing the betas now contain a 10bit H.264-compatible FFDShow-tryouts -- beginning with the 2011-07-10 beta. Available at the usual place.

What works:

10bit H.264 decoding in both 4:2:0 (YAY!) as well as 4:4:4.

Conversion of the 10bit colorspace to a related 8bit one, and passing that on via -tryouts systems (these conversions are usually of good quality, and might even have dithering -- haven't read the code yet).

Most of the stuff related to this as far as I can see.

What doesn't work / is not so good:

9bit H.264 will most probably just crash or do something similar. Haven't tested as A) x264 seems to be the only thing capable of making these streams and B) the 9bit colorspaces weren't added because of an amount limitation in -tryouts. Decoding functions on the libavcodec side should be enabled.

If you are used to the "high quality RGB conversion" feature in FFDShow-tryouts, this will not work with 10bit H.264, as 420R is not YV12 or anything else that this feature can take in. It will go through libswscale's 4:2:0->RGB conversion algorithm, which is not exactly the best-looking thing around. I remember D_S saying that better-quality conversion is possible, and thus we are looking into making it look better. If you are using Haali's renderer (not a default one in the CCCP, but some people either prefer it -- or have this as the only one that works for their borked GPU/drivers), it will be given RGB32 by default, which will lead to this being manifested.

High bit depth (10bit and 16bit) output to video renderers is not yet implemented. Mainly because we have to write something that would convert the libswscale/libavcodec planar 420P10 colorspace to the MS's partially planar 420P10 colorspace. Also, it seems like it needs hardware support, and to be honest we have no idea if it's better to output 10bit or 16bit YUV hardware-compatibility wise.

[SacredCultivator]

Thanks... But ehhh how do I benefit from the 10bit / I guess better question is, would I need to be concerned about using it over whatever the norm was before this was implemented?

[Guest Guest]

Thanks... But ehhh how do I benefit from the 10bit / I guess better question is, would I need to be concerned about using it over whatever the norm was before this was implemented?

You don't need 10bit colors on 8bit monitors cause majority of them don't support the former while professionals/developers use 10bit displays one really wouldn't notice the difference on normal monitors whilst those that support 10bit are inexorability expensive ^_^

P.S.

MPC supports this feature & if you turn it on you won't be able to see your average videos on normal displays, so try it on & see what happens :lol: