madVR - high quality video renderer (GPU assisted) [Archive] - Page 63

pie1394

8th June 2010, 15:02

If you have both the top two flush settings as 'don't flush,' there will definitely be tearing, in my experience with Aero off.

Do you have tearing with MadVR's current defaults?

Test it again, and it is what I described last time. Forced V-SYNC ON in the driver does not make any difference, either. At 59.94 Hz, the tearing happens to FILM contents occassionally. It might be hard to notice that unless I watch the screen very carefully.

During the recent tests, I just found some stupid bugs happening to 197.xx series previously have been fixed in Forceware Win7 driver 257.15 beta. For example:

1. Cannot set 32-bit color at 1080p60 via Control Panel. (was ok with 196.xx)
2. 23 / 29 / 59 Hz modes get 23 / 29 / 59 Hz refresh rates instead of 23.976 / 29.97 / 59.94 Hz. (was also NG with 196.xx)

namaiki

8th June 2010, 15:07

STaRGaZeR

8th June 2010, 16:43

http://dl.dropbox.com/u/1372034/subtitle_image.bmp

http://dl.dropbox.com/u/1372034/subtitle_image_2.bmp

Not knowing how you rip your movies, and unless you have that font inside your MKV file or installed in your system, I'll say those are not text subtitles but images, like BD and DVD subs. Completely different things. MakeMKV maybe?

Well, as madshi said he will add pin for subs, so don't think that I'm asking again about it

The problem I see here is that adding a subtitle pin will not print the subs on the image. You need a parser, a rasterizer... basically the whole engine VSFilter, MPC and ffdshow have. And this is pure speculation on my part, but I think it's more difficult to write that that the whole video renderer itself.

Razoola

8th June 2010, 16:54

Then, I guess it depends on the setup. :P

For me, on my ~60Hz screen, I will experience tearing if I have both of the top two options set to don't flush.

I have the same, either of the top two settings must be set to flush to remove the tearing. With both disabled there is tearing but not not on a constant scanline, it varies much like it would in a game thus making the tearing harder to spot.

madshi, maybe you could add a tearing test line panning across the screen to allow people to spot tearing easier? I use the one built into reclock so its not a problem for me.

Keiyakusha

8th June 2010, 17:32

The problem I see here is that adding a subtitle pin will not print the subs on the image. You need a parser, a rasterizer... basically the whole engine VSFilter, MPC and ffdshow have. And this is pure speculation on my part, but I think it's more difficult to write that that the whole video renderer itself.
Maybe I'm misunderstanding you but MPC-HC already have this "whole engine" which is almost the same code as vsfilter + some additional stuff. At least that's how it was explained in MPC-HC thread some time ago. The point was to make subtitles work with MPC-HC & madvr and not with every possible player, right?

STaRGaZeR

8th June 2010, 19:09

Maybe I'm misunderstanding you but MPC-HC already have this "whole engine" which is almost the same code as vsfilter + some additional stuff. At least that's how it was explained in MPC-HC thread some time ago. The point was to make subtitles work with MPC-HC & madvr and not with every possible player, right?

Yes. But that engine is integrated in their custom renderers, that's why you can use it with DXVA, that's why you can't use it outside MPC and that's why it only works with those renderers and not in, for example, vanilla EVR. If you want to use it in madVR I believe you'd need MPC's code in madVR, and that's not possible due to GPL violations. madVR would need its own engine, that takes the subs "raw" info (text and settings in text subtitles, PGS bitstream in BD subs, etc.) from the subtitle input pin, parses it and puts it on screen, like MPC, VSFilter and ffdshow do.

Correct me if I'm wrong!

ranpha

8th June 2010, 19:17

Yes. But that engine is integrated in their custom renderers, that's why you can use it with DXVA, that's why you can't use it outside MPC and that's why it only works with those renderers and not in, for example, vanilla EVR. If you want to use it in madVR I believe you'd need MPC's code in madVR, and that's not possible due to GPL violations. madVR would need its own engine, that takes the subs "raw" info (text and settings in text subtitles, PGS bitstream in BD subs, etc.) from the subtitle input pin, parses it and puts it on screen, like MPC, VSFilter and ffdshow do.

Correct me if I'm wrong!

Haali Video Renderer can use MPC-HC subtitle engine yet it is closed-source.

STaRGaZeR

8th June 2010, 20:55

Haali Video Renderer can use MPC-HC subtitle engine yet it is closed-source.

Indeed, forgot about that. A quick Google search after looking at Haali's renderer subtitle pin reveals this:

// {5965E924-63F9-4a64-B71E-F75188FD6384}
DEFINE_GUID(MEDIASUBTYPE_DXRSub,
0x5965e924, 0x63f9, 0x4a64, 0xb7, 0x1e, 0xf7, 0x51, 0x88, 0xfd, 0x63, 0x84);

MEDIASUBTYPE_DXRSub. Looks like a custom pin. I wonder what goes thru there, and if madVR would need another custom one.

Mark_A_W

8th June 2010, 23:11

Not knowing how you rip your movies, and unless you have that font inside your MKV file or installed in your system, I'll say those are not text subtitles but images, like BD and DVD subs. Completely different things. MakeMKV maybe?

I already said, it's a bluray rip.

Done with AnotherEac3toGui (which uses BDsup2sub).

Fer

8th June 2010, 23:32

(1) GPU: ATI 2600XT
(2) OS: Windows XP
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display resolution + refresh rate: 1920x1080, 23.976 with PowerStrip (I DO NOT use reclock!)
(5) Single monitor setup
(6) MPC Homecinema
(7) Video decoder: ffdshow (AVC: libavcodec, VC1: wmv9)
(8) madVR 0.17

Finally, for the first time with madVR, with the default flush options, I have playback without tearing, zero dropped frames and perfect smooth !!!!

http://img535.imageshack.us/img535/7676/dibujoacb.th.jpg (http://img535.imageshack.us/i/dibujoacb.jpg/)

Some minor observations:
- With "don´t flush" for all the items I have the same good behaviour.
- VSFilter 2.39 do not work. I manage the subtitles with ffdshow perfectly (There is any version of VSFilter that works? thank you).

I think that madVR will be now my default video renderer. Before madflac the only way to achieve smooth and free tearing playback was EVR Custom Pres with
D3D Fullscreen. Now with madVR and SoftCubic100 for Chroma resampling (fortunately I don´t need luma up or downsampling), I have an image much, much better.
And all of them with my "old" ATI 2600XT (I don´t need to change the graphic card!!).

Great Madshi. People like you are very good people (madflac, eac3to, madVR,...).

:thanks::thanks::thanks:

leeperry

9th June 2010, 03:32

Well, I think it will be fixed in the next build. At least one bug responsible for the problem. Maybe there are more bugs. If so, just create another log for me with the next build. I'm sure we'll get this fixed soon.
I thought I would do that right away, play a movie w/ the 0.17 debug version, wait for hiccuping to occur after 45/60 mins and you'd see whether it's due to another bug...but my windows partition is rather small, and the last log I made was 2.5MB for 10 secs. Any chance you could possibly allow to change the log file location please? so I could put it on a drive w/ a lot of free space and not worry :)

I should also add that the problem shown in the last log I sent you occurs w/ pretty much all the other VR's(HR/VMR9/vanilla EVR)...except Beliyaal's EVR CP. When using Reclock, the latter never hiccups after seeking from what I've seen.

namaiki

9th June 2010, 05:53

- VSFilter 2.39 do not work. I manage the subtitles with ffdshow perfectly (There is any version of VSFilter that works? thank you).

Try the one that comes with CCCP. :p It has been working for me.

What happens when you try use VSFilter 2.39?

Also, could you pretty please try~
after render steps: flush and wait|sleep
after last step: flush
after backbuffer: don't flush
before present: don't flush
after present: don't flush

Mark_A_W

9th June 2010, 10:54

(1) GPU: ATI 2600XT
(2) OS: Windows XP
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display resolution + refresh rate: 1920x1080, 24.976 with PowerStrip (I DO NOT use reclock!)
(5) Single monitor setup
(6) MPC Homecinema
(7) Video decoder: ffdshow (AVC: libavcodec, VC1: wmv9)
(8) madVR 0.17

Finally, for the first time with madVR, with the default flush options, I have playback without tearing, zero dropped frames and perfect smooth !!!!

http://img535.imageshack.us/img535/7676/dibujoacb.th.jpg (http://img535.imageshack.us/i/dibujoacb.jpg/)

Some minor observations:
- With "don´t flush" for all the items I have the same good behaviour.
- VSFilter 2.39 do not work. I manage the subtitles with ffdshow perfectly (There is any version of VSFilter that works? thank you).

I think that madVR will be now my default video renderer. Before madflac the only way to achieve smooth and free tearing playback was EVR Custom Pres with
D3D Fullscreen. Now with madVR and SoftCubic100 for Chroma resampling (fortunately I don´t need luma up or downsampling), I have an image much, much better.
And all of them with my "old" ATI 2600XT (I don´t need to change the graphic card!!).

Great Madshi. People like you are very good people (madflac, eac3to, madVR,...).

:thanks::thanks::thanks:

Directvobsub (vsfilter) v2.39 works fine for me. That's what I used to do the couple of small screenshots I did yesterday.

And my HD2600XT works fine for me too, as long as I don't enable the 3DLUT.

djsolidsnake86

9th June 2010, 11:50

0.17: there is a problem with some wmv files, the playback don't start and the screen remain black with no audio
this problem was explained pages ago by another user

with other renderers these wmv works!

namaiki

9th June 2010, 13:35

pie1394

9th June 2010, 14:19

pie1394: in short, how is playback with with the exact following combination?
after render steps: flush and wait|sleep
after last step: flush
after backbuffer: don't flush
before present: don't flush
after present: don't flush

Also, maybe try reclock, but disable reclock's own vsync correction.

With the settings you mentioned, it does not produce any difference at 23.976 Hz.
But it gets tiering at the same place with 59.94 Hz.

So the setting at "after render steps: flush" still works better at 59.94 Hz.

If we compare madVR 0.17 with EVR-CP at 23.976 Hz, EVR-CP is actually worse than madVR. It always gets 2 tierings at near 1/4 and 3/4 vertical positions. Yet the tiering disappers with EVR-CP at 23.976 Hz if "Alternative VSync" is ON and "Flush GPU after Present" is OFF.

With EVR Sync mode, it never has tearing issue on my systems regardless of refresh rate.

6233638

9th June 2010, 15:21

After extensive testing:

flush
sleep
flush
dont
dont

is still the best performer by far for me. Changing the second flush to dont is smoother when using upsampling the gpu can't handle, but you never want to use that anyway as it is not smooth.

madshi

9th June 2010, 15:40

In fact, we speak about Aero, but in fact, I think the only thing it does is activate V-Sync from drivers. But there are bugs and V-sync is sometimes disable without noticeable reason. So, if you use Direct3D, you'll be able to activate V-Sync by this method, and we'll be still able not to use Aero.
I've already said that I plan to write rendering paths for both Aero and exclusive mode. So you will be able to pick what works best for you.

Am I understanding it correctly that if we have a missed/dropped or repeated frame we will see stutter? It will be great if we can measure it - "missed/dropped" frames in the last 5 seconds (didn't make it to the screen - to be shown) and "repeated" (or it's more accurate to say - missed vsync at which a new frame should have been presented) frames in the last 5 seconds (stayed too long on screen).
I can't measure "repeated" frames because that's not the way madVR currently works. Currently madVR simply calculates the best vsync at which each frame should be shown. Whether that produces repeated frames or not does not bother madVR. It's your responsibility to set display refresh rate to a multiply of the source frame rate, then madVR will not produce repeated frames.

The next madVR version will have two other new error indicators in the OSD, though.

I understand, but seriously, there isn't any other real solution to that "issue"? This renderer wants something more than YV12 ;)
The reason why I want YV12 is because madVR can convert YV12 to RGB better than any other HTPC software/hardware out there (AFAIK). Less is more in this case. You want to feed madVR more than YV12? Then tell me one common source format which (in its native form) has more than YV12. I don't know any. DVD, Blu-Ray, SD PAL broadcasts, SD NTSC broadcasts, HD PAL broadcasts, HD ATSC broadcasts - they are all native YCbCr 4:2:0.

As I said multiple times now, I haven't even started to look into subtitles yet. So there's nothing I can say about it right now. Please have a little bit of patience...

Finally, for the first time with madVR, with the default flush options, I have playback without tearing, zero dropped frames and perfect smooth !!!!
Great!

VSFilter 2.39 do not work. I manage the subtitles with ffdshow perfectly (There is any version of VSFilter that works? thank you).
I think the MPC-HC one works.

I thought I would do that right away, play a movie w/ the 0.17 debug version, wait for hiccuping to occur after 45/60 mins and you'd see whether it's due to another bug...
Please wait for 0.18.

Any chance you could possibly allow to change the log file location please?
I think if we can get the problem fixed after seeking, it will also be gone after 45/60 min of runtime.

0.17: there is a problem with some wmv files, the playback don't start and the screen remain black with no audio
As always in such cases, I need samples, and I need to know which decoder and which splitter you're using.

pie1394

9th June 2010, 16:37

The reason why I want YV12 is because madVR can convert YV12 to RGB better than any other HTPC software/hardware out there (AFAIK). Less is more in this case. You want to feed madVR more than YV12? Then tell me one common source format which (in its native form) has more than YV12. I don't know any. DVD, Blu-Ray, SD PAL broadcasts, SD NTSC broadcasts, HD PAL broadcasts, HD ATSC broadcasts - they are all native YCbCr 4:2:0.

It looks like NV12 is preferred in modern optimized DXVA MPEG Decoder engine design rather than YV12 / I420 for the video output.

It is very simple reason to do that -- Increase the HW processing throughput on sub-sampled Chroma colors. Paired sub-sampled U/V pixels always share the same motion vector. So the Chroma motion compensation can be considered as 16x8 per macroblock for 1MV mode, 8x4 for 4MV mode. If the HW design does not have the row stride cache, it will save some memory bandwidth, too.

For 128-bit 1D processing engine, it often processes 8 pixels in a row. So U/V interleaved NV12 in a 16x16 macroblock will achieve the similar throughput as Y component on the same engine.

For 256-bit 2D processing engine, it even has better throughput on processing NV12 4x4-tiled-planar images.

For YUY2 / UYVY 4:2:2 mode's alpha-blending to composite OSD image, NV12 is often better, too.

But I admit it is more efficient to use Y / U / V planar images of YV12/I420 modes for image scaling operation. This is for both 1D and 2D vector processors.

For RGBA / UYVA 4:4:4 OSD alpha-blending, I think planar / packed video image input does not produce much difference. The cost memory bandwidth is equal. The extra needed instructions to perform permutations are not much for 1D VP, and almost none for 2D VP.

dukey

9th June 2010, 16:46

Can madVR work with the microsoft dvd navigator under vista/7 ?

STaRGaZeR

9th June 2010, 17:24

I already said, it's a bluray rip.

Done with AnotherEac3toGui (which uses BDsup2sub).

You can always OCR them. You captures are VobSub subtitles, not text subtitles, it's normal that you don't see these issues.

The reason why I want YV12 is because madVR can convert YV12 to RGB better than any other HTPC software/hardware out there (AFAIK). Less is more in this case. You want to feed madVR more than YV12? Then tell me one common source format which (in its native form) has more than YV12. I don't know any. DVD, Blu-Ray, SD PAL broadcasts, SD NTSC broadcasts, HD PAL broadcasts, HD ATSC broadcasts - they are all native YCbCr 4:2:0.

It has to be common? Any video game capture (with Fraps) can be RGB32, difference is huge. Subtitles really need (http://forum.doom9.org/showpost.php?p=1406430&postcount=3076) RGB. Even if you manage to create a subtitle pin so MPC's renderer can work with madVR, people still use ffdshow or VSFilter. One reason, because they work in any player, another reason is that MPC blurs the subs by default and you can't turn it off.

I agree that native YCbCr 4:2:2 is very hard to find/need, but RGB32 is a must in my book for the above reasons. I don't know about DirectShow, but if a video decoder can output YV12 and RGB32 for example, can't you force it to YV12 supposing madVR accepts both? And if another decoder can only output RGB32, accept RGB32?

madshi

9th June 2010, 17:39

It looks like NV12 is preferred in modern optimized DXVA MPEG Decoder engine design rather than YV12 / I420 for the video output.
Yeah. If I ever do anything DXVA like, I'll most likely have to use NV12, too.

Even if you manage to create a subtitle pin so MPC's renderer can work with madVR, people still use ffdshow or VSFilter. One reason, because they work in any player, another reason is that MPC blurs the subs by default and you can't turn it off.
How often do I have to repeat that I haven't even started looking into subtitles yet? This is my last post on this for now.

I agree that native YCbCr 4:2:2 is very hard to find/need, but RGB32 is a must in my book for the above reasons.
So you value subtitle quality higher than quality of the video image itself? I think that's a rather rare point of view.

I don't know about DirectShow, but if a video decoder can output YV12 and RGB32 for example, can't you force it to YV12 supposing madVR accepts both?
Some maybe, but not all.

madshi

9th June 2010, 17:58

madVR 0.18 released

http://madshi.net/madVR.zip

* fixed: bug in "anti synchronized judder" code
* fixed: backbuffers weren't properly invalidated after a frame drop
* fixed: a media player exit crash cause
* improved "flush (sleep)"
* added option "don't render right before presentation"
* officially reintroduced support for "delayed frames"
* added "delayed frames" information to OSD
* added "presentation glitches" information to OSD
* dithering is done by using shader math now, instead of texture access
* removed "flush before present" option
I had high hopes for the new option "don't render right before presentation" to improve windowed mode playback (less dropped frames). But it doesn't really work for me. Still, I thought I'll let you guys try. Does anybody see an improvement when using this option? I rather don't expect that, so I'll likely remove that option again in a future build. But if many of you find that this option is really helpful, I might keep it.

I've improved the "flush & wait (sleep)" code. All of you who were using "flush & wait (loop)", can you please try whether the "sleep" version now works just as well for you with madVR 0.18? I hope so, because then I can remove the "loop" option. Every option I can delete makes the settings dialog easier to understand...

I've reintroduced the concept of "delayed frames". That means that if your display refresh rate is higher than the movie frame rate, and if madVR doesn't manage to show a video frame in time, madVR will simply show it a bit later, but doesn't drop it (unless it's absolutely necessary). This should reduce the stuttering a little bit.

When reimplementing the logic for delayed frames, I noticed that madVR actually was already sometimes showing delayed frames, without noticing. So that explains why some people saw motion stuttering, although the OSD didn't show any problems. I think with 0.18 this problem should be gone now: Whenever you see a stutter, the OSD should show either delayed or dropped frames now (I hope). I've also added a "presentation glitch" statistic to the OSD, but I've never seen it going to any value other than 0 yet. Probably this kind of glitch simply doesn't occur (?).

@leeperry, please test for the stuttering after a seek. If it's still there, please create a new log.

@JarrettH, I need a new log for the FS <-> windowed switching lag from you with 0.18. Still not sure where the problem is coming from. Have added some more logging output to 0.18.

Thunderbolt8

9th June 2010, 18:05

thanks!

Im getting few dropped and delayed frames at playback of some higher bitrate BD stuff. approx like ~1 dropped and 10-15 delayed frames per minute in some more or less regular amount of time. madVR settings are all default. dont ask me whether it was the same with the last builds and I just didnt notice.

win xp pro sp3
aero?
radeon HD 4770
1920x1080 24fps movie @1680x1050 60Hz monitor.

edit: nvm, got better now. had ffdshow sharpening activated which must have used additional power. with deactivating, I get way less dropped and delayed frames.

JarrettH

9th June 2010, 18:42

Well I can't reproduce that epic switching lag even when I use alt+enter. I think you squashed whatever bug I had madshi :D
Seeking seems to be better too. Also with the previous version I noticed in the ffdshow OSD Video Delay would sometimes shoot up into the 130,000ms which I can't reproduce anymore either. I haven't changed your flushing defaults for 0.18. I'll still keep my eye on all this stuff. :cool:

This isn't new, but I've always been able to see the video being scaled to keep its aspect ratio when I enter fullscreen. Do you want a log even if I can't reproduce it?

Thanks madshi!!! :devil:

6233638

9th June 2010, 18:50

"don't render right before presentation" kills performance. Without it bicubic75 chroma is 100% smooth.
Turning it on looks like it drops average render times but starts delaying frames and the max stats go too high even though average is fine.

flush, sleep, flush, dont still works best.

FS/Window switching still taking 3+ frames.

FS>Windowed:
1) Black
2) Wrong aspect image
3) Aspect fixed
4) OSD position fix

Window>FS:
1) Wrong aspect image
2) Aspect fixed
3) OSD Position fix

namaiki

9th June 2010, 18:57

madshi

9th June 2010, 18:58

Well I can't reproduce that epic switching lag even when I use alt+enter. I think you squashed whatever bug I had madshi :D
Seeking seems to be better too. Also with the previous version I noticed in the ffdshow OSD Video Delay would sometimes shoot up into the 130,000ms which I can't reproduce anymore either.
Weird. I have no explanation for any of that!

This isn't new, but I've always been able to see the video being scaled to keep its aspect ratio when I enter fullscreen. Do you want a log even if I can't reproduce it?
No, that's a cosmetic thing I'm not bothering with right now. More important things to do...

6233638

9th June 2010, 19:12

6233638: Not sure if I asked you (I did ask a number of users), but how are the following settings for you? (ie no change, stutter, tearing etc)

after render steps: flush and wait|sleep
after last step: flush
after backbuffer: don't flush
after present: don't flush
Worse performance.

Testing Lanczos3 (too much for my gpu) and sleep/flush/dont/dont with a clip I get:
62 Dropped/306 Delayed

With flush/sleep/flush/dont I get:
38 Dropped/285 Delayed

Your settings also break render time stats. It is a more consistent stutter with your settings though.

With yours its just stutter, stutter, stutter, stutter.
With mine its stutter, smooth, stutter, smooth.

With bicubic75 which runs smooth your settings seem ok, no delayed frames/glitches.

But render times are:
Average: ? + 12ms
Max: ? + 26ms

Render times with mine are:
Average: 20ms
Max: 30ms

Don't know what the ?ms is, but if its a consistent number your settings possibly have worse max times. (+14ms instead of +10ms)

namaiki

9th June 2010, 19:19

Thanks for the feedback. I don't usually look at the OSD as I think it hurts performance a bit.

At least it's smooth when you have your normal scaling settings though.

If you get a chance, could you please test sleep/flush/flush/don't with lanczos3?

for me, "don't render right before presentation" doesn't seem to make any difference, but 6233638 has written that it 'kills performance'
edit: reading 6233638's response below, what I meant is all is not well.

XPC

9th June 2010, 19:48

Hi Madshi,

I started testing Madvr on MPC-HC some weeks ago and I have to say that the image quality I get on my JVC HD350 projector is really impressive. Unfortunately when using for DVB-t live TV (from MPC-HC) I only get sound, but the screen remains black. If I record a ts file and then play it back it works fine.

I 'm using ffdshow (Yadif deinterlacing and YV12 output) for SD and CoreAvc for HD and I'm getting the same results for both. This configuration is the one I use with EVR sync renderer and works fine.

I tried in two different systems:

Windows 7 64 bits/ i7 processor / nvidia GTS 250 (I tried several drivers with the same result)

Windows 7 32 bits / Core Quad processor / intel G45 graphics

Any ideas on what could be the problem?

XPC

6233638

9th June 2010, 19:50

If you get a chance, could you please test sleep/flush/flush/don't with lanczos3?
54/316. Better dropped, worse delayed. Still worse than flush/sleep/flush/dont.

for me, "don't render right before presentation" doesn't seem to make any difference, but 6233638 has written that it 'kills performance'
bicubic75 has been 100% smooth for me recently, with this option enabled average render time drops, max goes up and I start getting delayed frames.

djsolidsnake86

9th June 2010, 20:10

madshi the video filter that i use for wmv files is this
Filter : WMVideo Decoder DMO - CLSID : {94297043-BD82-4DFD-B0DE-8177739C6D20}

- Connected to:

CLSID: {187463A0-5BB7-11D3-ACBE-0080C75E246E}
Filter: C:\Users\Andy\Desktop\Nuova cartella\06.wmv
Pin: Raw Video 1

- Connection media type:

Video: Windows Media Video 9 320x240 25.00fps 512kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {33564D57-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 92

VIDEOINFOHEADER:
rcSource: (0,0)-(320,240)
rcTarget: (0,0)-(320,240)
dwBitRate: 512000
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 44
biWidth: 320
biHeight: 240
biPlanes: 1
biBitCount: 24
biCompression: WMV3
biSizeImage: 230400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 40 01 00 00 f0 00 00 00 ........@...ð...
0010: 00 00 00 00 00 00 00 00 40 01 00 00 f0 00 00 00 ........@...ð...
0020: 00 d0 07 00 00 00 00 00 80 1a 06 00 00 00 00 00 .Ð......€.......
0030: 2c 00 00 00 40 01 00 00 f0 00 00 00 01 00 18 00 ,...@...ð.......
0040: 57 4d 56 33 00 84 03 00 00 00 00 00 00 00 00 00 WMV3.„..........
0050: 00 00 00 00 00 00 00 00|4c 89 1a 01 ........L‰..

- Enumerated media type 0:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31564D57-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 1:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {32564D57-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 2:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {33564D57-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 3:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {41564D57-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 4:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 5:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {50564D57-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

- Enumerated media type 6:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {32505657-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0

all my wmv with these don't play, black screen and no audio
can you try with these filter, madvr, and latest mpc svn? see if do you have my problem
if you need i'll send a short wmv video, also try with yours ;)

madshi

9th June 2010, 20:15

I started testing Madvr on MPC-HC some weeks ago and I have to say that the image quality I get on my JVC HD350 projector is really impressive. Unfortunately when using for DVB-t live TV (from MPC-HC) I only get sound, but the screen remains black. If I record a ts file and then play it back it works fine.
Is there any easy way for me to reproduce the problem? If not, you can try making (and uploading somewhere, but don't attach to this forum) a log with the [debug] build. Maybe I can see something in the log. Or maybe not...

madshi the video filter that i use for wmv files is this
Filter : WMVideo Decoder DMO - CLSID : {94297043-BD82-4DFD-B0DE-8177739C6D20}

all my wmv with these don't play, black screen and no audio
can you try with these filter, madvr, and latest mpc svn? see if do you have my problem
if you need i'll send a short wmv video, also try with yours ;)
I've tried about 20 WMV files (all I had) and they all play fine for me with the WMVideo Decoder DMO. So I'll need a sample with which I can reproduce the problem.

djsolidsnake86

9th June 2010, 20:20

http://web.tiscali.it/djsolidsnake86/Servizio.wmv

ok here the sample ;)

yes, win 7 64bit i use

XPC

9th June 2010, 20:21

Is there any easy way for me to reproduce the problem? If not, you can try making (and uploading somewhere, but don't attach to this forum) a log with the [debug] build. Maybe I can see something in the log. Or maybe not...

If you have DVB-t tuner card is very easy, otherwise I will follow your instructions and upload the log at mediafire...

nlnl

9th June 2010, 21:04

Mpc HC (Haali mkv splitter, CoreAVC, WMVideo Decoder DMO) + ATI 5400 (10.5) + Vista 32 + Aero on + 0.18 + monitor 1080p@23, 24, 50 (single)

1) Madvr default settings
Playing 1080p23;24 files (no resizing)
Very smooth. Sometimes it does not even drop or delay frames after seeking or audio track switching!

2)Playing 720p50 file (720 -> 1080 resizing).
Smooth playback only if Luma upscaling = Bicubic 75, Chroma upsampling= Softcubic100 (weak videocard ATI 5400)

3) Playing 720p25 file (720 -> 1080 resizing).
Smooth playback even if Luma upscaling = Spline 64, Chroma upsampling= Spline 64

Thank you Madshi!

madshi

9th June 2010, 21:30

ok here the sample ;)

yes, win 7 64bit i use
I've tried to reproduce it with the same decoder/splitter you're using, on both XPSP3 and Vista x64, but it works on both for me. Haven't had a chance to test win7 yet, though.

Can anybody reproduce this problem? On XPSP3 or Vista x64? Or only on win7?

If you have DVB-t tuner card is very easy, otherwise I will follow your instructions and upload the log at mediafire...
I don't have a DVT-T tuner.

XPC

9th June 2010, 21:59

Madshi,

Here you have the log file using SD TV life broadcast.

http://www.mediafire.com/download.php?ntta5xzylk5

Please let me know if you need more information.

XPC

cyberbeing

9th June 2010, 22:12

Hmm... Something seems broken with your re-added delayed frame logic.

Playing back a 1920x1080 24fps video at 1920x1080 @120Hz, I'm getting a delayed frame almost exactly every second. 10 seconds = 10 delayed frames. 500 seconds = 500 delayed frames. Etc. Same thing happens no matter what flush settings I use, 3DLut enabled/disabled, dithering enabled/disabled, etc.

The problem occurs with numerous other resolutions above 1920x1080, including 2048x1152 @96Hz & 2560x1440 @72Hz.

The problem does not occur with numerous other resolutions below 1920x1080, including 1600x1200 @96Hz, 1600x900 @120Hz, or 1280x720 @120Hz.

I conclude that it is only happening when 1080p video is being displayed at 1920x1080 or above display resolution. When 1080p video is downscaled to a lower display resolution, the problem does not happen, even with high refresh rates.
__________________________________________________
Debug logs with constant Delayed Frames
http://www.mediafire.com/?ztzd2mlziij

The sample is a 53 second 1080p video. If windowed mode was downscaling, I went to full screen during the first second of the video. If windowed mode showed the full frame I didn't go to full screen.

Includes 2560x1440 @72Hz, 2048x1536 @72Hz, 2048x1152 @96Hz, and 1920x1080 @120Hz.
__________________________________________________
Debug logs WITHOUT Delayed Frames for reference
http://www.mediafire.com/?memgttzdnzm

The sample is a 53 second 1080p video. All were resized to fullscreen during the first second of the video.

Includes 1600x1200 @96Hz, 1600x900 @120Hz, 1280x720 @168Hz, 1280x720 @120Hz.
__________________________________________________

Windows XP SP3 x86
AMD X2 4800+ (939) @2.64Ghz (220Mhz x12)
2GB DDR400 @ 440Mhz 2-3-3-6 (1:1 ratio with CPU)
NVIDIA GTX 470 (PCI-E 1.0 w/ x8 link)
CRT Monitor
MPC-HC
__________________________________________________

Until this is fixed, I'm going to hold off on testing your 0.18 improvements, since this bug may skew the results.

madshi

9th June 2010, 22:13

Here you have the log file using SD TV life broadcast.
Wow, that is weird. It seems that two madVR instances are created after each other, and then one of them is deleted again, while the other one stays active. madVR currently does not expect/support such a behaviour. As a result the surviving madVR instance refuses to display anything in your situation. I'll have to change some things to support having multiple madVR instances running at the same time. <Argh>

madshi

9th June 2010, 22:22

Hmm... Something seems broken with your re-added delayed frame logic.

Playing back a 1920x1080 24fps video at 1920x1080 @120Hz, I'm getting a delayed frame almost exactly every second. 10 seconds = 10 delayed frames. 500 seconds = 500 delayed frames. Etc. Same thing happens no matter what flush settings I use, 3DLut enabled/disabled, dithering enabled/disabled, etc.

The problem occurs with numerous other resolutions above 1920x1080, including 2048x1152 @96Hz & 2560x1440 @72Hz.

The problem does not occur with numerous other resolutions below 1920x1080, including 1600x1200 @96Hz, 1600x900 @120Hz, or 1280x720 @120Hz.

I conclude that it is only happening when 1080p video is being displayed at 1920x1080 or above display resolution. When 1080p video is downscaled to a lower display resolution, the problem does not happen, even with high refresh rates.
Hmmmm... Thanks for the logs, I'll look into them later.

Until this is fixed, I'm going to hold off on testing your 0.18 improvements, since this bug may skew the results.
Could you at least compare 0.17 to 0.18 with identical settings? As I explained in the 0.18 release post, even 0.17 already (silently) sometimes showed delayed frames. So it's quite possible that 0.17 behaved exactly the same way for you as 0.18 does, just without the OSD information. What is your *subjective* impression about motion smoothness. Is it comparable to 0.17 or did it actually get worse? Do you actually see the delayed frames with 0.18 (and not with 0.17)?

XPC

9th June 2010, 22:38

Wow, that is weird. It seems that two madVR instances are created after each other, and then one of them is deleted again, while the other one stays active. madVR currently does not expect/support such a behaviour. As a result the surviving madVR instance refuses to display anything in your situation. I'll have to change some things to support having multiple madVR instances running at the same time. <Argh>

The graph is created using multiple video decoder instances (one for MPEG2, another for H.264,...) to allow switching channels without having to rebuild the whole graph. I was not aware that multiple renderer instances were running at the same time.

vucloutr

9th June 2010, 22:44

sys specs: Server2008x86,GF8200@500MHz(8SP),Aero off,Haali 1.10.175.0,CoreAVC 2.0 (software)
clip used: 1280x720 4,5Mbps => windowed => target rectangle 0,2,1272,718

flush & wait (sleep) has improved. it was ~3ms slower with flushing defaults than flush & wait (loop). now it's mostly 0-1ms slower.

no flushing is bad. flushing at any point except for don't flush,don't flush,don't flush,flush does good.
where it's flush > flush & wait (sleep|loop) > don't flush. generally more flushing doesn't hurt but flush & wait (sleep|loop) eats too much performance if used more than once.
(flush,flush & wait (sleep),flush,flush is fine for example)

don't render right before presentation does from mostly nothing to introduces stuttering and delayed frames in heavy GPU load situations.

my subjective favourite setting is flush,flush,flush,don't flush with don't render right before presentation off.

PS: i notice very slight stuttering with any settings which is not recognized by madVR's statistics, neither dropped nor delayed frames. EVR and HVR suffer under this too. i think it's the same with what other members describe with stuttering. imho the real cause is somewhere else but trying to find it would be like trying to find a needle in a haystack. :rolleyes: