View Issue Details

IDProjectCategoryView StatusLast Update
0000075madVRbugpublic2013-06-05 13:21
ReporterTheShadowRunner Assigned Tomadshi  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionwon't fix 
PlatformWin32OSWindows XP SP3OS Version5.1
Summary0000075: madVR rendering bug with Cinepak/CVID
DescriptionHi, madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up (big blocks).
In the exact same graph, replacing madvr by the VMRs or EVR solves the issue.

Steps To ReproducePlay this CVID sample file with madVR:
http://videoff7.free.fr/cvid_sample.avi
(see how the picture is flawed)

Then play the same file with the VMRs or EVR and see how OK it is ;)
TagsNo tags attached.
madVR Version0.86.2
Media Player (with version info)Zoom Player MAX v8.5
Splitter (with version info)AVI Splitter (quartz.dll) ver. 6.5.2600.6333
Decoder (with version info)Tried with both quartz.dll + iccvid.dll (1.10.0.13) or ffdshow rev4513
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOff
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU Model8500GT
GPU Driver Version320.18 WHQL

Activities

madshi

2013-06-05 13:21

administrator   ~0000159

It plays just fine on my PC when using MPC-HC. The chain seems to be LAV Splitter -> ffdshow Video Decoder -> madVR.

I can reproduce the issue with ZoomPlayer, which seems to use a different filter chain. The guilty one is not madVR, however, although the problem only occurs with madVR. The "decoder" in the ZoomPlayer chain expects that it always gets the same buffer for the frames. But madVR is feeding it different buffers, due to the madVR decoder queue. The madVR buffers happen to be zeroed out (black). The decoder expects every buffer to contain the last decoded image. This happens to be the case with VMR/EVR due to the way those renderers work. But relying on that is a pretty stupid behaviour by the decoder and IMHO a clear decoder bug. There's nothing I can do about this. Well, I could copy every decoded frame to the next queue buffer, but that would seriously cost performance for *every* decoder out there. So I'm not going to do that...

Issue History

Date Modified Username Field Change
2013-06-05 12:43 TheShadowRunner New Issue
2013-06-05 13:21 madshi Note Added: 0000159
2013-06-05 13:21 madshi Status new => closed
2013-06-05 13:21 madshi Assigned To => madshi
2013-06-05 13:21 madshi Resolution open => won't fix