madVR - high quality video renderer (GPU assisted)

[someone`]

Can you please retry with v0.53? Having to pause/play every time is very annoying, of course

It still happens , but i found new trick : start playback --> pause --> reopen --> smooth playback .
I got green screen with v0.53 because using too much memory , i only have 1GB .

[SamuriHL]

Just tested 0.53 on my laptop. With my 2 test files I didn't go over 60% for MPC-HC CPU usage and only had under 10 dropped frames at the very beginning. Video is smooth and looks awesome. Considering it's my laptop I expect 0 problems on my 2 HTPC's, so, for me, things are very good! Thanks for your work on this, madshi! What a great amount of improvement over the last few weeks!!

[toniash]

Have you seen this ->? http://forum.doom9.org/showpost.php?...postcount=1331

[Mark_A_W]

Originally Posted by Mark_A_W

madshi

With the new exclusive rendering path, fullscreen exclusive works on my interlaced VGA display at 96hz (it didn't before).


But the playback is jerky and the presentation glitches continually climb - in batches of ~40 every 1/4 second.

The render and backbuffer queues are near empty.


However this gives me hope that it may one day work for me. Would a log help? I do realise I'm the only one here with a system like this, so if you don't want to expend effort, that's cool (I'm gunna get a new projector running 24p one day).

Here are the logs madshi.

The first log is of this strange thing where the monitor changes from 95.906hz interlaced to 60hz interlaced when it jumps into exclusive mode.

This also happens to me when I install something and the screen darkens when windows asks "are you sure" - a powerstrip quirk I think.

The log plays at 60hz for a while (no drops or delays or glitches), then I pause/play and it returns to 95.906hz, still in exclusive mode, but then I get the pres glitches.

http://dl.dropbox.com/u/1372034/madV...hen%2096hz.txt


The second log is a clean entry to exclusive at 95.906hz, but with lots of pres glitches.

http://dl.dropbox.com/u/1372034/madV...20glitches.txt

I will try 0.53 now....I can't keep up with you!!


Edit: 0.53 is no different with the pres glitches. My render/backbuffer/present queues are all low/empty. Bilinear didn't help (I have an i7 950 and an ATi4850), ..it's got grunt. But is it possible it's not enough grunt for 96hz?

[Andy o]

Originally Posted by madshi

(1) A madVR log of the high CPU consumption.
(2) The ProcessExplorer should show which thread is consuming the most CPU in the media player process. This thread is probably named "madVR.ax + xxxx". Please tell me the "TID" number of this thread. You'll find it in the properties of the media player process in the "threads" tab.

But as I said, with a single monitor setup getting information (2) will probably be impossible because you can't see the ProcessExplorer while madVR is in exclusive mode.

You just need that TID number, besides the log? Cause process explorer takes a few seconds to update, so can I just take that TID right after I switch from exclusive to windowed?

If so, it's 2444 madVR.ax+0x8470

I'll post the log in a while.

[sneaker_ger]

Originally Posted by toniash

Have you seen this ->? http://forum.doom9.org/showpost.php?...postcount=1331

Yes, there's a similar project for ffdshow.

But frames have to be copied back on forth to the GPU, so it's less efficient than conventional DXVA.

@madshi
Thx for the new version and the changed OSD. Will test it later.

[madshi]

Originally Posted by LoRd_MuldeR

I do remember this was important for you...

Originally Posted by someone`

It still happens , but i found new trick : start playback --> pause --> reopen --> smooth playback .

Hmmmm... Can I have a log, please?

Originally Posted by SamuriHL

Just tested 0.53 on my laptop. With my 2 test files I didn't go over 60% for MPC-HC CPU usage and only had under 10 dropped frames at the very beginning. Video is smooth and looks awesome.

So 0.53 is a noticeable improvement on your laptop? That's great to hear!

Originally Posted by toniash

Have you seen this ->? http://forum.doom9.org/showpost.php?...postcount=1331

Haven't seen that. I imagine it should work quite well for NVidia, but I think there might be problems with ATI.

Originally Posted by Mark_A_W

The first log is of this strange thing where the monitor changes from 95.906hz interlaced to 60hz interlaced when it jumps into exclusive mode.

Yeah, I don't understand that, either. On my secondary monitor similar things happen. It seems that *after* I switch to the correct refresh rate, Windows suddenly reports 60Hz. So madVR says: Ok, then I'll use that. Very weird. Should be solved once I implement the automatic refresh rate changing. Oh well, maybe I should stop being such a perfectionist and implement a crude automatic refresh rate changer soon instead of waiting for the perfect solution (which will take time).

Originally Posted by Mark_A_W

I will try 0.53 now....I can't keep up with you!!

Originally Posted by Andy o

You just need that TID number, besides the log? Cause process explorer takes a few seconds to update, so can I just take that TID right after I switch from exclusive to windowed?

If so, it's 2444 madVR.ax+0x8470

Yes, that's the number I need. But the number changes every time you start a new video. And I need the number to match the log you're creating. Then I can search the log for that number.

[Andy o]

OK, I found out that you can switch the refresh to up to 10 seconds so there's plenty of time to get the info. I'll get you the log in a while, thanks.

[SamuriHL]

Originally Posted by madshi

So 0.53 is a noticeable improvement on your laptop? That's great to hear!

Yea it seems to be. Either that or my laptop was just being stupid yesterday when testing 0.52. In either case, it's running quite well given the performance of this laptop overall. I haven't tried running it on my work laptop. I keep avoiding putting things on there that aren't work related because it's a powerhouse machine and I might get too comfortable using it. In any case, on my laptop and my 2 HTPC's I have madVR running extremely well now. I'm really quite happy.

[someone`]

My log 61MB unzip :
http://www.fileserve.com/file/gfHsw6j

Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Codec ID                         : V_MPEG4/ISO/AVC
Duration                         : 1mn 29s
Bit rate                         : 13.8 Mbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 23.976 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.278
Stream size                      : 148 MiB (95%)

[watchman]

Hello madshi,
i did few tests with new 0.53 version and there seems to be some new problem. With this new version i have really choppy playback and OSD stats are just confirming it - there are tons of presentation glitches. To be totally sure i tried 0.52 and everything was fine and there was no glithes at all and also no dropped frames.

I also created you a log. Hope it helps you figure out what's wrong. http://www.mediafire.com/?hhl3ohyvhnr6nwa

On the other hand, i can play Samsung ocean life demo (1080p 30fps 40mbps) without dropped frames. So performance will be better i think

About my config: nV 9600gt (270.51) under vista sp2

[Andy o]

madshi here is the info and the log

TID 4488 madVR.ax+0xb5d0

Just in case, there's another one that uses lower CPU:

TID 3872 madVR.ax+0xb500

File name: madVR - log.zip File size: 1.19 MB

Don't know if I should have kept the video running longer though? The log was getting very big.

[kasper93]

Originally Posted by madshi

Please try again with v0.53. Of course if there are no dropped/delayed frames and no presentation glitches then it's not a big problem if the queues are not stable. Anyway, if it bothers you, try fixing the GPU clock to a specific level. Maybe your GPU clocks down and up all the time, resulting in this queue behaviour? Not sure, just guessing...

Thanks for 0.53 After 5 minutes test it's look better. Maybe vsync were causing the problem. My GPU clocks are fine, I checked it yesterday. Anyway until it isn't drop frames is not a problem. Thanks

Originally Posted by ajp_anton

The point was that the name of the .ax file that is currently not being used would immediately tell the user whether debug mode is enabled or not.
Your filenames instead tell you which one is which, and only if you know what's going on. If one sees "madVR [Normal].ax", one may think "everything is normal" instead of "the normal one doesn't have the correct filename, therefore the debug build is active".

Maybe you're right ... I have a different view on this matter. But it's not so important ;P

[sneaker_ger]

First, short tests of 0.53:

1080p60 on 9200M GS with bilinear:
perfect

1080p60 on 5850:
perfect (the queues and dropped frames look like burned into the monitor, they fill up and stay filled, not changing at all)

1080p24 on 9200M GS with Soft Bicubic Chroma + Lanczos Luma:
The decoder queue stays at 0, whereas the old path would at least fill up a decoder queue. I didn't expect the decoder queue to stay at zero when the GPU is not powerful enough to render in real time.

XXXXp24 on 9200M GS at 60 Hz display:
No dropped or delayed frames but many glitches. log

I experienced two hangs on close on my laptop, but I can't reproduce it nor did I have logging enabled at that time.

[madshi]

Originally Posted by cyberbeing

Ok I got a log with madVR 0.52. It doesn't appear to be caused by the new Fullscreen render path after-all, in the following log it happened in windowed mode with no resizing.

Ok, here's a test build with more log output:

http://madshi.net/madVRcpu.rar

Not useful for anything other than logging either the hang or the high CPU consumption.

Originally Posted by watchman

i did few tests with new 0.53 version and there seems to be some new problem. With this new version i have really choppy playback and OSD stats are just confirming it - there are tons of presentation glitches. To be totally sure i tried 0.52 and everything was fine and there was no glithes at all and also no dropped frames.

Interesting. I've had a few flushs in v0.52 which I've removed for v0.53. It seems that the new exclusive mode does need a flush setting after all...

Originally Posted by someone`

My log 61MB unzip

Thanks, will look at that later...

Originally Posted by Andy o

madshi here is the info and the log

TID 4488 madVR.ax+0xb5d0

Just in case, there's another one that uses lower CPU:

TID 3872 madVR.ax+0xb500

File name: madVR - log.zip File size: 1.19 MB

Don't know if I should have kept the video running longer though? The log was getting very big.

Thanks. It's the rendering thread. Ok, so I've created and uploaded a special log build here:

http://madshi.net/madVRcpu.rar

Can you create another log for me with this build? It may help finding the cause of the problem. Or maybe not. I'm not sure. I don't need Process Explorer TID numbers, anymore. Just the log.

Originally Posted by sneaker_ger

1080p24 on 9200M GS with Soft Bicubic Chroma + Lanczos Luma:
The decoder queue stays at 0, whereas the old path would at least fill up a decoder queue. I didn't expect the decoder queue to stay at zero when the GPU is not powerful enough to render in real time.

Hmmmmm... No idea why the decoder queue doesn't move. It should. Unless your CPU is too slow.

Originally Posted by sneaker_ger

XXXXp24 on 9200M GS at 60 Hz display:
No dropped or delayed frames but many glitches.

Bilinear?

[Andy o]

Thanks madshi here's the new log

File name: madVRcpu - log.zip File size: 1.99 MB

[madshi]

Originally Posted by someone`

My log 61MB unzip

I've tried to have a look at your log, but it's a mess really. In the beginning of the log you're switching between windowed and exclusive mode like 10 times or so. I don't even know where to look for the problem exactly in the log. What I can see is that you're using a rather high refresh rate (72Hz) and a rather low number of pre-rendered frames. Try increasing the number of pre-rendered frames to 8. Maybe that helps a little?

[madshi]

Originally Posted by Andy o

Thanks madshi here's the new log

File name: madVRcpu - log.zip File size: 1.99 MB

Thanks!

Does this build fix the problem?

http://madshi.net/madVRcpu2.rar

If not, please another log with that build...

[DigitalLF]

MadShi: small bugreport.

first my screen was using DVI and it got the name u2711 in madvr and today i got a new displayport cable to handle the full resolution on this screen and in madvr i renamed it from u2711 (1) to u2711 at that time i had 2 with same name so i tried to delete the one i wasn't using and madvr crashed....

no hurry about that bug fix it will never happen to me again....

[DigitalLF]

MadShi: oh one other thing.... 0.52 (*) got my computer to freeze up completely today i had to hard reboot it ... do you think if i enable debug and in case that would ever happen again... will the reason be in the log file ?


* and by 0.52 i might mean 0.52 or ati drivers or win7 x64