View Issue Details

IDProjectCategoryView StatusLast Update
0000472madVRbugpublic2017-02-28 13:32
Reporterhannes69 Assigned Tomadshi  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformWindowsOS7OS Versionx64 SP1
Summary0000472: display switcher switching to wrong display mode
DescriptionA) Assigned display modes: 1680x1050p60, 1680x1050p71, 1680x1050p72, 1680x1050p75.
Playing back 25fps movies lead for certain movies always to wrong 1680x1050p60 display mode chosen. For other 25fps movies always the right 1680x1050p75 mode is chosen. In every case OSD reports: "movie 25.000fps (says source filter)".

B) When assigning 1680x1050p50, 1680x1050p60, 1680x1050p71, 1680x1050p72 instead everything is working as expected.
Additional InformationRAR file attached with:
- OSD screenshot + debug log for case A) = NOK
- OSD screenshot + debug log for case B) = OK
TagsNo tags attached.
madVR Version0.91.3
Media Player (with version info)MPC HC x64 1.7.10.290
Splitter (with version info)LAV 0.69
Decoder (with version info)LAV 0.69
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerAMD
GPU ModelAMD R7 250
GPU Driver VersionRadeon Crimson Relive 17.1.2

Activities

hannes69

2017-02-28 00:40

reporter  

debuglogs_OSDscreens.rar (748,976 bytes)

madshi

2017-02-28 09:57

administrator   ~0001590

Last edited: 2017-02-28 09:58

This is caused by the upstream filter reporting that the video is interlaced with "bob or weave", which means the upstream filter is reporting that it's not sure if the video is telecined film or native video content, and if deinterlacing is needed.

In this situation madVR internally remembers "maybe I need to deinterlace, but I'm not sure yet", and deinterlacing is initially turned off, but will be turned on immediately as soon as the first interlaced frame gets in.

This is the usual way the splitter/decoder reports interlaced material, so madVR cannot know for sure if deinterlacing will be needed or not, atm when the upstream filter reports this. Furthermore, refresh rate switching is done at the very start of playback, which is a point in time where madVR can't be sure yet if deinterlacing will be turned on or off.

If in this situation madVR started with 25Hz, it would have to do 2 mode switches for every actually interlaced content (which later turns out to need deinterlacing). Which is very bad, obviously. So in case madVR isn't sure if (video mode) deinterlacing will later be needed, it decides to error on the safe side and tries to switch to refresh rate which can handle both non-deinterlaced and interlaced sources, which means 50Hz. If 50Hz is not available, madVR switches to the next best refresh rate, which is this case happens is decided to be 60Hz.

Possible solutions:

1) You only have 60fps, 72fps and 75fps in the display mode list. At the same time you have deinterlacing turned *on* and forced film mode turned *off*. Which IMHO classifies as a bad configuration. Let's say you actually played a natively interlaced PAL video with this setup, there's no good refresh rate that could be used! I don't really understand your setup. It seems you're thinking that you don't ever need video mode deinterlacing. If that's the case then your list of refresh rates is ok, but then you should turn deinterlacing off or switch it to film mode. If you do that, madVR should switch to 75fps just fine.

2) Or, if you want to actually be able to play video mode PAL files, add 50fps, because that's the only way to properly play video mode PAL files.

3) I could modify the refresh rate logic a bit to pick 75Hz instead of 60Hz when madVR really wants to use 50Hz and it's not available (due to your bad config). But I'm not sure if that's really necessary. After all fixing your bad config should already fix the problem.

hannes69

2017-02-28 13:09

reporter   ~0001591

Thanks for clarification the problem in my setup.
I accept 1) as solution for me personally. Indeed I am thinking that I never will need video mode deinterlacing. I am one of those people who consider interlaced material as a kind of broken because of being interlaced...
I use paid online video streaming services and online TV mostly, all of this video material is normally progressive in my case.
The "bad" configuration is maybe an academic example, maybe it has practical relevance: when configuring several display modes, most people (or let´s say at least me) think mostly about fps and Hz. And we know it´s important that a) the refresh rate has to be as exact as possible and b) has to be a multiple of the frame rate. Considering interlaced material there would be c) the multiplier has to be even. When not thinking about c) and simply using madVR´s defaults, you achieve the "bad" configuration.
There´s another real point leading to this issue: When configuring display modes, there are physical limitations. My TFT monitor has a vertical refresh rate range of 56 - 75 Hz (datasheet numbers and EDID specs) and my projector 56 - 85 Hz (datasheet numbers and EDID specs). Ok, in reality both devices can be forced to use a custom resolution of 50Hz, but the "normal" way would maybe be to create display modes in the official valid range. And that would lead to the odd multiplier of 3 for 25fps material.
Saying all of that, I don´t consider this topic a bug anymore, but maybe an issue. It seems to be more a question of reasonable defaults. I personally don´t have the overview about the current world wide interlaced/progressive situation... I for myself intuitively thought: Yes, there is interlaced material, but this is some nostalgic stuff from yesterday. And people watching that probably should know how to set the right preferences in madVR because of making use of antique techniques ;) So I thought furthermore that madVR has the "right" defaults for watching today´s "normal" "modern" progressive content. Maybe I´m totally wrong about that... And then of course it is not madVR´s fault when some video files are flagged incorrectly.

madshi

2017-02-28 13:31

administrator   ~0001592

There's an overhaul of the whole display mode switcher planned for v1.0, which will probably resolve this problem altogether. For now, I think I can close this bug report.

FWIW, the pin connection reports the video file you had problems with as being "interlaced", so although you seem to think you have only progressive sources, this source is at least "sort of" interlaced.

Issue History

Date Modified Username Field Change
2017-02-28 00:40 hannes69 New Issue
2017-02-28 00:40 hannes69 File Added: debuglogs_OSDscreens.rar
2017-02-28 09:57 madshi Note Added: 0001590
2017-02-28 09:58 madshi Note Edited: 0001590
2017-02-28 09:59 madshi Assigned To => madshi
2017-02-28 09:59 madshi Status new => feedback
2017-02-28 13:09 hannes69 Note Added: 0001591
2017-02-28 13:09 hannes69 Status feedback => assigned
2017-02-28 13:31 madshi Note Added: 0001592
2017-02-28 13:32 madshi Status assigned => closed
2017-02-28 13:32 madshi Resolution open => no change required