View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
6th May 2009, 17:04
Pb' = B' - Y'
Three questions:
(1) wikipedia says: "Pb' = 0.5 * (B' - Y') / (1 - Kb)". So you see, the wikipedia formula is different to yours. Is wikipedia wrong?
(2) You write "B' = Cb + Y'eq + 0.5". That can't be right! I mean both Cb' and Y' are in the range [0..1]. If I add them up and add another 0.5 on top of that, I will end up with > 1 for many pixels! E.g. a middle brightness grey has both Y' and Cb' at 0.5. So for middle brightness grey your formula would give me a B' value of 1.5! Or am I missing something?
(3) Could you please explain to me why scaling B' and R' would result in better results compared to scaling Cb' and Cr'?
Thanks!
Thunderbolt8
6th May 2009, 18:00
never quote from wikipedia :P
Wilbert
6th May 2009, 21:46
never quote from wikipedia :P
wikipedia quotes poyton (http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html) for these formulas, see equation 28. Assuming Poyton is correct, wikipedia is also correct. yesgrey3 has forgotten to scale the components to [-0.5,0.5].
ericgur
6th May 2009, 23:14
Hi madshi,
Upscaling algorithms is a matter of taste. Downscaling algorithms are not, as an ideal algorithm exists.
Can you make the downscaling algorithms different from the upscaling algorithms (per axis)?
Example: I want the upscaling algorithm to be some bicubic and the downscaling Lanczos8. So if the video is 720p and my plasma TV is XGA (1024x768) than I can enjoy the high quality downscaling of Lanczos8 and mild upscaling of bicubic.
Note that the chroma in the above example is upscaled in both axises.
The only problem I see, besides the extra steps, is you considering that R", G" and B" would get the same correction from Y' values. R', G' and B' have different contributions to Y', so R", G" and B" should also be corrected by different values, which could not be computed with the suggestion you made.
I think that my method should be pretty simple to try, because does not require significative changes by madshi. Then, if it gives any improvement, maybe we can think on more complex methods.
Thanks!
And why your method does not finish in R'G'B' space like this:
4) Calculate G' values using the upsampled B' and R' and the Y' values of each pixel: G'=(Y'-Kr*R'-Kb*B')/Kg.
5) Degamma R'G'B' --> RGB
6) Scale
7) Gamma it RGB --> R'G'B'
@madshi
Would it save CPU/GPU cycles to detect black bars at the top/bottom and omit them from processing? This could be done in different ways:
- on-the-fly, i.e. madVR analyzes the first few minutes and determines the probable crop frame
- in the renderer settings dialog, e.g. implement known offsets for various ARs, e.g. 136px top/bottom for 2.35:1
- by supplying an auto-loading *.madvrpreset file with movie-specific settings, similar to what ffdshow provides
The third option could also be used for setting movie-specific resampling options or presets, e.g. for anime content.
madshi
7th May 2009, 07:12
Upscaling algorithms is a matter of taste. Downscaling algorithms are not, as an ideal algorithm exists.
Can you make the downscaling algorithms different from the upscaling algorithms (per axis)?
Example: I want the upscaling algorithm to be some bicubic and the downscaling Lanczos8. So if the video is 720p and my plasma TV is XGA (1024x768) than I can enjoy the high quality downscaling of Lanczos8 and mild upscaling of bicubic.
Note that the chroma in the above example is upscaled in both axises.
I already thought about doing that, but then I thought it might be too complicated for users to set 3 different algorithms. But I guess image quality is more important than settings dialog complexness. So I'll add separate controls for luma up/downscaling.
Would it save CPU/GPU cycles to detect black bars at the top/bottom and omit them from processing?
Doing it via settings somewhere would save some GPU cycles. Not sure about performance effect on doing it on-the-fly. Might save performance or actually cost performance. Anyway, I think the gain is performance would probably be small (10%-20%?), so I'm not sure if it's worth complicating things by adding such a thing.
pankov
7th May 2009, 10:27
Doing it via settings somewhere would save some GPU cycles. Not sure about performance effect on doing it on-the-fly. Might save performance or actually cost performance. Anyway, I think the gain is performance would probably be small (10%-20%?), so I'm not sure if it's worth complicating things by adding such a thing.
Also there are rare cases like The Dark Knight when the movie changes resolution/aspect ratio a few times during it's length (IMAX (16:9) vs. "normal" (2.35:1)). What will happen then with "on-the-fly" prediction? I really don't like "too smart" application - they always make a mistake sooner or later.
mark0077
7th May 2009, 10:44
Also there are rare cases like The Dark Knight when the movie changes resolution/aspect ratio a few times during it's length (IMAX (16:9) vs. "normal" (2.35:1)). What will happen then with "on-the-fly" prediction? I really don't like "too smart" application - they always make a mistake sooner or later.
Yeah I don't think the internal AR is encoded (ie 2.35:1 within 16:9 or 16:9 within 16:9) so I would imagine it would be more costly to check each frame for pure black bars before any resizing. Also the black bar's are often not 100% black, I mean they sometimes may be slightly grainy.
On-the-fly was not supposed to mean for each frame but to lock the detected AR after a few minutes (intro, titles, etc).
The question is: isn't the cost of scaling/post-processing each frame linearly dependant on the number of pixels of each frame? So for a 1920x1080 frame at 2.35:1, cropping off black borders saves processing 25% of all pixels. I'd say this is quite significant and might be the difference between smooth and not smooth playback. ;)
Anyway, the most practical solution would be to have the user set the crop frame (like in ffdshow) and auto-load that preset file depending on the filename (like in ffdshow).
This concept works quite well in ffdshow, why shouldn't it in madVR? Also, given the discussion about the "optimal" resampling algorithm for different movie types, I dare to say that in the end madVR will include such a mechanism anyway ... ;)
yesgrey
7th May 2009, 11:33
yesgrey3 has forgotten to scale the components to [-0.5,0.5].
(1) wikipedia says: "Pb' = 0.5 * (B' - Y') / (1 - Kb)". So you see, the wikipedia formula is different to yours. Is wikipedia wrong?
No, I have not forgotten to scale the components. I just thought that for the intent it's not needed.
If you look only to the final result you will see that they will be within the range. The B' and R' intermediate values are only used to calculate the Cb' and Cr', nothing more.
Of course I could have added the scaling like noted in the wikipedia formula, but that would only be an extra computation step in the chain, and if not needed, we can simply dismiss it. Unless the upscaling algorythms, or the shaders, only work fine within the range [0.0 1.0], there is no need to add the scaling so we can get B' and R' values in the [0.0 1.0] range.
(2) You write "B' = Cb + Y'eq + 0.5". That can't be right!
Yes, it's not. The correct formulas are:
B' = Cb' + Y'eq - 0.5
R' = Cr' + Y'eq - 0.5
I will correct the post.
Sorry. It was late, a big day, and I switched the signal.:o
(3) Could you please explain to me why scaling B' and R' would result in better results compared to scaling Cb' and Cr'?
Considering the formulas
Cb' = 0.5 + B' - Y'
Cr' = 0.5 + R' - Y'
If we scale Cb' and Cr', we will scale, indirectly, both B', R' and Y', so B', R' and Y' would have an error.
If we only scale B' and R', only B' and R' would have an error, because the Y' value is already known.
The question is. Would the error in B' and R' when scaling Cb' and Cr', when compared to only scaling B' and R', be the same, less or higher?
Also, our eyes are more sensitive to green than to red or blue, and Y' has more green than red and blue, so, even if the error when scaling only B' or R' is higher, maybe the final result would be better, because the Y' will not have any error...
As I said, my proposed method could be a very dumb idea, but since it should be pretty simple to test, maybe it's worth doing it...
It's your decision.;)
Thanks!
And why your method does not finish in R'G'B' space like this...
That could be an option in the future, but for now madshi is not (yet) doing the scaling in the linear domain.;)
pie1394
7th May 2009, 14:52
Good Job! madshi. :thanks:
You have done the job to make my dream come true. Two years ago when I was working on the image processing product for one embedded processor platform, it was onced dreamed when "Lanczos3/4" algorithm can be implemented on nVidia G80 with FullHD output.
The output image color and sharpness by madVR look better than those by EVR and HaaliVR on my Hitachi PDP TV.
Here are the setup and measured numbers with my system.
CPU: C2D E6750 (2.66GHz)
GPU: 8800GTS/320 (G80) + Forceware 182.50 for XP
Player: MPC-HC + Reclock
VR: madVR 0.9 + Lanczos4 + Disable Tearing Fix
Screen Resolution: 1920x1080 32bpp (59.94Hz)
Video Resolution --> AvgTime (MaxTime)
640x352 --> 9.33ms (15.61ms)
1280x720 --> 12.92ms (18.88ms)
1440x1080 --> 17.14ms (23.14ms)
1904x1072 --> 17.56ms (23.63ms)
1920x1080 --> 11.39ms (17.81ms)
ps:
It is not recommended to do scaling if there is less than 16 pixel difference between video-in and video-out. For the above 1904x1072 video, madVR 0.9 gets it scaled to (1,0)-(1919,1080) on my system.
It is not recommended to do scaling if there is less than 16 pixel difference between video-in and video-out. For the above 1904x1072 video, madVR 0.9 gets it scaled to (1,0)-(1919,1080) on my system.
Why? Also such scaling is pretty typical when showing video in a window (i.e. not fullscreen mode). I don't see why it is not good in this case.
mark0077
7th May 2009, 21:25
On-the-fly was not supposed to mean for each frame but to lock the detected AR after a few minutes (intro, titles, etc).
The question is: isn't the cost of scaling/post-processing each frame linearly dependant on the number of pixels of each frame? So for a 1920x1080 frame at 2.35:1, cropping off black borders saves processing 25% of all pixels. I'd say this is quite significant and might be the difference between smooth and not smooth playback. ;)
Anyway, the most practical solution would be to have the user set the crop frame (like in ffdshow) and auto-load that preset file depending on the filename (like in ffdshow).
This concept works quite well in ffdshow, why shouldn't it in madVR? Also, given the discussion about the "optimal" resampling algorithm for different movie types, I dare to say that in the end madVR will include such a mechanism anyway ... ;)
Well as Pankov pointed out, movies which might look to be say 2.35:1 for the first 20 minutes, might still contain scenes that contain the full 16:9 aspect ratio, I guess the director did this for some reason....
In this case, manual setting a crop size for a movie is not correct.... or at least time consuming to add various ratios for diffrent scenes... I guess in the scenario when the user KNOWS a whole scene / movie is say 2.35:1 then an option to crop off these sections for performance would be nice... but long term I can't see such a feature being kept as the average users gpu's performance grows to the point where its not an issue.
ericgur
7th May 2009, 23:25
Found a bug in 0.9. When a video is opened and the video window is at the exact resolution of the video clip the video is offseted to the right and down. The amount of offset looks like the distance from the player's top left corner to the desktop corner.
I rechecked with 0.8 and it doesn't happen. When the video is either opened when scaling is needed or when scaling the video at any time the video is displayed correctly.
I'm using ZoomPlayer (latest).
How to reproduce:
Open a video with ZP in window mode (not full screen). Press either ~ or CTRL+2 to make the video display at 100% size (use a video with square pixels so no scaling is done). Press 'O' and open the same video again and see the problem.
pie1394
8th May 2009, 05:43
Why? Also such scaling is pretty typical when showing video in a window (i.e. not fullscreen mode). I don't see why it is not good in this case.
It is just an idea to skip image scaling action for the condition that it is not absolutely necessary. With such idea, the image will be put centered with very thin black bars at two border sides. Most people should not even notice that, is it?
The real situation also depends on the top-left output (x,y) axis position. Modern HW-accelerated GPU could have 8 or 16 pixel-aligned restriction due to fetched image's pixel packing format in the frame buffer.
Nvidia 9400 IGP, MPC-НC 1095, Directx 10.0(6.0.6000.16386)
Vista 32
MadVR can not detect correctly display refresh rate with new driver Nvidia 185.85 (By the way driver properties in control panel say "compatible Windows 7 display driver", so can it output 30/36 bit RGB? Is there any card supporting deep color?).
Using 182.08 everything was OK.
Nvidia 182.08
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable)
display 23.976 (absolutly stable)
Nvidia 185.85
Aero ON
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 26.976Hz (unstable)
display 27.976 (1s) (unstable)
Aero OFF
display estimate 1: 24.97Hz
display estimate 2: 0.0Hz
display estimate 3: 0.0Hz
display 55.9 (1s)
tetsuo55
8th May 2009, 16:10
I built a new system, the videocard is a 4770.
Estimate 1 is always wrong
Estimate 2 is very close to the fact
Estimate 3 is slighty less accurate than 2
2 and 3 are really close to eachother.
Even with lancsoz8 total rendering time stays below 10ms regardless of resolution,
(Too bad that the image stutters like crazy in pans or this would be my default renderer, i am patiently awaiting smoothvideo)
I built a new system, the videocard is a 4770....
Tetsuo55, I just ordered a 4770 as well and it will driving a dual-mon set up with my sec as a 1080P LG HDTV (set for PC levels input, HDMI).
I'm curious what monitor you are driving and if you've tried SplineX/SoftCubicX and what refresh rate your panel is set for and what type of videos are you playing?
tetsuo55
8th May 2009, 16:34
Tetsuo55, I just ordered a 4770 as well and it will driving a dual-mon set up with my sec as a 1080P LG HDTV (set for PC levels input, HDMI).
I'm curious what monitor you are driving and if you've tried SplineX/SoftCubicX and what refresh rate your panel is set for and what type of videos are you playing?
I am currently using a DVI <> HDMI cable, i will start using the dongle soon.
My panel is 1920x1080@60hz(sony bravia) (single monitor setup)
I have tried every filter and none of them push the average rendering time over 10 ms, although i have seen a max rendering time of 42 once, but i think that was caused by seeking.
type of videos i have tried are 480p, 480i, 720p, 1080p.
h264, divx, VC1, mpeg2, realvideo
Pretty extensive testing i would say.
Indeed. Have you tried setting your Bravia to 24Hz (if it supports it) for your 23.976fps material to see what happens? Do you use Reclock with madVR?
tetsuo55
8th May 2009, 16:57
Indeed. Have you tried setting your Bravia to 24Hz (if it supports it) for your 23.976fps material to see what happens?The Bravia does support 25hz but i have not tested madVR with it.
The reason for this is that i have mixed FPS content, and the desktop/Gaming is terrible with 24hzDo you use Reclock with madVR?I do not use reclock at all.
Three questions:
(3) Could you please explain to me why scaling B' and R' would result in better results compared to scaling Cb' and Cr'?
Thanks!
@madshi
Excuse me for replying for yesgrey3 and let me quote Don Munsil:
#102
http://archive2.avsforum.com/avs-vb/showthread.php?t=460922&page=4&pp=30
Quote:
Do you know of any specific problems processing Y'CbCr where the result is bad and not fixable with careful coding?
It's always bad working in Y'CbCr, because as mentioned before it's not a linear space. Any normal linear math you might want to do, like interpolation, completely fails because the final R, G, and B values are all dependent on more than one of Y', Cb, and Cr. Interpolated Y'CbCr values do not map to the same colors as the equivalent RGB values equivalently interpolated.
In R'G'B' it's a little better, but not much. Again, linear operations (like interpolation) produce incorrect results. The short version of the problem is that all edges get pulled toward black.
The "careful coding" solution is simple: convert to linear.
madshi
8th May 2009, 19:40
If we scale Cb' and Cr', we will scale, indirectly, both B', R' and Y', so B', R' and Y' would have an error.
If we only scale B' and R', only B' and R' would have an error, because the Y' value is already known.
The question is. Would the error in B' and R' when scaling Cb' and Cr', when compared to only scaling B' and R', be the same, less or higher?
Also, our eyes are more sensitive to green than to red or blue, and Y' has more green than red and blue, so, even if the error when scaling only B' or R' is higher, maybe the final result would be better, because the Y' will not have any error...
As I said, my proposed method could be a very dumb idea, but since it should be pretty simple to test, maybe it's worth doing it...
I guess I'll need to get into my meditation chair and spend a few hours thinking about that, so that I might hopefully understand it... :o
The output image color and sharpness by madVR look better than those by EVR and HaaliVR on my Hitachi PDP TV.
Glad you like it! Your numbers are pretty fine, for movie content at least.
It is not recommended to do scaling if there is less than 16 pixel difference between video-in and video-out. For the above 1904x1072 video, madVR 0.9 gets it scaled to (1,0)-(1919,1080) on my system.
madVR does not decide how much is scaled or not. That's up to the media player to decide. E.g. in MPC HC you can select unscaled output, or fit to window size or some other options. MPC HC then tells madVR what to do. So it is not really in my hand if less than 16 pixel differences are scaled or not. I think the MPC HC guys would have to implement that...
Found a bug in 0.9. When a video is opened and the video window is at the exact resolution of the video clip the video is offseted to the right and down. The amount of offset looks like the distance from the player's top left corner to the desktop corner.
I rechecked with 0.8 and it doesn't happen. When the video is either opened when scaling is needed or when scaling the video at any time the video is displayed correctly.
I'm using ZoomPlayer (latest).
How to reproduce:
Open a video with ZP in window mode (not full screen). Press either ~ or CTRL+2 to make the video display at 100% size (use a video with square pixels so no scaling is done). Press 'O' and open the same video again and see the problem.
I can reproduce it, thanks. Will fix it later...
BTW, just wondering: Do you happen to know (and are you allowed to tell) which upscaling algorithms the professional chips (HQV Realta, Gennum VXP, DVDO etc) are using? Do they use some sort of Lanczos? Or do they use some special tricks?
I built a new system, the videocard is a 4770.
Even with lancsoz8 total rendering time stays below 10ms regardless of resolution
Well, that sounds awesome! I expected the 4770 to do good, but not *that* good. Practically it means that you'll be able to use Lanczos8 even for 60p video content, which is really hard on the GPU (when using madVR). However, madVR is not yet feature complete. I'm sure I'll find some new algorithms to bring even the 4770 to its knees... ;)
Excuse me for replying for yesgrey3 and let me quote Don Munsil
There's no information in that post that I didn't already know. yesgrey3 did *not* suggest to do chroma upsampling in linear light, which Don advertises in his post. And FWIW, Don doesn't seem to think that chroma upsampling should or could be done in linear light, as he told me in another thread.
pie1394
9th May 2009, 02:25
BTW, just wondering: Do you happen to know (and are you allowed to tell) which upscaling algorithms the professional chips (HQV Realta, Gennum VXP, DVDO etc) are using? Do they use some sort of Lanczos? Or do they use some special tricks?
Here is the link of Realta v1.6 datasheet which briefly describes the features:
http://www.siliconoptix.com/contentEngine/dspDocumentDownload.cfm?PCVID=2d432425-a82d-4ad0-d280-92e6c8f3c801
It can apply 16 ~ 1024 tap adaptive filtering for scaling. If I don't read it wrong, the Lanczos8 can be easily achieved at 1/64x ~ 1.0x down-scaling on it.
The Japanese LCD TV vendors like Hitachi, JVC, Sony, Toshiba design their own scaling algorithm, which is called somthing like "super resolution". As I know, they are not just 1-pass scaling processing, but multi-passes. The basic idea seems to deal with different frequency signals with different methods.
The Realta chip's deinterlacing algorithm uses 4 fields to decide the pixel motion direction. If I am not wrong, it is a very luxury motion-adaptive DCDi algorithm since it requires the hardware to choose the Median value from 5 inputs.
Before I ever tried the basic (2D) DCDi method, which just needs 1 field and thus the Median from 3 inputs. But the quality is bad at the edge of shape. The workaround is to add 5-tap VT (Vertical Temporal) deinterlaced value into consideration (2-field algorithm). The value difference between input value and DCDi predicted one is checked. Let me take 8-bit color depth as the example. For digital contents, if the difference is equal or less than 20, choose DCDi predicted one. Otherwise choose 5-tap VT one. (The reason is easy to understand...)
Not quite sure how it is costly to run such algorithm with the Pixel Shader. The vector processor I used before has the throughput of processing 16 8-bit pixels per cycle with 8-tap filtering in pure Horizontal or pure Vertical direction, or random 8 inputs per pixel from somewhat limited 2D positions. Thus the 5-tap or 7-tap VT has such theoretical throughput. If I don't remember it wrong, the pure DCDi method requires about 31 ~ 33 cycles to do 8x8 on such processor while it only needs 4 cycles for 5/7-tap VT. With that MIMD processor, it just requires extra 4~5 cycles to run the cominbed Motion-adaptive algorithm.
It is believed you will add the OSD Pin to support subtitle later. Do you plan to do it with 32-bit RGBA or even 40 / 64-bit one? (if the input OSD pin requires scaling...)
Mark_A_W
9th May 2009, 06:02
Tetsuo55, I just ordered a 4770 as well and it will driving a dual-mon set up with my sec as a 1080P LG HDTV (set for PC levels input, HDMI).
I'm curious what monitor you are driving and if you've tried SplineX/SoftCubicX and what refresh rate your panel is set for and what type of videos are you playing?
Anyone know if the 4770 will be available in a single slot model?
All the ones I have seen have a dual slot cooler.....and my Xonar will only fit right next to the video card :(
madshi
9th May 2009, 08:06
Here is the link of Realta v1.6 datasheet which briefly describes the features. [...] It can apply 16 ~ 1024 tap adaptive filtering for scaling.
Thanks. But that doesn't tell us anything about what they do with the taps, which kind of filter they're using etc...
The Japanese LCD TV vendors like Hitachi, JVC, Sony, Toshiba design their own scaling algorithm, which is called somthing like "super resolution". As I know, they are not just 1-pass scaling processing, but multi-passes. The basic idea seems to deal with different frequency signals with different methods.
AFAIK, this is not part of the scaling algorithm, but it's a separate sharpening/detail enhancement step.
Real "super resolution" uses multiple frames and compares them somehow to increase resolution. At least that's what I read somewhere. I don't think any TV vendor has implemented such a thing yet. Maybe Toshiba is trying with their Cell based architecture, I don't know...
The Realta chip's deinterlacing
I don't know if I will ever implement any deinterlacing. Probably not, but I've not fully decided yet. I only have that much time on my hands. And my main priority is Blu-Ray (24p), anyway. All that DCDi etc stuff is only needed for video content and that is < 1% of my personal viewing content.
It is believed you will add the OSD Pin to support subtitle later. Do you plan to do it with 32-bit RGBA or even 40 / 64-bit one? (if the input OSD pin requires scaling...)
I've no idea. I don't know anything about subtitle rendering. It's not the top priority on my to do list, so I haven't even looked into it yet. I'll have to dig into how it all works once I come to that point in my to do list...
yesgrey
9th May 2009, 13:43
I guess I'll need to get into my meditation chair and spend a few hours thinking about that, so that I might hopefully understand it... :o
You can always do what some scientists do. First, you try it, then, if it works, you try to understand how.:D
More seriously, I'm sorry if I'm not clear enough, but english is not my native language, so it's a bit harder for me to explain my ideas...
yesgrey3 did *not* suggest to do chroma upsampling in linear light, which Don advertises in his post. And FWIW, Don doesn't seem to think that chroma upsampling should or could be done in linear light, as he told me in another thread.
Yes. The chroma downsampling is performed in non-linear light, so it seems to be more reasonable to also perform it in the non-linear light; also, to convert to linear light for processing, we would need the missing chroma samples, and that would be a problem...;)
But of course that, when madshi decides to try the resizing in the linear light, we can also try something with it. Both me and madshi already discussed this briefly in another thread, we even proposed two methods for doing it.
wayland
9th May 2009, 16:16
attached is a vsync.dat file, had to wait until i could post it. i got a 9600gt yesterday, i also have a vsync.dat file from a ati 3400 if it will help
Here is the comparison between an nVidia 9600GT and the new ATI 4770. The rest of the configuration is the same (Vista Ultimate SP1 32-bit, MPC-HC 1101 SVN, ReClock 1.8.4.2 no resampling no vsync, madVR 0.9, CoreAVC 1.9.5.0 no CUDA), playing Iron Man (US) AVC BD from HDD, on an AMD 9650 AM2, 2.5GHz 4 cores, 4 (3.5) GB RAM.
(1) nVidia 9600GT, 1024 MB RAM on graphics card, 1920x1080 video resized to 1680x1050 display, SoftCubic 50/100:
avg gpu rendering time: 14.09ms
6.38ms update textures
3.92ms resample textures
0.16ms clear
0.10ms init samplers
3.53ms render
max gpu rendering time 17.79ms
6.40ms update textures
7.35ms resample textures
0.23ms clear
0.22ms init samplers
3.59ms render
avrg present wait 4.26ms
(1) ATI 4770, 512 MB RAM on graphics card, 1920x1080 video resized to 1680x1050 display, SoftCubic 50/100:
avg gpu rendering time: 15.02ms
5.39ms update textures
5.30ms resample textures
0.44ms clear
0.05ms init samplers
3.84ms render
max gpu rendering time 20.76ms
6.79ms update textures
8.49ms resample textures
0.54ms clear
0.29ms init samplers
4.65ms render
avrg present wait 5.38ms
;)
EDIT:
I have to say, though, that subjectively playback on the 4770 appears to be a lot smoother than on the 9600. While on the 9600 I had tearing, on the 4770 there is none, just a very slight stuttering.
tetsuo55
9th May 2009, 19:45
(1) ATI 4770, 512 MB RAM on graphics card, 1920x1080 video resized to 1680x1050 display, SoftCubic 50/100:
avg gpu rendering time: 15.02ms
5.39ms update textures
5.30ms resample textures
0.44ms clear
0.05ms init samplers
3.84ms render
max gpu rendering time 20.76ms
6.79ms update textures
8.49ms resample textures
0.54ms clear
0.29ms init samplers
4.65ms render
avrg present wait 5.38ms
;).
wow those values are pretty bad compared to my system
I get a avg gpu rendering time of between 5 and 8 ms with those settings.
Is downscaling more intesive than upscaling?
My system:
e8400(3ghz) on a p45 mobo, 4gb ddr2, windows 7 RC1 x64
EDIT:
Which drivers are you using? i have CAT9.4(it came on the disc and uses a modified inf file because the one on amd.com does not support the 4770)
I used the drivers from the CD since, as you pointed out, the AMD drivers don't support the GPU (officially).
I have a different CPU, different OS, different chipset, so I don't think your numbers and mine are comparable.
What I wanted to compare was the 9600 to the 4770 on my system, assuming that the rest of my build is not biased against the 4770 or in favor of the 9600. Especially in light of my point that memory bus width might be more important than raw processing power or (theoretical) GPU RAM bandwidth.
mark0077
9th May 2009, 20:38
Just trying out an m2ts file 1920 x 1080 with madVR 0.9 and got statistics up for the first time.
I am getting what people described earlier where looks like chroma luma are offset vertically by quite a distance, maybe 50 pixels. Bottom of the screen then shows a 10 pixel high~ yellow horizontal bar and on top a greenish 40 pixel high~ bar that goes accross the entire screen.
Using NVidia GTX 295 with lanczos 4tap, getting ~ 7ms gpu rendering time average.
So finaly i had some time to start playing around with madVR, i just started to put some numbers to every possible scaling method. I used a free available trailer for this, so other can compare there GPU easily:
Star Trek Trailer 1080p (http://movies.apple.com/movies/paramount/star_trek/startrek-tlr3_h1080p.mov)
Star Trek Trailer 480p (http://movies.apple.com/movies/paramount/star_trek/startrek-tlr3_h480p.mov)
And then i just did a screenshot of every available scaling method (i did always used the same one for luma and chroma, so i missed the SoftCubic100 because its just for chroma). I named those pics 480pA-480pP and 1080pA-1080pP from A=top (Nearest Neighbor) to P=bottom (Spline64):
http://www.armster.de/caspar/A-P.jpg
You can find all the pics in the following zip (55MB):
http://rapidshare.com/files/231087017/startrek.zip
If you study my numbers you will find that its all okay till Lanczos4, there my GPU starts breaking ;-) Ohh and the colors are of - but i guess its to the stupid coding of apple, they will just took the 1080p material and scaled it down to 480p without changing the colorspace and now madVR uses the 601 code for the 480p version and i guess its stil 709...
PC System: Intel Q9550 + 2GB RAM + ATi 3650 (old driver 8.4 or 8.5 because that was the last one that doesn't produce tearing for me with vmr9), Software is Win XP Sp3 + ZoomPlayer + CoreAVC + madVR 0.9 + ffdshow (audio) + ReClock
I already got a ATi 4770 here, but didn't had the time to intigrate it into my htpc - numbers with the 4770 will follow (madshi you get something from ati/amd for promoting the 4770, or ? ;-))
Now back to a little problem i already described a few pages back with the OSD and strange ARs. In my homecinema i use a ISCO II lens for 2.35/2.40 content, so i do a digital vertical stretch so my lens can horizontal stretch the image later:
Normal AR for 1.78:1 stuff:
http://www.armster.de/caspar/AR01.jpg
Changed AR for 2.35/2.40:1 stuff:
http://www.armster.de/caspar/AR02.jpg
http://www.armster.de/caspar/AR03.jpg
As you can see on my following screenshots of the Ironman BD i loose the top 11 lines of the OSD Information that way:
Screenshot 1 - normal AR (http://www.armster.de/caspar/ironman01.png)
Screenshot 2 - custom AR (http://www.armster.de/caspar/ironman02.png)
Is it possible to somehow change the position of the OSD ?
Anyway, good work madshi with the renderer i already love it ! I would like it if you could later add some kind of deinterlacing if you find the time (and ofcourse its way down the list) because i love my concert blu-rays, many of them have perfect PQ (The Police, Jeff Beck, Die Toten Hosen, etc.), but most of them are interlaced (some 60hz, even some 50hz) and my CPU needs already to be overclocked for some, because some are VC-1 and Windows Media DMO is not really good multithreaded and ffdshow/ffdmpeg can not handle interlaced VC-1 - so there is no room for deinterlacing on the CPU even with a Q9550... but first the smooth/anti-tearing stuff ;-) Thanks !
EDIT: Changed the big PNGs from image to download, sorry !
STARSBG
10th May 2009, 18:20
Hello. Is there way with which I use MadVR and subtitle ?
kostik
10th May 2009, 19:43
Here is my OSD screenshot:
http://rotter.name/User_files/nor/4a071ed805fde58f.jpg
The movie I played is 1080p.
my specs:
qued core q6600
ati 4850HD
2gb ram ocz
windows 7
coreavc codec+haali splitter +mpc hc.
Resolution in catalyst: 1920*1080P 24HZ which my tv supports.
Works great and smooth without reclock,
I use the default softbicub resample settings
ericgur
10th May 2009, 22:01
BTW, just wondering: Do you happen to know (and are you allowed to tell) which upscaling algorithms the professional chips (HQV Realta, Gennum VXP, DVDO etc) are using? Do they use some sort of Lanczos? Or do they use some special tricks?
Well, I didn't work for any of these companies. But you had a great idea in avsforum about using an adaptive scaler - switch the algorithm or coefficients depending on the content of the sampling window. Adaptive scaling (in non academic solutions) are usually done in 1D (horizontally then vertically or vice versa). Native 2D scaling in HW (using >4x4 windows) is very expensive and I'm not aware of any implemetations. In SW it would not be close to real time. Personally I think the 1D approach is the way to go. BTW, 1D bilinear, bicubic or lanczos produce the same results as their 2D versions unless there's clipping after the first 1D scaling. By clipping I mean removing negative values or values above 255 - if the intermediate results are in floating point or fixed point with enough headroom then you're fine. The most important thing about doing any adaptive video processing algorithm in general, is to make the decision a 'soft' one not a binary one. So when 2 similar (look similar) sampling windows are analized, the scaler coefficients for both windows will be similar as well.
I'll try to find a good paper on this type of scalers.
Note that if you use a sharp scaler you'll also sharpen the noise (digital and analog) and might produce a very noisy image. Adaptiveness might also come from choosing the sharpness of the scaler depending on the quaility of the video (blocky video should be scaled with a soft scaler for better image quality).
I'm sorry I can't be more specific.
ericgur
10th May 2009, 22:16
Almost forgot, the holy grail of (up) scaling is called super resolution. The principle is guessing the values of a pixel using several 2D sampling windows over time, taking into account the motion between them. This way you can actually recover details that are lost in the individual frames. This is espcially impressive on moving text. As a bonus you also get very good noise reduction. The problem is that you'll need an excellent motion estimator, unlike the ones found in encoders :(
The artifacts caused by bad motion vectors are quite horrible and the computation cost is high. It's probably possible to do this on a modern GPU if motion vectors are not calculated for each source pixel. You can google for it for more info.
@Madshi;yesgrey3:
can you give me any link about spline resampling math? Would be interesting to see actual coefficients and how they are derived for spline16/36 etc. That might help to find coefficients for spline256. It seems some commercial softs use such method e.g. for photoprocessing.
yesgrey
10th May 2009, 22:48
Sorry, I can't help you on that. Maybe madshi, he's the one of the upscaling algorythms.
Have you tryed googling about it?
Sorry, I can't help you on that. Maybe madshi, he's the one of the upscaling algorythms.
Have you tryed googling about it?
Of course. Wiki section on spline interpolation is very poor (compared with Lanc for instance). And one source which has coefficients doesn't even describe how they are derived.
You see I have a m8 of mine which is able to derive these coefficients provided he knew how they are derived for spline36 etc. He studied avs source for spline resampling but so far he doesn't quite understand the actual path to calculate these coefficients.
Grmpf
11th May 2009, 07:55
Okay got the time to install the 4770 into my htpc and just did a quick test with the same trailers i used earlier - only the gpu + driver changed, left = 3650, right = 4770, all options in madVR are the same as in my last post, scaling is lanczos8 for both chroma and luma (top image 480p->FullHD, bottom image 1080p->FullHD):
http://www.armster.de/caspar/480pN_compare.jpg
http://www.armster.de/caspar/1080pN_compare.jpg
One problem i found was that Powerstrip does *not* support the RV7xx GPUs atm, so i am stuck with 24hz instead of 23.976hz because the ATi driver only have the options for 23.976/59.940 if you use Vista but not for Win XP - damn. Wait for Powerstrip to support the new GPUs (could take a couple of month i guess), or move on to vista ? If madVR would have the "smooth playback code" already it would be a easy decision ;-) Maybe i go back to the old 3650 till then - totaly irresolute atm...
masaykh
11th May 2009, 12:36
not vista - seven
EVR renderer give good smooth playback to me in MPC-HC
One problem i found was that Powerstrip does *not* support the RV7xx GPUs atm, so i am stuck with 24hz instead of 23.976hz because the ATi driver only have the options for 23.976/59.940 if you use Vista but not for Win XP - damn.
It sure does support the Radeon 4850, which is a RV770 PRO (http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units#Radeon_R700_.28HD_4xxx.29_series). I can't really believe the 4770 (which would be the RV740) behaves different here - but maybe there's a check in PowerStrip that prevents it from working with unknown chipset revisions...
It can't hurt to ask about it on the PowerStrip forum, though...
Grmpf
11th May 2009, 14:58
Hello Leak,
i already did ask in their forum and they told me its not supported and if you look into the powerstrip readme it official supports up to RV6xx, but no RV7xx GPU - with my 4770 i get all the refreshrates divided through 3.7037037, so 60hz = 16.200hz in powerstrip and 50hz = 13.500hz in powerstrip, but i can't change them even if i try for excample 6.474 (23.976 / 3.7037037) its just not working... will have to wait for powerstrip to be upgraded, or switch to vista for the options in ccc.
masaykh
11th May 2009, 18:21
I wonder is there any progress in statistic reporting by madvr ?
i mean like evr or vmr (even haali) , info like jitter time ?
madshi
11th May 2009, 18:56
Here is the comparison between an nVidia 9600GT and the new ATI 4770.
Interesting - especially comparing your results to tetsuo55's results! Probably the texture uploading number is quite big for you? That might explain a bit why tetsuo55 had lower numbers: Of course uploading HD content to the GPU takes more time than uploading SD content.
Have you tried Lanczos8, just to put some real pressure on the GPUs?
I am getting what people described earlier where looks like chroma luma are offset vertically by quite a distance, maybe 50 pixels. Bottom of the screen then shows a 10 pixel high~ yellow horizontal bar and on top a greenish 40 pixel high~ bar that goes accross the entire screen.
That is most probably a decoder bug. Which decoder did you use?
madshi you get something from ati/amd for promoting the 4770, or ? ;-)
I wish!
Is it possible to somehow change the position of the OSD ?
Yeah, I'll look at this later. (If I forget, please remind me.) It's not top priority right now, though. I want to work on those things which are important for *all* users first, before working on things that only affect a few users.
I would like it if you could later add some kind of deinterlacing
I don't have plans for that.
Hello. Is there way with which I use MadVR and subtitle ?
It seems there is, although I don't know personally how. Please do a search in this thread for "subtitles".
you had a great idea in avsforum about using an adaptive scaler - switch the algorithm or coefficients depending on the content of the sampling window. Adaptive scaling (in non academic solutions) are usually done in 1D (horizontally then vertically or vice versa). Native 2D scaling in HW (using >4x4 windows) is very expensive and I'm not aware of any implemetations.
I'm currently using 1D because obviously it's faster. I had already tried 2 tap 2D and it was slower, but not by much. I might eventually offer 2D scaling as an option later, after I've implemented my adaptive scaling algorithm.
BTW, 1D bilinear, bicubic or lanczos produce the same results as their 2D versions unless there's clipping after the first 1D scaling. By clipping I mean removing negative values or values above 255 - if the intermediate results are in floating point or fixed point with enough headroom then you're fine.
I'm using 16bit integer buffers. So clipping can occur. But I don't think it's a major problem with the current algorithm. However, I've seen clear differences between using 1D vs. 2D scaling for my adaptive algorithm.
Almost forgot, the holy grail of (up) scaling is called super resolution. The principle is guessing the values of a pixel using several 2D sampling windows over time, taking into account the motion between them. This way you can actually recover details that are lost in the individual frames. This is espcially impressive on moving text. As a bonus you also get very good noise reduction. The problem is that you'll need an excellent motion estimator, unlike the ones found in encoders :(
The artifacts caused by bad motion vectors are quite horrible and the computation cost is high. It's probably possible to do this on a modern GPU if motion vectors are not calculated for each source pixel. You can google for it for more info.
I've seen a Gennum VXP guy talk about super resolution. But to my knowledge no current video processing hardware available to consumers can do this kind of "super resolution" processing. It's an interesting topic, but I don't really plan to implement such a feature, because it would require a lot of math work on my part and I don't really have enough knowledge for that. Implementing Lanczos etc scalers was simple cause there are dozens of free sources on the net. Another reason why I don't plan to look into super resolution is that I don't want to spend too much time on scaling, because my main priority is Blu-Ray playback, anyway, and scaling is usually not needed there...
can you give me any link about spline resampling math? Would be interesting to see actual coefficients and how they are derived for spline16/36 etc.
I wish I could. I'm using the same coefficients everyone else is also using. I've not the slightest idea how the coefficients were calculated. And it seems to me that nobody else does, either.
Okay got the time to install the 4770 into my htpc and just did a quick test with the same trailers i used earlier - only the gpu + driver changed, left = 3650, right = 4770, all options in madVR are the same as in my last post, scaling is lanczos8 for both chroma and luma (top image 480p->FullHD, bottom image 1080p->FullHD)
Nice numbers for the 4770! However, you've displayed the HD content 1:1 without any scaling. So the Lanczos8 resampling was fully disabled. It might be interesting to zoom in just a tiny bit to activate resampling, so that we can see, how the 4770 handles the load.
One problem i found was that Powerstrip does *not* support the RV7xx GPUs atm, so i am stuck with 24hz instead of 23.976hz because the ATi driver only have the options for 23.976/59.940 if you use Vista but not for Win XP - damn. Wait for Powerstrip to support the new GPUs (could take a couple of month i guess), or move on to vista ? If madVR would have the "smooth playback code" already it would be a easy decision ;-) Maybe i go back to the old 3650 till then - totaly irresolute atm...
Personally, I'm planning to install the Windows 7 RC on my newly built HTPC later this week.
Smooth playback is currently worked on, but I've no idea how long it will take to get it right.
I wonder is there any progress in statistic reporting by madvr ?
i mean like evr or vmr (even haali) , info like jitter time ?
If anyone can explain to me why (technically!) jitter would cause any trouble in a video renderer, please let me know. Right now I don't really understand where the problem is. Now please don't post something like "I don't know why, but in renderer XYZ you can see that playback stutters whenever jitter...". I'm not interested in that. Please post only if you know exactly WHY jitter can affect video playback. Right now I'm not even sure which kind of jitter you guys mean. Do you mean inconsistent timestamps reported/produced by the decoder? Or do you mean frames being delivered in inconsistent intervals by the decoder? Or something else?
mark0077
11th May 2009, 19:05
frames being delivered in inconsistent intervals by the decoder
This would be my definition of jitter, and if I was to make my own renderer, when creating the playback smoothness part of the renderer, for a stats screen I would first calculate what the best case jitter could be. ie something like 7ms for 24fps content on 60hz display. Then an average actual jitter could be shown next to this, with the aim of renderer being keeping jitter it at 7ms or as close to that as possible, if it does its job right.. Thats just my opinion, maybe I also have the wrong definition of jitter in my mind...
madshi
11th May 2009, 19:13
This would be my definition of jitter
If that is what all you guys mean with jitter then it is IMHO totally irrelevant to any renderer which has a correctly working frame queue.
mark0077
11th May 2009, 19:27
If that is what all you guys mean with jitter then it is IMHO totally irrelevant to any renderer which has a correctly working frame queue.
Well if I was to alter it slightly, frames being delivered in inconsistent intervals by the RENDERER.
By definition, its probably not strictly upto the renderer to do anything about jitter but what alot of people see as being a "problem" with renderers is the lack of ability to improve scenarios like 23.976 at 24hz for example. I think is where alot of users want to see the renderer taking responsibility for these tiny adjustments, ie 23.976fps -> 24fps conversions to bring jitter to 0.
In my opinion, if things like this could be split into seperate components, users could swap in and out different components when needed. Like a component in the graph that can do this altering of fps based on some logic or user defined settings. I still think the renderer shouldn't really worry about this but obviously it would be great to have this piece of technology in there somewhere.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.