View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
15th April 2009, 10:00
madshi, I'm not sure if this would be classified as a MPC-HC issue or a madVR issue, but whenever you try to take a screenshot while using madVR (only tested it with the non-special build), an error appears about GetCurrentImage failing with error code 80070057.
Already reported, on my to do list.
Bugfix request: multiple monitor support ...
Should work just fine with v0.4, as long as you don't move the media player window to another monitor after playback has already started. That needs some work, but it's not top priority for me. Just make sure you start playback on the monitor you want to watch on.
I was wondering why you chose to use 3D LUTs for CSC and gamma correction.
The main purpose of using the 3D LUT is gamut correction. Actually, offering a way of doing gamut correction via shaders has been one of the major reasons why I started madVR in the first place.
However, I have on my to do list to offer CSC via shader math as an option for those (probably many) people who do not want/need to do gamut correction. Not sure whether I'll offer gamma correction via 1D LUTs then, though, cause I don't like having 100 different code paths. I'll probably only offer either CSC via shaders and no gamut/gamma correction at all. Or the full deal with a monstrous 3D LUT, which will offer all the calibration/correction power we could ever dream of.
3D LUTs are normally used for complex Gamut correction (mostly for printing purposes) and are (almost) never used in professional video processing HW.
Yes, complex gamut correction is exactly one of the things madVR is intended for. What works for still pictures should also do the trick for moving pictures. Actually it may almost be too good quality for moving pictures. But that doesn't harm, does it? And even last generation mid range graphics cards seem to be able to handle the load just fine. So why should we not go for the best possible gamut correction solution?
Writing shaders for CSC will also allow adding features like contract brightness, saturation and hue modifications with a small complication to the shader code - perform full 3x3 matrix multiplication (9 multiplications, 12 additions, 3 clips). All of these can be easily modified in realtime.
You seem to know this math quite well. Do you happen to have some formulas ready for doing CSC including brightness, contrast, saturation and hue modifications? I'm just a programmer, but not a math guy, so I'll need help in that area. Well, probably yesgrey3 could help me out there just fine, too. But if you already have some formulas ready, then that would help!
madshi
15th April 2009, 13:27
Performing CSC using 3D LUTs is a major overkill and should be significantly faster by performing the calculations in a shader.
Actually the 3D LUT processing doesn't cost much performance at all. I've just checked: If I simply skip the 3D LUT (and thus display YCbCr without converting it to RGB), rendering one 1080p24 frame takes about 15.5ms on my ATI HD3850 graphics card. If I enable 3D LUT processing, it takes 17ms.
leeperry
15th April 2009, 13:38
Actually the 3D LUT processing doesn't cost much performance at all. I've just checked: If I simply skip the 3D LUT (and thus display YCbCr without converting it to RGB), rendering one 1080p24 frame takes about 15.5ms on my ATI HD3850 graphics card. If I enable 3D LUT processing, it takes 17ms.
so you could render YCbCr and output it losslessly over HDMI/DVI? because it's not possible in either MPC HC/EVR/HR...they all convert to RGB32, then encode in RGB24 TMDS AFAIK.
but I think most displays will convert again to RGB internally, and w/ much worse results than yours anyway..
mark0077
15th April 2009, 13:42
I imagined the LUT would be faster also. madshi, just want to tell you about a huge lut I made use of during a uni project. I am wondering how much memory does your lut table take up. Maybe it could be optimized like I did for this project I talk of.
The lut I worked on was a 7 dimension array of 0-51 possibilities, of 7 poker card values actually (0-51 as possible values for each card) with each combination in the array pointing to a ranking between 0 and 7142. (It turns out surprisingly that thats the amount of 5 card texas holdem possibilities there are possible from 7 cards). You can image a 7^52 array would have been MASSIVE, like hundreds of gigabytes. I used a pruning technique I found on a maths forum specific to this to reduce the size, where after the second or third card (2nd or 3rd dimension in the array) various combinations of those 3 values would point to an equivalent future. (eg, AKQJT of hearts always shares the same final value as AKQJT of clubs, no matter what the last two cards are. It took a large loop, and the use of the original massive array to figure out which early dimensions ALWAYS follow the same path to a final value and generate the pruned array (actually 7 smaller arrays, each one a different size depending on futures at each stage instead of one giant one). I hope I have made this clear, and hope it can help somehow.
I am not sure how this could be applied exactly to this color levels conversion / gamut conversion case but something I wouldn't mind looking into if you think it might help. For my poker project it ended up going from hundreds of megabytes, down to something that could fit in a mobile phones memory and executed MUCH faster than the original massive array because most of the array could be fit in the cpu's inner cache. What sort of dimensions is the LUT you are dealing with and whats the final size in mb?
madshi
15th April 2009, 13:54
so you could render YCbCr and output it losslessly over HDMI/DVI?
No, in my test I output YCbCr data, masked as RGB. So colors were all funny.
The lut I worked on was of 7 poker card values (0-51 as possible values for each card) with each 7 card values pointing to a rank between 0 and 7142 I believe. Turns out thats the amount of 5 card possibilities there are from 7 cards. You can image a 7^52 array would have been MASSIVE, like hundreds of gigabytes. I used a pruning technique I found on a maths forum to reduce the size, where after the second or third card (2nd or 3rd dimension in the array) various combinations of those 3 values would point to an equivalent future. (eg, AKQJT of hearts always shares the same final value as AKQJT of clubs, no matter what the last two cards are. It took a large loop, and the use of the original massive array to figure out and generate the pruned array (actually 7 smaller arrays instead of one giant one). I hope I have made this clear, and hope it can help somehow.
I am not sure how this could be applied exactly to this color levels conversion / gamut conversion case but something I wouldn't mind looking into if you think it might help. What sort of dimensions is the LUT and whats the final size in mb?
It has 3 dimensions, that's why the file has the extension "3dlut"... ;) Size is 96MB. I don't think pruning would work well for this type of LUT because virtually any input color maps to a different output color.
mark0077
15th April 2009, 13:59
No, in my test I output YCbCr data, masked as RGB. So colors were all funny.
It has 3 dimensions, that's why the file has the extension "3dlut"... ;) Size is 96MB. I don't think pruning would work well for this type of LUT because virtually any input color maps to a different output color.
Ah thats not too huge. :D
Egh
15th April 2009, 15:10
If madVR employed shaders to do the conversion, that would be just Haali Render clone in effect ;) Colour Gamuts conversion may be very much of use per se as well, as there're different LCD monitors now available, including those which colour gamut widely exceeds sRGB standard, for instance LED-backlight displays (upto 120% of NTSC gamut). They are rare nowdays but certainly going to become much more popular when technology evolves.
racerxnet
15th April 2009, 16:35
DVD navigation should be a must. I realize this renderer is in its infancy, but selecting a VOB is a pain in the butt. For everyday use this has no WAF. It does not play from one VOB to the next, it stops playing at the end of the file and you need to select the next to continue.
The picture looks great and I thank Madishi for his efforts. As he has stated, he has his priorities. Basic playback capabilities will put this as MY number one renderer.
I think that the more user friendly it becomes, the more people will use it. Right now it has potential, but without navigation from within the disc it is very limited in its use.
Thanks for everyone's support and help.
MAK :thanks:
Rectal Prolapse
15th April 2009, 17:07
leeperry, et. al.: What is this powerstrip search engine you guys are talking about? I can't find a reference to it anywhere else except doom9! :)
EDIT: Oh, I think I found it (had to use google):
From a post about powerstrip 3.80 back in june 2008:
In addition to support for a couple of new GPUs from S3 and AMD, this build includes:
1. tooltips for h/v frequency providing mathematically more precise data: hover the mouse pointer over the H/V "Geometry" labels.
2. a timing "finder" for registered users with GF6/GF7, Radeon and Intel Extreme graphics: UNcheck "Real-time adjustrment", input the refresh rate desired, hold down Ctrl+Alt+LShift and double-click the "Vertical geometry" label
3. improved Windows device/hardware controller correspondence for dual-headed R600 and newer AMD GPUs
4. more precise measurement of the vertical refresh rate using the DirectX VBI: double-click the camera icon on the Display profiles page
leeperry
15th April 2009, 17:15
leeperry, et. al.: What is this powerstrip search engine you guys are talking about? I can't find a reference to it anywhere else except doom9! :)
look for threads created by Seb.26 on the official pstrip forum, after a few pages he managed to make Rik Wang agree to add it and it's all explained :)
make sure to run it w/ your display turned off as it cycles refresh rates very quickly and might very well make it go up in smoke http://forum-images.hardware.fr/images/perso/yanhoupa.gif
Rectal Prolapse
15th April 2009, 17:17
Thanks leeperry. :)
flanger216
15th April 2009, 17:30
If madVR employed shaders to do the conversion, that would be just Haali Render clone in effect ;) Colour Gamuts conversion may be very much of use per se as well, as there're different LCD monitors now available, including those which colour gamut widely exceeds sRGB standard, for instance LED-backlight displays (upto 120% of NTSC gamut). They are rare nowdays but certainly going to become much more popular when technology evolves.
Ah, that's a really good point. I tested a prerelease LCD from DELL that can operate natively in a ProPhoto RGB colorspace (roughly 200% sRGB). So I guess the efficacy of 3Dlut conversions can only increase with time...
leeperry
15th April 2009, 17:58
DVD navigation should be a must. I realize this renderer is in its infancy, but selecting a VOB is a pain in the butt. For everyday use this has no WAF. It does not play from one VOB to the next, it stops playing at the end of the file and you need to select the next to continue.
it's not the renderer's job to take care of this ?!
try KMPlayer, enable "seamless playback", open the first VOB and it will play all of them in a row seamlessly.
if that feature was in MPC, I would drop KMP instantly :o
and there's also an option to do this w/ ALL the videos within the same folder, so it looks like this :
http://www.image-load.eu/out.php/t157858_kmp.png (http://www.image-load.eu/out.php/i157858_kmp.png)
that's 114 720p WMV files opened seamlessly(no gap, acts as if it were one single file)...so opening 5 VOB files in a row is like child's play :D
I wish so much that madshi would allow us to fake the GUID of mVR via the .ini file, so we could use it in KMP http://forum-images.hardware.fr/images/perso/nanou34.gif
Kazuya
15th April 2009, 18:01
I wish so much that madshi would allow us to fake the GUID of mVR via the .ini file, so we could use it in KMP http://forum-images.hardware.fr/images/perso/nanou34.gif
Oh yeah, that would be awesome ! :cool:
Egh
15th April 2009, 18:09
Ah, that's a really good point. I tested a prerelease LCD from DELL that can operate natively in a ProPhoto RGB colorspace (roughly 200% sRGB). So I guess the efficacy of 3Dlut conversions can only increase with time...
Yes. And as I already researched that issue (LED LCD panels etc) I'm already aware about downside -- due to increased gamut the clear colour gradients become even worse than on typical LCD panels. I.e. the colour span is wider but in current ubiquitous RGB32 just 8bit may not be enough to represent a gradient artifact-free (this of more importance to anime content of course). That's where madVR comes into play :thanks: If only the producers understood that 10bit is good (and some AVC profiles like High10 actually support 10bit...)
racerxnet
15th April 2009, 20:07
It's not the renderer's job to take care of this ?!
try KMPlayer, enable "seamless playback", open the first VOB and it will play all of them in a row seamlessly.
Thanks for the heads up on this, but unfortunately, searching for the starting VOB within the disk is not going to cut it for the family. Casino Royal has about 100 VOB files. Which one to choose??? Maybe KMPlayer can choose the correct one... I will look into the player. On another note is calibration disc usage to set primary and secondaries on my Marquee 9500 is tiresome. No way to navigate through the disc. PGCC from the AVS forum does the same thing as the LUT file in this program.
Once again, thanks for the information and knowledge.. Just my .02.
MAK
flanger216
15th April 2009, 22:20
Thanks for the heads up on this, but unfortunately, searching for the starting VOB within the disk is not going to cut it for the family. Casino Royal has about 100 VOB files. Which one to choose??? Maybe KMPlayer can choose the correct one... I will look into the player. On another note is calibration disc usage to set primary and secondaries on my Marquee 9500 is tiresome. No way to navigate through the disc. PGCC from the AVS forum does the same thing as the LUT file in this program.
Once again, thanks for the information and knowledge.. Just my .02.
MAK
But again, what you're talking about has absolutely nothing to do with video renderers. The renderer is just responsible for the output to your display; the media player itself is responsible for how files are played back. And anyway, almost all media players can play DVDs from a hard disk: in MPC-HC, you'd select 'open DVD,' browse to the folder containing all your "Casino Royale" VOBs, and then MPC-HC would open all of them as a cohesive DVD (menu support, seamless playback, the whole shebang). Wouldn't that be sufficient?
leeperry
15th April 2009, 22:42
But again, what you're talking about has absolutely nothing to do with video renderers. The renderer is just responsible for the output to your display; the media player itself is responsible for how files are played back. And anyway, almost all media players can play DVDs from a hard disk: in MPC-HC, you'd select 'open DVD,' browse to the folder containing all your "Casino Royale" VOBs, and then MPC-HC would open all of them as a cohesive DVD (menu support, seamless playback, the whole shebang). Wouldn't that be sufficient?
menus don't work in HR, and neither did they do in EVR last time I tried....apparently DVD Navigator is not being used properly by either the player or the video renderers?!
@racerxnet: open those that are 1GB in a row, that's the movie! but no subs w/o menus I think
cyberbeing
15th April 2009, 23:50
menus don't work in HR
DVD menus do work in Haali Renderer.
leeperry
16th April 2009, 00:07
DVD menus do work in Haali Renderer.
hah...in what player? w/ ffdshow on top of it? Mark0707 seemed to suggest that ffdshow was at cause somehow ?!
and w/ the m$ DVD Navigator?
mark0077
16th April 2009, 00:25
hah...in what player? w/ ffdshow on top of it? Mark0707 seemed to suggest that ffdshow was at cause somehow ?!
and w/ the m$ DVD Navigator?
ffdshow HAD many many dvd menu problems which have all been fixed by haruhiko over the past few months. Any problems with menu's are surely haali's problem. I always have menu problems with haali.
noee
16th April 2009, 00:29
fwiw, I have DVD menus working here with FFDshow (2880), HR and jRiver MC13....
cyberbeing
16th April 2009, 04:10
hah...in what player? w/ ffdshow on top of it? Mark0707 seemed to suggest that ffdshow was at cause somehow ?!
and w/ the m$ DVD Navigator?
All I know is DVD menus have always worked with Haali Renderer for me (for at least the past 2 years) with MPC or MPC-HC, but occasionally they do get 'stuck', so it's not flawless. Even when they do get stuck, you can usually get them 'unstuck' with a bit of fiddling.
Just now I tested it with ffdshow rev2857, the internal MPC-HC mpeg2 decoder, and the NVIDIA PureVideo MPEG2 software decoder with Haali Renderer (built February 1st, 2009) + MS Navigator, and all seem to work fine, like they always have. I never really used ffdshow for watching DVDs in the past (I always used NVIDIA's decoder), so if it was somehow the cause, I wouldn't have known of it.
Leeperry, I have no idea what is causing menus not to work for you with HR, but I would guess it has something to do with all the extra stuff you always have going on for post-processing. :confused:
Mike5
16th April 2009, 07:43
DVD Menu, renderers and OS. For me:
Renderer Overlay, VMR7/9: Menu work both in XP SP3 and Win7
Renderer EVR: Menu don't work in XP SP3 (in the sense they are not responsive to mouse) but work perfectly in Win 7
Renderer madVR: Menu don't work both in XP SP3 and Win7 (DVD doesn't open: Macromedia Fail)
Renderer HR: Menu don't work in XP SP3 (in the sense they are not responsive to mouse); I haven't tried in Win7
So, in a way, renderer (and OS too) has to do with menu navigation, while I don't have a clue about how.
Further, the Macromedia error in madVR misleads to thinking about something to do with protection, but it hasn't anything to do with protection, because I can always see a single VOB file inside a protected DVD, and even a m2ts file inside a protected BD, with AnyDVD HD in background.
Is anyone able to explain these behaviours ?
FoLLgoTT
16th April 2009, 07:50
@madshi
In the screenshots of the grey ramp in your first post I noticed that the gradient of madVR differs to the gradients of the other renderers. It looks like clipping black and white on the left and right, as if the levels in the LUT were not set up correctly or something like this.
Beside that the smoothness is absolutely stunning! :)
madshi
16th April 2009, 08:31
In the screenshots of the grey ramp in your first post I noticed that the gradient of madVR differs to the gradients of the other renderers. It looks like clipping black and white on the left and right, as if the levels in the LUT were not set up correctly or something like this.
Argh, my fault. I originally intended to do these screenshots with PC levels, cause the conversion YCbCr (video) -> RGB (PC) produces more noticeable banding, especially with ffdshow. But then I didn't manage to get ATI VMR9 to do PC levels. So I changed my mind and used video levels for the comparison screenshot - but forgot to redo the madVR screenshot. I've now updated the madVR screenshot to video levels (see first page).
For your interest, here is a comparison with PC levels:
http://madshi.net/madVR/ffdshow 2867 - smallramp (PC).png
http://madshi.net/madVR/madVR 0.4 - smallramp (PC).png
Ouch... ;)
FoLLgoTT
16th April 2009, 09:48
No big problem. :)
I originally intended to do these screenshots with PC levels, cause the conversion YCbCr (video) -> RGB (PC) produces more noticeable banding, especially with ffdshow. But then I didn't manage to get ATI VMR9 to do PC levels.
This is possible using the brightness and contrast sliders in CCC. A time ago I managed to find the right values, but I forgot them. For overlay you have to set brightness at 126% and contrast at 86%. Maybe it is the same with VMR9...
leeperry
16th April 2009, 10:48
Renderer EVR: Menu don't work in XP SP3 (in the sense they are not responsive to mouse)
Renderer madVR: Menu don't work both in XP SP3
Renderer HR: Menu don't work in XP SP3
yes, apparently either the player or the renderers don't play nice w/ the m$ DVD Navigator filter...but it's prolly the player so it will never work.
Casshern
16th April 2009, 12:15
I think its a matter of preference,
the ideal function for reconstruction can easily be derived from the shannon-whittaker sampling theorem - it corresponds to the sinc function. All other just try to approximate this function (with lanczos being the closest), but many of the assumptions of the theorem, while reasonable, do not really describe reality (infinite windows etc.). So basically there is not a right or wrong here. I personally am a little bit on follgotts side, and like details if the ringing is not overly pronounced. But i also understand that some people like a silky smooth picture. The real problem was ATIs horrendous chroma upsampling. Glad that has been solved (ffdshow, mpc hc shader, madvr etc).
I would love an integration of reclock and the video renderer, much like gothplayer has done. Also his integration into the VMR9 renderer allows for using DXVA decoding. Any plans madshi?
regards,
Casshern
I admit in this example the additional ringing inside the fonts is clearly visible and annoying. Thank you for the example! :)
But is it really visible inside of text lacking movie scenes? I never saw it.
On the other hand if you look at these shots from the same movie you can see much less aliasing on the inner side of the mirror (very annoying in moving scenes), but no additional ringing.
And if we analyze the picture a bit closer with the h-sweep pattern and a waveform analyzer:
It is obvious that the higher frequencies are transported better with Lanczos10 and that this algorithm acts as a better low pass, because beats (aliasing) gets less. The h-sweep looks cleaner and very slightly more detail is visible.
Of course if you look at the sides of the h-sweep (hard edges, square wave) there is additional ringing introduced by the scaling algorithm. But these areas content high spatial frequencies which movies *usually* don't (or as I learned only rarely), because of the necessary low pass filtering.
Anyway, you are right. Because everything is just a big compromise it is just a matter of preference. Less aliasing and more detail (Lanczos8) or less ringing (e.g. Catmull-Rom). :)
flanger216
16th April 2009, 15:06
I'm also getting the wierd 'color bug' when I use ffdshow to resize to my native resolution...
madshi
16th April 2009, 15:22
I would love an integration of reclock and the video renderer, much like gothplayer has done. Also his integration into the VMR9 renderer allows for using DXVA decoding. Any plans madshi?
Definitely no for VMR and DXVA. That will never happen. Integration of ReClock and video renderer? Most probably no. I don't like the general concept of manipulating audio in order to achieve smooth video playback. I think there are better ways to solve the underlying problem which nobody has implemented yet. And no, I will not tell you what I have in mind. ;) I generally don't like talking about things I have not implemented yet. I prefer to do it the other way round. Which is also the reason why I avoid any discussion about smooth video playback at this point in time.
leeperry
16th April 2009, 15:25
I don't like the general concept of manipulating audio in order to achieve smooth video playback.
hope it'll still allow 25@24 and 23.976@24 :o
and HR is very presenter-dependent(works fine in MPC/KP, pretty badly in ZP6)....I guess all video renderers are?
madshi
16th April 2009, 15:32
I'm also getting the wierd 'color bug' when I use ffdshow to resize to my native resolution...
Why do you resize with ffdshow? Anyway, can I see a screenshot, please? Which resolution is the source and which is your native resolution? Which ffdshow resize options are you using?
hope it'll still allow 25@24 and 23.976@24 :o
Of course if you want to change 25 movies or 23.976 movies to 24.000, you will have to resample them. If you want that, that's fine with me, although personally I play 23.976 with 23.976. Resampling one movie framerate to another framerate is not the part I dislike. What I dislike is the general idea of using resampling (with varying frequencies) to make the audio clock match the video clock.
I guess all video renderers are?
I don't know. Too early to talk about that...
leeperry
16th April 2009, 15:44
Of course if you want to change 25 movies or 23.976 movies to 24.000, you will have to resample them. If you want that, that's fine with me, although personally I play 23.976 with 23.976. Resampling one movie framerate to another framerate is not the part I dislike. What I dislike is the general idea of using resampling (with varying frequencies) to make the audio clock match the video clock.
I don't know. Too early to talk about that...
1) your audio is resampled by windows anyway...except if you enable rewire to ASIO in your audio drivers, or use Reclock in pass-through mode w/ a bitperfect audio renderer...so to most ppl, it doesn't matter at all. but we already discussed that..
well ar-jar was implying that when we output 23.976@48Hz in his gothplayer, the audio is not resampled, but its pitch is modified by DirectX....losslessly? that's the question :confused:
2) yeah OK, anyway MPC HC's presenter seems to work just fine....and soon the CMS will be fully functional(identical to ddcc in realtime I mean) so I'll be able to run more real world tests, but so far it looked great!
madshi
16th April 2009, 16:10
your audio is resampled by windows anyway... [...] so to most ppl, it doesn't matter at all.
That is not a good argument. I'm here to realize perfection, not just something slightly above the average. If you're satisfied with what "matters to most people" then you're in the wrong thread... ;)
Obviously, the perfect overall HTPC playback solution will include an audio renderer (not written by me) which bypasses the kernel mixer. And of course best audio will be realized by (1) bypassing the kernel mixer and (2) *not* doing resampling.
Now you may be happy with perfect video and manipulated audio. Personally, I'm not. Resampling audio results in a measureable hit on audio quality.
well ar-jar was implying that when we output 23.976@48Hz in his gothplayer, the audio is not resampled, but its pitch is modified by DirectX....losslessly? that's the question
I'm not sure if it really works the way ar-jar is thinking. Maybe it is, maybe not. The problem is that it seems to me that he's relying on what Windows/DirectX hopefully does in the background. And in my experience it's better to take things into your own hands instead of relying on Windows to get things right. I'm not saying that his solution doesn't work. Maybe it's the perfect solution. It's just difficult to check. How do we know what really happens in the background with the way he's doing things? How do we know what DirectX does if you play around with the audio clock? Will Windows modify the clock of the DAC in realtime? Will it just send audio data with a high jitter rate to the DAC and rely on the DAC to smoothen things out? What will the DAC do? Will it do some internal correction method to smooth out the data? Will that still be lossless? What happens with digital transport? Will HDMI just stop sending audio samples for a few nano/milliseconds if ar-jar is doing his magic? Or will HDMI loop samples or send zero samples? What will the receiver do? Or will audio/video sync slightly drift away for a while, until the sync mismatch is getting too big, at which moment DirectX might decide to finally do something (e.g. loop or drop audio samples)? Will every audio card behave the same way? Will every OS behave the same way? Will every media player behave the same way? Will every audio driver behave the same way? So many questions about what happens in the background and so few answers...
leeperry
16th April 2009, 16:58
That is not a good argument. I'm here to realize perfection, not just something slightly above the average. If you're satisfied with what "matters to most people" then you're in the wrong thread... ;)
well a very high percentage of HTPC's users couldn't care less about CMS & bit-perfect audio...can't deny that ;)
Obviously, the perfect overall HTPC playback solution will include an audio renderer (not written by me) which bypasses the kernel mixer. And of course best audio will be realized by (1) bypassing the kernel mixer and (2) *not* doing resampling.
perfection exists, it's called RME or Lynx....for a measly thousand bucks :D
and it very much works(thanks to yesgrey again) :
http://forum.slysoft.com/showthread.php?t=27610
Now you may be happy with perfect video and manipulated audio. Personally, I'm not. Resampling audio results in a measureable hit on audio quality.
well 23.976 audio is 1% slown down...I don't call this perfection. and for 25fps PAL stuff, if you don't have a RME/Lynx souncard you're SOL anyway. I prefer correct pitch and resampling, each to his own ;)
I'm not sure if it really works the way ar-jar is thinking. Maybe it is, maybe not.
[...] So many questions about what happens in the background and so few answers...
indeed, Windows is not really known to care about quality and it might go crazy over HDMI :o
Casshern
16th April 2009, 17:39
I am anxious to see what you have in mind. Is it something like gothplayer does when he manipulates the Powerstrip timings in real time? Does it interpolate the two critical frames? Does it find the perfect tear by anayzing picture content? As it doesn't involve the audio, the options are limited. Does it wait for the next fade to black to maybe skip a frame or repeat one while the screen is black? What if the stream doesn't have any? If i would be forced to guess, i would say you have this in mind: analyze picture content and if its static, blank or content you do a premature flip so that the tear is not visible.
bye,
Casshern
Definitely no for VMR and DXVA. That will never happen. Integration of ReClock and video renderer? Most probably no. I don't like the general concept of manipulating audio in order to achieve smooth video playback. I think there are better ways to solve the underlying problem which nobody has implemented yet. And no, I will not tell you what I have in mind. ;) I generally don't like talking about things I have not implemented yet. I prefer to do it the other way round. Which is also the reason why I avoid any discussion about smooth video playback at this point in time.
ice25
16th April 2009, 17:48
well 23.976 audio is 1% slown down...I don't call this perfection.
Gotta agree there, i'd rather have a movie with a slight audio resampling to the correct speed of 24.000, than playing it at the native slowed down 23.976fps. It's probably a matter of preference though, do u want perfect audio or video playback..
STaRGaZeR
16th April 2009, 18:18
Why do you resize with ffdshow? Anyway, can I see a screenshot, please? Which resolution is the source and which is your native resolution? Which ffdshow resize options are you using?
Your renderer uses the video resolution that comes from the previous filter. If he has resized SD video to HD in ffdshow leaving it in YV12 it'll be converted to RGB using BT.709 instead of BT.601. I experienced this myself too with madVR and when the graphics card drivers are used to convert to RGB. Is there any way of getting the resolution directly from the splitter instead of the decoder?
Jong
16th April 2009, 18:20
Gotta agree there, i'd rather have a movie with a slight audio resampling to the correct speed of 24.000, than playing it at the native slowed down 23.976fps. It's probably a matter of preference though, do u want perfect audio or video playback..Yes. I do not see how there can be a "perfect" solution to this. There is no magic way to change the playback speed, even slightly and leave the audio untouched and at the right pitch. I think ar-jar, in this one instance, just hasn't had this is a priority to look into and is hoping somewhat "blindly" that Windows will fix all. It's not a criticism, given everything else he has had to work on, but I'd be surprised if I were not right!
Mind you, just to throw a spanner in the works, do we know they bother to pitch correct the audio 0.1% down when encoding @23.976 and if they do the same thing consistently from disc to disc? I would be surprised, as they rarely, but sometimes(!), bother to correct the 4% pitch error on PAL DVDs!
Madshi, have you listened to audio sampled by Reclock using its recently improved resampler (speed and quality) in "excellent" mode. It is quite practical to use this now and I think Yesgrey believes it is effectively lossless (yes I know that is oxymoron). With your keen ear I'd be interested in your thoughts.
Beliyaal
16th April 2009, 18:24
23.976 vs 24 is 0.1% and not 1%
leeperry
16th April 2009, 18:28
do we know they bother to pitch correct the audio 1% down when encoding @23.976 and if they do the same thing consistently from disc to disc?
[...]
I think Yesgrey believes it is effectively lossless (yes I know that is oxymoron).
1) the only way to pitch correct is timestrech as you know, and it's ugly....luckily they hardly ever do it(LOTR PAL anyone?)
2) Reclock's resampling engine does ruin the SQ...a bit, but it's either this or judder(Reclock doesn't work too well in "slave" mode AFAIK)
23.976 vs 24 is 0.1% and not 1%
good point! it's still clearly audible :o
STaRGaZeR
16th April 2009, 18:50
Sorry typo, I meant resolution not framerate :D
Beliyaal
16th April 2009, 18:55
good point! it's still clearly audible :o
Naa, it's very unlikely that anyone except you can hear a difference :)
I just tested with a tone generator, and
440Hz vs 439.56Hz is indistinguishable (24 vs 23.976).
440Hz vs 458.33Hz is very distinguishable (24 vs 25).
racerxnet
16th April 2009, 18:57
well a very high percentage of HTPC's users couldn't care less about CMS & bit-perfect audio...can't deny that
People who are popping for the RME or Lynnx card are the ones who care about bit perfect playback. Why blow the wad on using the Kmangler when they support ASIO in the first place. I run the RME card for my 2 channel set-up and have no interest in 5.1. Others may, but they (RME and Lynnx) are geared toward the professional user, not the gamers.
For my 50 grand in audio and CRT projection, I want the best of all worlds. Great video,audio, and user interfaces that work as should.
I see bit perfect discusions at Audioasylum as well as audiogon. Not to mention AVS.
MAK :thanks:
Jong
16th April 2009, 18:58
23.976 vs 24 is 0.1% and not 1%Yes of course! I plead typo :o
madshi
16th April 2009, 19:04
perfection exists, it's called RME or Lynx....for a measly thousand bucks :D
and it very much works(thanks to yesgrey again) :
http://forum.slysoft.com/showthread.php?t=27610
I don't agree that this is the perfect solution. For one, it's analog. So you need 8 cables (and please high-quality ones!) between sound card and receiver. And you can't use any digital post processing in the processor like e.g. room correction. Furthermore, every time ReClock changes the sample rate to match audio and video clocks, pitch changes slightly. That is not perfection. It's a lot better than doing resampling, but still no perfection.
Now I hear you saying: "Room correction is not lossless, either". Sure, but I don't really want to discuss the benefits of room correction in my madVR thread.
If i would be forced to guess, i would say you have this in mind: analyze picture content and if its static, blank or content you do a premature flip so that the tear is not visible.
Good guess! ;)
Your renderer uses the video resolution that comes from the previous filter. If he has resized SD video to HD in ffdshow leaving it in YV12 it'll be converted to RGB using BT.709 instead of BT.601.
Quite true. But then the question is: Why scaling in ffdshow with 8bit precision when madVR scales with 16bit precision?
Still, I guess the problem could be worked around. But things like this are really ultra low priority for me right now.
Mind you, just to throw a spanner in the works, do we know they bother to pitch correct the audio 1% down when encoding @23.976 and if they do the same thing consistently from disc to disc? I would be surprised, as they rarely, but sometimes(!), bother to correct the 4% pitch error on PAL DVDs!
It's only 0.1%!! So it's very very much less than PAL speedup. PAL speedup is 40x or 4000% worse than the 24.000 -> 23.976 slowdown. I think that's a very important point to make.
Anyway, your argument is a good one: E.g. studios in Germany usually use resampling to speedup the original 24.000 masters to 25.000. But I've been told that e.g. in Spain studios usually use a pitch correction algorithm (like TimeFactory) to create PAL audio tracks! Both methods are used in reality. So you can never know for sure whether an audio track has wrong pitch or not. There are even 23.976 Blu-Rays which have audio tracks with the Mickey Mouse effect still in there!! Also I've seen DVDs where the German PAL track was created by resampling (-> too high pitch) while the English PAL track on the same DVD was created by using a pitch correction algorithm (-> same pitch as original).
What does this mean? It means that blindly using resampling to change FPS is the wrong thing to do. That applies to PAL tracks, but probably also to 23.976 Blu-Rays. My guess would be that studios are also sometimes using resampling and sometimes pitch correction to change audio FPS from 24.000 to 23.976.
Madshi, have you listened to audio sampled by Reclock using its recently improved resampler (speed and quality) in "excellent" mode. It is quite practical to use this now and I think Yesgrey believes it is effectively lossless (yes I know that is oxymoron). With your keen ear I'd be interested in your thoughts.
I don't have good enough equipment to really test this right now. But as you probably know, I've implemented resampling in eac3to and I've tweaked the SSRC algorithm to produce better results than the original implementation of the algorithm. Based on that experience I know that every resampling algorithm is a trade off in frequency response, aliasing and ringing (same problem as with video resampling filters). So whenever you resample (even for a tiny bit), you either get ringing, aliasing or loss of frequency range. Or all 3 at the same time. But there's always some hit on audio quality. There simply is no magic bullet which can resample audio without any loss in audio quality.
Jong
16th April 2009, 19:11
2) Reclock's resampling engine does ruin the SQ...a bitIf you, of the 0.1% pitch accurate, "I just cannot listen to movies @23.976" ears, says only "a bit" I will take that any day! ;)
Jong
16th April 2009, 19:20
But there's always some hit on audio quality. There simply is no magic bullet which can resample audio without any loss in audio quality.Yes, I accept and agree with that. The only questions for me are:
- does this loss in quality get lost in the "noise" of compression for lossy tracks i.e. in a blind test with PERFECT equipment you could not tell which was an original lossy compressed track at the same pitch and speed and which was the resampled version.
- does this loss in quality even with a LOSSLESS original track get lost in the IMPERFECT equipment and acoustic environment most, if not all of us, live with?
It is a real question, I do not know the answer. I suspect for the vast majority they will not notice.... but then probably 90% do not realise in PAL land most DVDs are the wrong pitch, so maybe it is not such a tough ask! But I still think even the majority of peope who do care about such things would struggle to pass a blind test. :)
leeperry
16th April 2009, 19:24
Naa, it's very unlikely that anyone except you can hear a difference :)
well the dialogs sound too slow if you A/B of course, and on my favorite movie(Revolver) I can hear when it doesn't play at 24fps :scared:
0.1% pitch difference is vey much audible I think, for music at least..
People who are popping for the RME or Lynnx card are the ones who care about bit perfect playback. Why blow the wad on using the Kmangler when they support ASIO in the first place. [..] (RME and Lynnx) are geared toward the professional user, not the gamers.
sure, but what's a % ppl having such a card that come to doom9? if it didn't cost a grand, I'd have one too.
but getting bit-perfect Reclock for a grand doesn't sound like a great ROI to me, not for now at least :D
every time ReClock changes the sample rate to match audio and video clocks, pitch changes slightly. That is not perfection. It's a lot better than doing resampling, but still no perfection.
good point. I assumed it would simply change the sampling freq once and for all...if it keeps changing the audio pitch constantly, then I'd definitely prefer resampling...yesgrey can you confirm? maybe it's not even audible, though :D
Why scaling in ffdshow with 8bit precision when madVR scales with 16bit precision?
because if you have a 1080p source, a 720p display and do all kind of PP(sharpening etc) you wanna do it in the native res of your display IMHO
same for SD, it'll look far better if you upscale to 720p then PP at this resolution than upscale PP'ed SD to 720p in mVR
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.