ffdshow tryouts project: Discussion & Development [Archive] - Page 126

Mark_A_W

18th January 2009, 14:16

I notice a another bug with ffdshow.
With some blu-ray, If I select MLP soundtrack, I have no sound

here an example of this problem
http://www.zshare.net/info.html?54310400-a553b6c77ff2d34994f4f3bc51b23de2

my config:
Q6600
xp sp3
geforce gtx280 180.48
MPC-HC 1.2.976

vmr9 renderless without direct3d and dxva option (i use ffdshow video decoder)
ffdshow audio 2624
xfi titanium last driver

Me too. DTS-MA as well.

The audio decoder jumps samplerate and sample type, but never picks the right one.

It happened a couple of SVN versions ago, not sure which exactly, but 2615 is broken. I'm using the MPC-HC splitter.

(However it could be MPC-HC..but I think it is ffdshow.)

Edit: might be a different issue if yours is related to the Haali Splitter.

ikarad

18th January 2009, 14:47

If you are using Haali's media splitter, there is no output pin of audio for the file.

I don't use haali's media splitter

I use only mpc-Hc (vmr9 renderless) and ffdshow.

If I use only mpc-HC and lpcm codec integrated from MPC-HC, I can select and listen lpcm soundtrack. But with ffdshow audio codec used instead of lpcm codec from mpc-hc, I can't select lpcm soundtrack

Me too. DTS-MA as well.

The audio decoder jumps samplerate and sample type, but never picks the right one.

It happened a couple of SVN versions ago, not sure which exactly, but 2615 is broken. I'm using the MPC-HC splitter.

(However it could be MPC-HC..but I think it is ffdshow.)

Edit: might be a different issue if yours is related to the Haali Splitter.

I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for all blu-rays (that I own) including both lpcm and mlp soundtracks.

haruhiko_yamagata

18th January 2009, 15:30

I disabled ffdshow audio and enabled MPC-HC (977) internal TS splitter and LPCM, still can't select LPCM track.

haruhiko_yamagata

18th January 2009, 15:36

ikarad

18th January 2009, 16:15

I disabled ffdshow audio and enabled MPC-HC (977) internal TS splitter and LPCM, still can't select LPCM track.

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

Try to disable haali's media splitter because before I used haali and with haali I could not listen lpcm soundtrack from blu-ray but It was 6 months ago

proof here:
http://nsa04.casimages.com/img/2009/01/18/mini_090118042021598636.jpg (http://www.casimages.com/img.php?i=090118042021598636.jpg)

video captured with fraps during 5 seconds (I have sound with lpcm selected)
http://www.zshare.net/info.html?54319451-e8a97d7fdf7d4b2dad1928df2fde1423

parameters: (nero splitter disabled, ffdshow aduio disabled, ffdshow video prefer)
http://nsa04.casimages.com/img/2009/01/18/mini_090118042140159696.jpg (http://www.casimages.com/img.php?i=090118042140159696.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042223212915.jpg (http://www.casimages.com/img.php?i=090118042223212915.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042332418520.jpg (http://www.casimages.com/img.php?i=090118042332418520.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042753730970.jpg (http://www.casimages.com/img.php?i=090118042753730970.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042603316648.jpg (http://www.casimages.com/img.php?i=090118042603316648.jpg)

clsid

18th January 2009, 16:46

A bit off-topic, but those external filter settings are completely pointless.
* If you enable an internal splitter, there is no need to block external ones
* If you enable an internal decoder, there is no need to block external ones
* ffdshow already has a high merit by default, there is no need to set it as preferred, it will automatically get used when needed

yesgrey

18th January 2009, 18:42

I'm trying to implement H.264's colour primaries staff.

The spec says about ITU-R Rec. BT.709-5

primary x y
green 0.300 0.600
blue 0.150 0.060
red 0.640 0.330
white D65 0.3127 0.3290

What do these values mean?
I would like to help, but I don't understand your question completelly...
Those numbers are the coordinates of the primaries used in BT.709-5 conformant material.

By the way, about the YUV->RGB Conversion, I think you should use the correct designation.
It's not YUV, it's YCbCr (the b and r should be subscript, but I think in lower case is good enough). We should not continue the spread of this misinformation...;)

leeperry

18th January 2009, 20:33

Revision 2393 - Directory Listing
Modified Sun Nov 30 01:01:29 2008 UTC (7 weeks ago) by h_yamagata
Crop: Check "Process whole image" checked by default
Deinterlacers: Hide "Cubic blending" and "Framerate doubler" from GUI
is there a good reason why you hide the "Framerate doubler" ? :(
I understand it might create some problems, but it was actually funny to use it on progressive material...to get fake 48/50fps effect.

there's still Avisynth scripts to do that :
http://www.avsforum.com/avs-vb/showthread.php?t=1025800

...but on slow motion scenes it was great to have it in ffdshow :)

haruhiko_yamagata

18th January 2009, 23:35

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

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

haruhiko_yamagata

19th January 2009, 12:51

I would like to help, but I don't understand your question completelly...
Those numbers are the coordinates of the primaries used in BT.709-5 conformant material.

By the way, about the YUV->RGB Conversion, I think you should use the correct designation.
It's not YUV, it's YCbCr (the b and r should be subscript, but I think in lower case is good enough). We should not continue the spread of this misinformation...;)
OK, I found colour_primaries indicates the chromaticity coordinates of the source primaries as specified in Table E-3 in terms of
the CIE 1931 definition of x and y as specified by ISO/CIE 10527.Still not understanding perfectly though.
There are several color spaces such as 709-5, 470-6, 601-6, 240M and "Genelic film".

More confusingly, the spec says,
video_full_range_flag indicates the black level and range of the luma and chroma signals as derived from E’Y, E’PB,
and E’PR or E’R, E’G, and E’B analogue component signals.I don't understand at all :confused:

madshi

19th January 2009, 12:57

tetsuo55

19th January 2009, 13:00

tetsuo55

19th January 2009, 13:03

"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.

I know a lot of users will mind, but imho those streams are broken and should be fixed(probably a small script could be made to fix it)

MPC-HC/FFdshow have to follow the spec as best as possible

diizzy

19th January 2009, 13:36

As usual, thanks for the time you're devoting into this project.
I've found a little interesting bug that appears occasionally using libavcodec to decode MPEG2 sometimes results in garbled display.
Using libmpeg2 works fine also MPC-HCs decoder so it's not the file itself.
It's reproducable in both rev2615 (clsid build) and rev2547 (clsid build) with both YV12 and NV12 as output (not that I think it matters) using the standalone splitter from MPC (Home Cinema) rev974 or rev940 (xvidvideo.ru).
Here's a sample of what it looks like, I can also provide a video sample if you want to.

Edit:
As I don't know how long it will take for getting the attachment approved I'm linking it to an external site.
http://bayimg.com/ganPfAAbA
//Danne

haruhiko_yamagata

19th January 2009, 13:52

haruhiko_yamagata
I was unable to reply to feature request 2510387

You asked me if high quality YV12>RGB conversion works in 10bit.
I have no idea, i am not sure where to find that piece of code..

there is also the any>YV12 conversion that should be done in 10bit aswell
As you know, "High quality ..." is YV12->YUY2->RGB24/32.
I think YUY2->RGB conversion is 16bit.
However, YV12->YUY2 conversion rounds to 8bit (naturally). This may be a bit of loss.
I would like to implement direct YV12->RGB32 in the future.

The related files are convert_yuy2.h and convert_yv12.h.

haruhiko_yamagata

19th January 2009, 13:54

haruhiko_yamagata

19th January 2009, 13:56

"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.
Apart from the broken streams, can I simply assume full range means the range of Y is 0-255?

yesgrey

19th January 2009, 14:08

There are several color spaces such as 709-5, 470-6, 601-6, 240M and "Genelic film".
This is related to the phosphors used. Different media has different sensibility to light and its components. See Charle's Poynton's excellent colorfaq, and read the n.11. You can get it here: http://www.poynton.com/PDFs/ColorFAQ.pdf

That's why we need to perform the color correction to our display primaries coordinates. It's the only way we can watch our sources with accurate colors. Different sources are created with different RGB primaries, so, since our display has it's own set of RGB primaries, the colors only will look as it should if we watch material created with primaries equal to our display primaries.
We can color correct the sources to our own display primaries, that's what we can do with the solutions I and several other people have been working in - the reason why I requested the 3D LUT support in ffdshow.
Currently tritical have done it using avisynth, and now I am writing a little program to create the 3D LUTs outside Avisynth. The 3D LUT will include the YCbCr->RGB conversion and the color correction (including gamma correction), all with just the cpu load of using the 3D LUT and the 4:2:0 or 4:2:2 to 4:4:4 conversion. You can learn more about it in here (http://forum.doom9.org/showthread.php?t=139389) and in the first post in here (http://www.avsforum.com/avs-vb/showthread.php?t=912720).
More confusingly, the spec says...
Can you give me the link so I can try to understand it? Note that the specs also refer to the analog signals, which do not interest us...

yesgrey

19th January 2009, 14:12

Apart from the broken streams, can I simply assume full range means the range of Y is 0-255?
I don't think so.
Y full range is 1-254. The 0 and 255 values should never be used.
For video, the black is at Y:16 and white is at Y:235.

tetsuo55

19th January 2009, 14:52

I just finished reading the colorfaq.

It states(spread over the document)

To convert Y'CbCr to linear RGB you must color diff. decode to non-linear R'G'B and then apply a Gamma correction to get linear RGB.

This conversion officially only has 3 flavours.

1.Modern NTSC Rec601
2.PAL Rec601
3.HD Rec709

The conversion can be made near lossless by:
-Using 9bit or higher precision
-Dithering back to 8bit if/when needed. With dithering focused in the "blue" spectrum

Some notes:
-The conversion is always the same regardless of white/black reference point (0-255 or 16-235)
-The white/black reference point output choice changes the Gamma conversion.
-All the examples in the document are based on 8bit conversion, so we can use these only if we convert them to 9bit+
-Every step of the decoding and conversion steps are lossy in one way or another, by using 9bit or higher precision for each step and dithering back down to 8bit we can greatly reduce the loss in detail(and fix some banding at the same time)
-We should be able to disable to conversion to 8bit for windows7 as it supports up to 16bit.

I have yet to read the gammafaq

yesgrey3,

Do you agree? Did i understand it correctly?

EDIT:

Finished the GammaFAQ, seems to confirm the above.
It does add that any calculations involving luma should be done with linear values if you use non-linear a lot of errors occur. Also the 9bit+ processing seems to help black levels the most.

EDIT2:
The correct naming for the settings screen would be:

Luma reference black/white setting:**ToolTip**<The value at which your display renders Reference white/black, see "Link to ffdshow manual" for more information>
Studio (sRGB) : 16(black) and 235(white)**ToolTip**<This value is correct for most TV's and Projectors>
Computer (Full-RGB): 0(black) and 255(white**ToolTip**<This value is correct for most Computer monitors>

EDIT3:

Using 16bit instead of 8bit processing would result in a perfect scale for luma and a perfect gamut for visable colors(they don't all fit in sRGB/709 though).
Because of the rounding errors in conversion we might as well go all the way and do the calculations in 16bit. I will now take a look at the current ffdshow code

diizzy

19th January 2009, 15:38

As requested, here's a sample
http://www.zshare.net/download/54358430d47a4775/
//Danne

tetsuo55

19th January 2009, 16:06

As you know, "High quality ..." is YV12->YUY2->RGB24/32.
I think YUY2->RGB conversion is 16bit.
However, YV12->YUY2 conversion rounds to 8bit (naturally). This may be a bit of loss.
I would like to implement direct YV12->RGB32 in the future.

The related files are convert_yuy2.h and convert_yv12.h.

I cannot understand the code, too low level for me :(
I did see some conversions using "RGB24", according to what i read using RGB32 should result in faster calculation because 32 is a native value and 24 is not

yesgrey

19th January 2009, 16:39

This conversion officially only has 3 flavours.
1.Modern NTSC Rec601
2.PAL Rec601
3.HD Rec709

Unfortunatelly it seems not. Apparently some studios still perform the Blu-ray mastering using SMPTE-C or EBU monitors without color gammut correction, instead of BT.709 monitors. So, for you to see Blu-ray with accurate colors, sometimes you have to color correct to SMPTE-C or EBU primaries, not BT.709.
Please note that color gammut and conversion matrix are two different things. The Blu-ray conversion matrix is always BT.709, only the primaries could be different.
The conversion can be made near lossless by:
-Using 9bit or higher precision
-Dithering back to 8bit if/when needed. With dithering focused in the "blue" spectrum

The problem is not the conversion. All the calculations are done using 64 bit FP, so there is no problem with it. The only problem is that currently, in PC, we are still bounded by 8 bit per component color modes, so, the possibility of getting some banding is possible. In practice, with real world images, no one notices it...
Do you agree? Did i understand it correctly?

Yes, I think you have understand the essential questions.

-We should be able to disable to conversion to 8bit for windows7 as it supports up to 16bit.

But ffdshow and avisynth don't, and most of the displays also don't. Currently your only option with Windows7 is using mpc-hc with the pixel shader code, and only if your display also supports those modes.

The correct naming for the settings screen would be:
I think we should not complicate the naming too much, just enough to make it more intuitive while keeping it accurate enough.

yesgrey

19th January 2009, 16:46

@haruhiko,
About the 3D LUT thing - when you find the time, of course, i'm not pressuring you - you could take a look at the rgb3dlut code. It seems to me that it would be just adding rgb3dlut code to ffdshow; it already supports YUY2,RGB24 and RGB32 input.
Currently it can all be done in an avisynth script with ffdshow, but would it be faster to include the code inside ffdshow? If it would not be faster, we can forget about it and keep using it in an avisynth script.:)

madshi

19th January 2009, 16:52

I would like to implement direct YV12->RGB32 in the future.
That would be nice!

Also maybe some kind of dithering instead of using simple rounding would improve image quality further? FWIW, the Lumagen Radiance video processor has several dithering options to reduce banding with digital video output.

tetsuo55

19th January 2009, 16:58

Unfortunatelly it seems not. Apparently some studios still perform the Blu-ray mastering using SMPTE-C or EBU monitors without color gammut correction, instead of BT.709 monitors. So, for you to see Blu-ray with accurate colors, sometimes you have to color correct to SMPTE-C or EBU primaries, not BT.709.
Please note that color gammut and conversion matrix are two different things. The Blu-ray conversion matrix is always BT.709, only the primaries could be different.

i don't see any hard proof for this, other than a forum post and a guy in france with a website. And both are based on a loose conversation with some guy who works in a studio that happens to also produce bluray.

The colorfaq says that the mastering displays have been calibrated to 709/65D. Even the existing SMPTE-C or EBU have been re-calibrated to those values.
I also read that most of the newer DVD's are not 601 corrected from the 709 master, again i have seen no proof of this.

IMHO only the 3 i mentioned need to be used, followed by a 3dLUT containing the primaries of the user's display

The problem is not the conversion. All the calculations are done using 64 bit FP, so there is no problem with it. The only problem is that currently, in PC, we are still bounded by 8 bit per component color modes, so, the possibility of getting some banding is possible. In practice, with real world images, no one notices it...

Is the calculation 64 bit for all 3 color primaries or 64bit per color primary? Whichever it is it results in a higher than 16bit precision.
Dithering this back to 8bit should result in a banding free image in 99% of the situations, yet i see banding in almost every image. The problem must then not be the calculations of the rgb values, but the dithering back to 8bit

But ffdshow and avisynth don't, and most of the displays also don't. Currently your only option with Windows7 is using mpc-hc with the pixel shader code, and only if your display also supports those modes.

All videocards i could find made after 2007 support 10bit, there are a lot more that did before that, but those where insanely priced. You can get a 10bit videocard for 40$

All HDMI1.3a panels support 10bit(possibly using dithering to actually display them) signals.

Support for 10bit signals will have to be added. It's a chicken and egg story, but in this case the hardware is there, we just need software support.

(Note for anyone possibly misreading this, 10bit for 8bit source reduces banding, nothing more nothing less)

I think we should not complicate the naming too much, just enough to make it more intuitive while keeping it accurate enough.
Hmm, i think the descriptions i gave are both technically accurate and very easy to understand for end users

tetsuo55

19th January 2009, 17:04

That would be nice!

Also maybe some kind of dithering instead of using simple rounding would improve image quality further? FWIW, the Lumagen Radiance video processor has several dithering options to reduce banding with digital video output.

Wow that thing is awesome.
I think that's a good goal for ffdshow.

FFdshow should strive for a processing quality similar to that device

Or in other words.

the Lumagen Radiance video processor is the benchmark that ffdshow is compared too.

madshi

19th January 2009, 17:17

The problem must then not be the calculations of the rgb values, but the dithering back to 8bit
Banding can also come from the source.

The correct naming for the settings screen would be
Please let's not restart the discussion! ;) Let haruhiko_yamagata make the final decision, based on the very long discussion we already had a few days ago.

leeperry

19th January 2009, 18:38

i don't see any hard proof for this, other than a forum post and a guy in france with a website. And both are based on a loose conversation with some guy who works in a studio that happens to also produce bluray.
you might find the first page instructive:
http://www.avsforum.com/avs-vb/showthread.php?t=1038602

anyone23

19th January 2009, 18:52

Although MD5 sum doesn't match with xvid, I can't reproduce the first screen shot.
Which version do you use?

PC1
Win Vista SP1 32bit
ffdshow-mt 2624 icl10
libavcodec.dll 52.10.0 MinGw GCC 4.3.2, x86r, (Jan15 2009)

PC2
WinXP Sp3 32bit
ffdshow 2323 icl10
libavcodec.dll 52.10.0 ...

Has anybody else problems with this sample (http://www.megaupload.com/de/?d=IIZHGT1W) + libav (FourCC: Xvid)?

tetsuo55

19th January 2009, 19:08

you might find the first page instructive:
http://www.avsforum.com/avs-vb/showthread.php?t=1038602

Read the whole thread.
I see more confirmation of "The final print has 709 primaries" than the other side.

Also the examples discussed prove the use of 709 primaries.

All (US) content is mastered using SMPTE C monitors, however, either the display is being fed a color-converted 709/sRGB image or there is a post-processer that converts the image to 709/sRGB

Somewhere in the thread it's also stated that the final print is tested using a 709/sRGB projector

yesgrey

19th January 2009, 19:42

Also maybe some kind of dithering instead of using simple rounding would improve image quality further?
I will use it in my program for creating the 3D LUTs, but I don't believe it would be very significant.
YCbCr has less than 25% of the colors possible in 8bit RGB, so, even if we use only 8bit without dithering, the banding will hardly be an issue.

iIs the calculation 64 bit for all 3 color primaries or 64bit per color primary?
Dithering this back to 8bit should result in a banding free image in 99% of the situations, yet i see banding in almost every image. The problem must then not be the calculations of the rgb values, but the dithering back to 8bit.
64bit per color primary, of course.
Do you see the banding when? Always, or when you are using our color correction methods?

leeperry

19th January 2009, 19:56

there is a post-processer that converts the image to 709/sRGB
noone has ever said anything about that AFAIK.
they master stuff on these SONY CRT's, and then they are ENCODED in REC709 for HD....but they're still using the CRT gamut, which happens to be SMPTE-C or EBU.

ppl pushing this theory are from the ISF and/or mastering houses....and I can tell you that US BD's look better in SMPTE-C on a D65 calibrated display, and european BD's in EBU...to my eyes at least :D

the main Cars hero will never be as red in the cartoon as he is on the posters...

anyhow, use the HDTV/sRGB gamut conversion for everything if you think it looks better...it's a free country :p

I will use it in my program for creating the 3D LUTs
...which will be ready when it'll be ready, right ? :D

tritical is using some HQ chroma upsampling, better than anything available in ffdshow or avisynth at this point....can't....wait http://forum-images.hardware.fr/images/perso/agla.gif

mark0077

19th January 2009, 20:16

Great to see all of this work being done! I really can't wait for this gamut work to be completed, and just wondering do I need the 64bit version of Windows 7 to get higher than 32bit colour output.

I am using nvidia card and Samsung Series 9 over hdmi, but still nothing higher than 32bit color yet.

Also, just out of interest, when all of this gamut conversion is done, what should we calibrate our displays to, for example I am using settings on my Samsung at the moment that were apparantly calibrated to 709. I am not an expert on all of this so I wonder is calibrating to this correct.... I will be using the PC for more than just movies and would hope to calibrate the Samsung just once, and have everything look close to correct.

Cheers all.

tetsuo55

19th January 2009, 20:27

noone has ever said anything about that AFAIK.
they master stuff on these SONY CRT's, and then they are ENCODED in REC709 for HD....but they're still using the CRT gamut, which happens to be SMPTE-C or EBU.

ppl pushing this theory are from the ISF and/or mastering houses....and I can tell you that US BD's look better in SMPTE-C on a D65 calibrated display, and european BD's in EBU...to my eyes at least :D

the main Cars hero will never be as red in the cartoon as he is on the posters...

anyhow, use the HDTV/sRGB gamut conversion for everything if you think it looks better...it's a free country :p

...which will be ready when it'll be ready, right ? :D

tritical is using some HQ chroma upsampling, better than anything available in ffdshow or avisynth at this point....can't....wait http://forum-images.hardware.fr/images/perso/agla.gif

I am simply condensing the text from your source.
HoustonHoyaFan talked about the fact that the end result, the Bluray or DVD will be 709/sRGB.

I am dissapointed that no-one in that thread tried Cars with SMPTE-C primaries.
With my 709/sRGB and ati expansion settings he is about as red as the cover. Not orangy at all.

What do you see on your display?

I also tested skintones in several samples and they look lifelike to me.
The samples i have chosen as test-discs are like looking through a window.

tetsuo55

19th January 2009, 20:28

leeperry

19th January 2009, 20:32

Windows 7 to get higher than 32bit colour output.
it would only be useful on a HDMI 1.3 display...with a HDMI 1.3 graphic card, which doesn't exist at this point.

besides there won't be xvYCC sources before a long while, apparently it's never gonna happen for BD...so it'll only be useful for gamut conversions because 8 bits input/output is lossy.

when all of this gamut conversion is done, what should we calibrate our displays to, for example I am using settings on my Samsung at the moment that were apparantly calibrated to 709. I am not an expert on all of this so I wonder is calibrating to this correct.... I will be using the PC for more than just movies and would hope to calibrate the Samsung just once, and have everything look close to correct.Cheers all.
D65, with a ±2.2 gamma.
native gamut will do, or SMPTE-C/EBU/HTDV if your display enables you to select them(at least your display might work in 10 bits internally)

anyhow, when yesgrey3's app is ready, I will compare the chroma upsampling from tritical to ffdshow and the nvidia drivers with both your and my test patterns :p

mark0077

19th January 2009, 20:35

Ah thats good, looking forward to seeing the results. So I think I will leave my TV's settings alone for the moment, calibrated to 709 should be fine. Exciting times :D

leeperry

19th January 2009, 21:45

HoustonHoyaFan talked about the fact that the end result, the Bluray or DVD will be 709/sRGB.
yes, it will be encoded to Rec.709, but there won't be any 3D LUT to convert the primaries from SMPTE-C.
I am dissapointed that no-one in that thread tried Cars with SMPTE-C primaries.
before yesgrey3, JohnAd and tritical worked on the case, there simply was no free solution to convert gamuts....you had to use crazy expensive equipment such as the Lumagen scalers.
With my 709/sRGB and ati expansion settings he is about as red as the cover. Not orangy at all.
lemme guess, your display has oversaturated primaries ?
What do you see on your display?
well SMPTE-C was chosen coz it was free of royalties...JVC and SONY had much wider gamuts but they refused to GPL them.
SMPTE-C's major flaw is the red part, that is actually more orangey...and reason why the SMPTE decided to go Rec.709 later on, because HD couldn't fit in such a small gamut.

on my D65/2.4 gamma calibrated DLP pj, in SMPTE-C the Cars Hero is not really red...or at least definitely not as red as on the BD cover.

some more food for thoughts :
http://forum.doom9.org/showthread.php?t=132745

and a very interesting PDF about 3D LUT's in the movie industry :
http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

tetsuo55

19th January 2009, 22:52

yes, it will be encoded to Rec.709, but there won't be any 3D LUT to convert the primaries from SMPTE-C.

First i am just quoting information to get things more clear, i am not convinced either side is correct.

3dluts being used for mastering:
http://www.avsforum.com/avs-vb/showthread.php?p=14370428#post14370428
http://www.avsforum.com/avs-vb/showthread.php?p=14104661#post14104661
http://www.avsforum.com/avs-vb/showthread.php?p=14083637#post14083637
http://www.avsforum.com/avs-vb/showthread.php?p=14083989#post14083989

There is a lot more,

Long story short. "Color is mastered using SMPTE-C primaries, and then converted to 709/sRGB primaries"
So according to the various discussions the 3Dlut we are talking about has already been done at the end of production. (and color conversion is near lossless in this case).

So when you convert the values back to SMPTE-C primaries you WILL have the image that the color guys had while post-producing
However you will NOT have the image the director saw when he okay'd the product as this test was done with 709/sRGB primaries
Most imporant quote here:
http://www.avsforum.com/avs-vb/showthread.php?p=14080317#post14080317

before yesgrey3, JohnAd and tritical worked on the case, there simply was no free solution to convert gamuts....you had to use crazy expensive equipment such as the Lumagen scalers.

Actrually several of the people responding to that thread have these type of devices.

lemme guess, your display has oversaturated primaries ?
My red and blue are 99% accurate and my green is slightly off(709/sRGB/D65)

well SMPTE-C was chosen coz it was free of royalties...JVC and SONY had much wider gamuts but they refused to GPL them.
SMPTE-C's major flaw is the red part, that is actually more orangey...and reason why the SMPTE decided to go Rec.709 later on, because HD couldn't fit in such a small gamut.
Interesting!

on my D65/2.4 gamma calibrated DLP pj, in SMPTE-C the Cars Hero is not really red...or at least definitely not as red as on the BD cover.
But not orange either right? does choosing 709/sRGB primaries look more or less red?

some more food for thoughts :
http://forum.doom9.org/showthread.php?t=132745

and a very interesting PDF about 3D LUT's in the movie industry :
http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

Goint to read those links, thanks!

leeperry

20th January 2009, 00:34

true, noone tells you that the mastering house didn't finally realize that they should run a 3D LUT from SMPTE-C to REC.709....but let's say that most don't, as confirmed by the ISF and many cinema professionals.

little do you care about the true original colors, look at what happened to TDK between the quicktime trailer and the final BD : http://forum.doom9.org/showpost.php?p=1236592&postcount=53

you want the colors the mastering engineer had on his CRT screen.

the only problen is with movies shot on HD cameras, coz their native gamut is indeed sRGB....my approach is to go SMPTE-C/EBU if it's a BD/DVD and sRGB if it's a web video shot on consumer stuff(and didn't get through mastering).

one quote that sums all that up is:
http://forum.doom9.org/showpost.php?p=1076274&postcount=4

Most consumers actually don't like a realistic, correctly calibrated picture. They like oversaturated colors and high contrast ratios.

if ppl don't care, why should mastering houses do? why do you, anyway? :D

yesgrey

20th January 2009, 01:13

You can get a 10bit videocard for 40$.
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.

...which will be ready when it'll be ready, right ? :D
Yes.;)
I am trying to release it during this week, but I don't want to do it without a good and comprehensive readme, and that will take me some time to write, since english is not my native language...

tobinaka

20th January 2009, 02:07

Oh, I'm coming here at the very good time! Hello and Thanks for ffdshow's developmets. I'm a x264 user and now interested in digital colors.

Don't confuse colour_primaries with matrix_coefficient. color_primaries is more connected with transfer_characteristics while video_full_range_flag with matrix_coefficient. color_primaries is for such profiles as sRGB or AdobeRGB. video_full_range_flag is for RGB<->YUV converting.

Anyway, I'm coming here to report that I found Flash Player on the web supports H.264's video_full_range_flag then I want ffdshow to suport it, too. First at all, look at the results of my comparing.
http://www.tobinaka.com/files/matrix_fullrange2.bmp (It's 1040x600 bmp)

-on RGB->YUV convert
I use ConvertToYV12 filter of AviSynth. Convert filter has 4 matrix options: Rec601, Rec709, pc.601, pc.709. 601 and 709 means matrix coefficients for SD and HD, while Rec and pc. means TV range and full range. This time I want to test full range then I use Rec601 and pc.601 to compare.

-on input in x264 the information to send to video player (decoder)
The information of the range which is used at RGB->YUV converting is NOT input when you finish AviSynth, BUT is input when you set H.264/AVC flag by setting x264 VUI option. Then if you use other ConvertToYV12 options than default, you must set x264 VUI options. To input fullrange information in H.264, you set x264 --fullrange off(default, Rec601) or on(pc.601).
(The same can be said about matrix coefficients that is used in ConvertToYV12 of AviSynth and can be set at x264. color_primaries and transfer_characteristics are different from them -- these are used before AviSynth and its information are input in H.264 parameters at x264.)

-on YUV->RGB convert (player and decoder)
I use Flash Player on Nicovideo (a YouTube-like video sharing service but allows posting by MP4 directly) and AviUtl (the same result with my eyes as WMP with WMP but I can't caputure the result of WMP for copyright protection function).

-Suggestion
On my test I found ffdshow_beta6_rev2527_20081219.exe (last stable) don't support H.264's video_full_range_flag. Is that right?

On Flash Player supporting fullrange flag,
-Rec601 with fullrange off
-pc.601 with fullrange on
show the same colors as original. That meets with the theory.
But there is one but inportant difference. RGB->YUV converting in Rec601 may cause some distortions for color banding because reducing 256 color steps into 224steps, while in pc.601 don't. That distortion is similar those caused by resize with no interpolation. To be pricise, pc.601 may causes color distortions (see the conveting equations with quantization), but it's much better than Rec601.

On ffdshow not supporting fullrange flag,
-Rec601 fullrange off
-Rec601 fullrange on
show the same colors as original. That meets the theory. ffdshow don't actually support fullrange flag. :)
Until now, we're content with Rec601 because it shows us the original colors. But, as above, Rec601 is worse than pc.601. Originally, Rec601 is for analog videos. Then if you use videos in digital from start to finish, it's better to use pc.601.

AviSynth supports fullrange, H.264 and x264 supports, Flash Player supports, but ffdshow don't supports. Then I want ffdshow to support and tell you about it. Thanks!

tritical

20th January 2009, 06:30

I will use it in my program for creating the 3D LUTs, but I don't believe it would be very significant.
YCbCr has less than 25% of the colors possible in 8bit RGB, so, even if we use only 8bit without dithering, the banding will hardly be an issue.
Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut. Simply adjusting the rounding used while creating the lut will not eliminate banding. You need to spread the quantization error over neighboring pixels within the image... to do that you need to know the quantization error created when each new pixel value is converted to 8-bit. It would be possible to do it if in the lut you stored, along with the new rgb values, the quantization error for each band (or if you stored the new rgb values in greater precision). Then it would be possible to implement Floyd-Steinberg dithering or similar algorithms. Although, if people think the current lut method by itself is slow :p...

madshi

20th January 2009, 10:30

Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut. Simply adjusting the rounding used while creating the lut will not eliminate banding. You need to spread the quantization error over neighboring pixels within the image... to do that you need to know the quantization error created when each new pixel value is converted to 8-bit. It would be possible to do it if in the lut you stored, along with the new rgb values, the quantization error for each band (or if you stored the new rgb values in greater precision). Then it would be possible to implement Floyd-Steinberg dithering or similar algorithms.
I think we should take into account that with Windows 7 it might be possible to output more than 8bit RGB. So I think the preferred solution should be for the LUT algorithm to output 16bit RGB (* 3 = 48bit). Some new MPC HC version might some day be able to output these 16bit RGB directly through HDMI 1.3.

For today (XP + Vista) of course we would then need a way to downconvert those 16bit RGB to 8bit RGB. So we'd need an additional algorithm which can downconvert those 16bit RGB to any bitdepth needed, e.g. 8bit for XP and Vista. This downconversion should ideally use dithering, e.g. Floyd-Steinberg, or something else...

Although, if people think the current lut method by itself is slow :p...
IMHO that shouldn't really be a thing to be worried about. PCs get faster all the time. Primery concern should be for the algorithm to do their job in the highest possible quality. If a given PC is not fast enough to execute the algorithms, then that's not your problem. Of course it would be nice to try to optimize the algorithms for best possible performance. But I wouldn't do any compromises on quality, just to increase performance. But of course that's just my opinion...

haruhiko_yamagata

20th January 2009, 10:34

Don't confuse colour_primaries with matrix_coefficient. color_primaries is more connected with transfer_characteristics while video_full_range_flag with matrix_coefficient. color_primaries is for such profiles as sRGB or AdobeRGB. video_full_range_flag is for RGB<->YUV converting.
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.

madshi

20th January 2009, 10:42

ffdshow does not support video_full_range_flag at all currently, and that's why I'm working on it.
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...

shambles

20th January 2009, 12:12

if you change profile in either video or audio config and press ok without changing anything else, it reverts back to the original profile.

it's not really very hard to work around it but still i think the profile selection should stick when clicking ok.

yesgrey

20th January 2009, 13:13

Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut.
Yes, you are right. When I said I will do it, I was thinking in noise shaping, but then I realized I was confusing names... dither is another thing.:o
I was going to post about it but you came first.
But as I said, I don't think banding is an issue. After having the program ready I will test and look for it, to see if I can make it appear.
So I think the preferred solution should be for the LUT algorithm to output 16bit RGB (* 3 = 48bit).
Yes, I agree with that. 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.
I'm more than confused. Could you explain how the similar two (colour_primaries and matrix_coefficient) differ?
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

In short, may I ignore colour_primaries and use matrix_coefficient?
Yes.