madVR - high quality video renderer (GPU assisted)

[kasper93]

Originally Posted by madshi

I think it's probably when the seek bar *shows*, not hides?

You are right. I didn't wait till statistic update with open seekbar.

[BatKnight]

Originally Posted by madshi

I think it's probably when the seek bar *shows*, not hides?

Yes, it's when it shows (exclusive mode)... Didn't happen with older versions.

Another thing. I can't use D3D11 presentation mode, because when used together with MPC-HC's refresh rate changer, I can't get 24Hz. It stays at 60Hz. But without the D3D11 mode, it changes fine.
On the other hand, It works with your refresh rate changer inside madVR, but I miss the "change only when fullscreen" option. For example, I don't need the refresh rate to change when I'm at window mode, just previewing videos.
Would it be possible to add a "change refresh rate only when going fullscreen (or exclusive, whatever is easier for you)" option, please?

Thanks for understanding.

Nuno

[madshi]

Originally Posted by graeme

The easiest way to reproduce it is probably to install NextPVR, then file up GraphEdit, insert the 'NPVR TS Reader', select a sample .ts file, insert the MPEG2 Demultiplexer, connect the TS Reader to the Demux. Insert a video decoder (like ffdshow), connect the 'video' pin from the demux to the video decoder, then insert the madVR renderer, and connect teh video decoder to madVR. It'll crash at this point.

The cause of the crash is that your filter does implement "IFileSourceFilter" and "IFileSourceFilter.GetCurFile()" returns success, but the returned file name is NULL. madVR then crashes when later calling CoTaskMemFree() to properly release the file name. You can fix the crash by either returning a proper file name, or by letting GetCurFile() return an error, or by not supporting IFileSourceFilter. I'll add a check for a NULL file name to the next build. But I think you should implement the suggested change in your filter, anyway.

[graeme]

Originally Posted by madshi

The cause of the crash is that your filter does implement "IFileSourceFilter" and "IFileSourceFilter.GetCurFile()" returns success, but the returned file name is NULL. madVR then crashes when later calling CoTaskMemFree() to properly release the file name. You can fix the crash by either returning a proper file name, or by letting GetCurFile() return an error, or by not supporting IFileSourceFilter. I'll add a check for a NULL file name to the next build. But I think you should implement the suggested change in your filter, anyway.

Brilliant - thanks for this insight. I'll try this.

[madshi]

Originally Posted by Blight

Madshi:
Here's an updated log file. This time with MadVR 0.72 with MadVR's OSD visible (using ctrl+j).

Hmmmm... According to the log, the display mode changes and madVR switches from exclusive mode to windowed mode as a reaction of the display mode change. The display mode change was not initiated by madVR. I don't know who initiated it and why. Maybe you can find out?

Originally Posted by Blight

Are you calling WinAPI's "IsWindowVisible"? and are you checking the window's dimensions to see if they cover the MadVR window?
Cause what happens that exclusive mode is lost for a split second and then it re-activates. If the new window was problematic, wouldn't exclusive mode stay disabled?

Yes, I'm using IsWindowVisible and I'm also checking the window dimensions.

[madshi]

madVR v0.73 released

http://madshi.net/madVR.zip

* fixed (again): video playback in PotPlayer froze in various situations
* fixed: OSD changes could result in dropped frames (reverted to older code)
* fixed: crash if the source filter reported a NULL file name

I've decided to revert to an older OSD update code, which should fix the frame drops reported by some. However, that also restores the old (bad) OSD response times. Maybe I'll find a better overall solution for a future build.

Those of you who want to use the madVR internal decoders with MPC-HC, please update to build 3520 (or newer). That build allows you to set madVR to "preferred" in the external filter list, without losing the OSD and subtitle functionality.

[Nevilne]

I can confirm that potplayer freeze at start is fixed.

[joe42]

Originally Posted by madshi

Those of you who want to use the madVR internal decoders with MPC-HC, please update to build 3520 (or newer). That build allows you to set madVR to "preferred" in the external filter list, without losing the OSD and subtitle functionality.

Yes, thanks for the note. I tried MPC-HC 3538, with madVR external filter set to prefer, and OSD and subtitles worked properly.

[SoupRKnowva]

i dont even put madVR in the external decoders, i just turn off the internal decoders, and turn them on in madVR settings, and it works good.

why would it need to be in the external decoders list?

[nand chan]

Any approximate time frame on 10 bit output?

Edit: By the way, I wrote a small guide on how to properly set up MPC-HC + madVR (with madVR's internal decoders), in case you want to hotlink it anywhere: http://haruhichan.com/wpblog/?p=205#guide. A slightly older version of this guide can also be found on coalgirl's page.

[ryrynz]

Originally Posted by madshi

Hmmmmm... In that log there are so many seeks. One seek after 2.5 seconds of playback, then one after 3.5, another one after 5, another one after 6 seconds. That's not a good thing for a log, it makes the log very complicated and hard to read.

Yeah, I have to seek a few times for it to become noticeable, I wanted to make sure I captured the sync issue.

Originally Posted by madshi

Anyway, the whole problem does not occur with external decoders, correct? Can I have a small sample of the VOB file? Of course that would make sense only if the problem also occurs with the small sample. Which splitter are you using?

Originally Posted by madshi

P.S: The splitter seems to behave very weird. Most frames come to madVR without any timestamps, which make it hard for madVR to properly sync. Which exact splitter is that? Have you tried a different splitter?

Correct, there is no sync problem when I'm using ffdshow. Currently I'm using LAV splitter 0.31 and the issue seems limited to that splitter as Haali's splitter didn't produce the same issue.
I can reproduce it on any VOB file I have, hopefully you can too. It does sound like this report belongs in the LAV splitter thread instead, let me know if you'd like me to report there.

[nevcairiel]

If a file does not contain timestamps for all frames, LAV Splitter will not invent any. I leave it to the decoder to properly deal with it, and frankly, all external decoders are doing just fine with that.
If all external decoders work, and the internal doesnt, it must be the splitters problem, right?

[ice25]

Not sure if it's a bug, but in my setup Reclock isn't detecting the video stream fps with the internal decoders. Tested with internal MPC and Haali Splitter.

[ryrynz]

Originally Posted by nevcairiel

If a file does not contain timestamps for all frames, LAV Splitter will not invent any. I leave it to the decoder to properly deal with it, and frankly, all external decoders are doing just fine with that.
If all external decoders work, and the internal doesnt, it must be the splitters problem, right?

Gotta love Nevcairiel's sense of humor

[madshi]

Originally Posted by nevcairiel

If a file does not contain timestamps for all frames, LAV Splitter will not invent any. I leave it to the decoder to properly deal with it, and frankly, all external decoders are doing just fine with that.
If all external decoders work, and the internal doesnt, it must be the splitters problem, right?

In my log it seems that roughly only one out of a hundred video frames has a timestamp. That surely can't be right, can it? Of course if the external decoders have a problem and the internal ones don't, this points to the internal decoders. However, if the issue occurs only with LAV Splitter and not with any other splitter, then that points to the splitter. Probably it's a combination of the two somehow. Anyway, I'm wondering how I can do proper syncing if there are virtually not any timestamps available at all?

[nevcairiel]

As always, i cannot comment on files without a sample of such a file.
I have however seen MPEG-2 files with really terrible timestamping.

[ajp_anton]

Whoa. Never really understood the smoothness problem with 60Hz displays. But I just learned that my Macbook supports 48Hz. Meh, now I'll never be able to watch movies on my bigger 60Hz-only screens...

Feature request: Add an option to change the refresh rate only when going into (and out of) fullscreen mode.

When presenting lots of frames in advance, is it normal for the sound to be slightly out of sync (video comes too late)?

[pie1394]

Originally Posted by madshi

madVR v0.73 released

This version seems the most stable one in recent releases to me.

Originally Posted by madshi

Those of you who want to use the madVR internal decoders with MPC-HC, please update to build 3520 (or newer). That build allows you to set madVR to "preferred" in the external filter list, without losing the OSD and subtitle functionality.

About this I use the different approach.
Disable all other available video decoders in MPC-HC.
The MPC-HC internal ones must not be selected, either.

For my HTPC, LAVCUVID is still the preferred video decoder. Once a HW-unsupported H.264 video stream is opened, madVR internal video decoder is automatically used. (Due to the fact it is the only available choice to MPC-HC)

Currently I only found this method to play with the H.264 yuv420p10 contents correctly. With most other video decoders, the output colors are incorrect.

[rahzel]

Originally Posted by ice25

Not sure if it's a bug, but in my setup Reclock isn't detecting the video stream fps with the internal decoders. Tested with internal MPC and Haali Splitter.

I had the same problem with v0.72, also tested LAV Splitter. Had to use Divx H264, which is fine because it's slightly faster for my slower machine.

[Plutotype]

Originally Posted by rahzel

I had the same problem with v0.72, also tested LAV Splitter. Had to use Divx H264, which is fine because it's slightly faster for my slower machine.

same with 0.73 here
http://imageshack.us/f/38/madvrreclockfpsissue.png/