ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

The difference it's not in the values, but in the usage.
The matrix coefficients are used for the conversion YCbCr<->RGB.
The colour primaries are used to inform us the accurate position of the colors that are converted.
For example:
Consider the red primary RGB [255,0,0] with bt.709 chromaticity coordinates x=0.64; y=0.33:
In YCbCr using bt.601 matrix: Y:81;Cb:90;Cr:240
In YCbCr using bt.709 matrix: Y:63;Cb:102;Cr:240
If you convert to RGB with the correct matrix, the resulting RGB will always be [255,0,0]
Now, if you output the RGB [255,0,0] in a display with:
-bt.709 primaries, the red chromaticity coordinates will be x=0.64; y=0.33
-smpte-c primaries, the red chromaticity coordinates will be x=0.63; y=0.34
-ebu primaries, the red chromaticity coordinates will be x=0.64; y=0.33
Then, is colour_primaries to be used for calibrating display?

[haruhiko_yamagata]

As I said before, there are lots of broadcasts out there (not just a few!!!) with incorrectly set "video_full_range_flag". So please let me advise you again to ignore this flag. Or if you insist on honoring this flag, then you *MUST* add an option to ignore it, or else you'll be flooded with complaints about incorrect black levels etc when using the ffdshow h264 decoder...
OK, I'll add an option.

[tobinaka]

I'm more than confused. Could you explain how the similar two (colour_primaries and matrix_coefficient) differ?
In short, may I ignore colour_primaries and use matrix_coefficient?

ffdshow does not support video_full_range_flag at all currently, and that's why I'm working on it.

Let me say first I'm not the professional but just read some textbook and have come to understand recently (that's why I'm coming here today).

Here I show you 4 parameters which MP4 decoders have to manage in colors (see also ITU-T H.264/AVC Annex.E):

-video_full_range_flag
-colour_primaries
-transfer_characteristics
-matrix_coefficients

"video_full_range_flag" and "matrix_coefficients" tell decoders about the way of RGB->YUV converting. When decoders reconvert YUV into RGB, they must know how RGB was coverted into YUV, especially in the form of equations.

Let see BT.601 with TV range for example. Annex.E says about matrix that Kr=0.299 and Kb=0.114. There are only two values because the last can be determined by those two (Kr+Kg+Kb=1).

YUV is originally used at analog videos, then we should begin with 0-1 range for RGB. Set Er for R in 0-1 range, Eg for G, Eb for B.

Annex.E says analog values of YPbPr are determined as below:
Ey = Kr * Er + ( 1 – Kr – Kb ) * Eg + Kb * Eb
Epb = 0.5 * ( Eb – Ey ) ÷ ( 1 – Kb )
Epr = 0.5 * ( Er – Ey ) ÷ ( 1 – Kr )
In BT.601, Kr=0.299 and Kb=0.114, and you already have the values of Er, Eg, Eb. Then you can determined Ey. After you get Ey value, you can determined Epb and Epr.

Now, let's have only Ey, Epb and Epr. Can you determined Er, Eg and Eb? What else are needed to do so? You need Kr, Kb to determined Er, Eg and Eb by Ey, Epb, Epr. H.264's matrix_coefficients tells you about Kr and Kb.

Well, we have Ey, Epb, and Epr, which are analog and in 0-1 range. But we need digital values then Annex.E show a few equations. When YUV depth is 8bit:
Y = 219 * Ey + 16
Cb = 224 * Epb + 128
Cr = 224 * Epr + 128
EDIT: Correct the equations. Thank you yesgrey3.

and please digitize(quantize) them. Finally you get YCbCr values you want!

But those equations are for TV range. How about full scale? Change the last equations like that:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr +128
That is the change which video_full_range_flug causes. But those equations is to convert RGB into YUV. To support fullrange in ffdshow, you must count them backward.

As we see above, "video_full_range_flag" and "matrix_coefficients" are connected with RGB<->YUV converting. On the other hand, "colour_primaries" and "transfer_characteristics" are prepared for color management system.

RGB values tell you only the strenght of Red, Green and Blue at pixels. But RGB values never tell you what red RGB's Red is. The same can be said for green and blue (RGB on computers are different from CIE's RGB which defines R to 700nm, G to 546.1nm, B to 435.8nm). RGB is "relative" and don't tell the color "directly". If display monitors and their settings are different, the colors are NOT the same even with the same RGB value.

So how to display the desired colors? Then CIE(Commission Internationale de L'Eclairage, or International Commission on Illumination) difined color spaces in 1931. One of those is XYZ color space.

Using XYZ color space (and it variant xy or xyY chromaticity diagram), we can know the RGB gamut by determined the locations of red, green, blue and white. With three points of red, green and blue you can picture a triangle on xy chromaticity. After that, with white point you can make color gradations in the triangle (gamma correction changes the gradient of gradation). Now you know what colors your RGB can express for the limit!

H.264's colour_primaries tells you the locations of the four colors. So colour_primaries is connected with xy chromaticity.

xy chromaticity is often used to tell the spec of digital cameras, display monitors and printers. There are some profiles for xy chromaticity such as sRGB and AdobeRGB. AdobeRGB is larger than sRGB and AdobeRGB contains sRGB inside, so some monitors says "we can display AdobeRGB!"

Thus, xy chromaticity like sRGB is used in input devices like digital cameras, and in output devices like display monitors and printers. The xy chromaticity of input devices tells what colors the RGB values of their production means. The xy chromaticity for output devices are received for how to relate RGB values to actual colors. If xy chromaticities of both input and output is the same, we don't need to become aware of colour_primaries (because it's always the same).

I think ffdshow can manage colour_primaries when input xy chromacity is smaller than output xy chromacity. That's because ffdshow can't express the colors beyond the spec of display monitors. When input chromacity is smaller than output, ffdshow can narrow the RGB gamut. But at this time ffdshow will need the xy chromacity of output device. That's just my opinion. I could be wrong.

EDIT: I have a mistake. When input xy chromacity is larger than output xy chromacity, ffdshow have two ways. One is to ignore the input chromacity and adjust RGB with output. Another is to keep the input chromacity and cut off the colors beyond the output chromacity into inside of it. My textbook of color management says there are some ways to cut off colors outside into inside and it's difficult to select one from them.

transfer_characteristics is famous for gamma correction. CRT monitors can't display simple gradations linearly, but shows a curve. But we want to display simple gradations linearly so we gives a curve to RGB before CRT displays it. The strength of how much we should bend the linear curve is determined by the spec of CRT monitors. transfer_characteristics tells you about the bentness of the curve.

Originally, transfer characteristics is only for CRT monitors. But we need give gamma correction to videos before CRT displays it, so even if we use LCD monitors, not CRT monitors, videos have already given gamma correction to. Then LCD monitors have transfer characteristics, too, involuntarily.

Not only as above, but gamma curve is connected with xy chromacity. Then when ffdshow manage colour_primaries, ffdshow should manage transfer_characteristics at the same time.

That' the reason why I say video_full_range_flag is connected with matrix_coefficients while colour_primaries is connected with transfer_characteristics. I think the effects are stronger when I change x264's --fullrange and --colormatrix than x264's --colorprim and --transfer.

Sorry for that my explanation becomes so long.

[tobinaka]

Oh, my post is too late... :(

[STaRGaZeR]

Oh, my post is too late... :(

It's never too late for that kind of posts! http://www.xtremesystems.org/forums/images/smilies/thumbsup.gif

[haruhiko_yamagata]

Thank you very much. If I understand correctly,
To decode YCbCr to RGB, video_full_range_flag and matrix_coefficients should be used.
After knowing output device's color primaries, ffdshow may use colour_primaries and transfer_characteristics to 'calibrate' the RGB values (this isn't planed for now).

[haruhiko_yamagata]

"video_full_range_flag" is a special flag which is often set incorrectly in broadcasts. E.g. older SkyHD and PremiereHD broadcasts have it all set to "1" although the correct value would be "0". Newer PremiereHD broadcasts have it set correctly. So it might be better to ignore it. All current PC h264 decoders seem to ignore it. If you actually honored this flag, playback of older SkyHD and PremiereHD broadcasts would produce incorrect output.
CoreAVC does not ignore it if "Input levels" is set to "Auto detect" (default).
As for premiere HD, it is 1 as it should. I think it's true full range as far as I tested premiere-paff.ts. Although it looks better with standard range, it has some "blacker than black".

[madshi]

CoreAVC does not ignore it if "Input levels" is set to "Auto detect" (default).
Didn't know that. I never set it to "Auto detect". Currently using ATI hardware accelerated h264 decoding, anyway.

As for premiere HD, it is 1 as it should. I think it's true full range as far as I tested premiere-paff.ts. Although it looks better with standard range, it has some "blacker than black".
It is 1 for older PremiereHD broadcasts, but 0 for newer PremiereHD broadcasts. And I think the image is correct with 0 and not with 1. The same problem occurs with SkyHD broadcasts. I don't know how newer SkyHD broadcasts have set the flag, but older SkyHD broadcasts have set it to 1.

There are reports from people who have decoding problems with SkyHD broadcasts on their NMT media players due to this flag being set incorrectly. They claim that the image is wrong, unless they change the flag. The SkyHD satellite box seems to ignore the flag.

[madshi]

First, I will create the possibility of 8bit, then I will add the possibility of other bit depths. If tritical wants to add dithering in a rgb3dlut future version the 3D lut file will already exist...;)
Of course this only makes sense for 8bit input.
Why would that only make sense for 8bit input? Dithering is *always* recommended, if you go from a higher bitdepth to a lower bitdepth.

[tetsuo55]

64bit per color primary, of course.
Do you see the banding when? Always, or when you are using our color correction methods?

I see banding straight from source, without editing the image.
I can almost completely get rid of it with avisynth filters, but these are far from realtime...

Since we are doing the RGB conversion anyway we might as well apply dithering in that fase

Yes, but even if you buy one for $400 you cannot work in 10bit mode, XP and Vista do not support it. You cannot have a 10bit per component desktop resolution.

10bit works just fine and has done so for a long time, there are even 16bit videocards(not consumer products though)

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.

This monitor is going to cost you an arm and a leg though :P

Why would that only make sense for 8bit input? Dithering is *always* recommended, if you go from a higher bitdepth to a lower bitdepth.

Exactly, if FFdshow currently does it with 64 bits per primary all we need to add really is that Floyd-Steinberg dithering.
That should remove any and all banding, even if the source is a banding-fest

[madshi]

10bit works just fine and has done so for a long time, there are even 16bit videocards(not consumer products though)

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.
10bit is only available for YCbCr and only in 4:2:2. It's not available for RGB until HDMI 1.3. And I don't think Windows can output YCbCr in XP+Vista.

Exactly, if FFdshow currently does it with 64 bits per primary all we need to add really is that Floyd-Steinberg dithering.
That should remove any and all banding, even if the source is a banding-fest
Normal dithering does *not* get rid of banding in the source. It just reduces/eliminates banding caused by bitdepth reduction.

Dithering can help getting rid of source banding, if you use more dithering than you would normally use. But that would be a special post processing filter which should (if available at all) be strictly optional.

Proper dithering helps us getting as near to the original source data as possible (perceptually), while artificially increased dithering is a post processing filter which actually does the opposite: It intentionally changes the original source data. So these two kinds of dithering should be strictly separated.

[Px]

First at all, look at the results of my comparing.
http://www.tobinaka.com/files/matrix_fullrange2.bmp (It's 1040x600 bmp)
Am I see right, that picture 2 must be same as 1 and 6, but it differs?

[yesgrey]

But those equations are for TV range. How about full scale? Change the last equations like that:
Y = 255 * Ey
Cb = 255 * Epb
Cr = 255 * Epr

Excellent post tobinaka! Just a small correction, for full scale the equations are:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr + 128

After knowing output device's color primaries, ffdshow may use colour_primaries and transfer_characteristics to 'calibrate' the RGB values (this isn't planed for now).
This is what's done by the 3D LUT we are talking about. When you find the time to include the 3D LUT, ffdshow will support it.;)

Why would that only make sense for 8bit input?
Well, the formula for calculating the size of the 3D LUT in bytes is:
3*(2^(n.bit in))^3*(n.bit out)/8

So, for n.bit source/ n. bit output:
-8/8: 48MB
-8/16: 96MB
-9/9: 432MB
-10/10: 3840MB
Do you think it makes any sense using a 3D LUT with almost 4GB size? Even one with 432MB is a bit unreasonable...;)
But since the sources are all 8 bit, we can go for the 8/16, which gives 96MB, which is still a reasonable size.

I see banding straight from source, without editing the image.
Well, then you have to find a better source, or your YCbCr->RGB conversion is flawed. The problem is not related with the gammut conversion.

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.

Have you seen this working? I am asking because it doesn't make sense to me. Any crt can easilly support more than 8 bit (it's analog), and all the graphic cards dacs are already 10 or 12 bit, so why do not enable the option for the crt users?

[leeperry]

Any crt can easilly support more than 8 bit (it's analog), and all the graphic cards dacs are already 10 or 12 bit, so why do not enable the option for the crt users?
you get 10 bits gamma correction on a CRT using an nvidia card(it said 9 bits for ati 3850/2600)...the ARGYLLCMS package has a tool to check the LUT accuracy, but you can only output 8 bits video...if that makes any sense :D

the LUT's compress really well(48>1mb in RAR) so if that dithering stuff actually makes a difference, it's most welcome :)

[tobinaka]

Excellent post tobinaka! Just a small correction, for full scale the equations are:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr + 128


I corrected my privious post. Thank you yesgrey3.

Note: 10bit YUV, even with TV range used, will have less banding and less quantization errors in RGB<->YUV convertions.

[yesgrey]

so if that dithering stuff actually makes a difference, it's most welcome :)
I don't think it will...

[leeperry]

I don't think it will...
I don't think either, I believe tritical's algorithms are plenty accurate already for 8 bits resolution :cool:

call me crazy, but that precalculated LUT stuff is clearly more accurate than the old realtime 3D LUT to me, just like tritical said...colors have never looked so good, better than that doesn't seem achievable IMHO, or not w/o a true spectrophotometer thingie anyway :D

[madshi]

Well, the formula for calculating the size of the 3D LUT in bytes is:
3*(2^(n.bit in))^3*(n.bit out)/8

So, for n.bit source/ n. bit output:
-8/8: 48MB
-8/16: 96MB
-9/9: 432MB
-10/10: 3840MB
Do you think it makes any sense using a 3D LUT with almost 4GB size? Even one with 432MB is a bit unreasonable...;)
But since the sources are all 8 bit, we can go for the 8/16, which gives 96MB, which is still a reasonable size.
Ouch. Didn't know this formula.

I still think that we should handle all this more pragmatically. It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?). I don't think that's a good approach. IMHO the dithering should be done in a separate step and only if it's really necessary. I think it should ideally be done like this:

(1) Any YCbCr to RGB conversion (regardless of whether 3D LUT correction is involved or not) should be done to a reasonably high RGB output bitdepth (e.g. 16bit).
(2) If 3D LUT correction is done, it should work with the full input bitdepth and output a reasonably high output bitdepth (e.g. 16bit).
(3) If the display process doesn't support outputting the RGB data in the full calculation bitdepth (e.g. 16bit), the bitdepth needs to be dithered down to whatever bitdepth the display process supports.

I think step (3) should be a separate step and not part of the 3D LUT processing, so that it can also be used if 3D LUT processing is turned off.

I don't think it will...
Why?

[tetsuo55]

Ouch. Didn't know this formula.

I still think that we should handle all this more pragmatically. It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?). I don't think that's a good approach. IMHO the dithering should be done in a separate step and only if it's really necessary. I think it should ideally be done like this:

(1) Any YCbCr to RGB conversion (regardless of whether 3D LUT correction is involved or not) should be done to a reasonably high RGB output bitdepth (e.g. 16bit).
(2) If 3D LUT correction is done, it should work with the full input bitdepth and output a reasonably high output bitdepth (e.g. 16bit).
(3) If the display process doesn't support outputting the RGB data in the full calculation bitdepth (e.g. 16bit), the bitdepth needs to be dithered down to whatever bitdepth the display process supports.

I think step (3) should be a separate step and not part of the 3D LUT processing, so that it can also be used if 3D LUT processing is turned off.

I completely agree with this system.

Current RGB<->YCbCr is done in 64bit
A 64bit 3DLUT table is going to be HUGE!

Step 3 should indeed be a choice between either rounding(fast) or dithering(slow)

I have seen many examples of rounding VS dithering, and i have always prefered the dithered image to the rounded one.

[haruhiko_yamagata]

As requested, here's a sample
http://www.zshare.net/download/54358430d47a4775/
//Danne
Thank you. I can reproduce.

[tobinaka]

I don't know there have already shown the coefficients or the equations to convert between RGB and YUV with various ways. I think haruhiko_yamagata, or other developers, has already known them, but for reference at least, I show here the process to determined the equations to reconvert YUV into RGB in 8bit from those to RGB->YUV.

Now, let's start from H.264's Annex.E where the equations below are shown.
E'Y = KR * E'R + ( 1 - KR - KB ) * E'G + KB * E'B ... (E-13)
E'PB = 0.5 * ( E'B - E'Y ) / ( 1 - KB ) ............. (E-14)
E'PR = 0.5 * ( E'R - E'Y ) / ( 1 - KR ) ............. (E-15)

The details of the values:

Kr and Kb .... The coefficients given from matrix_coefficient such as BT.601, BT.709 and so on.
Analog ErEgEb .... Er, Eg and Eb range from 0 to 1
Analog EyEpbEpr .... Ey ranges from 0 to 1, Epb and Epr range from -0.5 to 0.5
Digital RGB .... R, B and G range from 0 to 255
Digiital TV range YUV .... Y ranges from 16 to 235, U and V range from 16 to 240
Digital full range YUV .... Y, U and V range from 0 to 255


Input (or substitute) Ey into the equations of Epb and Epr.
Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb

Epb = 0.5 * ( Eb - Ey ) / ( 1 - Kb )
= 0.5 * [ Eb - { Kr * Er + ( 1 - Kr - Kb ) * Eg - Kb * Eb } ] / ( 1 - Kb )
= 0.5 * { - Kr * Er - ( 1 - Kr - Kb ) * Eg + ( 1 - Kb ) * Eb } / ( 1 - Kb )

Epr = 0.5 * ( Er - Ey ) / ( 1 - Kr )
= 0.5 * { ( 1 - Kr ) * Er - ( 1 - Kr - Kb ) * Eg - Kb * Eb } / ( 1 - Kr )

Then let's get analog RGBs(Er, Eg, Eb) from Ey, Epb and Epr.
Epb = 0.5 * ( Eb - Ey ) / ( 1 - Kb )
Eb = Epb * ( 1 - Kb ) * 2 + Ey

Epr = 0.5 * ( Er - Ey ) / ( 1 - Kr )
Er = Epr * ( 1- Kr ) * 2 + Ey

Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb
Eg = ( Ey - Kr * Er - Kb * Eb ) / ( 1 - Kr - Kb )
= [ Ey - Kr * { Epr * ( 1- Kr ) * 2 + Ey } - Kb * { Epb * ( 1 - Kb ) * 2 + Ey } ] / ( 1 - Kr - Kb )
= Ey - { 2 * Kr * ( 1 - Kr ) / ( 1 - Kr - Kb ) } * Epr - { 2 * Kb * ( 1 - Kb ) / ( 1 - Kr - Kb ) } * Epb


Now you have the equations to convert between analog RGB and analog YUV. Note there are still the given coefficients without change.
Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb
Epb = 0.5 * { - Kr * Er - ( 1 - Kr - Kb ) * Eg + ( 1 - Kb ) * Eb } / ( 1 - Kb )
Epr = 0.5 * { ( 1 - Kr ) * Er - ( 1 - Kr - Kb ) * Eg - Kb * Eb } / ( 1- Kr )

Er = Epr * ( 1 - Kr ) * 2 + Ey
Eg = Ey - { 2 * Kr * ( 1 - Kr ) / ( 1 - Kr - Kb ) } * Epr + { 2 * Kb * ( 1 - Kb ) / ( 1 - Kr - Kb ) } * Epb
Eb = Epb * ( 1 - Kb ) * 2 + Ey


Next time, prepare the equations to convert RGB and YUV between analog and digital.

between analog RGB and digital RGB
R = 255 * Er
G = 255 * Eg
B = 255 * Eb

Er = R / 255
Eg = G / 255
Eb = B / 255

between TV range analog YUV and TV range digital YUV
Y = 219 * Ey + 16
U = 224 * Epb + 128
V = 224 * Epr + 128

Ey = ( Y - 16 ) / 219
Epb = ( U - 128 ) / 224
Epr = ( V - 128 ) / 224

between full range analog YUV and full range digital YUV
Y = 255 * Ey
U = 255 * Epb + 128
V = 255 * Epr + 128

Ey = Y / 255
Epb = ( U - 128 ) / 255
Epr = ( V - 128 ) / 255


Finally, input Kb and Kr (the given coefficients), and digital RGB and YUV into the equations of analog RGB and YUV. In this way, you can get all RGB<->YUV equations whatever coefficients are given by matrix_coefficient flag, especially for full range YUV.

[tritical]

Why?
I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.

[tetsuo55]

I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.

Is it possible though, to add a debanding function to the rgb conversion? And if so will that be more accurate than a seperate debanding step?

[madshi]

I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.
It's clear that using dithering for downconversion to 8bit will not fix any problems that are already in the source. However, I'm thinking along the lines of: What if there's a YCbCr value which when properly converted to RGB ends up with e.g. RGB (95.5, 95.5, 95.5). And what if there's a large color area using this exact color? With simple rounding the whole area would be (96, 96, 96). Wouldn't that be a noticable degradation? With dithering roughly half of the pixels would be (95, 95, 95) and the other half (96, 96, 96), which would be a much more accurate downconversion...

Edit: And I think this inaccurateness with simple rounding *can* eventually result in increased banding. E.g. what if there is a color fade which in floating point RGB would have steps like e.g. 90.4, 91.5. With simple rounding we would get 90 and 92, but no 91. With dithering we would get a dithered mixture of values 90, 91 and 92. The rounding would IMHO be in danger of adding visible banding, while there would be no such danger when using dithering.

[mark0077]

In my opinion, dithering creates an ugly effect. I rather 96 than half 95 and half 96 in your case..... but thats just me. I am basing my view really on old 16bit dithering years ago on games which looked so bad compared to normal 16bit color.

[tetsuo55]

In my opinion, dithering creates an ugly effect. I rather 96 than half 95 and half 96 in your case..... but thats just me. I am basing my view really on old 16bit dithering years ago on games which looked so bad compared to normal 16bit color.

That dithering sucks bad. The dithering was done with +/- 5 bits per component

Correct dithering will be invisible at the correct seating distance. Not to mention the fact that ffdshow does its RGB conversion with 64bits per component!

[leeperry]

Is it possible though, to add a debanding function to the rgb conversion?
did you try deband()? it looks UGLY :eek:

[tetsuo55]

did you try deband()? it looks UGLY :eek:

Yep i did, and yes i saw.

the best result for debanding i have seen was actually a 10bit per component dithering.

[yesgrey]

I still think that we should handle all this more pragmatically.
It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?).
No, I don't want to combine the 3D LUT with dithering, I only said that it could be a possibility, but I don't agree with it. It will slow down very much all the processing and probably without any benefit.
Why?
In fact, I'm very pragmatic, and since I've learned that YCbCr has less than 25% of the colors available in RGB (read this (http://www.poynton.com/PDFs/Merging_RGB_and_422.pdf) paper by Charle's Poynton) I have thought that's probably one of the reasons why I never had see banding with the color correction we are performing.
I think it should ideally be done like this...
I think you haven't understood completelly the 3D LUT thing...
In the beggining, the idea was only for color correction, but now, me and tritical, have extended it to also include the YCbCr->RGB conversion.
So, you can map a YCbCr value with the 3D LUT and it will output a RGB value. Currently, The YCbCr input is limited to YUY2, but maybe tritical could also add YV12 input support, and then we could use directly the output of the video decoders.
The 3D LUT is created using 64bit floating point per component in all stages, the roundings are all done only when creating the 3D LUT file, and will be to the output bit depth desired by the user. Currently, we only can use 8bit output, but maybe in the future, with Windows7, we can use a 3D LUT with 16bit output...

Wouldn't that be a noticable degradation? With dithering roughly half of the pixels would be (95, 95, 95) and the other half (96, 96, 96)
This logic only is valid if you have the full RGB colors available, and you don't, you will have less than 25% of it... and also remember, that probably you will not notice that color difference. When you notice banding, it's not color differences of only 1...

I think this discussion is becoming a little off-topic here... maybe it's better continuing it in the gammut correction thread, where ddcc was launched...

[madshi]

@yesgrey3,

sounds good to me, thanks.

Do you plan to replace the current "high quality RGB32" option in ffdshow with the new 3D LUT algorithm?

[Wilbert]

In fact, I'm very pragmatic, and since I've learned that YCbCr has less than 25% of the colors available in RGB (read this paper by Charle's Poynton) I have thought that's probably one of the reasons why I never had see banding with the color correction we are performing.
You will get that number if you start with 8-bit RGB and convert it to YCbCr [16,235]. I wonder how that number changes if you start with 10-bit RGB or whatever the studios use.

[SBeaver]

I can't seek in MLP audio tracks.
Is this a bug or a limitation?

[yesgrey]

You will get that number if you start with 8-bit RGB and convert it to YCbCr [16,235]. I wonder how that number changes if you start with 10-bit RGB or whatever the studios use.
You will always end with 8-bit YCbCr (that's what you get in the current consumer sources), so when you convert back to 8-bit RGB you will always get the < 25% number...

[ikarad]

Oh, I see. If I check both AC3 and LPCM in MPC, it works.

I hope a lpcm HD support as soon as possible.

[madshi]

Hey guys,

have been in contact with a Microsoft dev and he told me that the "official" Microsoft GUID for TrueHD is this:

DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);

Could you please add this to your TrueHD decoder (in case you haven't already)? Thanks!

[nautilus7]

Does this mean that we'll be able to mux TrueHD to matroska now (as long as support from mkvmerge is added)?

[albain]

Hey guys,

have been in contact with a Microsoft dev and he told me that the "official" Microsoft GUID for TrueHD is this:

DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);

Could you please add this to your TrueHD decoder (in case you haven't already)? Thanks!

Okay, I am on it but I won't have time to do it until monday.

I can't seek in MLP audio tracks.
Is this a bug or a limitation?



Concerning seeking on MLP, the problem is related to the parser.
The problem with this format is that there are not sync keywords for each frames, and this is (I think) the reason why the parser messes up when seeking is done

Regards,

Damien BT

[madshi]

Does this mean that we'll be able to mux TrueHD to matroska now (as long as support from mkvmerge is added)?
No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.

[haruhiko_yamagata]

Patch (http://ffdshow-tryout.sourceforge.net/samples/20080124a.patch)
Build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2631_20090124_Q.exe)

Please correct the tool tips. Discussion is welcome, of course.
Fraps auto detecting is not implemented yet (will do).

[nautilus7]

No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.
So, it is an "internal" matroska issue. Thanks.

P.S sorry for the off topic.

[yesgrey]

Discussion is welcome, of course.
For me it's good. As I have said, I think you had enough information to make a good decision.

Just some minor things...
Since you decided to use the correct designation YCbCr in the specification group, I think it should also be used in the levels description... ( Y: 16-235; CbCr: 16-240)
I prefer the look without using spaces between the brackets. For example: instead of ( RGB: 0 - 255 ), I prefer (RGB: 0-255). Just cosmetic, nothing more.
If the spaces should be used, then the last field misses one space... (RGB: 16 - 235 ) should be: ( RGB: 16 - 235 );)

And... Thank you very much for your work.
:thanks:

[madshi]

For me it's good. As I have said, I think you had enough information to make a good decision.

Just some minor things...
Since you decided to use the correct designation YCbCr in the specification group, I think it should also be used in the levels description... ( Y: 16-235; CbCr: 16-240)
I prefer the look without using spaces between the brackets. For example: instead of ( RGB: 0 - 255 ), I prefer (RGB: 0-255). Just cosmetic, nothing more.
If the spaces should be used, then the last field misses one space... (RGB: 16 - 235 ) should be: ( RGB: 16 - 235 );)

And... Thank you very much for your work.
:thanks:
I agree with everything yesgrey3 said.

I also like the way the h264 "video_full_range_flag" is handled!

Some additional small corrections:

(1) The hint for "Auto" input levels says: "Some people says ...". It should read "Some people say ...".
(2) The hint for "Standard" input says: "Nealy". It should read "Nearly".
(3) The hint for "Standard" input says: "For JPEG and MJPEG, full range is used". I'm not sure what this means exactly. Does it mean that ffdshow automatically uses full range when JPEG and MJPEG sources are detected? Or does it mean that the user is supposed to switch to "full range" for JPEG and MJPEG sources? Maybe the hint could be clarify that. In the first case I'd suggest: "For JPEG and MJPEG, ffdshow automatically uses full range". In the latter case I'd suggest "For JPEG and MJPEG please use full range".
(4) There's no hint for "Full range" input. Maybe: "JPEG, MJPEG and FRAPS sources usually use this".
(5) Cosmetical: I'd suggest to put two spaces between the label caption and the "(" bracket.

Thanks - the changes are much appreciated!

[haruhiko_yamagata]

@yesgrey3: Thank you for comment. I'll fix the dialog.
"For JPEG and MJPEG, ffdshow automatically uses full range".
"JPEG, MJPEG and FRAPS sources usually use this".
I'll use these.

[mark0077]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....

[madshi]

P.S: Just checked out "wmcodecdsp.h" in the Windows SDK. There are a number of interesting GUIDs in there:

DEFINE_GUID(MEDIASUBTYPE_MSAUDIO1, 0x00000160, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO2, 0x00000161, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO3, 0x00000162, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO_LOSSLESS, 0x00000163, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMASPDIF, 0x00000164, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_ADTS_AAC, 0x00001600, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_RAW_AAC, 0x00001601, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_ADTS_AAC, 0x00001608, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_RAW_AAC, 0x00001609, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_ADTS_AAC, 0x0000160A, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_RAW_AAC, 0x0000160B, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS, 0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD, 0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x6, 0x45);
I'd suggest adding support for DOLBY_DDPLUS, DOLBY_TRUEHD and DTS_HD. I think DOLBY_DDPLUS and DTS_HD should be treated just the same way as the conventional AC3 and DTS GUIDs, though...

[tetsuo55]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....

Yeah this is a good idea,

We need to find as many difficult samples as possible so we can create the ultimate detection algorithm

[Mercury_22]

ffdshow_rev2632_20090124_xxl_mt.exe it's crashing all my AVC ! :helpful: :mad:


P.S. I have No problem with ffdshow_rev2631_20090123_sse_icl10 or ffdshow_rev2631_20090123_x64 also I had no problems with MT until now:D

[alexins]

ffdshow_rev2632_20090124_xxl_mt.exe it's crashing all my AVC ! :helpful: :mad:


P.S. I have No problem with ffdshow_rev2631_20090123_sse_icl10 or ffdshow_rev2631_20090123_x64 also I had no problems with MT until now:D


The problem is the build libavcodec.dll. Because of this, I did not publish this revision on its website.

[STaRGaZeR]

No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.

Do you know how's in charge of adding support for new formats in Matroska? We need TrueHD support badly :D

[haruhiko_yamagata]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?Not yet.

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....
Interesting, though I'm not sure if I can handle it.