Best output format and colorspace?

[sswroom]

What is the best output format and colorspace for video playback?

I have tried to use AdobeRGB (8-bit). The color range is much wider than commonly used sRGB (8-bit).
I found that MadVR support to output 10-bit YUV (Unknown colorspace). Will it be better than AdobeRGB (8-bit)?

P.S. My computer is not fast enough to use MadVR.
P.S. My monitor (UP2414Q) only supports AdobeRGB and sRGB.

[huhn]

What is the best output format and colorspace for video playback?

I have tried to use AdobeRGB (8-bit). The color range is much wider than commonly used sRGB (8-bit).
I found that MadVR support to output 10-bit YUV (Unknown colorspace). Will it be better than AdobeRGB (8-bit)?

P.S. My computer is not fast enough to use MadVR.
P.S. My monitor (UP2414Q) only supports AdobeRGB and sRGB.

no colorspace is the best colorspace conversation.

madVR can only output 8-10 bit RGB. but can handle nearly every colorspace as input.

sRGB is about the same as BT 709 with a difference in gamma. so set your display to sRBb and every normal video player should output everything as bt 709 RGB.

BTW. selecting sRGB in a monitor doesn't mean it displays sRGB. without calibrtaion it is outputing something that's closer to sRGB than the adobe RGB settings.

output formats have nothing to do with this.

and yeah read forum rule 12: http://forum.doom9.org/forum-rules.htm

[sswroom]

This is the not same as situation as Forum rule 12 because it is not asking for objective result. It should be discussed in technical/subjective ways.

For AdobeRGB, it has color level less than sRGB. Usually, video source has 219 levels for Y or 224 levels for C. That means lesser levels should not be a problem.

For the 10-bit YUV output, I don't have detailed information on it. Could you provide detail in order to have a subjective comparison, such as output YUV Matrix, monitor input YUV Matrix, color primaries on YUV ouptut, transfer characteristics of YUV output?

For the monitor, sRGB means that it is factory calibrated that it should display "Correct" color if the input signal is in sRGB. AdobeRGB is also factory calibrated.

[huhn]

For AdobeRGB, it has color level less than sRGB. Usually, video source has 219 levels for Y or 224 levels for C. That means lesser levels should not be a problem.
but your GPU is outputting RGB when used with DVI and YCbCr (Y 16-235, Cb/Cr 16-240) 4:2:2, 4:4:4; limited RGB(16-235) or unlimted RGB(0-255) when using HDMI1.4/DP1.2.
YCbCr is always limited range and every Tv screen will convert this to full range RGB so this is meaningless.

same goes for 10-12 bit GPU output.

technically it is best to send limited RGB in a screen and the screen is showing this RGB signal without touching this but reality looks different.


For the 10-bit YUV output, I don't have detailed information on it. Could you provide detail in order to have a subjective comparison, such as output YUV Matrix, monitor input YUV Matrix, color primaries on YUV ouptut, transfer characteristics of YUV output?
a GPU will assume BT 709 for everything. so nothing really changes only the bit deep.
windows can only give the GPU driver 10 bit using a full screen exclusive directx 10 surface or newer. openGL is a bit different. so it's unlikely you will send 10 bit to the GPU driver in the first place.

For the monitor, sRGB means that it is factory calibrated that it should display "Correct" color if the input signal is in sRGB. AdobeRGB is also factory calibrated.

if you real trust in a factory calibration. use sRGB and you should be "fine". video player assume that the output device is BT 709 by default and every usable video renderer should transform every colrospace to BT 709 before outputting. so this is as close as you can get without calibrations.

[sswroom]

but your GPU is outputting RGB when used with DVI and YCbCr (Y 16-235, Cb/Cr 16-240) 4:2:2, 4:4:4; limited RGB(16-235) or unlimted RGB(0-255) when using HDMI1.4/DP1.2.
YCbCr is always limited range and every Tv screen will convert this to full range RGB so this is meaningless.
That means I should give up in trying to output YUV signal.



same goes for 10-12 bit GPU output.

technically it is best to send limited RGB in a screen and the screen is showing this RGB signal without touching this but reality looks different.

a GPU will assume BT 709 for everything. so nothing really changes only the bit deep.
windows can only give the GPU driver 10 bit using a full screen exclusive directx 10 surface or newer. openGL is a bit different. so it's unlikely you will send 10 bit to the GPU driver in the first place.

if you real trust in a factory calibration. use sRGB and you should be "fine". video player assume that the output device is BT 709 by default and every usable video renderer should transform every colrospace to BT 709 before outputting. so this is as close as you can get without calibrations.
Most computer monitor does not natively support Bt.709 Gamma. Output Bt.709 RGB will give wrong color. It is better to convert to sRGB or Adobe RGB in order to get a more accurate color. There are some video players support to convert to any colorspace in realtime.

For the display calibration, I have tried to use third party display calibrator. The calibration result is not as good as factory calibration.

[foxyshadis]

BT.709 is sRGB. Adobe RGB isn't an option to use lightly; if you don't convert correctly or your monitor doesn't support it, you'll get washed out video.

[baii]

I don't think there is any player/chain that support outputting specifically srgb or argb (w.o color conversion like a shader or 3dlut). The OP probably mean his monitor had such modes. For all current media, using argb mode will make everything look more saturated if you don't use some kind of colorspace conversion in the chain.

Windows and gpu don't give a beep on rgb colorspace unless the software is color management aware.

[iSunrise]

...P.S. My computer is not fast enough to use MadVR.
Even 5 year old and and even older computers are fast enough for madVR. Can you share your specs please. madVR is the only solution when you want to adhere to and display at specific calibration targets that can be selected within madVR. Also, you can use an additional 3DLUT to perfect your result.

Without madVR this will be a nightmare and almost impossible to do for every content, since the renderer needs to know both the source colorspace, the monitors colorspace and the desired output colorspace you want it to display at for perfect results.

A more general question to your answer would be, that "the best" colorspace to display the source is always the colorspace that the source was created in, so that should answer your question as accurately as possible.

Meaning, there is no "best", that's why in this forum "best" is usually not a good word to use, just use "most accurate" and you're fine.

[huhn]

I don't think there is any player/chain that support outputting specifically srgb or argb. The OP probably mean his monitor had such modes. For all current media, using argb mode will make everything look more saturated if you don't use some kind of colorspace conversion in the chain.

Windows and gpu don't give a beep on rgb colorspace unless the software is color management aware.

the only difference between sRGB and RGB from BT 709 video source is the gamma nothing else. and the difference in gamma is not huge at all.

[sswroom]

BT.709 is sRGB. Adobe RGB isn't an option to use lightly; if you don't convert correctly or your monitor doesn't support it, you'll get washed out video.
RGB Colorspace consist of 2 parts:
1) Transfer Characteristics (Or called Transfer Function, Gamma Curve)
2) Color Primaries

Bt. 709 and sRGB has same "Color Primaries" but different "Transfer Characteristics". So they should be treated as different colorspace.
Adobe RGB is not use oftenly because old computer is not fast enough to convert in realtime. But the current generation computer is fast enough to perform colorspace conversion in realtime. So, this is not a a problem now. And the Bt.2020 (Used in UHD BD) colorspace has wide color range and many color cannot be presented in sRGB. It is time to find ways to present as many color as possible.

P.S. My computer is fast enough to perform upscale and convert to Adobe RGB in realtime to at least 3840x2160@30fps.
Chroma upscale: Lanczos (Vertical) + Linear Resizer (Horizontal).
RGB Upscale: Lanczos Resizer in linear RGB.
All are done in single CPU (Intel i7-4771) without GPU assist.

[sswroom]

Even 5 year old and and even older computers are fast enough for madVR. Can you share your specs please. madVR is the only solution when you want to adhere to and display at specific calibration targets that can be selected within madVR. Also, you can use an additional 3DLUT to perfect your result.

My computer is Intel i7-4771 (GPU Intel HD 4600)

If I use other player without GPU assist, I can perform chrome upscale (Lanczos) > Upscale (Lanczos in Linear RGB) > Colorspace convert to AdobeRGB smoothly.
720x480 > 3840x2160@30fps = 4x% CPU usage
1920x1080 > 3840x2160@30fps = 5x% CPU usage
720x480 > 1920x1080@60fps = 2x% CPU usage

If I use MadVR with same algorithm, it cannot play smoothly with 720x480 > 1920x1080@60fps.

[huhn]

My computer is Intel i7-4771 (GPU Intel HD 4600)

If I use other player without GPU assist, I can perform chrome upscale (Lanczos) > Upscale (Lanczos in Linear RGB) > Colorspace convert to AdobeRGB smoothly.
720x480 > 3840x2160@30fps = 4x% CPU usage
1920x1080 > 3840x2160@30fps = 5x% CPU usage
720x480 > 1920x1080@60fps = 2x% CPU usage

If I use MadVR with same algorithm, it cannot play smoothly with 720x480 > 1920x1080@60fps.

which player are you using.

and please make a screen from the madVR OSD.

i have to say i'm not sure if a HD 4600 can do real time 3D LUT color correction at UHD 60 HZ.

and about the difference between bt 709 and sRGB: http://www.image-engineering.de/index.php?option=com_content&view=article&id=592&Itemid=210

so you just ahve to choice a gamma of about 2.4 to get a gamma of about 2.2. gamma should be choice on room lightning and not by simply fol lowering the spec the is a reason 2.4 gamma is now the recommended none BT 1886 gamma.

[baii]

What do OP mean convert to argb? Still don't get what OP is trying to achieve here...

Sent from my 306SH

[huhn]

What do OP mean convert to argb? Still don't get what OP is trying to achieve here...

Sent from my 306SH

the screen can do adobe RGB and widnows doesn't know that so all colors are send as sRGB/BT.709 so you get wrong colors.

[sswroom]

Video player I used for MadVR is MPC-BE x64.

Here is the screen capture on MadVR. As screen of exclusive mode cannot be captured, I capture the screen at non-exclusive mode.
Number of drop frame is much less in exclusive mode than non-exclusive mode. In exclusive mode, it gives around 5 drop frames per second.

Also, MadVR give poor chroma upsampling in some video source like this one.

P.S. Advantage for Adobe RGB over sRGB is that it provides wider coverage of NTSC and BT.2020 color.

[huhn]

Video player I used for MadVR is MPC-BE x64.

Here is the screen capture on MadVR. As screen of exclusive mode cannot be captured, I capture the screen at non-exclusive mode.
Number of drop frame is much less in exclusive mode than non-exclusive mode. In exclusive mode, it gives around 5 drop frames per second.

Also, MadVR give poor chroma upsampling in some video source like this one.

P.S. Advantage for Adobe RGB over sRGB is that it provides wider coverage of NTSC and BT.2020 color.

if madVR does a bad job on chroma up sampling please provide a small 5-10 sec sample so it is possibler to have a look at it.

[sswroom]

Here is the 5 second video segment which has chroma upsampling problem in MadVR:
http://sswroom.no-ip.org:5080/temp/MadVR/test.m2p

[captainadamo]

Posting it in the madVR thread would probably be more helpful to madshi.

[iSunrise]

P.S. Advantage for Adobe RGB over sRGB is that it provides wider coverage of NTSC and BT.2020 color.
Yes, but the problem with that is that madVR doesn't directly support sRGB or AdobeRGB via "the display is already calibrated to the following primaries / gamut" setting. You can only choose video related primaries / gamut settings, which was a decision madshi made back then.

For this exact reason everyone that has a PC monitor needs to either calibrate to video targets themselves, use a custom 3DLUT (e.x. AdobeRGB of your monitor) or you can choose something that is closer like BT.2020 (which is questionable, because it's not exact).

If you do anything else, you will get wrong colors, because there's no real movie content with AdobeRGB.

PS: This would indeed be better suited for the official madVR thread, because madshi could take a look.
PPS: You HD 4600 will indeed limit you greatly for such a specific configuration.

[huhn]

Yes, but the problem with that is that madVR doesn't directly support sRGB or AdobeRGB via "the display is already calibrated to the following primaries / gamut" setting. You can only choose video related primaries / gamut settings, which was a decision madshi made back then.

For this exact reason everyone that has a PC monitor needs to either calibrate to video targets themselves, use a custom 3DLUT (e.x. AdobeRGB of your monitor) or you can choose something that is closer like BT.2020 (which is questionable, because it's not exact).

If you do anything else, you will get wrong colors, because there's no real movie content with AdobeRGB.

PS: This would indeed be better suited for the official madVR thread, because madshi could take a look.

adobe RGb is not closer to BT 2020 it is way closer to bt 709

[iSunrise]

adobe RGb is not closer to BT 2020 it is way closer to bt 709
I don't really care. The problem is the same, it won't be accurate. Either won't help him to achieve what he wants.

In that case he should just go BT.709 in madVR and choose the monitors sRGB setting, because that would be a safe bet that most of the content will be displayed correctly.

[JanWillem32]

For this exact reason everyone that has a PC monitor needs to either calibrate to video targets themselves, use a custom 3DLUT (e.x. AdobeRGB of your monitor) or you can choose something that is closer like BT.2020 (which is questionable, because it's not exact).Using a custom lookup table is the preferred solution to mapping the renderer color space to the display output space. Using a generic Adobe RGB profile for this is possible, but inexact.If you do anything else, you will get wrong colors, because there's no real movie content with AdobeRGB.There's plenty of professional-grade video available in the Digital Cinema XYZ color space, which is larger than most other color spaces. (For Digital Cinema it's not useful other than getting more than 53 candela absolute color tone mapping to use a different color system than XYZ to encode color, as all visible colors can be encoded as XYZ.) Consumer video and display systems are just fifteen years behind professional-grade stuff regarding this issue.

[sswroom]

I don't really care. The problem is the same, it won't be accurate. Either won't help him to achieve what he wants.

In that case he should just go BT.709 in madVR and choose the monitors sRGB setting, because that would be a safe bet that most of the content will be displayed correctly.
Adobe RGB output can be accurate. As I know, there are at least 2 video player which support realtime accurate colorspace conversion with custom output colorspace. One of them is very expensive which is used in film production. Another one is made by me which is still under testing.

Color Primaries:
Bt.2020
rx = 0.708; ry = 0.292;
gx = 0.170; gy = 0.797;
bx = 0.131; by = 0.046;
w = D65

Bt.470M (NTSC)
rx = 0.6700; ry = 0.3300;
gx = 0.2100; gy = 0.7100;
bx = 0.1400; by = 0.0800;
w = C

Bt.709/sRGB
rx = 0.6400; ry = 0.3300;
gx = 0.3000; gy = 0.6000;
bx = 0.1500; by = 0.0600;
w = D65

Adobe RGB
rx = 0.6400; ry = 0.3300;
gx = 0.2100; gy = 0.7100;
bx = 0.1500; by = 0.0600;
w = D65

You will see that Adobe RGB is much wider than Bt.709, gx +0.09, gy +0.11
Bt.470M (NTSC) has only slightly different with Adobe RGB rx +0.03, bx +0.01 by -0.02.
For Bt.2020, it is defined to present nearly all visible color such that it is the most wide color range in all common colorspace.
In theory, Adobe RGB should have better color range which can use up nearly full range of monitor color. Disadvantage is that color level will have 10-20% decrease.

[huhn]

Adobe RGB output can be accurate. As I know, there are at least 2 video player which support realtime accurate colorspace conversion with custom output colorspace. One of them is very expensive which is used in film production. Another one is made by me which is still under testing.


3. madVR can do this too. you just need an 3D LUT which can be easily created.

the limited for madVR is currently bt 2020. you can do everything in between.

[iSunrise]

Adobe RGB output can be accurate.
Can you please stop speaking in riddles? Accurate for what exactly? What content do you have that needs the AdobeRGB colorspace?

Secondly, I already told you that madVR can do convert between colorspaces if you feed it with a custom 3DLUT that you can create yourself, but you need to calibrate your display for that, otherwise it won't be accurate.

A third option would have been to just assume that your monitor's AdobeRGB setting is fairly accurate, but for that to work madVR would need to have an option for "AdobeRGB" in the "the display is already calibrated to the following primaries / gamut" setting. Same applies for sRGB, but madVR simply doesn't have an option for it, it has been requested before, but madshi didn't feel it was worth it.

[huhn]

A third option would have been to just assume that your monitor's AdobeRGB setting is fairly accurate, but for that to work madVR would need to have an option for "AdobeRGB" in the "the display is already calibrated to the following primaries / gamut" setting. Same applies for sRGB, but madVR simply doesn't have an option for it, it has been requested before, but madshi didn't feel it was worth it.

you can just take a abdobe RGB icm and match it to bt 2020 and you are done.
this would do the same as adding adobe RGB in madVR. and yes i think it's worthless adobe RGB is not worth adding a 3D LUT is all that's needed.

[iSunrise]

you can just take a abdobe RGB icm and match it to bt 2020 and you are done.
this would do the same as adding adobe RGB in madVR. and yes i think it's worthless adobe RGB is not worth adding a 3D LUT is all that's needed.
madVR should have way higher quality than that. I would consider this a rather crude hack. Might work, but the 3DLUT would be much better, since it would actually include real measurements from the panel.

In any case, with your hack BT.2020 would need to be selected anyway, otherwise madVR can't convert between colorspaces on-the-fly when he feeds it with different content.

[baii]

What content OP exactly have here?
I mean madvr intended purpose is for viewing "video out there", and it does that.

Unless OP have video in made in aRGB space (let alone bt2020), I don't see the discussion going anywhere.

[huhn]

madVR should have way higher quality than that. I would consider this a rather crude hack. Might work, but the 3DLUT would be much better, since it would actually include real measurements from the panel.

In any case, with your hack BT.2020 would need to be selected anyway, otherwise madVR can't convert between colorspaces on-the-fly when he feeds it with different content.

a 16 bit 3D LUT is very accurate.

with real measuring and a real 3D LUT this hole topic is pointless because colors are accurate after that no matter what the display is. so yes you a right here.

but if you think your factory calibration is accurate you can just use the easy way with the bt 2020 "hack".

in the end this 3d LUT wil nearly never be used because it is only used for source over bt 709 and that's not even 0.1 % of all source a normal user will hold in his hands these days for everything esle the bt 709 adobe RGB 3D LUT will be used.

[sswroom]

madVR should have way higher quality than that. I would consider this a rather crude hack. Might work, but the 3DLUT would be much better, since it would actually include real measurements from the panel.

In any case, with your hack BT.2020 would need to be selected anyway, otherwise madVR can't convert between colorspaces on-the-fly when he feeds it with different content.
The best way to perform colorspace conversion is not using 3DLUT. As I search from the internet, 3DLUT values are usually in Gamma-corrected RGB value, not linear RGB value. As the previous process (Resize/deinterlace) are done in Linear RGB, convert back to Gamma-corrected RGB will lose precision.
Another problem is that 3DLUT is not memory efficient. It can only use ~25% of memory bandwidth.

The best method to convert colorspace is using PCS Matrix to perform floating-point multiplication in linear RGB which will not lose precision.
For the icm files, it only has the precision of 1/65536 which is not enough for 16 bit RGB calculation.

[huhn]

The best way to perform colorspace conversion is not using 3DLUT. As I search from the internet, 3DLUT values are usually in Gamma-corrected RGB value, not linear RGB value. As the previous process (Resize/deinterlace) are done in Linear RGB, convert back to Gamma-corrected RGB will lose precision.
Another problem is that 3DLUT is not memory efficient. It can only use ~25% of memory bandwidth.

The best method to convert colorspace is using PCS Matrix to perform floating-point multiplication in linear RGB which will not lose precision.
For the icm files, it only has the precision of 1/65536 which is not enough for 16 bit RGB calculation.

where does memory bandwidth play a rule for video playback?

even if multiply conversation are needed it doesn't really matter a madVR 3d LUT is 16 bit.

[sswroom]

where does memory bandwidth play a rule for video playback?

even if multiply conversation are needed it doesn't really matter a madVR 3d LUT is 16 bit.
I have made a Video player using pure CPU process. After several testing, the playback bottleneck is on memory bandwidth, not CPU power.
Memory performance in my computer:
speed using memcpy = ~6.5GB/s
My optimized memory copy = ~8.2GB/s (Memory bandwidth limit)
Speed required to write to display 3840x2160@60fps 8-bit = 1990656000 (~2GB/s)
Normal process is to process and write to a process buffer. And then wait for v-blank. After that, copy to display memory.
That means it requires minimum 4GB/s memory bandwidth (Process buffer + display memory) for display, no processing.
For normal lanczos resizer, it uses 2 1D resizer (Horizontal Lanczos filter + Vertical Lanczos filter). There should be an image buffer between these 2 operation. Which is another 2GB/s bandwidth.
There are only 2.2GB/s left for other operations including File reading, Decoding, YUV->RGB, RGB->Linear RGB, deinterlacing, LUT of lanczos resizer, Linear RGB->Output RGB. It is not enough.

The estimated processing speed I can get in my computer is around 1920x1080->3840x2160@50fps with full colorspace conversion in the limit of 8.2GB/s memory bandwidth.

[huhn]

I have made a Video player using pure CPU process. After several testing, the playback bottleneck is on memory bandwidth, not CPU power.
Memory performance in my computer:
speed using memcpy = ~6.5GB/s
My optimized memory copy = ~8.2GB/s (Memory bandwidth limit)
Speed required to write to display 3840x2160@60fps 8-bit = 1990656000 (~2GB/s)
Normal process is to process and write to a process buffer. And then wait for v-blank. After that, copy to display memory.
That means it requires minimum 4GB/s memory bandwidth (Process buffer + display memory) for display, no processing.
For normal lanczos resizer, it uses 2 1D resizer (Horizontal Lanczos filter + Vertical Lanczos filter). There should be an image buffer between these 2 operation. Which is another 2GB/s bandwidth.
There are only 2.2GB/s left for other operations including File reading, Decoding, YUV->RGB, RGB->Linear RGB, deinterlacing, LUT of lanczos resizer, Linear RGB->Output RGB. It is not enough.

The estimated processing speed I can get in my computer is around 1920x1080->3840x2160@50fps with full colorspace conversion in the limit of 8.2GB/s memory bandwidth.

and that's why microsoft EVR, MPDN and madVR use the GPU for such things.

[foxyshadis]

You'll never find a monitor accurate enough that 16-bit rounding on output will actually be meaningful, so the ICM fault is a bit of a red herring. You can assume each conversion shaves a half-bit off with dither, or a whole bit without, and that's still well above the 10-bit maximum you can output and input into a high-end monitor.

Still, it seems like you know what you're doing while working with colorspaces, and that's the most important part of all. Too many will switch around and just mess up their colors.

Also, interesting that Adobe RGB takes the red and blue from sRGB and the green from NTSC. I never realized it worked out that way.

[huhn]

You'll never find a monitor accurate enough that 16-bit rounding on output will actually be meaningful, so the ICM fault is a bit of a red herring. You can assume each conversion shaves a half-bit off with dither, or a whole bit without, and that's still well above the 10-bit maximum you can output and input into a high-end monitor.

Still, it seems like you know what you're doing while working with colorspaces, and that's the most important part of all. Too many will switch around and just mess up their colors.

Also, interesting that Adobe RGB takes the red and blue from sRGB and the green from NTSC. I never realized it worked out that way.

adobe RGB was created with a typo in green. it was just a mistake from adobe.

[huhn]

Video player I used for MadVR is MPC-BE x64.

Here is the screen capture on MadVR. As screen of exclusive mode cannot be captured, I capture the screen at non-exclusive mode.
Number of drop frame is much less in exclusive mode than non-exclusive mode. In exclusive mode, it gives around 5 drop frames per second.

Also, MadVR give poor chroma upsampling in some video source like this one.

P.S. Advantage for Adobe RGB over sRGB is that it provides wider coverage of NTSC and BT.2020 color.

the attached screen clear show you are using DXVA chroma upsampling not madVR chroma upsampling and your deinterlacing is buggy for what ever reason.

[vivan]

Intel chroma upscaling is broken and "use DXVA chroma upscaling when ..." are enabled by default. Disable those options (in rendering -> trade quality for performance).
In LAV Video Decoder settings switch "Hardware decoder to use" to None and enable YADIF. This will free up some GPU resources.

What are rendering times now? If still above 16ms - try switching chroma to bilinear, image to bicubic (catmul-rom or whatever). If still not enough - try DXVA upscaling.
4K display @ 60 fps is a really heavy load...

[sswroom]

Intel chroma upscaling is broken and "use DXVA chroma upscaling when ..." are enabled by default. Disable those options (in rendering -> trade quality for performance).
In LAV Video Decoder settings switch "Hardware decoder to use" to None and enable YADIF. This will free up some GPU resources.

What are rendering times now? If still above 16ms - try switching chroma to bilinear, image to bicubic (catmul-rom or whatever). If still not enough - try DXVA upscaling.
4K display @ 60 fps is a really heavy load...
Thank you for your information. After changing the setting, it gives around 17ms rendering time now. It give around 4-5 drop frames per second. It is outputing 2K @ 60 fps, not 4K. 4K is much slower. For 720x480x30p->4K@30fps, it gives avg ~41ms rendering, 14-15ms present time.

One point is that same algorithm (Lancoz in linear RGB upscale) is fast enough in pure CPU but is not fast enough in MadVR. Are there any setting can improve MadVR performance without changing algorithm? (Such as modifying internal process flow, using other optimization code)

[huhn]

Thank you for your information. After changing the setting, it gives around 17ms rendering time now. It give around 4-5 drop frames per second. It is outputing 2K @ 60 fps, not 4K. 4K is much slower. For 720x480x30p->4K@30fps, it gives avg ~41ms rendering, 14-15ms present time.

One point is that same algorithm (Lancoz in linear RGB upscale) is fast enough in pure CPU but is not fast enough in MadVR. Are there any setting can improve MadVR performance without changing algorithm? (Such as modifying internal process flow, using other optimization code)

you can go down to 10 bit buffering under rendering -> trade quality for performance and use software deinteralcing YADIF from lavfilter.

high present times are very strange is this windows 7 without aero ?

[sswroom]

you can go down to 10 bit buffering under rendering -> trade quality for performance and use software deinteralcing YADIF from lavfilter.

high present times are very strange is this windows 7 without aero ?
After setting to 10 bit buffering, total time is similar. 41-43ms for rendering, 12-15ms for present.
It give around 14 drop frames per second (720x480x30p video).

Memory bandwidth of GPU should be same as CPU becuase it uses shared memory from CPU which is ~8.2GB/s.

It is Windows 7 without Aero.

[vivan]

Memory performance in my computer:
speed using memcpy = ~6.5GB/s
My optimized memory copy = ~8.2GB/s (Memory bandwidth limit)
Speed required to write to display 3840x2160@60fps 8-bit = 1990656000 (~2GB/s)That's odd, dual-channel DDR3-1600 is supposed to be around 25.6 GB/s. It should be easier for GPU to reach peak bandwidth.
Also 1D scaling requires buffer proportional to the one of the source dimensions (means 1920x480 or 720x1080 - but not 1920x1080). It's also possible to run it with only ~1080*6 pixel buffer which should fit CPU cache - by processing it simultaneously in a wavefront manner.
After scaling you don't need any extra buffer (color correction and ordered dithering need only current pixel value).

One point is that same algorithm (Lancoz in linear RGB upscale) is fast enough in pure CPU but is not fast enough in MadVR. Are there any setting can improve MadVR performance without changing algorithm? (Such as modifying internal process flow, using other optimization code)Well, there're several other options in "trade quality" page, but I'm not sure if they would affect performance in this case.
madVR is not really optimized for slow graphics - it sacrifices some performance that would be neglectable on GPUs that it's designed for (e.g. it does some extra RGB<->YUV conversions during some rendering steps). But with closed source it's impossible to know how slower it is compared to a "perfect optimization".

It is Windows 7 without Aero.Playing video without Aero (without using fullscreen exclusive mode where it doesn't matter) is generally a bad idea, so try enabling it.

[sswroom]

That's odd, dual-channel DDR3-1600 is supposed to be around 25.6 GB/s. It should be easier for GPU to reach peak bandwidth.
Also 1D scaling requires buffer proportional to the one of the source dimensions (means 1920x480 or 720x1080 - but not 1920x1080). It's also possible to run it with only ~1080*6 pixel buffer which should fit CPU cache - by processing it simultaneously in a wavefront manner.
After scaling you don't need any extra buffer (color correction and ordered dithering need only current pixel value).

I can get ~20GB/s for write only operation, ~16GB/s for read only operation. Memory copy is the combination of read and write, so it should be much slower. Also, the peak memory bandwidth is the bandwidth between RAM and L1 Cache, not L2/L3 cache that used in instructions.

1D scaling buffer I calculated is 3840x1080x60x8 (16-bit*4) ~= 2GB/s (4 channel is optimized for 1-bank/16 bytes memory access)


Well, there're several other options in "trade quality" page, but I'm not sure if they would affect performance in this case.
madVR is not really optimized for slow graphics - it sacrifices some performance that would be neglectable on GPUs that it's designed for (e.g. it does some extra RGB<->YUV conversions during some rendering steps). But with closed source it's impossible to know how slower it is compared to a "perfect optimization".

What I guess is that MadVR uses module base operation. There are some extra temporary buffer such that memory requirement higher than necessary. i.e. after resize, there is a buffer to store all 16 bit RGB data and pass to next module. It is much easier to program but less efficiency. Another possible reason is that GPU operation does not support 16 bytes/1 bank memory operation and memory efficiency is reduced.


Playing video without Aero (without using fullscreen exclusive mode where it doesn't matter) is generally a bad idea, so try enabling it.
The time is measured in fullscreen exclusive mode which should be independent on Aero mode. There are some bad side effects to enable Aero mode because the machine is 7x24 machine.