Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[Zachs]

@AnimeViewer
BTW, the dump file is located in %localappdata%\MediaPlayerDotNet.exe.dump
Can you check if you have such a file please?

[Zachs]

I paused a scene where there are a couple of different shades of red, but I'm not seeing a difference between it being enabled/disabled.
Does the video have to be running in Full Screen Exclusive Mode for the improvement to happen?
How about settings? Any particular ones that might make it stand out more, or where other effects might make it less noticeable? (For example: with or without render scripts running, with or without debanding, with or without dithering, with any particular Presentation API (D3D 11, 10.1, 9Ex), with any particular color settings (ex: PC Range BT 601, 709 or 2020, Full or Limited Output, 8,10,or 16 bit bit depth, using any particular up/down scalers?

Run it without render scripts. Bright fully saturated red is the easiest to see the changes.
EDIT: This is assuming the proper colorimetric has been used. If the encoder lied about it then that's a separate issue.

[Anime Viewer]

@AnimeViewer
BTW, the dump file is located in %localappdata%\MediaPlayerDotNet.exe.dump
Can you check if you have such a file please?

Ah ha! I found it there. Here is the dump which I opened and copied from Notepad:


*** Thread 1 ***

Stack Trace:

Mpdn.VideoFrameServices.DxgiPresenter.DxgiPresentEx(IntPtr, Int32)
Mpdn.VideoFrameServices.DxgiPresenter.DxgiPresentEx(IntPtr, Int32)
DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Int32)
Mpdn.D3D9VideoRenderer.FrameComposer.Dx11.FrameComposer.Present(Int64 ByRef)
Mpdn.D3D9VideoRenderer.VideoRenderer.PresentInternal(Int64 ByRef)
Mpdn.D3D9VideoRenderer.VideoRenderer.Present(Boolean, Boolean, SharpDX.Result ByRef, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present(Boolean, SharpDX.Result ByRef, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.WaitAndPresent(Int64, Int64, Boolean, Boolean, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present(Int64, Int64, Boolean, Int64 ByRef)
Mpdn.VideoPlayer.VideoPlayer.Present()
Mpdn.VideoPlayer.VideoPlayer.PresentSample(Mpdn.VideoPlayer.MediaSample)
Mpdn.VideoPlayer.VideoPlayer+<>c__DisplayClass2.<set_EnableFullScreen>b__0(Boolean)
Mpdn.VideoPlayer.VideoPlayer.SyncRendererInvoke(System.Action`1<Boolean>)
Mpdn.VideoPlayer.VideoPlayer.set_EnableFullScreen(Boolean)
MediaPlayerDotNet.MainForm.†††
††††��()
MediaPlayerDotNet.MainForm.†††
††††�›()
MediaPlayerDotNet.MainForm.†††
†††‡ˆŽ(System.Object, System.Windows.Forms.MouseEventArgs)
System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int32, Int64, Int64)
System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef)
System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
†††
†††‡•š.†††
†††‡•™.†††
†††‹�•(System.Object)
†††
†††‡•š.†††
†††‡•™.†††
†††‡•›(System.Object)
<PrivateImplementationDetails>{B078818A-34A0-41B9-9995-5CD01146F517}.Main(System.String[])



-------------------------------------------------------------------------------------------


*** Thread 2 ***

Stack Trace:




-------------------------------------------------------------------------------------------


*** Thread 4 ***

Stack Trace:

System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)
Mpdn.Threading.TaskThread.DoWork()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()




-------------------------------------------------------------------------------------------


*** Thread 10 ***

Stack Trace:

System.Windows.Forms.UnsafeNativeMethods.WaitMessage()
System.Windows.Forms.UnsafeNativeMethods.WaitMessage()
System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()




-------------------------------------------------------------------------------------------


*** Thread 13 ***

Stack Trace:

System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
Mpdn.VideoPlayer.DirectShowVideo.HandleEvents(Microsoft.Win32.SafeHandles.SafeWaitHandle, Microsoft.Win32.SafeHandles.SafeWaitHandle)
Mpdn.VideoPlayer.DirectShowVideo.HandleEvents(System.Object)
Mpdn.Threading.WorkerThread+<>c__DisplayClass6.<.ctor>b__4(System.Object)
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart(System.Object)




-------------------------------------------------------------------------------------------


*** Thread 14 ***

Stack Trace:

System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
Mpdn.VideoPlayer.VideoPlayer.PresentLoop()
Mpdn.Threading.WorkerThread+<>c__DisplayClass2.<.ctor>b__0()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()




-------------------------------------------------------------------------------------------


*** Thread 15 ***

Stack Trace:



System.Threading.Monitor.Enter(System.Object)
Mpdn.VideoPlayer.VideoPlayer.RenderLoop()
Mpdn.Threading.WorkerThread+<>c__DisplayClass2.<.ctor>b__0()
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
System.Threading.ThreadHelper.ThreadStart()




-------------------------------------------------------------------------------------------


*** Thread 18 ***

Stack Trace:



System.Threading.Monitor.Enter(System.Object)
Mpdn.VideoPlayer.VideoPlayer.UpdateVideoFrame(Mpdn.VideoPlayer.MediaSample)
Mpdn.VideoPlayer.DirectShowVideo.Mpdn.VideoPlayer.ICallbackFilterCB.SampleCb(Int64, DirectShowLib.IMediaSample)
DomainBoundILStubClass.IL_STUB_COMtoCLR(Int64, IntPtr)



-------------------------------------------------------------------------------------------

[ryrynz]

I paused a scene where there are a couple of different shades of red, but I'm not seeing a difference between it being enabled/disabled.

I've just done a number of comparisons on fairly red scenes and the changes are made on edges mostly. I've found the changes on either brownish or whiteish edges/areas, but yeah the changes are very subtle.. most of the time you actually won't notice them.

[Zachs]

Ah ha! I found it there. Here is the dump which I opened and copied from Notepad:

Right. Just as I feared.
I'll continue this in PM with you since it looks like it's specific to your Optimus system only.

[ryrynz]

but yeah the changes are very subtle.. most of the time you actually won't notice them.

This is the best example of the changes chroma reconstruction makes I've seen so far. The changes are certainly more noticeable with sharper resizers (lanczos, NNEDI3) These were taken using Lanzcos 16 tap AR.
The whites really do lighten up here, probably one of the best examples I could have hoped to find as all other changes have been relatively minor.

http://screenshotcomparison.com/comparison/128955

[huhn]

so it tries to counter the tons of artifacts from lanczos 8/16?

[Zachs]

No. It uses the information that would've otherwise been disposed off so it gives better quality.

[huhn]

No. It uses the information that would've otherwise been disposed off so it gives better quality.

why is lanczos 16 is needed than to show something off there must be better examples.

[Zachs]

Lanczos 16 causes more values to go out of range after scaling so the effect is more profound.

[Zachs]

As long as I set the Video Input Colormetric to one of the PC Ranges it looks fine, but if my system mis-detects the video, and sets it to one of the TV Ranges (while set to automatic) then I get the results I previously posted.

Righto! I found a bug in MPDN's automatic colorimetric detection logic! Specifically if the 720p clip doesn't have actual a height of 720 pixels, it assumes it's not HD!

This has been fixed in the next release.

Many thanks to ryrynz for discovering this.

[huhn]

does it work with RGB sources or 4.4:4 source?

[huhn]

here an extreme example:

http://screenshotcomparison.com/comparison/128957

i crippled a RGB source to 4:2:0 to make it work.

it turns some pixel totally black that shouldn't be black but i guess it gives an idea what it does.

[Zachs]

Depending on how you're scaling your chroma. If you scale it to target size directly with something like lanczos 16 then it may have some effect. I suspect you won't be able to see any difference but I haven't tested this myself.

[Zachs]

here an extreme example:

http://screenshotcomparison.com/comparison/128957

i crippled a RGB source to 4:2:0 to make it work.

it turns some pixel totally black that shouldn't be black but i guess it gives an idea what it does.

Is your RGB source closer to CR on or off?

EDIT: If you look closely at the disabled icons on the sidebar, you'll find CR on to do exactly what was intended to. There's no colour bleed at all and it shows a clear alternating pattern that I would image what the original looked like.

[huhn]

Is your RGB source closer to CR on or off?

yes and no.

the luma is closer the chroma is way off with CR on

EDIT: let me say it with other more correct words.

it removes chroma bleeding and under saturates chroma. most parts where chroma details shouldn't by they are not there anymore so the "luma" looks way more correct.

[Zachs]

Well it's done its job then!
But can you post the RGB and crippled version of that clip somewhere so we could take a look at it to see if we could improve it?

[ryrynz]

Hey Huhn can you link the 4:2:0 and the RGB source? I think that might be useful for tweaking chroma.

I guess ideally I'd really like to get my hands on a proper chroma test pattern to compare in that way to find accurate to the source chroma upscaler settings.

[huhn]

here is the RGB version.

http://www.file-upload.net/download-10648434/schweif_000-001.mkv.html

i forced lavfilter to NV12 output to get a 4:2:0 video of this so i don't have an encode of it.

but not sure if a normal video should be judge on a pixel art video like this.

[Zachs]

The same principal applies to normal video - chroma bleed is never desirable.

[huhn]

but who good is the studio downscaler compared to lavfilters?

[Zachs]

The problem there is the crippled chroma is just that - no 'good studio downscaler' exists that could 'retain' that information because it just isn't there - it had to be chucked out. If there's such a thing, then all we need for image upscaling would be nearest neighbour and hope that all downscalers are 'good studio downscalers'.

[huhn]

The problem there is the crippled chroma is just that - no 'good studio downscaler' exists that could 'retain' that information because it just isn't there - it had to be chucked out. If there's such a thing, then all we need for image upscaling would be nearest neighbour and hope that all downscalers are 'good studio downscalers'.

i don't say your idea is wrong in general or bad at all. no it does a very good job on this source with some major artifacts for now.

just look at the eyes they are black again like they should be.

i just say it shouldn't be judge on a source that is nearly for sure downscaled with bilinear and a pixel art game.

it very interesting to see that black pixels are really good reconstructed but white pixels not "at all".

[Zachs]

it very interesting to see that black pixels are really good reconstructed but white pixels not "at all".

Not sure I understand what you're saying. Care to explain further?

[Shiandow]

yes and no.

the luma is closer the chroma is way off with CR on

EDIT: let me say it with other more correct words.

it removes chroma bleeding and under saturates chroma. most parts where chroma details shouldn't by they are not there anymore so the "luma" looks way more correct.

In theory SuperChromaRes should add the removed chroma back in again, at least partially.

[ryrynz]

Hey huhn when looking at the video you posted I'm not seeing that same image quality you posted as the CR off image..
With your image if you look at the inside of the wizards sleeves, it's brown rather than black, also the third square under the mountains the blue sky has bleeding.
How did you get that to happen? My results are quite different.

http://i.imgur.com/z4mTT1Rm.png (http://i.imgur.com/z4mTT1R.png) (bicubic 100 AR used for luma and chroma)

[huhn]

Not sure I understand what you're saying. Care to explain further?

this is what i mean.

1 RGB
2 reconstructed
3 normal
http://abload.de/img/rgbg4j01.png

the eye white is still totally gone but the black part is a lot better with your algo.
i'm way over my english limited here.

In theory SuperChromaRes should add the removed chroma back in again, at least partially.

i didn't compared them. i just wanted to show the effect and the source did a good job on this.

if your superres can do this in the same or better way feel free to show that. source is linked

[huhn]

Hey huhn when looking at the video you posted I'm not seeing that same image quality you posted as the CR off image..
Look at the inside of the wizards sleeves, it's brown rather than black, also the third square under the mountains the blue sky has bleeding.
How did you get that to happen?

http://imgur.com/z4mTT1R

i had a 3D LUT load that has something to do with the black level.
but this should be the last part of the chain so it should affect the algo.

don't forget the source you have is RGB you have to force lavfilter to use nv12 as output by disabling all other formates this looks clearly like RGB input.

your gamma is way higher than on my screenshot even without 3D LUT.

i used spline 6 not sure anymore.

[Zachs]

Oh 3DLUT does affect your screen capture - how could it not?

[Zachs]

if your superres can do this in the same or better way feel free to show that. source is linked

Shiandow knows what he's talking about as always. He created the algo!

[huhn]

Oh 3DLUT does affect your screen capture - how could it not?

it doesn't alter the algorithm not the picture it self.

of cause it remaps the colors.

it's like using bt 601 on a bt 701 source at the end your algorithm doesn't care.

[Zachs]

it doesn't alter the algorithm not the picture it self.

of cause it remaps the colors.

it's like using bt 601 on a bt 701 source at the end your algorithm doesn't care.

I meant that'll probably account for the brown on your screen capture vs ryrynz's black.

[ryrynz]

I meant that'll probably account for the brown on your screen capture vs ryrynz's black.

Yup, my thoughts exactly.

[Anime Viewer]

Righto! I found a bug in MPDN's automatic colorimetric detection logic! Specifically if the 720p clip doesn't have actual a height of 720 pixels, it assumes it's not HD!

This has been fixed in the next release.

Many thanks to ryrynz for discovering this.

Interesting...I'll look forward to testing it out in the next release. I wasn't crazy about having the Video Input Colormetric forced to a setting, and would prefer to leave it at automatic (as long as it can detect the video properly). The video mis-detections weren't limited to 720p clips in my testing. I was seeing it in 480 videos as well. Two of those was reported as video 848x480 with it reporting a target rectangle of 853x480 in its default window, and of course 1920x1080 for target when I expanded it to full screen. (The video I posted screen shot(s) of was of those dimensions).
Did you test other video resolutions beside 720p for that same type of bug?

[huhn]

ok i see what you mean but this is the result i get with EVR CP.

http://abload.de/img/evrcp4aoa0.png

totally different from ryrynz

[ryrynz]

Here's a comparison (http://screenshotcomparison.com/comparison/128966) of CR off vs CR on with that output via NV12.

The significant changes are in the blue pixelated area in the third square under the hills (loses a lot of blue bleeding) and artefcats that are now visable around the clouds in the sky with the hills.

[ryrynz]

ok i see what you mean but this is the result i get with EVR CP.

http://abload.de/img/evrcp4aoa0.png

totally different from ryrynz

Your screenshot is a different size, but looks almost identical to my shot with CR off above.

[Zachs]

Interesting...I'll look forward to testing it out in the next release. I wasn't crazy about having the Video Input Colormetric forced to a setting, and would prefer to leave it at automatic (as long as it can detect the video properly). The video mis-detections weren't limited to 720p clips in my testing. I was seeing it in 480 videos as well. Two of those was reported as video 848x480 with it reporting a target rectangle of 853x480 in its default window, and of course 1920x1080 when I expanded it to full screen. (The video I posted screen shot(s) of was of those dimensions).
Did you test other video resolutions beside 720p for that same type of bug?

No. Ryrynz pointed out that if you tried downloading youtube videos, the stream encoding info isn't copied across, so for anything below height of 720 and width of 1280, bt.601 has to be assumed. There's nothing a player can do in that case - blame the faulty container repackager.

EDIT: In this situation you can toggle the YUV matrix via shortcut (Ctrl+Shift+M) until you get to the correct one.

[madshi]

Just wondering: Is there a specific reason why "Improve Chroma Reconstruction" is available as a separate option in addition to also being part of SuperChromaRes?

FWIW, I had experimented with a similar algo some time ago but removed it again because it produced artifacts with some sources. @Shiandow, did you find a way to get rid of those artifacts in your SuperChromaRes shader?

[Zachs]

So long as your yuv matrix is correct, I have yet to find a clip that shows any artefacts. I've tested over 50 clips so far. Trouble is a lot of them don't say they're using PC range when encoded as such!

[nevcairiel]

So long as your yuv matrix is correct, I have yet to find a clip that shows any artefacts. I've tested over 50 clips so far. Trouble is a lot of them don't say they're using PC range when encoded as such!

Just because a clip uses out-of-range chroma values doesn't mean its actually supposed to be PC range. Sometimes its just the way it is, same reason BTB and WTW are a thing.
Actual PC range content is very rare, practically only exist in video game recordings and things similar to that.

[Zachs]

How would you be able to tell one from the other? Wouldn't a BTB / WTW source look exactly like it's using PC ranges? In which case, we are back to square one, which is how do we tell one apart from the other?

[madshi]

BTB/WTW values can occur even if the source is limited range. E.g. ringing (due to scaling or sharpening) can cause that. I've also seen one authoring guy writing on some forum saying that he had to use some BTB values on some DVD encoding to make the color look "right". Then there are also some broadcasts where there's no BTB content, but some WTW data... :(

[Shiandow]

Just wondering: Is there a specific reason why "Improve Chroma Reconstruction" is available as a separate option in addition to also being part of SuperChromaRes?

FWIW, I had experimented with a similar algo some time ago but removed it again because it produced artifacts with some sources. @Shiandow, did you find a way to get rid of those artifacts in your SuperChromaRes shader?

Well I did find a way to remove some of them, but unfortunately not all of them. Some sources seem to want values that are not just a little impossible, but entirely impossible. There might be ways to lessen the artefacts, but I'm not sure if there's a way that doesn't look weird with at least some sources.

[Zachs]

BTB/WTW values can occur even if the source is limited range. E.g. ringing (due to scaling or sharpening) can cause that. I've also seen one authoring guy writing on some forum saying that he had to use some BTB values on some DVD encoding to make the color look "right". Then there are also some broadcasts where there's no BTB content, but some WTW data... :(

Ouch. These non standard encodes using btb/wtw are quite troublesome as they contain no additional info on their metadata as to whether they're actually using them. That's no different to chroma offset.

Anyway it's an option that's disabled by default with a warning that says not all sources are compatible. If they follow the standards strictly then there would be no problem enabling the option.

Those sources that use btb/wtw really have to be considered broken. I mean, how would they expect standard of the shelf set top boxes to handle the contents correctly when sophisticated software are missing info to decode them?

[huhn]

Here's a comparison (http://screenshotcomparison.com/comparison/128966) of CR off vs CR on with that output via NV12.

The significant changes are in the blue pixelated area in the third square under the hills (loses a lot of blue bleeding) and artefcats that are now visable around the clouds in the sky with the hills.

input is 16 bit 4:4:4 not 8 bit 4:2:0.

that's why the effect is so little

[nevcairiel]

Those sources that use btb/wtw really have to be considered broken. I mean, how would they expect standard of the shelf set top boxes to handle the contents correctly when sophisticated software are missing info to decode them?

They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.
BTB and WTW is more common than you might think, and I don't think simply calling it broken is a solution.

There is a reason why any YUV->RGB conversion formula includes a clipping step.. :)

PS:
xvYCC is a Blu-ray standard that encodes extended color ranges in the "out of range" chroma values.

[huhn]

They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.

i usually make the player clear that this file is PC range.

of cause i'm talking about a source with full PC range not some WTW parts no one will ever miss.

[Zachs]

Yeah I guess that makes sense.

Edit: I have just spent the last couple of hours retesting the clips with artefacts and they turn out to be genuine PC ranges that did not have their bitstream reporting it properly. I have to say so far I haven't encountered any btb/wtw ones yet, or at least they haven't caused any problems with the algo. It's easy to find out if they are meant to be PC ranges. If the whites are blown out in TV ranges but reveal extra details in PC ranges then it's not reporting it correctly. I went the extra step to verify that with screen capture and checking its actually a blown out and not just my display being inept at showing bright details.

At this point, I have to say it's actually very common to have a source with PC range! Which comes back to the original question I had now that both are common - how do we detect them? If we don't, and simply assume they are TV ranges then they're always going to be blown out with their whites and the opposite with their blacks. In the office, we have some IP cameras that record using those btb/wtw ranges but report they are encoding in TV range. These are expensive hardware from renown companies which I won't name, but they don't appear to care that they aren't recording in the range they're told. Needless to say the recordings need manual matrix override.

I'll stand by what I said earlier - so long as the matrix is set correctly, improve chroma reconstruction should work just fine. If you have some materials that would prove otherwise, I'd love to give it a go.

[Shiandow]

They decode just fine. Its your "sophisticated" extra algorithms that barf up on them. A simple decode and RGB conversion will just clip the extra values and they look and feel just fine.
BTB and WTW is more common than you might think, and I don't think simply calling it broken is a solution.

There is a reason why any YUV->RGB conversion formula includes a clipping step.. :)


All "Improve Chroma Reconstruction" is is just a different way of clipping those values. It tries to make sure that the luma remains correct. Of course some sources insist on making parts of the image simultaneously black and bright red, which doesn't work well.