madVR - high quality video renderer (GPU assisted)

[nevcairiel]

Originally Posted by madshi

Didn't check that. Which FourCC does the AVI splitter output?

Typically its MEDIASUBTYPE_H264, stored in AnnexB format. Some splitters (LAV Splitter specifically) convert it to MEDIASUBTYPE_AVC1, removing the AnnexB start codes.
Note that the typical AVI splitters use FORMAT_VideoInfo and do not have the SPS/PPS in the format block (as defined by MSDN, if using MEDIASUBTYPE_H264 with start codes, you do not have to supply the extradata)

The most important part about H264 in AVI is however that the timestamps are DTS, not PTS, therefor you shall not reorder them.

[madshi]

Ah ok, thanks for the heads up!

@Hypernova, which AVI Splitter are you using?

[Hypernova]

Originally Posted by madshi

Didn't check that. Which FourCC does the AVI splitter output? Does madVR even try to decode it (and fail)? Or does an external decoder take over?

It's H264. I am not sure how to find out the answer for the other two questions. I don't see any indication that madVR tried and failed though. I use Haali by the way.

Now that you mentioned FourCC. It's probably because H264 vs AVC1? I do not have h264 in avi that use AVC1 so I cannot be so sure.

Edit: Ah, looks like you and nevcairiel already figure it out

[madshi]

Originally Posted by Hypernova

It's H264. I am not sure how to find out the answer for the other two questions. I don't see any indication that madVR tried and failed though. I use Haali by the way.

So is there some h264 decoder filter in your filter list, when playing back AVI h264 files? Probably is, because madVR doesn't support the "h264" FourCC yet. Which decoder filter are you using? Does the seek crash occur with every h264 AVI file you have?

[Hypernova]

Originally Posted by madshi

So is there some h264 decoder filter in your filter list, when playing back AVI h264 files? Probably is, because madVR doesn't support the "h264" FourCC yet. Which decoder filter are you using? Does the seek crash occur with every h264 AVI file you have?

Yes, basically it fall back to ffdshow.

No it only crash on some files. That's why I kinda reluctant to report the crash by itself. I even suspect it's just a bad muxing somehow. If you still have the sample I uploaded before (http://www.mediafire.com/?9jf19139i6e0uh2) that was a part of one of the files that do crash. The strange thing is, that small sample does not crash every time I seek (unlike the original file), but take a long time to seek. And once in a while will crash MPC-HC.

Also, this looks like it has nothing to do with internal codec. I switched back to external ffdshow and it still crash. I'm certain that 0.67 does not crash. If you need to know if 0.68/0.69 crash on these files or not please let me know. TBH though I think this is a rare occasion so I'm exactly bother by it.

I tried checking the "delay playback..." and it does not help.

[agustin9]

Originally Posted by madshi

This doesn't seem to happen on my PC. Can anybody else reproduce this? A log might help. Try to keep it short, by doing this:

Start the video, go exclusive mode, pause, wait 2-3 seconds, unpause, wait until playback is fluid again, close the media player. Don't do anything else. Every action you take makes the log longer. Thanks.

Here is the log:
http://www.megaupload.com/?d=Q38MCKDT

Thanks for your hard work

[adam777]

Hi madshi,
Thanks as always for the hard work.
Just a quick one - are the internal decoders multi-threaded? couldn't find a reference.

[Hypernova]

madshi, subtitile disappeared when paused again..

[cyberbeing]

Originally Posted by Hypernova

AVI
...
I use Haali by the way.

Both the Haali AVI splitter (which is why it's disabled by default in the installer) and the Gabest/MPC-HC AVI splitter (no support for incomplete files?) have some bugs and limitations from what I remember. In general you should stick with the default Microsoft AVI Splitter, unless you have a particular reason to use something different. This could have nothing to do with your current problem of course.

[pirlouy]

Originally Posted by adam777

Just a quick one - are the internal decoders multi-threaded? couldn't find a reference.

Yes; confirmed by Madshi recently (in last pages of this thread)

[madshi]

Originally Posted by Hypernova

No it only crash on some files. That's why I kinda reluctant to report the crash by itself.

Originally Posted by agustin9

Here is the log:
http://www.megaupload.com/?d=Q38MCKDT

Originally Posted by cyberbeing

madshi, I just checked and there does appear to be a regression after madVR 0.66 with encrypted DVDs and the NVIDIA PureVideo Software decoder on Windows XP. madVR 0.67 has corruption. madVR 0.68-0.70 all crash the decoder.

Can the 3 of you please test whether these 3 problems are fixed in this special build?

http://madshi.net/madVR70special.zip

Originally Posted by adam777

Just a quick one - are the internal decoders multi-threaded?

Yes.

Originally Posted by Hypernova

madshi, subtitile disappeared when paused again..

Confirmed. <sigh> Will try to fix this again for the next build.

[adam777]

Thanks

[Blight]

madshi:

The good:
1. OSD flickering on pause/unpause is fixed.
2. The graph no longer pauses when switching to fullscreen on a second monitor.

The bad:
1. There's a lag of ~1 second between the time I call an OSD display function and the time the OSD appears on screen. You can clearly see it by playing in windowed mode and pressing space to show the control bar. You can see the difference in the time displayed in the control bar and the time displayed in the window. This is not such an issue when dealing with the limited OSD I've integrated, but it may prevent large scale OSD (like a menu system) from being responsive.
2. Alt+Enter is still causing issues. If I disable all my keyboard event handling, Alt+Enter is still doing something weird when MadVR is used. Are you familiar with a tool that will help me track the keyboard hook and find which module is causing this?

Feature Request:
Not really critical, but it may be 'nice to have' an additional OSD parameter that controls the alpha value of the entire OSD, for example, If I wanted to make the OSD dynamically translucent.

[cyberbeing]

Originally Posted by madshi

Can the 3 of you please test whether these 3 problems are fixed in this special build?

http://madshi.net/madVR70special.zip

Still crashes. Log: http://www.mediafire.com/?9k1y9goypb10fo6

[madshi]

Originally Posted by Blight

1. There's a lag of ~1 second between the time I call an OSD display function and the time the OSD appears on screen. You can clearly see it by playing in windowed mode and pressing space to show the control bar. You can see the difference in the time displayed in the control bar and the time displayed in the window. This is not such an issue when dealing with the limited OSD I've integrated, but it may prevent large scale OSD (like a menu system) from being responsive.

But in paused state the OSD reacts much faster, correct?

The problem is that I have to balance what is more important: (1) Smooth playback with no frame drops? Or (2) fast reacting OSD? Of course I could force a redraw of the next displayed frame to already include your modified OSD image, but that would require me to trash all pre-rendered frames (practically clear the rendering and backbuffer queues completely) and redo all the rendering work. I fear this might introduce a few frame drops once in a while. Maybe a compromise would make sense? E.g. instead of fully flushing the rendering queue, maybe I could only flush half of it? Or something like that? It's really not a problem getting the OSD to become quick. The only problem is that doing so might result in frame drops whenever the OSD changes...

Originally Posted by Blight

2. Alt+Enter is still causing issues. If I disable all my keyboard event handling, Alt+Enter is still doing something weird when MadVR is used. Are you familiar with a tool that will help me track the keyboard hook and find which module is causing this?

If only I could reproduce the problem! It works just fine on my PC, with ZP, too! I can do Alt+Enter with ZP8RC3 all day here without any problems.

Originally Posted by Blight

Feature Request:
Not really critical, but it may be 'nice to have' an additional OSD parameter that controls the alpha value of the entire OSD, for example, If I wanted to make the OSD dynamically translucent.

I wish you would have had this idea before I finalized the OSD interface! I don't want to break compatability now. My suggestion would be that you change from color keying to full alpha channels. It's not that hard to do (not in Delphi, either), and would allow you to do whatever you want, per pixel.

Originally Posted by cyberbeing

Still crashes.

Argh. Ok, here's the next try:

http://madshi.net/madVR70special2.zip

It will probably still crash (I guess), but if you can create another log, that might tell me more. I've added some logging specific to this crash. FWIW, on my PC there's no crash, DVD playback with the NVidia PureVideo Decoder works just fine here.

[racerxnet]

Can the 3 of you please test whether these 3 problems are fixed in this special build?

I still cannot insert a DVD and have it play with the internal decoders or Nvidia decoders. Tried several different configurations with no luck. NVdec.ax fault nag after inserting disc with MPC-HC.

Special build .70
Win XP SP3
Nvidia decoders - No good
Arcsoft decoders - No good
Internal filters - No good

Thanks,

MAK

[agustin9]

Originally Posted by madshi

Can the 3 of you please test whether these 3 problems are fixed in this special build?

My pause problem is gone in both special versions! Thanks!

[Blight]

Originally Posted by madshi

But in paused state the OSD reacts much faster, correct?

I think so, but I'm not 100% certain, it's hard to tell.
You can see the update frequency is much slower than it should be (even when paused).

Holding the left mouse button over the timeline and dragging it left/right (which updates the timeline graphics very quickly).
What happens is that the player based UI updates multiple times per second and the MadVR OSD updates much slower.

I've ran a few tests and GPU-Z is reporting 5% GPU load, so I don't think that's the problem.
checking the task manager, the CPU gets maxed, but it gets maxed when doing these crazy seeks even without the OSD visible.

I also had one beta tester report decreased play smoothness when playing an 1080p clip at full resolution when the control bar is visible.

Originally Posted by madshi

The problem is that I have to balance what is more important: (1) Smooth playback with no frame drops? Or (2) fast reacting OSD? Of course I could force a redraw of the next displayed frame to already include your modified OSD image, but that would require me to trash all pre-rendered frames (practically clear the rendering and backbuffer queues completely) and redo all the rendering work. I fear this might introduce a few frame drops once in a while. Maybe a compromise would make sense? E.g. instead of fully flushing the rendering queue, maybe I could only flush half of it? Or something like that? It's really not a problem getting the OSD to become quick. The only problem is that doing so might result in frame drops whenever the OSD changes...

As it happens with seeks, doesn't the buffer get cleared instantly?
Perhaps it can be a parameter that passes with the OSD? For example, if I'm working with menus, I want them to be responsive and don't care (as much) if a frame in the background is dropped.

Originally Posted by madshi

If only I could reproduce the problem! It works just fine on my PC, with ZP, too! I can do Alt+Enter with ZP8RC3 all day here without any problems.

I created two log files.
What I've done is very simple:
1. I disabled ZP's keyboard handling entirely.
2. I opened a simple AVI+XVID+MP3 video file and paused it after 1-2 seconds.
3. With "madVR - log_alt-enter.txt", I pressed Alt-Enter and then Alt+F4.
With "madVR - log.txt", I simply closed the player through the GUI.

Since I disabled keyboard handling in ZP, the log files should be pretty much identical, but I suspect they're not.
See if you can possibly find the cause.

Originally Posted by madshi

I wish you would have had this idea before I finalized the OSD interface! I don't want to break compatability now. My suggestion would be that you change from color keying to full alpha channels. It's not that hard to do (not in Delphi, either), and would allow you to do whatever you want, per pixel.

I can, but it's probably much faster to do it with a Shader.
Is the OSD interface locked-down?, is something using it other than ZP at the moment?
If the answer is 'no' then it's ok to change as there's no public beta of ZP that's capable of using the interface.

[Gleb Egorych]

With 0.70 crashes on Zoom are back.

[cyberbeing]

Originally Posted by madshi

http://madshi.net/madVR70special2.zip

It will probably still crash (I guess), but if you can create another log, that might tell me more. I've added some logging specific to this crash. FWIW, on my PC there's no crash, DVD playback with the NVidia PureVideo Decoder works just fine here.

Yep it still crashes. As I mentioned previously, it only crashes with encrypted DVDs from the DVD drive. Unencrypted DVDs work fine from both the DVD drive and ripped to ISO. If you can't reproduce the crash, could you reproduce corruption problem (frame split half-way down vertically, distorted video on top, green bar on bottom) with 0.67?

0.70 Special2 MPC-HC Log: http://www.mediafire.com/?mxu7y9mkatr4ucz

Edit: Interestingly it works with a ZoomPlayer 7 Smart Graph if I leave it alone for a couple minutes:
0.70 Special2 Working ZoomPlayer Log: http://www.mediafire.com/?hbn7zo0bo96860u

Edit2: Or not... I tried it again and ZoomPlayer 7 hung:
0.70 Special2 Hung ZoomPlayer Log: http://www.mediafire.com/?lm1qsb9q338wmsu

Edit3: And then it worked again in ZoomPlayer, and then it hung again <_<. Since the media player seems to play a part (or more likely just graph building), are you using a special MPC-HC build?