madVR - high quality video renderer (GPU assisted)

[KoD]

A feature request, if possible: some keyboard shortcut to switch the display refresh rate. I have files badly tagged as 23.976 fps, but when played at 23.976 the number of dropped frames increases continuously. However, when played at 60fps, everything is smooth, no dropped frames.

Another question is, what happens when the file has VFR? The file is tagged as 23.976fps, but in fact the duration of the frames varies continuously. How does madVR handle this?

And a bug report: when using the "switch to matching display mode", the switch does not really happen if the "list all display modes madVR may switch to" list is empty. Settings used:

switch to matching display mode = enabled
switch to matching display mode = when media player goes fullscreen
restore original display mode = enabled
restore original display mode = when media player is closed
general settings - delay playback start until render queue is full = on
general settings - delay playback start after seeking, too = on
general settings - enable windowed overlay = off
general settings - enable automatic fullscreen exclusive mode = off
general settings - disable desktop composition = off
general settings - use Direct3D 11 for presentation (Windows 7 and newer) = on
general settings - present a frame for every VSync = on
general settings - use a separate device for presentation = off
general settings - use a separate device for DXVA processing = off

Happens for any file fps (23.976p, 29.970p, etc).

In nvidia control panel, this is the list of available display modes (and they all work when switched to manually, or specifically including them in the "list all display modes madVR may switch to" list):
23Hz, 24Hz, 29Hz, 30Hz, 50Hz, 59Hz, 60Hz

PS: my 500th post! yay!

[huhn]

in most cases "display modes" will choice the wrong refreshrate because it is usually selected by the AVG FPS. but smoothmotion at 60 hz can handle VFR perfectly.

theoretically there are ways to add informations like min FPS, max FPS and AVG FPS. but this is rarely used in practice and AFAIK madVR can't make use of it.

[MokrySedeS]

Originally Posted by KoD

A feature request, if possible: some keyboard shortcut to switch the display refresh rate. I have files badly tagged as 23.976 fps, but when played at 23.976 the number of dropped frames increases continuously. However, when played at 60fps, everything is smooth, no dropped frames.

You should probably fix the affected files, but if you insist then you can use madVR's file tagging system, which is even better than suggested shorcuts in your case.

Originally Posted by madVR v0.85.4 changelog

* added tag "frameRate=%value%", e.g. 23.976, 24.000, 23, 24, ...
* added tag "refreshRate=%value%", e.g. 23.976, 24.000, 23, 24, ...

Originally Posted by KoD

And a bug report: when using the "switch to matching display mode", the switch does not really happen if the "list all display modes madVR may switch to" list is empty.

It's not a bug, it's a feature! :P
But seriously, madVR by design will switch only to the modes listed it this field.

[Ver Greeneyes]

Is there a keyboard shortcut to toggle black bar detection or cropping? I don't need black bar detection that often, and there will probably always be videos on which it doesn't quite work, but I'd like to be able to enable it easily when the black bars are obvious and consistent.

[KoD]

Originally Posted by huhn

in most cases "display modes" will choice the wrong refreshrate because it is usually selected by the AVG FPS. but smoothmotion at 60 hz can handle VFR perfectly.

theoretically there are ways to add informations like min FPS, max FPS and AVG FPS. but this is rarely used in practice and AFAIK madVR can't make use of it.

Hmm, I don't know. Does madVR really know the duration of each frame in order for its smooth motion algorithm to transition from one frame to the next at the right time, and not at multiples of, let's say, 23.976fps if the file is tagged with 23.976fps? And if a frame has a long duration, will it show a blend of frames only close to the transition points, or will it show blended frames for most of the duration of that single long frame? It's not min and max fps that would be required for proper VFR handling, but knowing the duration of the frame, I think. After all, a container such as mkv lets you specify that avg fps (like 23.976fps), but the actual duration of each frame is in no way linked to the value of this field. The frame timecodes can be anything - this is how VFR is actually implemented. One can make a 5 minutes video file which contains only one frame. I don't know if and how this info gets sent through the playback chain, maybe it would require a new API on the renderer for the player to send this info from the splitter? And you are right, it's not possible to properly see VFR content at a display refresh rate of 23.976Hz. One would need to set the display rate as high as possible (60Hz for most TVs), so that frames in the VFR file with durations smaller than 41.71ms would be properly displayed at the right moment.

Originally Posted by MokrySedeS

You should probably fix the affected files, but if you insist then you can use madVR's file tagging system, which is even better than suggested shorcuts in your case.

I was going through a folder of anime music videos. It's quite a big list of files collected over a large period of time, many of them are fan made (so, no chance of getting them redone), and in all media container formats used over years: mpg, avi, ogm, mp4, mkv.

Renaming them would involve opening each one several times, each time at a different display rate selected before starting playback, finding the one that does not cause jitter, and then remuxing them. It would be too time consuming to manually do this for every one to add a tag to its filename, and I don't see any automated way of doing this.

[SweetLow]

Originally Posted by madshi

What purpose would you use that for?

Enable or disable madVR dithering (right now). Intel well dither in hardware when out 10 bit on 10 bit device (HDMI TV in my case), but when out 10 bit on 6 bit (internal eDP panel of notebook in my case) it not dither properly (only dither from 8 bit to 6 bit, AFAIK by my tests).

Originally Posted by madshi

Intel/NVidia: DXVA2 image + Bilinear chroma upscaling -> DXVA chroma up

Thanks. Very fast reaction

P.S. To Intel users - as i see in my tests, dxva deinterlacing + dx11 rendering path don't work well with "frames present in advace" set to more then 2 (easy visible jumps in motion parts of image). dx9 work well with 4 frames. But lower value slightly increase GPU and power consumtion.

[JohnLai]

Question, is it possible to use madvr's smooth motion together with SVP? (gtx 980 and core i7 for instance)

[huhn]

AFAIK SVP provides proper timestamps. so yes.

[huhn]

Originally Posted by KoD

Hmm, I don't know. Does madVR really know the duration of each frame in order for its smooth motion algorithm to transition from one frame to the next at the right time, and not at multiples of, let's say, 23.976fps if the file is tagged with 23.976fps? And if a frame has a long duration, will it show a blend of frames only close to the transition points, or will it show blended frames for most of the duration of that single long frame? It's not min and max fps that would be required for proper VFR handling, but knowing the duration of the frame, I think. After all, a container such as mkv lets you specify that avg fps (like 23.976fps), but the actual duration of each frame is in no way linked to the value of this field. The frame timecodes can be anything - this is how VFR is actually implemented. One can make a 5 minutes video file which contains only one frame. I don't know if and how this info gets sent through the playback chain, maybe it would require a new API on the renderer for the player to send this info from the splitter? And you are right, it's not possible to properly see VFR content at a display refresh rate of 23.976Hz. One would need to set the display rate as high as possible (60Hz for most TVs), so that frames in the VFR file with durations smaller than 41.71ms would be properly displayed at the right moment.

mkv doesn't use FPS it only uses timestamps for each individual frame. so VFR in mkv is a no problem for madVR. a VFR file without timestamps(or something similar) would ran async so they all have "timestamps" or they are broken. and this information is provided.

max FPS is a good way to choice a good refreshrate by simply using that value. for SM the highest value is by far the best but not everyone wants to use SM.

madVR SM blending is very simple (in theory at least...) for example it has to display a frame for 20 ms and the time stamps of the frames show frame 1 should get the first 5 ms of these 20 ms and frame 2 the other 15 ms than they are blending.

so a "long" frame isn't blended most of the time only maybe at the end or the start if other frames share some time of that display interval.

[KoD]

Originally Posted by huhn

mkv doesn't use FPS it only uses timestamps for each individual frame. so VFR in mkv is a no problem for madVR. a VFR file without timestamps(or something similar) would ran async so they all have "timestamps" or they are broken. and this information is provided.

max FPS is a good way to choice a good refreshrate by simply using that value. for SM the highest value is by far the best but not everyone wants to use SM.

madVR SM blending is very simple (in theory at least...) for example it has to display a frame for 20 ms and the time stamps of the frames show frame 1 should get the first 5 ms of these 20 ms and frame 2 the other 15 ms than they are blending.

so a "long" frame isn't blended most of the time only maybe at the end or the start if other frames share some time of that display interval.

There is no explicit avg frame rate field in mkv files, indeed. But that purpose is fulfilled by a tag called "DefaultDuration". This is why you can have mkv files which madVR says they have 23.976fps, but when you set the display rate at 23.976Hz and try to play the file, it's a stuttering mess, and the dropped frame counter increases continuously. Perhaps this is the reason for the frame rate in filename tag functionality, to explicitly tell madVR what the framerate actually is, instead of trusting the one the splitter reads from the file and passes it up the chain. This only works for constant frame rate content, however.

The issue, I imagine, is that madVR does not honor frame durations, but instead bases its computations on the average frame rate. Which works fine most of the times, for straight to mkv remuxes or encodes of BluRay or DVD content (well, some DVDs), and that's why most people are not affected.

Or maybe the implementation is fine, it honors the proper individual frame duration, and works ok if I keep watching everything at 60Hz (with smooth motion on, and smooth motion only affecting the one or two frames around each transition point)? In that case it would just be my fault for drinking the videofile kool-aid and insisting on switching the display refresh rate to what the file is supposed to be at.

To be honest, I would welcome a proper implementation of frame duration display more than the constantly increasing number of resizing algorithms. The available algorithms have reached a level where the difference in quality is indistinguishable (and I mean here during actual movie viewing, and not doing comparisons of zoomed in screenshots). The stuttering during the playback of some files is so much more visible than whether there is any benefit when using anything above Jinc3.

[SweetLow]

Originally Posted by madshi

* added new profile rule script variables "display"

Umm... If this is my wish realization - it's work not as expected. In my case this variable always equal to the name of first device in devices list, not actual device of player window

[nevcairiel]

Originally Posted by KoD

To be honest, I would welcome a proper implementation of frame duration display

madVR implements frame timings quite well, however the entire system is quite limited by hardware.

The "problem" is of course that you can only present a new frame in every VSYNC, so if your display is set to 23.976, then you can present exactly 23.976 frames per second (and exactly at pre-defined times as well, a new frame every 41.7ms). If your file happens to have more frames per second, then madVR has to do the best it can, which means dropping a lot of frames. This can easily result in rather stuttery playback - but its not madVRs fault really, since it just can't show you anymore frames. Of course you could blame it for picking the wrong refresh rate, but it can only act on the information provided to it - scanning the entire file for the greatest common denominator of frame rates is hardly viable.

Assuming your file has both 23.976 and 29.970 parts, then you could set it to 29.970 Hz instead (or 59.94, which is more common), but then you couldn't show the 23.976 parts properly, because the frame timings of a 23.976 stream don't match a 59.94Hz VSYNC interval, and some frames would fall in-between VSYNCs.

If you want all possible videos to look properly, you need an infinite refresh rate monitor (or variable refresh rate for that matter). You can usually get pretty close by running at say 120Hz, as that is a clear multiple of 24 and 30, which are rates many "vfr" files use internally (some animes seem to like to switch between 24 and 30 for some reason). But if your video is real variable frame rate, then that won't save you either - although the short individual frame times at 120Hz (just 8.3ms) make any judder from a mis-matching framerate far less obvious.

One solution to that is Smooth Motion, which simulates an infinite refresh rate display, and then uses blending to map the frames as good as it can to your display refresh rate.

[chros]

Originally Posted by SweetLow

Enable or disable madVR dithering (right now). Intel well dither in hardware when out 10 bit on 10 bit device (HDMI TV in my case), but when out 10 bit on 6 bit (internal eDP panel of notebook in my case) it not dither properly (only dither from 8 bit to 6 bit, AFAIK by my tests).

Which CPU , chipset, driver, OS do you have?
I don't see any 10bit option in my driver settings (see my signature for details).
Thanks

[SweetLow]

Originally Posted by chros

Which CPU , chipset, driver, OS do you have?
I don't see any 10bit option in my driver settings (see my signature for details).
Thanks

It's not the driver setting, it's settings of madVR - use of DX 11 presentation + set more then 8 bitdepth in device properties+use of exclusive FS.

[Ruben0]

Originally Posted by madshi

I'm using the highest quality algo the GPU offers. What performance hit do you mean? GPU power? YADIF is done by LAV via CPU, so the GPU doesn't suffer. DXVA deinterlacing is done by the GPU. So it's clear that the GPU has more work to do when doing DXVA deinterlacing. It depends on the GPU model, though, because some have dedicated hard wired circuits to do deinterlacing, while others use pixel shader power for that. When using YADIF, make sure you use 50p/60p (Video) output, because that's what DXVA does (by default), too.

thanks for your answer.
I was mistaken the rendering and deinterlace stats, the big performance hit is in rendering while using nnedi3-32 in chroma upscaling and image doubling for dvd playing. The deinterlace stats are always low. I have an nvidia gtx 770 4GB.

keep up your excellent work!

[chros]

Originally Posted by SweetLow

It's not the driver setting, it's settings of madVR - use of DX 11 presentation + set more then 8 bitdepth in device properties+use of exclusive FS.

Yes, I know. Maybe my TV and/or my receiver doesn't support it.

[SweetLow]

Maybe, but it's easy to see actual state by moninfo or any other EDID info viewer. And, more important, the 10 bit device is not necessary to get 10 bit rendering.

[pankov]

madshi,
is it intentional that the hidden option to show the black bar detection using the ShowBlackBars empty file doesn't actually work if the "crop black bars" option is not enabled?
I want to debug a few situations with some TV stations with weird aspect ratios and hard coded black bars and it will be very useful if I can see what madVR detects and would crop but without actually cropping it so I can verify it visually.

I'd like also to ask a question about the new rotation feature.
Is it intentional that the subtitles (both external and internal ones) are rotated together with the picture ... and moved almost to the center of the image? While the centering seems like a bug I'm not exactly sure about the rotation ... I can see merit in both behaviors - showing the subtitles normally/horizontally while rotating only the video (because for example it was shot in "portrait" and not "landscape" mode) ... or rotating everything because the display that's used for presentation is rotated and the user wants everything rotated ... so it seems it might need to be optional.

[AngelGraves13]

Originally Posted by madshi

Those threads you linked to don't look like simple deblocking at all. They seem to be targetted at low quality Anime content, and they do all sorts of things, like removing noise, tighten up edges etc etc. You could use AviSynth via ffdshow raw video processor to do *exactly* what those 2 threads suggest in real time video playback (if your CPU is fast enough).

Fair enough. I'd settle a simple deblocker that has 3 settings like the debanding. Low, Medium, High. I'd likely just leave it on High just like the debanding filter.

Does deblocking just work on 4x4, 8x8, and 16x16 blocks? MPEG-2 was 8x8 only? I hardly notice any blocks in MPEG-4 unless it's a low bitrate file. MPEG-2 needs deblocking regardless of bitrate or resolution. Even the early blu-rays with MPEG-2 can look quite bad.

If it was to be implemented, would the deblocking be done before or after image and chroma upscaling?

[nevcairiel]

Originally Posted by AngelGraves13

If it was to be implemented, would the deblocking be done before or after image and chroma upscaling?

Before image upscaling would be best, not sure about chroma though.
Image upscaling could otherwise create new artifacts around the block edges (or smooth them, depending on the scaler) which makes a deblock filters job ever so much harder.