ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

Would it also make sense to add YV12 -> YUY2 conversion? I'm asking because the 3D LUT algorithm done by tcritical/yesgrey3 seems to want YUY2 input and having the option to let your new algorithm do YV12 -> YUY2 and then feed the result into the 3D LUT might be worthwhile?Current AviSynth's YV12->YUY2 conversion does 75:25 averaging. It's a very good converter. However it has limitation of output bit depth.
If 3D LUT support YV12 directly, it will benefit both in performance and quality.

[haruhiko_yamagata]

Is this conversion not a sort of resize, giving lots of different possible methods?
No, it's linear interpolation.
If we use resize, we have to move 0.5 pixel to the left by setting the matrix manually or something. Considering its performance and little difference in quality, I don't think it's a very good idea.

[haruhiko_yamagata]

It will depend on which part is the bottleneck.
In the yadif example you pointed, the code you used in ffdshow is exactly the same used in avisynth?
If it is, then the avisynth wrapping in ffdshow could be the limiting part...
I don't know much about the code of yadif in AviSynth. But assuming Fizick did his best for performance, the difference must be wrapping overhead. Copying HD content in memory is not a negligible overhead.

[Jong]

Anybody else noticed problems with some new DVD Menus and ffdshow beta6 post-processing? I have seen it with Mamma Mia (UK DVD) and Lars and the Real Girl (UK DVD). Both work fine in all players in DXVA mode. However, in both MPC-HC and TheaterTek (different MPEG-2 decoder in each, neither using ffdshow decoder) using ffdshow causes some of the menus to do what I can only describe as "crash" when navigating with the keyboard. The selected indicator in the menu stops moving. Even if you then try to use the mouse then the selected indicator does not change, although it did before the "crash" and if you click on a menu item it will play.
So the player is still active. If I press the appropriate key to go to the root menu that will work and the menu will start functioning again. However, after trying to navigate the troublesome menus with the keyboard the video window appears frozen.

This only happens at the moment with a small number of titles. It is maybe a new authoring tool or a new version of a tool that is confusing things. My first thought was that it was a bug in Theatertek, but now I have replicated the exact same issue in MPC-HC it seems more likely to be ffdshow. It occurs even if turn off all post-processing in ffdshow and output YV12, so it is essentially just passing through the video signal.

Anyone else seen this or have any ideas?

[noee]

...
Anyone else seen this or have any ideas?

Yes, I have seen that behavior with both jRiver MC13 and MPC-HC (Beelliyal's and SVN). I've tried HR and EVR and on the same DVD (Battlestar Galactica Season 4, D2) it does the same thing as you describe.

Seems to be more common with HR.

XPSP3, CCC8.12

[Jong]

I normally use VMR9 and it certainly occurs with that. Not sure about all the others. Also using XP SP3.

[Jeremy Duncan]

understand you are talking about RGB?

I know a Secret about RGB and I will tell it to you now.
- If you open a "Gradient Ramp", you can actually see if the RGB range is good or not!

In the ffdshow version I'm using: 2547. There is a difference in quality depending on if I use full range or standard, in the RGB conversion tab.
This is using bt.601, and output RGB32, high quality yv12 to RGB conversion.

I have tested the same gradient ramp on powerdvd ultra and the result was a better looking gradient ramp, and the ps3 gives a better esult as well than the ffdshow version I'm using.

So, you need to use a gradient ramp to see the difference.
I will now show you what a gradient ramp is, in case you don't know already. :)

http://img90.imageshack.us/img90/8723/gradientrampfullrangezy0.th.png (http://img90.imageshack.us/my.php?image=gradientrampfullrangezy0.png)


My input is all supported.
My output is rgb32 + high quality yv12 to rgb conversion
Rgb conversion tab uses bt 601
I use vmr9 renderless in mpc clsid build, I tried overlay too.

If I choose standard contrast in the rgb conversion tab, the gradient ramp is a bad result.
If I choose full range in the rgb conversion tab the gradient ramp is a better result than if I chose standard.

I would like to use standard though, by using full range the colors are not as good as they could be if I chose standard.

I have compaired the gradient ramp on the ps3 and cyberlink powerdvd ultra to the ffdshow version to see how the results vary.
At full range the ffdshow is better gradient ramp result than the ps3, the cyberlink gradient ramp is acceptable quality.

I understand you are looking at the output color range, and I ask that you look at improving the standard contrast in the rgb conversion tab. :)

[leeperry]

I ask that you look at improving the standard contrast in the rgb conversion tab. :)

"better result" / "colors are not as good" / "better gradient ramp"

do yourself a favor, get a colorimeter and calibrate your stuff, there's no better/good colors/levels...there's proper ones and uncalibrated ones ;)

[Jeremy Duncan]

"better result" / "colors are not as good" / "better gradient ramp"

do yourself a favor, get a colorimeter and calibrate your stuff, there's no better/good colors/levels...there's proper ones and uncalibrated ones ;)

You just Winky eyed my and tell me to shush!?

I did set the contrast and brightness to the best of my ability prior to this comparison.
I do not access the hidden monitor menu, I asked the tv repeir on how to and they would not let me know, and no web site tells me how either.

However I will look and see if my calibration can be improved and will see if this changes the resukt.

[leeperry]

You just Winky eyed my and tell me to shush!?

I did set the contrast and brightness to the best of my ability prior to this comparison.
well noone can calibrate video gear w/o a commercial sensor(spyder 2/3, eye one display 2)...it'd be like a partially deaf person complaining that his hifi set doesn't sound "good" :o
all my displays are calibrated, and colors/levels are "as good as they can get" :cool:

[Jeremy Duncan]

I just rechecked my brightness and contrast settings and they are fine.

I will tell you something, and you can choose to ignore it or not.
I have calibrated all three of my players: ps3, powerdvd ultra, mpc with ffdshow.
I know how and they are all calibrated to the same quality.
However the results the show on the gradient ramp show me that not all is well.

The result the cyberlink gives is different than the one the ps3 gives, and these two players are different than what the ffdshow rgb gives.
Why is that? Will you tell me that without another smiley wink?

Edit, and if you don't believe me, calibrate your monitor to the ps3 and the ffdshow and test with a gradient ramp and you will see with your own eyes.
It's testable. verify if I'm talking too much or not.

Edit. here's a better question.
If i use standard contrast, would the gradient bars be a different size than full range contrast? Or would the palet steps in the full range be more than the standard? And if the palet range is different between the standard and full range, would the standard range palet make it easier to see the gradient steps?

[leeperry]

if you expect some help, you should try to tone down maybe ;)
anyway, this is OT and not ffdshow related...ffdshow works perfectly fine as it is, when properly configured, that is :D
get a commercial sensor, create a 10 bits LUT w/ ARGYLLCMS to get perfect D65/2.2 colorimetry on your monitor, decode SD in REC601/HD in REC709 in full range RGB32HQ...and colors will look pretty darn good!
and if you crave for colorimetry awesomeness, use ddcc() to get spot-on gamut conversion....and then your troubles will be far away http://forum-images.hardware.fr/images/perso/dawen.gif

[Jeremy Duncan]

if you expect some help, you should try to tone down maybe ;)
anyway, this is OT and not ffdshow related...ffdshow works perfectly fine as it is, when properly configured, that is :D
get a commercial sensor, create a 10 bits LUT w/ ARGYLLCMS to get perfect D65/2.2 colorimetry on your monitor, decode SD in REC601/HD in REC709 in full range RGB32HQ...and colors will look pretty darn good!
and if you crave for colorimetry awesomeness, use ddcc() to get spot-on gamut conversion....and then your troubles will be far away http://forum-images.hardware.fr/images/perso/dawen.gif

If I understood your wisdom in the quote I would, but for now I will settle on simply believing your quoted response was valid.
I will be quiet now. :)

[leeperry]

I will settle on simply believing your quoted response was valid.
try this (http://tinyurl.com/apzh9l) ;)

long story made short, as long as your display won't be perfectly D65/2.2 calibrated....don't expect miracles out of ffdshow.

I never said it was easy, there's many places to learn about all this.....but this subject becomes addictive, you've been warned :)

[jmartinr]

No, it's linear interpolation.
If we use resize, we have to move 0.5 pixel to the left by setting the matrix manually or something. Considering its performance and little difference in quality, I don't think it's a very good idea.

I always resize to screen resolution anyway. Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?

[ikarad]

Hi,
That means that you played a blu-ray having an uncompressed 7.1 stream ?
I don't know if it possible for you to get a sample but I don't have any (I "only" have blurays with compressed TrueHD as highest quality, not with uncompressed streams)


Is this always related to LPCM checkbox or can you hear sound when you check AC3 SPDIF ?


In all cases I suppose that you have an ATI 4xxx card that is able to bitstream LPCM 7.1 with high bitrates through the HDMI connector ?

If this is the case it will be hard to figure out because I only have SPDIF to test.

EDIT :
I have made a few tests. Actually, LPCM does work on regular AC3/DTS streams but not on TrueHD, but it may be due to my SPDIF bandwidth limitation.

I don't have ati, I have geforce gtx280, xfi titanium + G51 logitech 5.1

here the example

http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx
Yes it is the same problem but I use geforce gtx280 + xfi titanium + G51 with analogic connection (no spidf) + iiyama 19" VGA CRT and this only happens with trueHD soundtrack.

[ikarad]

Can I have a sample?
Though I'm not sure if I have time to implement.

Have you time to implement lpcm HD (from blu-ray) support?

[Mc Onyx]

Has anyone been able to play 7.1 aac with latest FFDshow build or is 7.1 aac even supported? All I get is crackles and pops when i play 7.1 channel AAC audiotrack. Thanks for the answer.

[Px]

and I think it's not fair asking ffdshow's developers to spend their time with something that is already working...;)
Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D

[Jeremy Duncan]

try this (http://tinyurl.com/apzh9l) ;)

long story made short, as long as your display won't be perfectly D65/2.2 calibrated....don't expect miracles out of ffdshow.

I never said it was easy, there's many places to learn about all this.....but this subject becomes addictive, you've been warned :)

link to new quote (http://www.avsforum.com/avs-vb/showthread.php?p=15186601#post15186601)

There is no single right or wrong answer for this.

Source video files - DVD, HD-DVD, Blu-ray and Broadcast TV MPEG2, H264 and VC-1 will have their video stored in 16-235 format on-disc. This is what broadcast facilities and studios use as standard for digital video. Black is at 16, White is at 235. (There are values below black and above white to allow for undershoot and overshoot on high frequency edges without clipping, which would otherwise cause ringing etc. NB the black at 16 is nothing to do with composite NTSC 7.5IRE black level set-up) If you look at an SDI or HD-SDI signal in a broadcast facility or output from a VTR it will be 16-235 (or in some cases a 10 bit variant)

Some newer file-based video formats DON'T always use 16-235 though - and also SD and HD YCrCb to RGB mappings are different to each other. (601 vs 709 colourspace)

Sources can run at either 0-255 or 16-235 format. Original DVI output PCs ran 0-255 - as they were not designed with video in mind, and Windows ran with a 0-255 24bit desktop (8 bit 0-255 in each colour channel). Blu-ray players, satellite receivers, DVD players etc. with digital HDMI outputs would normally default to 16-235 output (as contained in the original broadcast or on the original disc) as this is the broadcast/production standard. (NB On-disc it is actuall YCrCb - with Y 16-235 and CrCb 16-240, but in RGB space it is 16-235 in all channels)

Displays can run in either 0-255 or 16-235 format in the same way. Most PC monitors with DVI-D inputs will usually expect a 0-255 input as a default, and most HDMI-equipped TVs will expect 16-235. That isn't to say that it isn't always possible to correctly calibrate a 0-255 display to correctly display a 16-235 input or vice versa - with the correct brightness (black level) and contrast (white level) settings it is often possible to correct for this (and many modern displays can have different brightness/contrast settings for different inputs). HOWEVER if you are switching HDMI multiple sources via an AV Amp into a single HDMI input, you really want your video levels to be consistent between sources.

So...

You have multiple points in the chain where 16-235 and 0-255 video can be used.

My understanding is that for consistency between applications and methods of display (though not always the highest quality), it is better for Windows to run internally in 0-255 mode. Thus either your video codec OR your overlay processor will ideally convert from 16-235 to 0-255 BUT NOT BOTH. Similarly your output video driver will then convert from 0-255 back to 16-235 for output if your display is a 16-235 model.

This MAY mean that there is some scaling going on, which could introduce some banding and truncation due to quantisation errors (as we don't have 30 or 36 bit internal RGB in many PCs yet - just 24 bit - which is 8 bit per channel).

Other options are possible - but they can leave you with crushed blacks or grey blacks if you aren't careful.

I'm not familiar with the Haali renderer I'm afraid - but if you only watch 16-235 sources, it may be worth setting it to 16-235 to see if you get consistent black levels between video playback and native Windows display (which won't use the renderer)

Using Vista EVR and an ATI driver registry hack to force 16-235 colour space conversion on SD content I have consistent black and white levels across content and apps now. I am able to set the output colour space of my HDMI output to RGB 16-235 in the drivers - and this works well for me.

So the new quote means if my video driver is using 0-255 levels, and ffdshow rgb contrast is using 16-235 levels, then there is some scaling which introduced the ugly gradient ramp result I complained about.
The solution is if I force ffdshow to use 16-235 levels, then my videocard needs to put out 16-235 levels.
The quoted fellow calls it 0-255 Mode. I dunno how to change the MODe in the settings to 16-235 so I can use ffdshow standard contrast with no banding.

heh heh. :helpful:

I am only saying this in the ffdshow thread because many people may put the rgb contrast to standard and then check the gradient ramp and not know whats the problem and why the result is ugliness.

[leeperry]

Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D
he's simply craving for the super neato experimental yv12 conversion algorithm from Haruhiko :D
the new quote means if my video driver is using 0-255 levels, and ffdshow rgb contrast is using 16-235 levels, then there is some scaling which introduced the ugly gradient ramp result I complained about.
The solution is if I force ffdshow to use 16-235 levels, then my videocard needs to put out 16-235 levels.
The quoted fellow calls it 0-255 Mode. I dunno how to change the MODe in the settings to 16-235 so I can use ffdshow standard contrast with no banding.
set ffdshow to full range in RGB32HQ, and it will output the original TV range(no TV>PC conversion).
most HDTV displays only accept 16-235 in HDMI, so this is your best option!
too bad it means your windows desktop will remain in 0-255, which can be a problem if you plan on watching digital pictures and stuff.
my pj accepts both TV/PC levels, but if I input TV levels it's internally converting to PC anyway....using it's cheapo onboard IC, which is of much lower quality than ffdshow :rolleyes:

there's no definitive answer to all situations, it's very much display dependent.

[noee]

Alright, I'm confused (whereas I thought I understood all this).

I play only SD material from DVDs (currently) and I have the ATI driver set to "Limited RGB". If I set FFDshow RGB32HQ output with:

YCbCr: BT.601
Input: Standard
Output: TV/Projector

Shouldn't this essentially be a "straight through" conversion, meaning there is really no levels conversion at all?

[yesgrey]

Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D
For the possibility (recently suported by haruhiko) that the integration in ffdshow could be faster than using the avisynth wrapping in ffdshow. And the new YV12->YV24 algorythm would also be nice, but the most important would be the speed gain.

[haruhiko_yamagata]

I always resize to screen resolution anyway. Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?It is possible, but it's a bit hard work.

[haruhiko_yamagata]

Have you time to implement lpcm HD (from blu-ray) support?No, I have been busy with RGB stuffs. And while I'm doing that, many people have reported many bugs. Among many feature requests, I can handle only a few. I can't promise, please wait.

[Px]

For the possibility (recently suported by haruhiko) that the integration in ffdshow could be faster than using the avisynth wrapping in ffdshow. And the new YV12->YV24 algorythm would also be nice, but the most important would be the speed gain.
Problems with speed? :rolleyes: Upgrade your system and don't waste developers time which they could spend on new features/bugfixes :D

[yesgrey]

Problems with speed?
Nope. For me it's ok now, I will not ask for it again. If any of the developers find the time do do it, great, if not, it will also be fine, I will keep use rgb3dlut, which is also great. I do not perform any video processing, it's only decoding, resizing to screen resolution, convert to rgb32 and then correct the gammut, so my E2160@3GHz is enough...;).
In fact, if I want, I even can use the new YV12->YV24 algorythm, is just using an Avisynth script with DirectShowSource to open the file and set ffdshow for decoding the format and output rgb32, then is just calling rgb3dlut for performing the gammut correction.:)

[yesgrey]

Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?

It is possible, but it's a bit hard work.

Now this seems to be a great idea...;)

[Jeremy Duncan]

Alright, I'm confused (whereas I thought I understood all this).

I play only SD material from DVDs (currently) and I have the ATI driver set to "Limited RGB". If I set FFDshow RGB32HQ output with:

YCbCr: BT.601
Input: Standard
Output: TV/Projector

Shouldn't this essentially be a "straight through" conversion, meaning there is really no levels conversion at all?

I googled some more on this and found out that if the videocard can't do 4:2:0 pixel format (limited) then there will be conversion, resulting in loss of information which means banding ugliness.

I then tried out ffdshow standard contrast and full range contrast with the ati 9.1 drivers and the various pixel formats it offers.
What I found out is, if I don't convert yv12 to rgb by using the output option to do that, but instead convert to rgb in avisynth, the banding seen is greatly reduced and so better quality.
Which leads me to the conclusion the "high quality yv12 to rgb conversion" isn't as high quality conversion as ConvertTorgb() in avisynth.

So I'm wondering is the code used for "high quality yv12 to rgb conversion" outdated or poor quality? :confused:

[ikarad]

No, I have been busy with RGB stuffs. And while I'm doing that, many people have reported many bugs. Among many feature requests, I can handle only a few. I can't promise, please wait.

thanks, I will wait

[leeperry]

I have been busy with RGB stuff
I've done another comparison w/ the latest ddcc() version :
http://forum.doom9.org/showpost.php?p=1243687&postcount=174

the background is R3/G1/B1 on all the screenshots, except in the new experimental "Q" version of yours where it's 2/0/0 :confused:

the only difference between the 6th & the 7th screenshots is that I've updated ffdshow, I haven't messed w/ the ffdshow settings at all..

Alright, I'm confused (whereas I thought I understood all this).
you'd be better off leaving the ATi drivers in full range RGB so they don't convert levels, and then set ffdshow to only do RGB32HQ w/o any levels conversion :)
but you should also try to set your display to full range (if any possible) to make sure that it doesn't work internally in 0-255 :o
Which leads me to the conclusion the "high quality yv12 to rgb conversion" isn't as high quality conversion as ConvertTorgb() in avisynth.
that's kinda funny, considering RGB32HQ is using ConvertToRGB32() code :D

[clsid]

But it executes that code at a different place, so it is possible the video is being altered somewhere esle in the processing chain in between the two places.

[albain]

thanks, I will wait

I have fixed the first bug already : no sound on some MLP/TrueHD samples.

Done in revision 2648

Concerning the other bug you mentioned, I wonder how to test it without an ATI 4xxx or a sound card that can handle HD bitstream ?

Maybe the previous fix will solve the problem...

[leeperry]

But it executes that code at a different place, so it is possible the video is being altered somewhere esle in the processing chain in between the two places.
left is colorYUV(levels="tv->pc")+ConvertToRGB32() REC601 full range / right is colorYUV(levels="tv->pc")+ffdshow RGB32HQ REC601 full range.

http://www.image-load.eu/out.php/t142541_convert32601.png (http://www.image-load.eu/out.php/i142541_convert32601.png)http://www.image-load.eu/out.php/t142542_ffdrgb32hq.png (http://www.image-load.eu/out.php/i142542_ffdrgb32hq.png)

Info
- date: 2/1/2009
- process: Compare
- source: convert32-601.png
- reference: ffd_rgb32hq.png

Basic statistics
- time elapsed: 00:00:00
- overall transfer [kB/s]: 2,851
- folders processed: 0
- files processed: 1

Errors
- errors: 0
- warnings: 0
- other: 0

[albain]

A new feature to be developed is the bitstream of HD audio streams to the HDMI output for receivers that can handle their decoding.

The question is : what is the difference in the implementation with SPDIF passthrough ?
Is there a specific media type to send, and most of all, it there a formatting to be done before ?

I really need to get my hand on a ATI 4xxxx card...

[Jeremy Duncan]

I will post a example of the ffdshow settings I used. For these pictures I used vista 32 bit, media player classic with vmr9 renderless.

________ top picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source checked,
3:2 Pulldown box: Ignore Pulldown checked,
Uncheck Buffer back/Ahead

setmemorymax(1024)
converttorgb32()

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

________ middle picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Resize & aspect tab checked
Multiply by:
2.668 (for 1920x1080 16:9 aspect ratio)
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Luma Gaussian Blur: 0.50
Accurate rounding checked

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked
high quality yv12 to rgb conversion checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

________ bottom picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source checked,
3:2 Pulldown box: Ignore Pulldown checked,
Uncheck Buffer back/Ahead

setmemorymax(1024)
converttorgb32()

Resize & aspect tab checked
Multiply by:
2.668 (for 1920x1080 16:9 aspect ratio)
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Luma Gaussian Blur: 0.50
Accurate rounding checked

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

http://thumbnails2.imagebam.com/2538/7b29a725374267.gif (http://www.imagebam.com/image/7b29a725374267)

click to enlarge picture

dl link of zipped picture (http://www.megaupload.com/?d=29CQPXGR)

[STaRGaZeR]

Shouldn't it be BT.709 for everything >1024 instead of >=1024? Width = 1024 is mostly used when encoding anamorphic PAL DVDs (resulting in 1024x576), which are BT.601 in origin.

[Jeremy Duncan]

no, the test disk is from calibrate.tv and it is a standard definition test disk, not rec 709.

I use ffdshow to resize dvd hollywood movies on my 1080p tv, and those movies use rec 601.

I asked the kind people in the avisynth forum and they said that if the source is rec 601 I should not use colormatrix to change it to rec 709.
Those weren't their exact words, I will get the thread link for their exact statement: link to the wise mans words (http://forum.doom9.org/showthread.php?p=1108131#post1108131)

[STaRGaZeR]

Oh I wasn't responding to you :p

[Jeremy Duncan]

http://thumbnails2.imagebam.com/2538/7b29a725374267.gif (http://www.imagebam.com/image/7b29a725374267)

click to enlarge picture

The bottom picture changes to the same quality as the two pictures above it if I move the avisynth tab below the resize tab.

So this means, if you want to use resizing in ffdshow, and you also want to use the output tab's high quality yv12 to rgb conversion.
- That once you check high quality yv12 to rgb conversion, it move up above the resizing tab as if the output tab was above the resizing tab.

This way you will get the same quality from just checking high quality yv12 to rgb conversion as the bottom picture shows.

Exactly HOW you make the high quality yv12 to rgb conversion behave like it's a tab above the resize tab, even though it's in the output tab is your problem.

[haruhiko_yamagata]

Shouldn't it be BT.709 for everything >1024 instead of >=1024? Width = 1024 is mostly used when encoding anamorphic PAL DVDs (resulting in 1024x576), which are BT.601 in origin.Thank you for the info. I have fixed at rev 2650.

[clsid]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.


Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."

[Mercury_22]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.


Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."

Yes but add HDMI cable to Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor." :)

[madshi]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.
It's one more control, which is a disadvantage, but I agree that it's probably cleaner because in the current dialog the "non-auto" controls still contain some "auto" logic.

Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."
That may be so with your LCD/Plasma TV, but not with mine. Generally DVI can transport video levels, too. And HDMI can also transport computer levels. Not sure about VGA, but I think it probably can also transport both video and computer levels.

[clsid]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.

[Mercury_22]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.

Or shorter "Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor. Consult your device's manual." :)

[madshi]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.
The problem is that I simply do not agree (at all!) with what you're aiming at. In my opinion most TVs expect RGB video levels, regardless of which connection type you're using. I believe TVs expecting RGB computer levels (even with DVI or VGA) are the exception and not the rule!

Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor.
Which is factually totally incorrect, AFAIK.

[mark0077]

All of this discussion and possible disagreement brings me back to the addition of the simple area in the conversion panel to TEST your screens output.

Describe what it should look like, and request the user to choose an output option that makes the test image match the desired output described. I would love this, especially for some friends that might not be sure which option is best. This would let them realize, aha, so thats the correct option and they can move on...

[clsid]

The two LCD TVs in my house (one Samsung, one JVC) both function as a computer monitor when I connect them with a VGA cable. The mode to view that input is even called "PC".

Does anyone here work in an electronics shop?

[mark0077]

I think if peoples TVs have the option for full range 0-255 then they should be hinted that this option might be available to them.

On my Samsung Series 9 the option is called "HDMI Black Level" and it can be set to Normal or Limited.

My perfect rgb conversion area would have a hint somewhere that if using a TV, to first check if it has the option to use "Full Range" or "Extended". If so set that to full range first.

THEN

Instruct them to use the image below to confirm which setting is correct for your display. When the correct setting is chosen, the image below should look like x y z and a b c should not be visible.... Something like this is what I think would be good.

That way they both get the benefits of full range for their pc usage, aswell as knowing based on the image test that they are setup correctly.