View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000276 | madVR | bug | public | 2015-04-01 01:34 | 2015-04-04 09:19 |
| Reporter | cyberbeing | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Platform | x64 | OS | Windows 7 SP1 | OS Version | 7601 |
| Summary | 0000276: Incorrect TV.601 Subtitle Colors with 'Trade Quality for Performance' when Upscaling Video | ||||
| Description | When '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 Information | Regression 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. | ||||
| Tags | No tags attached. | ||||
| madVR Version | v0.87.14 | ||||
| Media Player (with version info) | MPC-HC 1.7.8.123 | ||||
| Splitter (with version info) | LAV 0.64.0-37 | ||||
| Decoder (with version info) | LAV 0.64.0-37 | ||||
| Decoding | Software | ||||
| Deinterlacing | none (progressive) | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | all modes | ||||
| GPU Manufacturer | <select> | ||||
| GPU Model | GTX 770 | ||||
| GPU Driver Version | 347.09 | ||||
|
|
|
|
|
|
|
|
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 madVR.ax 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. |
|
|
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. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-01 01:34 | cyberbeing | New Issue | |
| 2015-04-01 01:34 | cyberbeing | File Added: color_matched_typesetting.zip | |
| 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 | |
| 2015-04-03 12:24 | cyberbeing | Note Edited: 0000917 | |
| 2015-04-03 12:25 | cyberbeing | Note Edited: 0000917 | |
| 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 |
