madVR - high quality video renderer (GPU assisted)

[madshi]

madVR v0.67 released

http://madshi.net/madVR.zip

* added libav/ffmpeg Software Decoders for MPEG2, VC-1 and h264 (experimental)
* added Intel Software Decoders for MPEG2, VC-1 and h264 (experimental)
* added new option "delay playback start until render queue is full"
* added new interface IMadVRRefreshRateInfo for media player developers
* fixed: OSD was updated all the time, even in paused state
* fixed: when using GraphEdit, madVR video window was sometimes too small
* fixed: madVR asked upstream filter to change output FourCC without need
Notes:

(1) As noted in the changelog, the software decoders are *experimental*. Because of that they are disabled by default. You need to enable them in the settings dialog before you can use them. Don't cry if they don't work as well as they should yet. I'm aware of several problems, occasional instability being one of them, bad timestamps being another, which can result in non-smooth playback, or delayed/dropped frames.

(2) The software decoders currently expect splitters to behave perfectly. If splitters don't, there might be some corrupted frames after a seek, or even at movie start. The Haali Media Splitter seems to work nicely. The LAV Splitter sometimes doesn't. I've notified nevcairiel about the problem. But of course in a future version I'll make the decoders more robust against non-optimal splitter behaviour.

(3) The libav/ffmpeg decoders support MPEG2 with both 4:2:0 and 4:2:2. They also support 8bit, 9bit and 10bit, 4:2:0 and 4:4:4 h264 decoding. Of course everything is decoded in full quality and passed to the madVR processing chain without any downconversion.

(4) There's no (zero, nada) support for deinterlacing at this point in time, so using the decoders for anything other than progressive content probably doesn't make much sense right now.

(5) While working on the decoders, I've found a nice trick to pre-buffer video frames. As a result madVR is now delaying playback start by up to 2 seconds (if necessary). Basically, at the start of movie playback and after every seek, madVR puts the player into paused mode, until all madVR queues are full. Only after that playback starts (at the latest after 2 seconds). The benefit of this approach is that there should be much less dropped/delayed frames at playback start and when seeking. If you don't like this new behaviour, you can turn it off in the settings, of course.

I'd like to get some feedback from you guys now. Do the decoders work as expected? E.g. can you find out and tell me which limitations the Intel decoders have exactly, so that I can switch to libav/ffmpeg on the fly, if necessary? Another question is whether the Intel decoders are worth shipping with madVR at all, anyway. Maybe the libav decoders are better in every way? But then the Intel VC-1 decoder can do interlaced decoding, I believe, which libav/ffmpeg can't do yet. However, for VC-1 interlaced decoding probably the MS VC-1 decoder is the best choice? I'm curious to hear your feedback.

P.S: You might be wondering why I'm adding video decoders to madVR now. There are several reasons for that. One is that I wanted to finally have high bitdepth and 4:2:2 and 4:4:4 decoding with full quality. There's at least one other reason I'm not ready to talk about yet. But I think you might be able to guess it... :)

[leeperry]

:thanks: for the new build! The about box still says 0.66 BTW.

So the new decoders aren't GPU accelerated? or "not yet" at least :D

I like the new feature concerning seeking, I shall try it and report back ASAP :)

[SamuriHL]

Holy snikes! :eek: That's quite an interesting changelist you got there! :)

[madshi]

The about box still says 0.66 BTW.
Just re-uploaded. No changes, other than the fixed version number.

I like the new feature concerning seeking, I shall try it and report back ASAP :)
Hope you'll still like it after testing... :p

Holy snikes! :eek: That's quite an interesting changelist you got there! :)
But it's so small!!

[SamuriHL]

But it's so small!!

RIGHTTTTTT! We believe you! Wait, no, no we don't! :) I really need to try the decoder on my AMD machine. cough cough :D You know, in case, uh, future enhancement might help me there. :D

[madshi]

So the new decoders aren't GPU accelerated?
No. I added the big fat word "software" into the changelog, just to make sure nobody gets a wrong impression.

[leeperry]

Hope you'll still like it after testing... :p
Well, indeed I don't really like it :p

Seeking used to be blazing fast before, now it takes a half second before playback actually starts...and the only occurrence where I would really need it to work doesn't: If I change something in my Avisynth ffdshow scripting(like enabling/disabling LSF) then I still get 3fps for a few seconds(and sometimes it won't go back to full speed until I reseek), but indeed technically I'm not reseeking so mVR can't guess that I'm messing w/ ffdshow. Still, it'd be great if it could buffer frames and avoid reseeking :o

[madshi]

Well, maybe I should make a vote for who likes the pre-buffering / playback start delay, and who doesn't, so that I can set the default value according to what the majority likes.

[noee]

Well, I like it, but then, I don't use AVIsynth for real-time video processing. Also, thanks for the c/c++ header file, lazy as I am...

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?

[SamuriHL]

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

[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]

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".

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]

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]

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]

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]

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!

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.

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]

...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....

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]

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]

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?? :p 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.

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]

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]

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]

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]

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?

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?

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.

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).

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.

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]

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]

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! :p :D

[oddball]

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]

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

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

[SamuriHL]

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

:D 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.

[madshi]

THe madVR decoders do not show in the external list in either MPC-HC or jrMC.
There are no additional filters, there's only madVR. But you can use madVR as a decoder and/or as a renderer. So basically in MC16 it should be possible to select madVR as the renderer and also as a decoder. FWIW, in MPC-HC, madVR automatically gets chosen for decoding, if you don't "prefer" any other decoder, and if you block ffdshow. It seems that ffdshow has such a high merit that it gets preferred over madVR if you don't block it.

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.
Agreed. If I wait for everything to be finished before releasing it, people will only test what they plan to use and I might never get feedback on some other stuff. By releasing things piece by piece, I hope to get feedback for every piece.

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.
Nice. Looking forward to it! :)

Is the screencap ability forthcoming?
Yes, some time in the future, but not too soon.

[noee]

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?


duh, right, I had something else going wrong....seems okay now.

But it still stutters the same way?

Yes.

So basically in MC16 it should be possible to select madVR as the renderer and also as a decoder.

Yep, but as SamuriHL says, they will have to add it to the whitelist, as madVR doesn't show in the "Other Filters" list in MC. And yes, MPC-HC seems to "find" the madVR decoders just fine.

[clsid]

Your plan seems to require the decoder and renderer working together in a way that goes beyond the standard functionality of DirectShow (and perhaps also MF?). Could the same be achieved through a new API by which a decoder communicates with madVR to perform the additional magic?
Please PM the details. You got me curious ;)

[e-t172]

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.

Well, I hate DXVA for precisely this reason. That's why I love LAV CUVID, too.

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.

I agree for the separate configuration dialog (which isn't exactly hard work). However, I see no problem in having the decoders shipped with madVR in the same package. As long as they appear separate in DirectShow.

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.

Or you could just say "no" to people who complain about broken filters. Just say that you will only support madVR as the downstream filter. As long as you don't actually prevent people from developing downstream filters, which is what you're doing right now.

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.

There isn't now. Doesn't mean there won't be tomorrow. The whole purpose in the "Do one thing and do it well" principle is that you don't try to predict what other people will do, so they can innovate in unexpected ways.

There's a good reason why I implemented the software decoders internally, which I'll explain sometime in the future.

I don't really understand the motivation behind the secrecy. It's not like you have any serious competition to worry about… But again, your software, your decisions, I respect that. I guess I'm too immersed in the open source philosophy myself.

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.

That's good to know. I'm still wondering what it is you want that cannot be done using the DirectShow infrastructure though, even if it involves creating new DirectShow media types from scratch.

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.

You must really like Apple products, given that you're producing the exact same rhetoric. Walled gardens anyone?

I admit, I may be a little exaggerating here. It's just that I don't want this to become a precedent in any way. There's a reason why "monolithic" players don't achieve the result of a well-configured DirectShow chain.

[nevcairiel]

You have to be careful in MPC-HC, if you add madVR to the list of preferred filters, it'll usually break subtitles, because then the filter is not added through the "normal" way to add the renderer, and all the special interfaces don't get hooked up.

[clsid]

Can you fix that? Imo the preferred filters should not override renderer settings. At least not for the known renderers.

Some people tend to unnecessarily add lots of filters to the preferred list, so it is a bugfest waiting to happen.

[xv]

Found several bugs:
-Fullrange crashes madVR (internal decoder)
-Internal decoder has problems (chroma planes not correctly aligned) if height is not a multiple of 16
-Crashes with many files (with internal decoder disabled, no special reason found (yet), but is reproduceable)

Still missing:
-Support for other chroma matrices than bt709/bt601

[robpdotcom]

Absolutely loving the new pre-buffer option. Seeking was fast before, now it seems instantaneous on my system. It's nice to open a video, seek through it like crazy, and only have 1 dropped frame the entire time. :cool:

Not sure what it means, but when testing the new decoders, I noticed they are the only decoder which will keep the present queue full. I don't see any difference in performance, but thought it was worth mentioning.

Also, I get corruption at the bottom of the screen using the libavcodec for VC-1 (if the source is letter-boxed, you'd never see it). No such issue with libavcodec in ffdshow, and no problem with the Intel decoder.

[madshi]

Well, I hate DXVA for precisely this reason. That's why I love LAV CUVID, too.
But LAV CUVID copies the decoded frames back from GPU RAM to System RAM. And then the video renderer copies them back to GPU RAM. Such a solution isn't really optimal for performance, especially not for AMD (AMD is notoriously bad at GPU RAM -> System RAM transfers). And this is *exactly* the reason why the whole external decoder thing would be of limited use: If the decoded frames are on the GPU and if you want them to stay there (for performance reasons), then you simply cannot send the video frames downstream via DirectShow input/output pins, because they are not in System RAM. What good would an IVTC post processing filter do if it can't reach the frames because they're not in System RAM? The IVTC post processing filter would have to use Direct3D or OpenCL to access the frames, and if it does that, instead of routing the data through the input/output pins, then it wouldn't be DirectShow, anymore, anyway.

There isn't now. Doesn't mean there won't be tomorrow. The whole purpose in the "Do one thing and do it well" principle is that you don't try to predict what other people will do, so they can innovate in unexpected ways.
Well, I'm not taking anything away. madVR still accepts raw RGB and YUV formats just fine. Actually madVR is more open than any other renderer in the variety of accepted input formats... :) This is where your Apple comparison really fails.

You have to be careful in MPC-HC, if you add madVR to the list of preferred filters, it'll usually break subtitles, because then the filter is not added through the "normal" way to add the renderer, and all the special interfaces don't get hooked up.
Yeah. Also I've noticed that prefering madVR doesn't make MPC-HC use madVR for video decoding. Instead you have to block ffdshow. Kinda weird.

-Fullrange crashes madVR (internal decoder)
Which one? Intel or libav/ffmpeg? Or both?

-Internal decoder has problems (chroma planes not correctly aligned) if height is not a multiple of 16
Intel or libav/ffmpeg or both? Can you provide a small sample, please?

-Crashes with many files (with internal decoder disabled, no special reason found (yet), but is reproduceable)
That's weird! Is that a new bug in v0.67? If so, samples would be greatly appreciated!

Still missing:
-Support for other chroma matrices than bt709/bt601
Yes, that's on my to do list. Could use sample files for this, too, btw...

Absolutely loving the new pre-buffer option. Seeking was fast before, now it seems instantaneous on my system. It's nice to open a video, seek through it like crazy, and only have 1 dropped frame the entire time. :cool:
Glad to hear that!

Not sure what it means, but when testing the new decoders, I noticed they are the only decoder which will keep the present queue full. I don't see any difference in performance, but thought it was worth mentioning.
You mean the internal decoders keep the present queue full, while external ones don't? That's weird.

Also, I get corruption at the bottom of the screen using the libavcodec for VC-1 (if the source is letter-boxed, you'd never see it). No such issue with libavcodec in ffdshow, and no problem with the Intel decoder.
Do you get this problem with all VC-1 files? Which splitter are you using? Can you try a different splitter, just to be safe?

[yesgrey]

You must really like Apple products

I admit, I may be a little exaggerating here.
I would say a lot.;)

How much is madshi asking for madVR? Infinitely less than Apple asks for their products.
Furthermore, you have exactly the same functionality as before. He did not stop accepting other decoders, he only decided to include one inside madVR for some future features, and since it's ffmpeg based it has nothing to offer that you could not get from any of the other decoders also based on ffmpeg, so I cannot see what's your problem...

[pirlouy]

Madshi... You're the Man !
And more. You're the man for audio renderer; stop saying you're not interested; think a little bit at others instead of being selfish ! :)

Else, I've just tried with default options; everything is still working (maybe seek is quicker, but nothing noticeable for a "normal" user like me); I've enabled new decoders (ffmpeg), and did not notice something weird. But I'll try to report useful bugs reports soon (if there are).

[Wile-E-Coyote]

Madshi, if you can have MadVR decode MPEG2, can you not go all the way and have it work with DVDs?

[robpdotcom]

You mean the internal decoders keep the present queue full, while external ones don't? That's weird.
Yes. For instance, if I set madVR to present 8 frames in advance, the OSD shows "8-8/8". If I use ffdshow, it fluctuates, but never goes higher than "7-8/8".

EDIT: It seems this only happens with the libavcodec decoder - the Intel decoder shows the same stats as ffdshow.

Also, If I set madVR to preset more than 10 frames in advance, it will show something like "11-12/12", and I start getting dropped frames. If I use ffdshow, it also says "11-12/12", but no dropped frames. I normally never set madVR to present that many frames in advance - I was just trying different scenarios.


Which splitter are you using? Can you try a different splitter, just to be safe?

Tried with Haali, LAVSplitter, and MPC-HC's internal splitter with no change.

Do you get this problem with all VC-1 files?

Well, the only VC-1 files I have are from Blurays, and most are letter-boxed. But I did find four that are not letter-boxed, and they all showed the same corrupted image.

[clsid]

Madshi, if you can have MadVR decode MPEG2, can you not go all the way and have it work with DVDs?The Macrovision error is not related to the video decoder. It occurs when you use a non-Microsoft renderer in combination with the Microsoft DVD Navigation filter.

[HitomiKun]

So I've been testing around the new libav/ffmpeg and Intel Software Decoders for h264 material. Both work but they have their disadvantages. I can switch between them on the fly without any problems. (Only if I click somewhere on the timeline after changing)

libav/ffmpeg for h264 works fluid and doesn't drain a lot CPU power but it shows animated subtitles (.ASS files) slightly laggy and also a bit timed off. It gets very confusing on fast scenes, because the subs aren't 100% timed right with libav/ffmpeg.

The Intel Software Decoder for h264 is exactly the other way around. It drains almost all of my CPU power and I get slight FPS drops but it shows animated subtitles lagfree and also with the right timing. (Well with those FPS drops ofc)

I normally use CoreAVC as my h264 decoder and it does it job pretty well. It costs something but it was worth it. It doesn't drain a lot of CPU power and also shows everything how it should be. (Just sayin, I don't really want to advertise or something)

So I like seperated decoder and renderer more than all in one. It just gives me better control over my decoders.

Here's the video I've been testing with:
(Before you download, make sure you don't mind to see some blood. It's the intro from Bakemonogatari and that is a bit bloody.)
http://www.megaupload.com/?d=0WM5KZPK
(I packed the video into a .rar file, because it made the video file 14% smaller. Less upload time.) :)

Video info:
Overall filesize: 127 MB
Codec: h264
Res: 1920x1080 @ 7000 kbit/s
Audio: FLAC
Container: MKV

My PC specs (Just for those who are wondering why I get lags with the Intel decoder.):
Sys: Windows 7 Ult 64 bit
CPU: AMD Quadcore 2.3 GHz
Graphics: NVIDIA Geforce GTX 260 (overclocked)
RAM: 4 GB DDR2
(I used 32bit MPC-HC 1.5.2.3391 for testing)

Hope that helps. ^^

[Hypernova]

Madshi, here are two problems I found:

1. When paused, the subtitle will still disappread. It stayed juat a short time, probably somewhere around 500ms-1s, but will definitely disappear.
2. The combination of Intel decoder+unchecked delay playback will usually crash MPC-HC on my setup after a couple successive seekings.

Also, the a/v unsynced problem on h264 with avi when using multithread is presented with both libav/ffmpeg and Intel decoder. This make me wonder since isn't this supposed to me libav/ffmpeg only bug? Anyway, I know you probably won't fix it, but you might want to keep a note if libav/ffmpeg fix that in the future.

Oh, and after a long(?) discussion about the OSD color, no one mention that now it's changed to white on transparency black? :D I like that by the way.

[fairchild]

Everything is working well here. Only changes I made from default MadVR config is to change to Spline3 for luma upscale/downscale, check the reclock 25p to 24p option, and made a new yCMS 3dlut. I like the new feature you added for seeking, I don't notice much of a delay here. Also the new yCMS seems to be giving better results than in the last version. (not sure if you and yesgrey changed anything around)

[oddball]

I'm confused. What's this about MadVR decoding? I tried with latest MPC-HC and do not see any decoding options (x264 in MKV)? All I get is MS DTV decoder if I block all my filters.

[Wile-E-Coyote]

nvm..

[Hprd]

Well the issue with the ques running out with the one option checked still extists.

I'll just quote my post from a couple weeks ago (i'm not assuming you didn't read it, but better to be safe then sorry i guess, plus the issue/temp solution is no different than then that i found. Anyhow, don't feel like i'm forcing you to address my little issue specifically, lol.):

Hmm well my issue that started with .63/4, i think it was, still exists, and i found out that my previous "workaround" didn't really work. The osd would show that it was ok, but playback was very stuttery.

Anyhow, the issue of course was, on 48/59hz with only "overshoot max frame latency" checked, the present que after a little while runs out (and the render que to an extent as well), and i get alot of glitches, and sometimes frame drops. The best playback i found was to set the pre-rendered frames to 16 (as the issue i had b4 for w/e reason is gone when setting it that high), and setting the option for "limit rendering times to prevent glitches". It isn't perfect, as there's still some glitches here and there, but it's the best solution for now. At 23/29hz for w/e reason (i played back a 1 1/2 hour+ movie with zero issues) it's perfect like it was b4 on all resolutions (with just the overshoot option checked).

Here's a log file in which i played a video up to the point where the ques started running out (if it helps):

http://www.megaupload.com/?d=F0L8L7JU