madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000276madVRbugpublic2015-04-01 01:342015-04-04 09:19
Assigned To 
StatusclosedResolutionunable to reproduce 
Platformx64OSWindows 7 SP1OS Version7601
Summary0000276: Incorrect TV.601 Subtitle Colors with 'Trade Quality for Performance' when Upscaling Video
DescriptionWhen 'Optimize Subtitle Quality for Performance instead of Quality' is enabled and the video is upscaled, madVR is doing the following:

'supportedLevels' changed from [3] to [1]
'yuvMatrix' changed from [TV.709] to [None]

When madVR reports 'supportedLevels' [3] + 'yuvMatrix' [TV.709]:

XySubFilter performs internal rgb matrix correction, and reports 'yuvMatrix' [None] to madVR so it knows no to perform matrix correction again.

Subtitle colors are correct.

When madVR changes to 'supportedLevels' [1] + 'yuvMatrix' [None] in the middle of playback:

madVR is most likely triggering a known imitation in XySubFilter which I've informed you of before, that causes it to be unable to change the state of its 'internal rgb matrix correction' from enabled to disabled during playback. What likely occurs at that point, is XySubFilter continues to use 'internal matrix correction enabled' & 'TV output levels' yet misreports what its doing to madVR.

Subtitle colors are incorrect.

I've not double checked this recently, but I believe the following is true,

internal rgb matrix correction [False] -> internal rgb matrix correction [True] = Supported
outputLevels [PC] -> 'outputLevels [TV] = Supported

internal rgb matrix correction [True] -> internal rgb matrix correction [False] = Not Supported
outputLevels [TV] -> outputLevels [PC] = Not Supported

internal rgb matrix correction [True] ==
supportedLevels [3] + yuvMatrix [TV.709] + Script YCbCr Matrix [TV.601]

internal rgb matrix correction [False] ==
supportedLevels [0|1|2] + yuvMatrix [TV|PC.601|709|240M|FCC|2020] + Script YCbCr Matrix [TV|PC.601|709|240M|FCC|2020]
supportedLevels [3] + yuvMatrix [TV|PC.601|709|240M|FCC|2020] + Script YCbCr Matrix [TV|PC.709|240M|FCC|2020]

outputLevels [TV] == supportedLevels [3]

outputLevels [PC] == supportedLevels [0|1|2]
Steps To Reproduce*Enable, Optimize Subtitle Quality for Performance instead of Quality
*Upscale rec709 Video
*TV.601 Subtitle Colors are incorrect
Additional InformationRegression occurred starting with madVR 0.87.10

madVR 0.87.9 and prior are unaffected.

While I would like this limitation to be resolved, XySubFilter has no active developer currently so that may never happen unless someone submits a patch.

Either way, I'd hope this would be trivial for madVR to fix, since the 'supportedLevels' & 'yuvMatrix' fields changing only when the video is unscaled is rather unexpected behavior.
TagsNo tags attached.
madVR Versionv0.87.14
Media Player (with version info)MPC-HC
Splitter (with version info)LAV 0.64.0-37
Decoder (with version info)LAV 0.64.0-37
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU Manufacturer<select>
GPU ModelGTX 770
GPU Driver Version347.09
Attached Fileszip file icon [^] (5,426,561 bytes) 2015-04-01 01:34
zip file icon XySubFilter_Test_(madVR_Issue_276).zip [^] (1,574,011 bytes) 2015-04-03 11:37

- Relationships

-  Notes
cyberbeing (reporter)
2015-04-03 12:22
edited on: 2015-04-03 12:25

I've attached a build which should hopefully resolve the issue which prevented internal rgb matrix correction from being disabled until playback was restarted.

So now when madVR changes...

supportedLevels from [3] to [1]
yuvMatrix from [TV.709] to [None]

XySubFilter should change...

outputLevels from [TV] to [PC]
yuvMatrix from [None] to [TV.601] (script YCbCr Matrix)
disable internal rgb matrix correction

It only resolves the issue around 80% though, since if you resize the video when paused (particularly when there is reduced performance, like using the logging build or very quickly resizing after a seek) madVR will display subtitles with incorrect colors and levels until playback is resumed.

I've played around with the idea (not included in the attached build) of sending ISubRenderConsumer2::Clear() to madVR whenever it changes supportedLevels or yuvMatrix, which seems to resolve the issue when resizing when paused. Though it introduced a new problem, which sometimes causes a crash in free.c when maximizing the mpc-hc window when a subtitle is displayed (original size -> upscaled). It occurs in the thread, but madVR doesn't catch the exception so I'm unsure if the issue is madVR calling Free() or XySubFilter. Maybe it would be safer if madVR just flushed its queues itself when making such changes.

Still madVR even changing supportedLevels & yuvMatrix during upscaling (ignoring the users trade quality setting) is unexpected behavior, so once you fix that, the remaining cosmetic issues with such parameter changes may not even matter.

cyberbeing (reporter)
2015-04-04 04:33

Okay, I think this behavior may have been caused by an overlooked targetwidth parameter in one of my madVR profiles which was triggering different trade quality settings.

The strange part was that originally, this issue was occurring whenever the video was upscaled even a single pixel (without the targetwidth profile triggering). Though now after changing some settings I can no longer seem to reproduce that. Maybe it was a setting bug caused by adding more trade quality settings in the recent madVR builds, which resolved itself when the settings were toggled?

Since I can no longer figure out how to reproduce unexpected subtitle parameter changes without them being triggered by an active profile, I'm going to close this issue and assume it was just a fluke.

There is still an issue with how madVR goes about changing subtitle parameters when they are triggered by a profile, but that's nowhere near critical as I expect there are very few people who'd actually do this with profiles. Changing the order which parameters are sent and automatically flushing madVR's subtitle queue with certain changes may be something to consider for future builds though.

That gives me another thought. Maybe madVR could add a setting to delay switching to new profiles until after madVR's CPU/Subtitle queues have been displayed (only apply the new profile to new frames added to the queues). While this would add a delay in how long it would take for profiles to apply, I could see this being preferred to madVR flushing its queues in some cases.
madshi (administrator)
2015-04-04 09:19

During playback most setting changes only take affect for newly rendered frames. So the last wish in your post should already be true for most settings, as long as the settings change in the middle of playback. In paused state things are different, though. Many users are pausing playback and then play with the parameters and expect to be able to see the affect on image quality immediately, without having to restart playback, so paused state has totally different requirements.

- Issue History
Date Modified Username Field Change
2015-04-01 01:34 cyberbeing New Issue
2015-04-01 01:34 cyberbeing File Added:
2015-04-03 11:37 cyberbeing File Added: XySubFilter_Test_(madVR_Issue_276).zip
2015-04-03 12:22 cyberbeing Note Added: 0000917
2015-04-03 12:23 cyberbeing Note Edited: 0000917 View Revisions
2015-04-03 12:24 cyberbeing Note Edited: 0000917 View Revisions
2015-04-03 12:25 cyberbeing Note Edited: 0000917 View Revisions
2015-04-04 04:33 cyberbeing Note Added: 0000923
2015-04-04 04:34 cyberbeing madVR Version v0.86.14 => v0.87.14
2015-04-04 04:34 cyberbeing Status new => closed
2015-04-04 04:34 cyberbeing Resolution open => unable to reproduce
2015-04-04 09:19 madshi Note Added: 0000926

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker