madVR - high quality video renderer (GPU assisted)

[pie1394]

Did you work on a software or hardware implementation? Which one? (If you're allowed to say.)


It was a VLIW-based of 256-bit 2D vector processor.
I am curious if Intel AVX has copied this idea.


The 3rd dimension being time (making use of multiple previous and future fields)? Or something else?

It just does the Edge-based DCDi on both Odd and Even field images if I don't remember it wrong. Select the Median from averaged values of 5 directions.



I'm wondering if DCDi filters are necessary at all, if you use a good resampling algorithm from the get go. E.g. ICBI automatically takes care of smoothing diagonal lines etc. But then you could probably say that ICBI has DCDi type algorithms built in.

If it can produces moving objects with various angles of complex pattern bar images and the object edge line is still stright and un-distorted, it means you are right and it would not produce weird result on interlaced CRT / PDP devices.

With my experience, "Adaptive per pixel" is absolutely necessary to prevent noisy pixels on some static object edges for Edge-based method. If I don't remember it wrong, there are often 3 (no motion) ~ 1x (quick motion) % of Edge-based deinterlaced image pixels which often produce very different pixel color value from the same position's next original temporal pixel.

By visual effect the 5-tap or 7-tap VT deinterlacing is the safest one althrough it loses some accurate high-frequency singals. Since 5/7-tap VT deinterlacing + per pixel adaptive selection are very low cost on my used platform, and I was not doing a high-end product, that is why such workaround was taken.
(If I don't remember it wrong, the throughput should be 35 ~ 40 cycles per 8x8 pixels for combined per-pixel adaptive, 30 ~ 32 cycles for pure 2D Edge-based, 5 ~ 8 cycles for either 5 or 7-tap VT one)

[madshi]

Oh, it switches to fullscreen alright, but the video seems to play the frames out of order, producing a weird stuttering effect making it unwatchable. Since you use 3 buffers, imagine that instead of 1 2 3, it plays 2 1 3 or something like that. I can't explain much better.
Ah, understand. This might be fixed in a future build, allowing madVR to work properly on Crossfire setups.

0.39 without "disable desktop composition" and 0.36 seems to be about the same - black screen on switch, old frame etc.
0.39 with "disable desktop composition" behaves as explained before - disappearing menu etc.

Anyway, as I've said before, it really isn't a big issue, whatever alternative I choose.
I'll probably try both (0.39 with and without) for a while, and see...
Ok.

dont know much about NV12, does it provide better quality than YV12?
No, it's exactly the same quality as YV12. But some decoders prefer outputting NV12 over YV12. Also EVR/VMR prefer NV12 input over YV12. So I've added NV12 support to madVR just to be as flexible as possible.

I'm having a problem w/ all builds >0.36 when switching between FSE and FSW(XPSP3/CoreAVC CUDA, both in 1024*768 and 1280*720), basically PotPlayer's transport bar is not allowed to show up properly: http://thumbnails8.imagebam.com/12072/be0032120713303.jpg (http://www.imagebam.com/image/be0032120713303)

and if I hover over the buttons, I get this: http://thumbnails4.imagebam.com/12072/dbc8ae120713306.jpg (http://www.imagebam.com/image/dbc8ae120713306)

There's a zombie frame that refuses to leave and masks PotPlayer's GUI. It's never happened w/ <0.37, and I haven't changed any setting. It's a fairly random problem, but easy to reproduce.

PS: if I move from FSE/W to windowed while being paused, it often does the same w/ the windows tasktray/desktop(I use a dark gray Vista theme). I've double-checked, no such problem w/ 0.36.
Weird, my changes shouldn't have affected XP, they were targetted at Vista/Windows 7, only. I'll see if I can reproduce this problem here.

The seekbar sometimes still won't disappear after switched to exclusive mode. I thought this was an old issue.
Are you using ZoomPlayer? If so, make sure you disable the "move mouse off-screen" options in ZoomPlayer.

I post this here because where else but madvr do people get 0-255 source. Wanted to confirm, its good to use the full 0-255 levels with MadVR. My issue is that not all display devices, including many projectors, don't have DVI inputs. IIRC every JVC PJ for the last 4 years from the RS1 on up 1. has no DVI input 2. has a setting for enhanced 0-255 input (though where this 0-255 into the PJ HDMI input originates in the first place is unclear to me).

Now, nVidia cards by default put out 0-255 on the DVI port, and will only put 16-235 on the HDMI port. nVidia cards are willing to mix HD audio into the DVI port, but when you use a DVI-HDMI adapter on the DVI port, the nVidia card detects that, and forces you back to 16-235. And, nVidia doesn't offer you software control of this.

ATI (AMD) is similar. It does offer a control panel option to request 0-255 output, but it actually doesn't do anything at all on the HDMI port. Its been this way for a year and they seem uninterested in fixing it.

Many projectors, including my RS2, accept only HDMI, and no DVI. And they let you choose standard 16-235 or enhanced 0-255 input levels. (This implies that HDMI cables are capable of carrying enhanced signal levels). But it seems there is no way to get neither nVidia nor ATI graphics cards to push 0-255 over the HDMI cable.

Well, there may be one way. Use a DVI-HDMI adapter on a 5000-series-and-up ATI card's DVI output, and set the control panel for 0-255. ATI does seem to detect the adapter, but doesn't seem to force you back to 16-235 like nVidia does. Assuming you have set the ATI control panel to 0-255. Having negotiated the above land mines, ATI still does not jam HD audio (TrueHD etc.) into the DVI output, so you set up a second monitor, and run a cable from the HDMI output of your ATI card, into the HDMI input of your AVR. You lose the graphical overlay of the AVR, and the sound may be out of sync, but you can probably correct the sync.

Have I summarized the situation correctly? And, it will never change from the above "state of the art"? For people with e.g. JVC projectors that don't have DVI input, but do want the full 0-255 madVR goodness? Could displayport help?
My understanding is that with NVidia you can force 0-255 output by creating a custom resolution. All custom resolutions seem to always output 0-255. With ATI, it seems to be luck if you get the limited vs full switch in the control panel. And if you do get it, it's luck if changing it actually works.

If your GPU/driver doesn't allow you to output 0-255 then you're screwed for image quality (probably you'll get some banding). In that case you should set madVR to PC levels, otherwise you'd get a washed out image. If you do manage to make your GPU/driver output 0-255 then image quality should be fine. There should be no difference between outputting video vs PC levels in madVR, as long as you switch your display/projector to the same mode.

I'm looking into options to force NVidia and ATI hardware to output 0-255, by bypassing the driver. Not sure if I will manage to make that work.

Hi everyone. Been using madVR for some months and came to conclusion that it provides the best PQ for my needs. The only question is, how to set the scaling algorithms to the best possible quality? I used the default and now changed to Lanczos / 8 taps to all three in hope for better quality, but im not sure.
This question comes up every couple of pages. The advice is always the same: Try out which looks best for you. Also you can get some ideas from the red/green graphs in the madVR settings dialog. Most scaling algorithms have advantages and disadvantages. There is no "best" algorithm. You'll have to pick an algorithm which produces that kind of artifacts that you can live with best. I don't really recommend Lanczos8 because it creates a lot of ringing without bringing much benefit otherwise. For chroma I recommend a soft algorithm, but that's a matter of taste.

And what about the new input formats, what should I select from ffdshow options to output for best quality? I have profiles for SD/HD so I can select different outputs.
It doesn't matter. madVR only accepts highest quality inputs. All input formats madVR accepts have identical quality.

It was a VLIW-based of 256-bit 2D vector processor.
Is it in use in today's hardware? If so, in which? :)

It just does the Edge-based DCDi on both Odd and Even field images if I don't remember it wrong. Select the Median from averaged values of 5 directions.
Ah, ok.

With my experience, "Adaptive per pixel" is absolutely necessary to prevent noisy pixels on some static object edges for Edge-based method. If I don't remember it wrong, there are often 3 (no motion) ~ 1x (quick motion) % of Edge-based deinterlaced image pixels which often produce very different pixel color value from the same position's next original temporal pixel.

By visual effect the 5-tap or 7-tap VT deinterlacing is the safest one althrough it loses some accurate high-frequency singals. Since 5/7-tap VT deinterlacing + per pixel adaptive selection are very low cost on my used platform, and I was not doing a high-end product, that is why such workaround was taken.
(If I don't remember it wrong, the throughput should be 35 ~ 40 cycles per 8x8 pixels for combined per-pixel adaptive, 30 ~ 32 cycles for pure 2D Edge-based, 5 ~ 8 cycles for either 5 or 7-tap VT one)
Do you happen to have a couple of useful movie clips which highlight typical problems of bad algorithms which you could share with me? E.g. that "noisy pixels on some static object edges" problem? If so, could you PM me? That would be great! Thanks...

[janos666]

v0.39
- (b) is gone with disabled Aero, sure. But I didn't bother about that old frame on exit anyway.
- (a) speeds up the windowed<->exclusive mode switches. However, it bothers me when Aero turns ON or OFF (it's relatively slow with it's delay and the whole display flashes when it happens...).
(2) is better in the way that I can see Aero turning ON only after exit. And there is a small flashing when it turns OFF. It doesn't really bother me but I can't see why it is better than (b).

- NV12 works with FFDShow software decoders, but doesn't work with the MPC-HC internal decoder (it said: "Not Using DXVA", so it's nothing like that). I see a green screen. (Not a real problem for me, I was only curious if it uses DXVA now.)

[Anima123]

Hi Madshi,

No, I was using mpc-hc latest nightly built by xhmikosr.

[nevcairiel]

Hi Madshi,

No, I was using mpc-hc latest nightly built by xhmikosr.

I see this as well sometimes, just move your mouse away from the bottom of the screen - even when the cursor is hidden, madVR still recognizes it as being where it is, over the seek bar.

[pie1394]

Is it in use in today's hardware? If so, in which? :)


I guess not since it is more complex than regular 128-bit stream processor design. Too many gate counts to duplicate such unit for hundreds or thousands of SP in GPU.

That video processor was originally designed for fully programmable video player (MPEG-1/2/4 VC-1 H.264 decode) / recorder (MPEG-2/4 VC-1 H.264 encode) applications. Yet its playback performance (less than 300 MHz for everything... somewhat too crazy) is not as powerful as old Sigma Design 862x / 863x series.

To take the advantage of 2D vector computation with maximum 1-cycle throughput of 1 256-bit Arithmetic + 1 256-bit Multiply-Add by up-to-8-vector inner product, the selected algorithm is very important. It is due to the fact that vector instructions are not actually fully flexible for 256-bit output, but it does for the 128-bit output per instruction.



Do you happen to have a couple of useful movie clips which highlight typical problems of bad algorithms which you could share with me? E.g. that "noisy pixels on some static object edges" problem? If so, could you PM me? That would be great! Thanks...

In my memory, it happens on most regular interlaced TV static scenes. The noisy pixels look like sparkles on the video.

But I don't know how the low-end TV chipset handle that if it is claimed motion-adaptive deinterlace by Edge-based method. I don't believe 5-tap VT will be used because it costs too much for pure HW engine with large on-chip SRAM buffer. Maybe a smooth Gaussian filter is applied to make that less obvious.

Anyway madVR should always provide the best quality ones. :devil:

[fatboyz]

Just updated from 0.36 to 0.39.

Now when open a 720p TV scene rip (tried multiple files) in MPC HC the sound is there, the menu and seek bar is there, but the screen is green.

Went back to 0.36 and it's fine. Any Help?

Tried re-downloading 0.39 again and that didn't work

MPC HC 1.5.1.2946 with (internal) MPC decoder and ac3 decoder.
Tried coreavc and that was fine.

So I can only assume MPC HC internal H264 codec is conflicting somehow with madVR 0.39.

[cca]

I have noticed the same. Actually what happens is that somehow MPC-HC is confused and activated it's DXVA decoder instead of the software one. Perhaps madVR advertises something it shouldn't in the input pin. FFdshow NV12 works as expected.

[Razoola]

I can confirm I too only get a green screen with mpc-hc 1.5.1.2946

[dansrfe]

Doesn't DXVA output NV12? if so shouldn't DXVA work with madVR or does DXVA send a different type of colorspace that isn't supported yet?

[fatboyz]

I managed to fix green screen problem in the end by deleting the registry files for MPC HC and setting it up again.

in xp it can be found at:
HKEY_CURRENT_USER\Software\Gabest
delete the entire key and setup MPC HC filters and settings again.


I have also found another bug though :(

If I start watching a PAL 720p 25fps (display resolution 1280x720 50hz)and launch MPC HC in full screen 'launch files in full screen' it is switching my screen to 1280x720 60hz!

If I don't have full screen ticked and start it windowed it behaves itself and stays at 50hz.
If they then double click on the screen to make it full screen it stays at 50hz.

It only goes to 60hz if you start in in full screen.

Tried with internal and coreavc filters and both switch to 60hz from 50hz.

Tried with haali renderer and this doesn't change to 60hz.

[cyberbeing]

Oh, it switches to fullscreen alright, but the video seems to play the frames out of order, producing a weird stuttering effect making it unwatchable. Since you use 3 buffers, imagine that instead of 1 2 3, it plays 2 1 3 or something like that. I can't explain much better.
Ah, understand. This might be fixed in a future build, allowing madVR to work properly on Crossfire setups.

What cca describes sounds almost identical to my symptoms with Fullscreen Exclusive (3 buffers, weird stuttering, out-of-order frames), except I'm using a single NVIDIA card on WinXP.

[madshi]

v0.39
- (b) is gone with disabled Aero, sure. But I didn't bother about that old frame on exit anyway.
- (a) speeds up the windowed<->exclusive mode switches. However, it bothers me when Aero turns ON or OFF (it's relatively slow with it's delay and the whole display flashes when it happens...).
(2) is better in the way that I can see Aero turning ON only after exit. And there is a small flashing when it turns OFF. It doesn't really bother me but I can't see why it is better than (b).
Hmmmmm... It looks like the beginning of your post is missing? At least I don't really understand which options you're talking about in the beginning of your post.

- NV12 works with FFDShow software decoders, but doesn't work with the MPC-HC internal decoder (it said: "Not Using DXVA", so it's nothing like that). I see a green screen.
Now when open a 720p TV scene rip (tried multiple files) in MPC HC the sound is there, the menu and seek bar is there, but the screen is green.
I have noticed the same. Actually what happens is that somehow MPC-HC is confused and activated it's DXVA decoder instead of the software one.
I can confirm I too only get a green screen with mpc-hc 1.5.1.2946
I've tried to reproduce that with the rather old MPC-HC version I'm still using and have no problems here. The MPC-HC decoders still connect via YV12 to madVR. I guess those new MPC-HC builds you guys are using have changed how the MPC-HC decoders behave? Anyway, I would suggest that it's probably a bug in the MPC-HC decoders, since all other decoders seem to work just fine with madVR + NV12.

BTW, why are you guys still using the MPC-HC decoders? I thought it was common knowledge that they're buggy as hell? I'd had more trouble with the MPC-HC decoders than with any other decoders.

Doesn't DXVA output NV12? if so shouldn't DXVA work with madVR or does DXVA send a different type of colorspace that isn't supported yet?
DXVA decoders to GPU RAM, while software decoders decode to system RAM. madVR expects the data in system RAM. Having the frame decoded to GPU RAM is problematic for various technical reasons.

I managed to fix green screen problem in the end by deleting the registry files for MPC HC and setting it up again.
Interesting. Do the MPC-HC decoders connect via NV12 or YV12? Or maybe the registry deletion you did resulted in other decoders being used now?

If I start watching a PAL 720p 25fps (display resolution 1280x720 50hz)and launch MPC HC in full screen 'launch files in full screen' it is switching my screen to 1280x720 60hz!

If I don't have full screen ticked and start it windowed it behaves itself and stays at 50hz.
If they then double click on the screen to make it full screen it stays at 50hz.

It only goes to 60hz if you start in in full screen.
That's weird. Can you reproduce this problem? And can you reproduce that it doesn't happen with v0.36?

Tried with haali renderer and this doesn't change to 60hz.
The Haali Renderer doesn't ever go into exclusive mode.

What cca describes sounds almost identical to my symptoms with Fullscreen Exclusive (3 buffers, weird stuttering, out-of-order frames), except I'm using a single NVIDIA card on WinXP.
Yes, I know. I expect that the final exclusive mode rendering path will fix this problem for both of you. This is the very next thing I'll be working on, so shouldn't be too far away.

To take the advantage of 2D vector computation with maximum 1-cycle throughput of 1 256-bit Arithmetic + 1 256-bit Multiply-Add by up-to-8-vector inner product, the selected algorithm is very important. It is due to the fact that vector instructions are not actually fully flexible for 256-bit output, but it does for the 128-bit output per instruction.
That sounds like chinese to me... :) I've no clue about the typical hardware limitations you run across when developing hardware circuits. Luckily in my position I don't have to worry about these things. High-end GPUs have shader/math power to spare!

In my memory, it happens on most regular interlaced TV static scenes. The noisy pixels look like sparkles on the video.

But I don't know how the low-end TV chipset handle that if it is claimed motion-adaptive deinterlace by Edge-based method. I don't believe 5-tap VT will be used because it costs too much for pure HW engine with large on-chip SRAM buffer. Maybe a smooth Gaussian filter is applied to make that less obvious.

Anyway madVR should always provide the best quality ones. :devil:
Well, the first step would be to try making DXVA deinterlacing work. Making the deinterlacing work in itself shouldn't be hard. But the problem is the same as with DXVA decoding: The DXVA decoding/deinterlacing results are stored on GPU RAM in a format that's almost impossible for madVR to access via pixel shaders.

[cca]

Just to clarify, I only use the DXVA decoders of MPC-HC, this is the reason I concluded it tries to feed DXVA data to the renderer. All the software decoders are disabled, I prefer FFDshow for software decoding.

EDIT: A possible workaround is to completely disable MPC's DXVA and use the FFDshow DXVA decoder, it is the same decoder essentially but behaves properly in regards to madVR

[fastplayer]

BTW, why are you guys still using the MPC-HC decoders? I thought it was common knowledge that they're buggy as hell? I'd had more trouble with the MPC-HC decoders than with any other decoders.
Do you mean problems with playback or getting it to work with madVR? Can you give us any recommendations particularly for H.264 playback?

[madshi]

Don't know. I'm using CoreAVC myself. But my experience is that ffdshow does the same as MPC-HC decoders, just with less bugs.

Anyway, I've just tested MPC-HC build 1.5.1.2948 (downloaded from xvidvideo.ru) and MPEG2, h264 and VC-1 MPC-HC decoders work just fine here with madVR v0.39. Those of you with a green screen, can you please try 1.5.1.2948, just to be safe? If you still have a green image, please post your "pin connection" information here. Thanks.

[fatboyz]

@madshi I have also managed to fix the 50hz 60hz switching in exclusive mode.

I tried installing an old version of madVR 0.29 and is was still switching to 60hz :(

I knew it didn't do this until recently, otherwise I would have noticed it.

I then remembered I updated Catalyst Control Center to 11.2 from 10.8 a few days ago.

So I uninstalled 11.2 and reinstalled 10.8 to test and it now does not switch.

So the latest Catalyst drivers and exclusive mode are obviously not a good mix.

[fatboyz]

As I said in previous post.

To fix the green screen problem just delete you gabast registry keys.

Then setup MPC HC again and this fixes it.

[cca]

Don't know. I'm using CoreAVC myself. But my experience is that ffdshow does the same as MPC-HC decoders, just with less bugs.

Anyway, I've just tested MPC-HC build 1.5.1.2948 (downloaded from xvidvideo.ru) and MPEG2, h264 and VC-1 MPC-HC decoders work just fine here with madVR v0.39. Those of you with a green screen, can you please try 1.5.1.2948, just to be safe? If you still have a green image, please post your "pin connection" information here. Thanks.

Confirmed, it does work with that version.

[janos666]

Hmmmmm... It looks like the beginning of your post is missing? At least I don't really understand which options you're talking about in the beginning of your post.


No, I just followed your descriptions:



(a) switching takes too much time
(b) an old video frame is sometimes shown for a short moment
(c) mouse cursor is reset to middle of screen

Problem (a) should generally be slightly improved in v0.37 now. But I've found a key solution to make it *much* faster (as fast as XP): By disabling desktop composition. Furthermore I've also found that disabling desktop composition also takes care of problem (b). As a result I've added new options to the madVR settings dialog to define if and when desktop composition is disabled. There are 5 options:

(1) don't disable desktop composition
This is similar to what older madVR versions did. Problem (a) should be improved slightly, but probably not by much. Problem (b) will still occur.

(2) disable desktop composition during exclusive -> windowed mode switch
This will disable + reenable desktop composition whenever madVR switches from exclusive mode to windowed mode. Not sure about problem (a), might eventually be worse for some people, not sure. Problem (b) should be fixed.

(3) disable desktop composition while madVR is in exclusive mode
Not sure about problem (a), might be slightly better or worse. Problem (b) should be fixed.

(4) disable desktop composition while media player is in fullscreen mode
This should fully fix problems (a) and (b). The disadvantage is that context menus and option windows in fullscreen mode will look uglier because Aero is disabled.

(5) always disable desktop composition
This should also fully fix problems (a) and (b). But Aero will be disabled even when running madVR in a small window.

[madshi]

So I uninstalled 11.2 and reinstalled 10.8 to test and it now does not switch.

So the latest Catalyst drivers and exclusive mode are obviously not a good mix.
This problem should be fixed once madVR takes control of refresh rates. Currently it does not, it just tells the OS/GPU "keep using the same fresh rate".

No, I just followed your descriptions
Ok. So have you tried all options? Which do you prefer / plan to use?

[pirlouy]

Just to clarify, I only use the DXVA decoders of MPC-HC
Not sure to understand. If you use madVR, these decoders are not used, so either it uses MPC decoders non DXVA, either it uses the next decoder in the chain (surely ffdshow).

[Luv]

Hmmmm... If you run that cheese slices test pattern with ZP + madVR, what image quality do you get? No combing, you say. But is it really VA quality?


No,no,Madshi ! :)
ZP+madVR in the test:combing
ZP+madVR with 1080i material: wonderful quality,no combing,no stuttering,superb.
I'm almost sure you could check for yourself by using with ZP:
- Cyberlink MPEG2 decoder
- madVR 0.36
- Radeon HD
- Catalyst 10.8 or 10.2

Anyway,this was just FYI even if it's hard to explain (Maybe the way you connected the decoder to your renderer?).But,please,do not modify anything on this side !
:thanks:

[nevcairiel]

That cheese slice test is 1080i material, and you will not get any deinterlacing, except if you use deinterlacing in another filter before madVR, and it will be ugly, as ugly as it gets.

[Razoola]

Confirmed, it does work with that version.

not working here.

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {008BAC12-FBAF-497B-9670-BC6F6FBAE2C4}
Filter: MPC Video Decoder
Pin: Output

- Connection media type:

Video: DXVA 2048x720 (16:9) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 2211840
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(1280,720)
rcTarget: (0,0)-(1280,720)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 2048
biHeight: 720
biPlanes: 1
biBitCount: 12
biCompression: dxva
biSizeImage: 2211840
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 ............Ð...
0010: 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 ............Ð...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 81 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 �...............
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 08 00 00 ........(.......
0050: d0 02 00 00 01 00 0c 00 64 78 76 61 00 c0 21 00 Ð.......dxva.À!.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[nevcairiel]

not working here.
<<snip>>

Video: DXVA 2048x720 (16:9) 23.98fps


madVR does not work with DXVA, and even less so with DXVA1 (like that there)

Whats with that huge Stride in that media type though? 2048 for a 1280 image? oh well..

[Razoola]

madVR does not work with DXVA, and even less so with DXVA1 (like that there)

Whats with that huge Stride in that media type though? 2048 for a 1280 image? oh well..

This is in relation to the green screen being reported. I still get it using the MPC build madshi suggests.

[nevcairiel]

This is in relation to the green screen being reported. I still get it using the MPC build madshi suggests.

madVR should probably reject media-type NV12 with biCompression = dxva then, didn't realize it would actually allow the connection.

[madshi]

No,no,Madshi ! :)
ZP+madVR in the test:combing
ZP+madVR with 1080i material: wonderful quality,no combing,no stuttering,superb.
Are you sure that 1080i material is really *video* material and not *movie* material? There's a world of a difference between those two.

Whats with that huge Stride in that media type though? 2048 for a 1280 image? oh well..
I haven't used such a huge stride in older versions, but that made the MPC-HC MPEG2 decoder crash for interlaced VOB files (just another MPC-HC decoder bug). So I've copied the stride logic from VMR/EVR. Both of these always use a 2^x stride. So madVR does that now, too, since version v0.37.

madVR should probably reject media-type NV12 with biCompression = dxva then, didn't realize it would actually allow the connection.
Hmmmm... You're right there. I wasn't aware that DXVA connections look like this, I thought they'd have their own GUIDs. You're right, I need to reject "biCompression = dxva".

[nevcairiel]

Hmmmm... You're right there. I wasn't aware that DXVA connections look like this, I thought they'd have their own GUIDs. You're right, I need to reject "biCompression = dxva".

The DXVA codec should in theory realize itself that the renderer does not provide the interfaces it needs to function properly, but that might just be another bug.

[djsolidsnake86]

anyone know why mpeg files are very bad with madvr?

[fairchild]

anyone know why mpeg files are very bad with madvr?

I have no problems with MPG/MPEG files. What exactly do you mean by "very bad with madvr"?

[lych_necross]

Do you mean problems with playback or getting it to work with madVR? Can you give us any recommendations particularly for H.264 playback?
I prefer DiAVC for H.264 playback. On my system, it performs faster than CoreAVC (which I also have). DiAVC is also updated more frequently than CoreAVC.

[Hypernova]

Just my 2 cents: I prefer not disable aero at all. Yes, the swtiching between windowed and exclusive mode is smoother without Aero, but switching Aero on and off is worse than exclusive mode switching. It is never really bother me though (the exclusive mode switching).

[Mangix]

i use DirectVobSub since i need subtitles with madVR. My question is, since the microsoft decoder outputs nv12 and DirectVobSub converts it to yv12, is the conversion lossless?

[nevcairiel]

Converting from NV12 to YV12 is lossless, if done right.

[fairchild]

Just my 2 cents: I prefer not disable aero at all. Yes, the swtiching between windowed and exclusive mode is smoother without Aero, but switching Aero on and off is worse than exclusive mode switching. It is never really bother me though (the exclusive mode switching).

What do you mean that Aero switching on and off is worse? If you set up the last option (always), it just does it once when you start to play a video and as long as you don't close your media player, it doesn't toggle it off and on constantly. Also there are other programs/games that do this already (disable Aero composition) to get better performance or for compatability reasons, so having MadVR do this now is excellent imo.

Before this update to MadVR, I used to always have Aero off, because with it on, it was not completely smooth. I had to have Aero off + FSE to have totally smooth playback. Now I have the best of both worlds Aero composition on for internet streaming videos so that there is no tearing, and then Aero composition off + MadVR FSE for no tearing + totally smooth playback. :thanks:

[Hypernova]

What do you mean that Aero switching on and off is worse? If you set up the last option (always), it just does it once when you start to play a video and as long as you don't close your media player, it doesn't toggle it off and on constantly. Also there are other programs/games that do this already (disable Aero composition) to get better performance or for compatability reasons, so having MadVR do this now is excellent imo.

Before this update to MadVR, I used to always have Aero off, because with it on, it was not completely smooth. I had to have Aero off + FSE to have totally smooth playback. Now I have the best of both worlds Aero composition on for internet streaming videos so that there is no tearing, and then Aero composition off + MadVR FSE for no tearing + totally smooth playback. :thanks:

I understand what you mean, but I really like to keep Aero on. Sometimes I play a video and then switch to something else for a moment, and seeing non-aero UI really annoy me. Disable Aero does not do any good to me, and even with Aero, exclusive switching is seemless enough to me already, so I prefer just keep Aero on all the time. Though I also have to say that I don't need exclusive mode anymore since I upgraded to 6850. It's planty fast enough.

[djsolidsnake86]

I have no problems with MPG/MPEG files. What exactly do you mean by "very bad with madvr"?

i see it very pixellate with madvr
no problem with evr sync

[dansrfe]

I can do Aero Flip 3D with madVR running and absolutely no stutter. That's how rock solid madVR is for me now. I'm impressed.

[cyberbeing]

i use DirectVobSub since i need subtitles with madVR. My question is, since the microsoft decoder outputs nv12 and DirectVobSub converts it to yv12, is the conversion lossless?
DirectVobSub (VSFilter) doesn't accept NV12, so if it's working, your decoder isn't outputting NV12.

DirectVobSub (VSFilter) accepted input/output formats:
YV12
YUY2
RGB32
I420
IYUV
RGB24
RGB555
RGB565

[Mr Alpha]

Oh, it switches to fullscreen alright, but the video seems to play the frames out of order, producing a weird stuttering effect making it unwatchable. Since you use 3 buffers, imagine that instead of 1 2 3, it plays 2 1 3 or something like that. I can't explain much better.Yes, I have that as well. The solution is to disable Catalyst AI. If you don't want to disable it globally you can download RadeonPro (http://www.radeonpro.info/en-US/), which lets you setup profiles for individual applications, and create a profile for your media player that disables Catalyst AI when it launches.

[pirlouy]

@Madshi: you ask for feedback, so here's mine: I agree with your choice.

Option (5) can be substituted by right clicking on mpc-hc.exe > properties > Disable desktop Composition.
Option (1): logical, in order to avoid "frackin' renderer who breaks Aero" comments...
Option (4) is the best "middle" solution.

I use (4), but I can't say if it improves something since I've never had Aero when launching mpc-hc...

[Toe Tag]

My understanding is that with NVidia you can force 0-255 output by creating a custom resolution. All custom resolutions seem to always output 0-255. With ATI, it seems to be luck if you get the limited vs full switch in the control panel. And if you do get it, it's luck if changing it actually works.

If your GPU/driver doesn't allow you to output 0-255 then you're screwed for image quality (probably you'll get some banding). In that case you should set madVR to PC levels, otherwise you'd get a washed out image. If you do manage to make your GPU/driver output 0-255 then image quality should be fine. There should be no difference between outputting video vs PC levels in madVR, as long as you switch your display/projector to the same mode.

I'm looking into options to force NVidia and ATI hardware to output 0-255, by bypassing the driver. Not sure if I will manage to make that work.

ATI luck, I think means in practice, it (working 0-255 levels out the HDMI plug or if needed the DVI port) varies across ATI CCC driver version. And now for me, on my Windows 7 SP1 (32-bit), with CCC 11.2 that came out 10 days ago, with a 5750 card, CCC not only offers 0-255 RGB, but it appears at first blush to actually work, out the HDMI port, without having to resort to the DVI port and a DVI-HDMI adapter shenanigans. It only took ATI a year to get their driver to this state.

[pankov]

madshi,
I just did find the time to test the new version and I have mixed success to report.
I'll start with the new stuff
1. I tried the new options to disable Aero an here are my comments
(1) don't disable - the switching seams a little bit faster but there is a problem in ZoomPlayer at least the control bar or any other UI (for example the Media Library Navigator) is not drawn correctly. It's either not visible at all (like the MediaLib Navigator) or partially drawn like the Control bar. I have to do something to force them to redraw and then it's OK. I guess this has something to do with your attempt to fix the "old frame showing".
(2) during switch - I really don't see the idea of this option. The Aero switch is presenting much more blinking and delay than the normal Exclusive -> Windows switch with Aero ON
(3) madVR in Exclusive - I guess this option is designed for those users that need Aero off to get perfect playback but for me personally it's not necessary and as it introduces again a lot of blinking/flickering when Aero is switched on I don't intent to use it
(4) only in fullscreen - this is something that I suppose is useful if anybody needs Aero off but still likes Aero on when not watching in fullscreen and it avoids the blinking when some of the players UI is used.
(5) always - I agree with pirlouy that this can be done outside of madVR - either in the player of in Windows itself as he pointed out but I guess you've added it for the less informed users.

So my personal favorites are (1) don't disable and (4) when player is in fullscreen

About the "old frame showing" - I don't seem to see it now with either (1) or (4) but I'll do more testing tonight on the big screen where it's more prominent.

Now to the old stuff.
2. Mouse cursor going to the center - it seems fixed :)
3. access violation when jumping to the next file - at first I thought it was fixed and I was extremely happy but than after a few more erratic jumping forward and backward through the list of episodes of a show I got an access violation again. :( I've tried different video decoders (CoreAVC, ffdshow, MPC's one) and they all present the same error. But I think I found a pattern. If I use the "[" "]" keys to jump to the next file without going out of exclusive (using my personal settings in ZP) and I wait a few seconds between jumps I don't get the error but if I press the button before the first frame is shown on screen (or it's possible before it's decoded - I can't really say) I get the access violation. madshi, do you want a new log file? I guess it has something to do with the buffers which are empty while destroying madVR instance ... or something like this ... I'm just guessing.
So sadly I have to go back to v0.31 again
:(

[namaiki]

i see it very pixellate with madvr
no problem with evr sync

Is madVR actually loading in that case?
(check the Play-> Filters menu for the word 'madVR')

[djsolidsnake86]

yes is loading

but this new version disable aero when playing a video? why?

[pirlouy]

Read Madshi posts, you'll find an explanation.
If you don't want, you can disable option "disable desktop composition" in settings.

[madshi]

The DXVA codec should in theory realize itself that the renderer does not provide the interfaces it needs to function properly, but that might just be another bug.
Yeah, but it's not correctly done in madVR, either, in this case, I think. I'll fix that in the next build.

anyone know why mpeg files are very bad with madvr?
Maybe it's a deinterlacing issue? When using madVR, you need to manually deinterlace the video before feeding it to madVR. When using EVR/VMR, you'll eventually get DXVA deinterlacing.

Maybe if you show us a screenshot of madVR vs. a screenshot of EVR/VMR we can tell you for sure if it's a deinterlacing issue or something else.

Option (5) can be substituted by right clicking on mpc-hc.exe > properties > Disable desktop Composition.
Yes, but not everybody uses MPC-HC, and maybe not every media player has an option to disable desktop composition. Furthermore whether you need/want to disable, might depend on the renderer. So I think having the option in madVR might be beneficial in many situations.

(1) don't disable - the switching seams a little bit faster but there is a problem in ZoomPlayer at least the control bar or any other UI (for example the Media Library Navigator) is not drawn correctly. It's either not visible at all (like the MediaLib Navigator) or partially drawn like the Control bar. I have to do something to force them to redraw and then it's OK. I guess this has something to do with your attempt to fix the "old frame showing".
Which OS are you on?

2. Mouse cursor going to the center - it seems fixed :)
Nice!

3. access violation when jumping to the next file - at first I thought it was fixed and I was extremely happy but than after a few more erratic jumping forward and backward through the list of episodes of a show I got an access violation again. :( I've tried different video decoders (CoreAVC, ffdshow, MPC's one) and they all present the same error. But I think I found a pattern. If I use the "[" "]" keys to jump to the next file without going out of exclusive (using my personal settings in ZP) and I wait a few seconds between jumps I don't get the error but if I press the button before the first frame is shown on screen (or it's possible before it's decoded - I can't really say) I get the access violation. madshi, do you want a new log file?
I've tried again. I can press PageDown as often as I want, and as quickly as I want, no problems here. You can send me a new log, but I don't have much hope it will help. Maybe the only way to fix this will be to wait until I get proper crash analyzation and reporting implemented. That may take a while, though.

I'm having a problem w/ all builds >0.36 when switching between FSE and FSW(XPSP3/CoreAVC CUDA, both in 1024*768 and 1280*720), basically PotPlayer's transport bar is not allowed to show up properly: http://thumbnails8.imagebam.com/12072/be0032120713303.jpg (http://www.imagebam.com/image/be0032120713303)

and if I hover over the buttons, I get this: http://thumbnails4.imagebam.com/12072/dbc8ae120713306.jpg (http://www.imagebam.com/image/dbc8ae120713306)

There's a zombie frame that refuses to leave and masks PotPlayer's GUI. It's never happened w/ <0.37, and I haven't changed any setting. It's a fairly random problem, but easy to reproduce.

PS: if I move from FSE/W to windowed while being paused, it often does the same w/ the windows tasktray/desktop(I use a dark gray Vista theme). I've double-checked, no such problem w/ 0.36.
I can't seem to reproduce this. If you still have this problem with the next madVR build, can you send me your potplayer configuration files (skin etc)? Maybe it only occurs with customized skins?

[skampy]

Is anyone able to help me install madVR? I've tried just about everything but MPC-HC simply won't recognise that it is registered/installed (it's grayed out).