INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: mykillk on December 14, 2012, 06:29:49 pm
-
I have a fairly low-end HTPC. It has an AMD E-450 CPU/GPU. It's plenty fast enough to watch 1080p x264 videos with DXVA, but not nearly fast enough to run Red October HQ (MadVR).
Let's look at my CPU/GPU usage (measured using the AMD System Monitor) when watching a 1080p x264 video with 6 channel AAC audio:
Red October Standard: 10%/20%
Red October HQ: 100%+
Red October Standard uses almost no resources at all, which is a big hint that it's using 8-bit integers in the video rendering pipeline. I wouldn't be surprised if a major portion of the CPU usage is dealing with the 64bit floating point audio pipeline and not even the video renderer!
Now let's look at my options with MPC-HC, which has some very neat options that JRiver should adopt.
baseline 8-bit rendering: 15%/25%
Baseline + "Force 10-bit RGB input" + "Half Floating-Point Rendering": 25%/45%
Baseline + "Force 10-bit RGB input" + "Full Floating-Point Rendering": 40%/70%
Using MadVR: 100%+
So, as you can see, MPC-HC allows a much greater range of video rendering options. Even my low-end HTPC can handle 10-bit RGB and full floating point processing. And yes, it's still compatible with DXVA!
The image quality, even using only half floating-point rendering, is far superior to JRiver. I compared several scenes in movies that featured a lot of fog and smoke, and examined the smoothness of the gradient. JRiver showed significantly more banding and color artifacts in every case.
It's a shame to have such amazing audio rendering quality and yet give no middle ground in terms of video rendering.
I would love to spend $40 on your media player because of it's superior WASAPI support and 64-bit audio rendering, but the poor video quality when compared to MPC-HC is a deal breaker.
-
You can choose your own directshow filters.
-
You can choose your own directshow filters.
The MPC-HC rendering options are built-in and independent of the filters being used.
-
But if you know what filters I can use to get 10-bit RGB input and floating-point rendering pipeline, compatible with DXVA, I'm all ears!
But I don't think there is a way to do that. This seems more tied in to the Video Renderer and DirectDraw/Direct3D than the decoding filters.
-
I could probably change the default MadVR settings, and disable a lot of the extra processing to essentially get what I want, but the problem is that MadVR breaks DXVA support which for my slow CPU is a necessity.
-
If this is true, I would be interested in similar "mid-level" capability.
BTW, the MPC-HC video decoder is available separately as a DirectShow filter.
-
If this is true, I would be interested in similar "mid-level" capability.
BTW, the MPC-HC video decoder is available separately as a DirectShow filter.
Right, but I believe MPC-HCs rendering options are occurring at the Video Renderer level, not at the DShow filter level, so that wouldn't help :(
-
Right, but I believe MPC-HCs rendering options are occurring at the Video Renderer level, not at the DShow filter level, so that wouldn't help :(
I just checked my MPC-HC and I don't see those options at all - but it is 1.5.2.3456 , so perhaps it has been added over the last year ?
-
I just checked my MPC-HC and I don't see those options at all - but it is 1.5.2.3456 , so perhaps it has been added over the last year ?
It's possible those options aren't in 1.5. I'm using a 1.6 version. But if they are there, they'll be at:
View->Renderer Settings->Presentation
Close and restart after making changes
-
but the problem is that MadVR breaks DXVA support which for my slow CPU is a necessity.
No longer the case.
-
It's possible those options aren't in 1.5. I'm using a 1.6 version. But if they are there, they'll be at:
View->Renderer Settings->Presentation
Close and restart after making changes
Actually the settings are there in 3456... they are greyed out for EVR Sync (the renderer I was using) and also for EVR... they are only available for "EVR Custom Presenter" which is unique to MPC-HC.
So, MC would have to create their own in-house renderer options to get those settings.
By the way, have you tried with and without the "10-bit RGB output" setting ?
-
No longer the case.
In the MadVR version included with MC18 ?
-
In the MadVR version included with MC18 ?
In the newest build, yes.
http://forum.doom9.org/showthread.php?t=146228 (http://forum.doom9.org/showthread.php?t=146228)
18.0.94 (12/11/2012)
6. Changed: Updated to madVR v0.85.3 when using Red October HQ.
-
You have every possible combination for Video Rendering in MC:
- RO Std -> EVR
- RO HQ -> madVR then in the madVR settings you can choose any of the algorithms and processing that you want.
-
I just tried, but MC18.0.94 with RO HQ and MadVR doesn't work with my CPU/GPU combination (Dual Core 2.8 ghz ; Radeon 4200 ) - I get severe jerkiness, even with 720p.
RO Std works fine for everything with that setup - I tried comparing to MPC-HC with the aforementioned options engaged, and I could not notice any difference in casual use - detail seemed the same - but I don't know what sort of difference to look for in this case. :)
-
It's because the built-in LAV Video decoder doesn't seem to properly utilize DXVA2 when using MadVR.
I added my own LAV Video decoder to the Red October HQ filter chain, and now DXVA2 native is working just fine with MadVR, at comparable CPU/GPU usage to MPC-HC!
If I might make a suggestion, DXVA should be enabled by default for Red October HQ, when the "use hardware acceleration option" is checked in the video settings, of course.
Thanks to all who helped!
-
I find it interesting that it seems to be working in DXVA2 native mode. Everything I've read says that MadVR doesn't work with that and you have to use DXVA2 copy-back mode. But the LAV Video decoder menu is clearly telling me that DXVA2 Native is "active" and I can tell by the changes in CPU/GPU usage that it is indeed working.
-
I find it interesting that it seems to be working in DXVA2 native mode. Everything I've read says that MadVR doesn't work with that and you have to use DXVA2 copy-back mode. But the LAV Video decoder menu is clearly telling me that DXVA2 Native is "active" and I can tell by the changes in CPU/GPU usage that it is indeed working.
Did you following the doom9 link above posted by Bryanhoop? MadVR working with DXVA2 was just added as a feature to MadVR and JRiver just added that MadVR version to the latest build.
-
Did you following the doom9 link above posted by Bryanhoop? MadVR working with DXVA2 was just added as a feature to MadVR and JRiver just added that MadVR version to the latest build.
Yes I did. But there are two types of DXVA2 modes: Native and copy-back.
The changelog didn't explicitly mention whether it was DXVA2 Native support that to got added so I was assuming it meant copy-back, but nope, it's native :)
-
It's because the built-in LAV Video decoder doesn't seem to properly utilize DXVA2 when using MadVR.
I added my own LAV Video decoder to the Red October HQ filter chain, and now DXVA2 native is working just fine with MadVR, at comparable CPU/GPU usage to MPC-HC!
If I might make a suggestion, DXVA should be enabled by default for Red October HQ, when the "use hardware acceleration option" is checked in the video settings, of course.
Thanks to all who helped!
Dude !
I went to:
http://code.google.com/p/lavfilters/
And downloaded the latest version 54.1 and installed.
I tried RO HQ and same as before.
Then I did "Custom" Video options in MC18 based on RO HQ, and made the only change "Video Decoder" and selected LAV - which should be the exact same thing, BUT when I installed the downloaded LAV, I changed from no hardware acceleration to DXVA2 Native, and voila - now it works !
So, it is possible that RO HQ already has the correct LAV, but RO always greys out the filters, so one cannot change to DXVA2 Native support.
-
Dude !
I went to:
http://code.google.com/p/lavfilters/
And downloaded the latest version 54.1 and installed.
I tried RO HQ and same as before.
Then I did "Custom" Video options in MC18 based on RO HQ, and made the only change "Video Decoder" and selected LAV - which should be the exact same thing, BUT when I installed the downloaded LAV, I changed from no hardware acceleration to DXVA2 Native, and voila - now it works !
So, it is possible that RO HQ already has the correct LAV, but RO always greys out the filters, so one cannot change to DXVA2 Native support.
I think you explained it just right. RO HQ uses an approproiate LAV video decoder (probably one of the newest versions, in fact), it's just that it isn't set up to use DXVA2 with MadVR. It will use DXVA2 when using the RO Standard, but not for HQ. And that's probably because up until this latest version of MadVR (which came out just a few days ago it looks like), DXVA support was still lacking.
-
I spoke too soon.
I had accidentally re-engaged Red October Standard when I added the custom filter setup.
With HQ and MadVR, it works better than without the downloaded LAV filter, but still has some jerkiness. By the way, I had to engage all 4 quality->performance tradeoffs to get it to work that well.
With MadVR and Native, I get a green line across the screen, and with Copy-Back, no green line, but the performance is not quiet as good, I believe.
I remember when I previously investigated MadVR, it uses quite a lot of GPU firepower.
-
What kind of video card do you have?
-
What kind of video card do you have?
As I mentioned above, Dual Core 2.8 ghz ; Radeon 4200.
It's all from 2009.
By the way, have you tried MPC-HC with and without the "10-bit RGB output" setting ?
-
I have, and it didn't seem to have much effect when either of the floating point options were selected
-
Wow, this is amazing. I went back through my test scenes.
MadVR + DXVA is working great. If anything, it looks even better than MPC-HC did, at comparable resource usage. The DXVA support helped so much I didn't even have to drop the default MadVR settings that much!
True to my word I'm buying the JRiver MC right now and am a proud new member of the community :)
Cheers!
-
Coming back to the original question. EVR is no "low end" solution, its more or less a mid-range thing. You can however also configure madVR from low-end to high-end, whatever your hardware can do. The most important settings are the scaling options. From bilinear (low-end), to Bicubic (mid-range), to Lanczos+Anti Ringing (high-end), to Jinc (ultra high-end), anything is possible.
-
Coming back to the original question. EVR is no "low end" solution, its more or less a mid-range thing. You can however also configure madVR from low-end to high-end, whatever your hardware can do. The most important settings are the scaling options. From bilinear (low-end), to Bicubic (mid-range), to Lanczos+Anti Ringing (high-end), to Jinc (ultra high-end), anything is possible.
Well, I guess what I meant to say was something in between Red October Standard (which was using approx. 15% of my APU resources...and this is a CPU/GPU combo that runs at only 18 watts!) and Red October HQ (which was using 100%+)
But now that I know that MadVR is DXVA compatible, you're absolutely right. MadVR has even MORE configuration options than MPC-HC did!
-
Coming back to the original question. EVR is no "low end" solution, its more or less a mid-range thing. You can however also configure madVR from low-end to high-end, whatever your hardware can do. The most important settings are the scaling options. From bilinear (low-end), to Bicubic (mid-range), to Lanczos+Anti Ringing (high-end), to Jinc (ultra high-end), anything is possible.
Just to check, I changed all three settings to bilinear, but it is still not quite working for me with 2.8 ghz dual core and Radeon 4200 (although I am playing back a 1080p video on a 1080p TV, so I don't think the scaling is even involved).
I did check all four of the "trade quality for performance" items and that helped, but not quite enough. It also would seem that if I need to trade quality then I might as well just use EVR.
-
There is always scaling of the Chroma as it subsampled with most video formats so it needs to be sacled back to the Luma resolution even if the "video" resolution = the "display" resolution. With a 4200 I'd just use EVR and kick back and enjoy the content!
http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:2
-
I went back to MPC-HC EVR-CustomPresenter and tried the Renderer settings with my HT-PC
I found relatively little benefit to the Full Floating Point setting (again for 1080p->1080p playback).
However, the 10-bit RGB toggles did make a visible difference - I found everything to work better with both 10-bit Input and Output both selected.
Interestingly, I also compared back to MC18 with RO Standard, and there wasn't much difference from MPC-HC with 10-bit RGB. I'm wondering if it is possible that the vanilla EVR now uses 10-bit RGB by default ?