madVR - high quality video renderer (GPU assisted)

[e-t172]

I must admit, I'm a little skeptical about the decoder thing.

Having the decoder and renderer in one component defeats the whole purpose of DirectShow: its flexibility. I know madVR still accepts pre-decoded (raw) video, but still… I'm a big fan of the "Do one thing and do it well" principle, and this clearly contradicts it.

It's your software madshi, but I really wonder what made you integrate this into madVR instead of developing a standard DirectShow decoder filter like everyone else. What if someone wants to put a filter (e.g. IVTC) between the decoder and the renderer? Right now, with your decoder, he can't.

I'm really worried about where this is going. What's the next step? The splitter? The audio decoder/renderer? Will we end up with madPlayer, with everything conveniently locked in? "Sponsored by Apple"?

[madshi]

Originally Posted by noee

btw, I can't get the madVR int decoders to work at all with jrMC. If I choose ROHQ w/addl, it crashes on LaVsplitter, I assume because it can't find the video decoder. If I just use regular ROHQ, MC auto-configures for FFdshow. Should I just uninstall ffdshow?

I don't know how the graph building in MC16 works. You'll have to ask over at j.river forums about that. Or, if you just want to do some decoder testing, you could use MPC-HC and set ffdshow to "block".

Originally Posted by SamuriHL

They'll need to be whitelisted in MC16. Post over at J River and see if Matt can add them.

Not sure what consequences "whitelisting" in MC16 would have exactly. FWIW, I wouldn't recommend to use the madVR internal decoders as default yet.

[noee]

Originally Posted by SamuriHL

They'll need to be whitelisted in MC16. Post over at J River and see if Matt can add them.

If I'm understanding what madshi has done, his int decoders are not technically pure DS filters, so I don't think whitelisting in jrMC will matter, since MC is, if I understand correctly, is DS right down the line.

madshi, just fyi,
I've found bad stuttering with the internal decoders on my playback monitor if I have it set at 24Hz for 23.976fps material (w/Reclock). Also, MPC-HC shows that it's paused in the taskbar, but it actually playing back with heavy stuttering. Setting the monitor to 60Hz, there is no stuttering.

dual-mon with playback on the second monitor, using LAVSplitter.

[SamuriHL]

Originally Posted by madshi

I don't know how the graph building in MC16 works. You'll have to ask over at j.river forums about that. Or, if you just want to do some decoder testing, you could use MPC-HC and set ffdshow to "block".


Not sure what consequences "whitelisting" in MC16 would have exactly. FWIW, I wouldn't recommend to use the madVR internal decoders as default yet.

I wasn't suggesting they become default. Simply "allowed". If it's not whitelisted, you can't choose it to use at all.

[SamuriHL]

Originally Posted by noee

If I'm understanding what madshi has done, his int decoders are not technically pure DS filters, so I don't think whitelisting in jrMC will matter, since MC is, if I understand correctly, is DS right down the line.

Then they may not work in MC16 at all. MC16 requires you to define a splitter, decoder, and renderer. If madVR can't be selected as a decoder according to DS rules, then it probably won't work. Admittedly, I've not had a chance to even look at this yet so I don't know. In any case, I would talk to the JRiver devs and see what they think.

[madshi]

Originally Posted by SamuriHL

I wasn't suggesting they become default. Simply "allowed". If it's not whitelisted, you can't choose it to use at all.

Ah, didn't know that!

Originally Posted by noee

If I'm understanding what madshi has done, his int decoders are not technically pure DS filters, so I don't think whitelisting in jrMC will matter, since MC is, if I understand correctly, is DS right down the line.

From the view of the splitter, madVR behaves just like a DS decoder does. So there's no reason why it wouldn't work.

Originally Posted by noee

I've found bad stuttering with the internal decoders on my playback monitor if I have it set at 24Hz for 23.976fps material (w/Reclock). Also, MPC-HC shows that it's paused in the taskbar, but it actually playing back with heavy stuttering. Setting the monitor to 60Hz, there is no stuttering.

Yeah, currently the timestamps assigned to each frame are really bad. They jump back and forth. The old madVR timestamp auto repair fixes some of that, so sometimes you have smooth playback even though the decoder timestamps are garbage. But sometimes the fixes don't work. Anyway, these problems should be fixed once I implement a proper timestamp solution.

I've a bit confused that MPC-HC still shows "paused" state! What happens if you disable the new pre-buffer option. Does the incorrect paused state problem then still occur?

[noee]

Originally Posted by SamuriHL

...In any case, I would talk to the JRiver devs and see what they think.

Yup, I think Matt is gonna use the new api so he doesn't have to create a D3D device to get refresh rate (Excl mode issue), so, we'll see what happens when it gets stable.

madshi,
I've noticed that your internal filters may not be report fps upstream, at least Reclock isn't getting anything from the decoder. Perhaps this is related to the timestamp issue you mentioned above, so you probably already know about this....

Originally Posted by madshi

What happens if you disable the new pre-buffer option. Does the incorrect paused state problem then still occur?

Yes, with the option disabled, MPC shows "normal" playing state in the taskbar (I'm on Win7 ult x64).

[SamuriHL]

Originally Posted by madshi

Ah, didn't know that!


From the view of the splitter, madVR behaves just like a DS decoder does. So there's no reason why it wouldn't work.

Ok, so, in that case then if Matt whitelists them in MC16, you'll be able to select them as the decoder when you use ROHQ + additional. So that's good. We just need to get them to whitelist it. Shouldn't be hard.

[Skwelcha]

finally i can watch mpeg2 videos with madvr, nice update!

btw i dont have any startup or seeking delays like some people reported ?

[clsid]

I also prefer to have the decoder and renderer fully separated. I assume they are integrated now primarily because it greatly simplifies the colorspace handling? Perhaps you can join forces with nevcariel to create a full featured LAV Video decoder that can output high bitdepth colorspaces to madVR. It would be a waste to do things twice.

With regard to the buffering, perhaps it would better to have two options, one for buffering at start, and one for buffering after seeking. I think most people will prefer instant seeking, while a short delay at start is probably less of a problem.

[madshi]

Originally Posted by e-t172

Having the decoder and renderer in one component defeats the whole purpose of DirectShow: its flexibility. I know madVR still accepts pre-decoded (raw) video, but still… I'm a big fan of the "Do one thing and do it well" principle, and this clearly contradicts it.

It's your software madshi, but I really wonder what made you integrate this into madVR instead of developing a standard DirectShow decoder filter like everyone else. What if someone wants to put a filter (e.g. IVTC) between the decoder and the renderer? Right now, with your decoder, he can't.

Well, you make it sound as if I did something totally new. But actually, the usual DXVA logic already means that the renderer does the deinterlacing and is also involved with video decoding (providing D3D surfaces for decoding etc, at least it was this way with DXVA1, IIRC). So my approach isn't all that new.

Yeah, I could have written a full blown separate DirectShow decoder filter. But that would have cost me a *LOT* more time. Like 5x or maybe even 10x the time. It would have required a separate installer, a separate download, a separate configuration dialog. It would have required me to test the decoder will all sorts of downstream filters (post processing, other renderers). It would have been too big a job for me. And what would have been the benefit? You're mentioning an IVTC filter. Is there only one IVTC (or any other post processing filter) available today which supports more than 8bit? Nope. So post processing benefit = 0. Ok, one potential benefit would have been that a separate DS filter would have worked with other renderers, too. Haha, why should I want THAT?? Furthermore, other renderers don't support more than 8bit input, either. So again, no real benefit.

There's a good reason why I implemented the software decoders internally, which I'll explain sometime in the future. Maybe I should have kept the software decoders secret/hidden until I'm ready to reveal the whole plan. But then, I thought, why keeping back functionality? So I decided to make what I have now available, although it's in experimental state and only half of the final solution.

Originally Posted by e-t172

I'm really worried about where this is going. What's the next step? The splitter? The audio decoder/renderer? Will we end up with madPlayer, with everything conveniently locked in? "Sponsored by Apple"?

I don't have any plans to add splitters to madVR. And I can promise you there won't ever be anything audio related in madVR. One thing I might add at some time in the future might be a subtitle renderer. That's not decided yet, though.

Let me say it like this: I will add to madVR only what is strictly video related and what in integrated form has benefits over being external.

[noee]

Originally Posted by SamuriHL

Ok, so, in that case then if Matt whitelists them in MC16, you'll be able to select them as the decoder when you use ROHQ + additional. So that's good. We just need to get them to whitelist it. Shouldn't be hard.

Okay, then I'm over-reacting, apparently. I thought the whitelist didn't matter with ROHQ w/addl if you could select it in the list of decoders (which, I assumed was not whitelist filterd with ROHQ w/addl). THe madVR decoders do not show in the external list in either MPC-HC or jrMC.

I started a thread at jR, fwiw.

[SamuriHL]

Originally Posted by madshi

There's a good reason why I implemented the software decoders internally, which I'll explain sometime in the future. Maybe I should have kept the software decoders secret/hidden until I'm ready to reveal the whole plan. But then, I thought, why keeping back functionality? So I decided to make what I have now available, although it's in experimental state and only half of the final solution.

I personally appreciate you releasing functionality this way. And there is a benefit to you for doing so, as well. If this master plan is....complex....this lets you piece it together a step at a time and get the bugs worked out on each piece without having to concentrate on everything at once. This is a good iterative practice and will, in the end, deliver higher quality software. Kudos.

[SamuriHL]

Originally Posted by noee

Okay, then I'm over-reacting, apparently. I thought the whitelist didn't matter with ROHQ w/addl if you could select it in the list of decoders (which, I assumed was not whitelist filterd with ROHQ w/addl). THe madVR decoders do not show in the external list in either MPC-HC or jrMC.

I started a thread at jR, fwiw.

Just to make sure, you did reinstall madVR instead of just dumping it in the directory, right? It MUST be reinstalled to register the new filters.

In any case, yes, the additional filters that show up in MC16 are whitelisted. There was a lot of debate about this at first, and this situation exemplifies the points that were made about it. However, that being said, we need to give J River a chance to address the situation. To expect them to do so a few hours after something brand new is released before they have a chance to evaluate the ramifications is a bit unfair. My guess is that it'll go to the beta team first so we can beat on it, and then once it's determined how well it works or not, they will decide to release it to the general audience. This, IMO, is a really good methodology so that new toys can be vetted by people who understand and can tolerate bugs.

[madshi]

Originally Posted by noee

I've noticed that your internal filters may not be report fps upstream, at least Reclock isn't getting anything from the decoder.

I don't think the decoder has anything to do with Reclock. There's no official way I know that a decoder would report the fps to Reclock. Maybe it's all about the pin connection media type? Is there no FPS information in the splitter <-> madVR connection media type?

Originally Posted by noee

Yes, with the option disabled, MPC shows "normal" playing state in the taskbar (I'm on Win7 ult x64).

But it still stutters the same way?

Originally Posted by Skwelcha

btw i dont have any startup or seeking delays like some people reported ?

The delay is only as long as madVR needs to fill the queues. If your PC is fast, the delay will be very small, maybe not noticeable at all.

Originally Posted by clsid

I also prefer to have the decoder and renderer fully separated. I assume they are integrated now primarily because it greatly simplifies the colorspace handling?

That's one reason, there are others. You can PM me if you want to know the others (this offer is only valid for clsid).

Originally Posted by clsid

Perhaps you can join forces with nevcariel to create a full featured LAV Video decoder that can output high bitdepth colorspaces to madVR. It would be a waste to do things twice.

I hate wasted resources, so I somewhat agree with you. But then, writing a separate decoder has so many consequences, so many more things to test and check and support, I don't really feel up to that task. I'm happy enough that the internal madVR decoders have nobody (no other renderers or post processing filters) to answer to than madVR. That makes things so much simpler.

Originally Posted by clsid

With regard to the buffering, perhaps it would better to have two options, one for buffering at start, and one for buffering after seeking. I think most people will prefer instant seeking, while a short delay at start is probably less of a problem.

Yes, if the majority of people prefer it that way, I'll have to make two options, although I generally prefer to keep the number of options as low as possible. Hopefully I'll get a lot of feedback from users so I can find out how many people prefer to have this option set which way.

[nevcairiel]

Originally Posted by clsid

Perhaps you can join forces with nevcariel to create a full featured LAV Video decoder that can output high bitdepth colorspaces to madVR.

But i already have a decoder which can decode H264 10-bit and output full 10-bit YUV to madVR without any degredation.
In theory it can output up to 16-bit YUV, but i don't know if any codec in ffmpeg supports that.

[SamuriHL]

Originally Posted by nevcairiel

But i already have a decoder which can decode H264 10-bit and output full 10-bit YUV to madVR without any degredation.
In theory it can output up to 16-bit YUV, but i don't know if any codec in ffmpeg supports that.

What about the rest of us? WE don't have such a decoder!

[oddball]

Originally Posted by madshi

No, not yet. Maybe in a future version, but not anytime soon.

Thanks. I wanted it to fix the green colourcast in LoTR:FoTR BluRay. Looks like I might have to tweak my HDTV settings for now (setup a seperate profile perhaps).

I think the ability to screencap is of more importance right now. It's the one thing missing from MadVR for me that would make it near perfect. Is the screencap ability forthcoming?

BTW subtitles vanish when I pause. Just going to test 0.67 but was wondering if that was fixed.

[nevcairiel]

Originally Posted by SamuriHL

What about the rest of us? WE don't have such a decoder!

I need a few more days to polish some things. jeez. patience.

[SamuriHL]

Originally Posted by nevcairiel

I need a few more days to polish some things. jeez. patience.

Looking forward to it. I'm really at a point where I'd like to get rid of the PDVD11 HAM decoder on my main HTPC. So, these new toys you and madshi are coming up with are EXTREMELY welcome and highly appreciated.