MP1 EVR Presenter/dshowhelper community development (1 Viewer)

[tourettes]

This was one of the problems that got me started on this whole development thread a long time ago.....

What happens is that Windows will sometimes block the rendering until the next vsync (which shows up as the long render time), then sometime later it seems like a pipeline gets unblocked and it returns to normal.

I've never managed to work out why (and I've tried all sorts of ideas to fix/work around it). It got much less frequent when the vsync correction was added, but it still happens sometimes - and it sometimes seems worse with 24Hz video...

My theory for that render time jump and then one dropped frame when it returns is quite simple. Reference clock is running a bit different speed than the GPU's HW clock and therefore there is drifting between those two clocks. At some point it is not possible to present on the targeted v-sync and then it will cause all the paint times to jump up approx the amount of one display refresh cycle.

I would suggest to try the MediaPortal Audio Renderer since it was build to combat that issue. I haven't ever seen that issue to appear during almost two years that I have been developing / using MPAR At least it is worth to try to see if the issue goes away. If it goes then there are only two possible solutions: 1) to use MPAR or 2) to find some HW combination that matches 1:1 on the video and audio clocks.

 

[peque]

I don't use MPAR (neither ReClock) because I bitstream all my audio to my AVR...

Could MPAR help anyway?

 

[mylle]

dshowhelper v92dwm and NoStopMod50 gives me this error trying to play live tv (UNC path)

2012-03-19 21:51:43.840726 [ERROR][MPMain(1)]: TSReaderPlayer: Exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2012-03-19 21:51:43.852727 [ERROR][MPMain(1)]: TSReaderPlayer:GetInterfaces() failed

any idea?

regards
Jacob

 

[tourettes]

I don't use MPAR (neither ReClock) because I bitstream all my audio to my AVR...

When bitstreaming it wont be possible to alter the audio stream in any way, so it wont be possible use audio renderer to correct the clocks (if they are source of the issue).

Could MPAR help anyway?

For pin pointing the possible source of the issue it could - but if you must use bitstreaming then it wont be able to do anything.

 

[Owlsroost]

My theory for that render time jump and then one dropped frame when it returns is quite simple. Reference clock is running a bit different speed than the GPU's HW clock and therefore there is drifting between those two clocks. At some point it is not possible to present on the targeted v-sync and then it will cause all the paint times to jump up approx the amount of one display refresh cycle.

EVR presenter always presents at approximately the same position relative to vsync (either because it's being internally controlled or under MPAR control) - so any frame drops or repeats should happen inside EVR presenter (and they do).

But this flip-flopping between normal and long render times still happens occasionally, so I suspect the 'vsync' the Windows (DWM?) render queue uses isn't always the same timing as the GPU version (which is effectively what EVR presenter is using for it's raster timing reference).

I'd love to see how EVR/DWM render pipeline actually works internally

Tony

 

[Owlsroost]

Peque - does it change the stuttering behaviour if you pause TV for short period ?

(Just wondering what the possible differences between running the same graph with GraphStudio and MP might be - the start-up timing might be different, which will change the amount of data buffered in the various filters)

Tony

 

[peque]

I don't use MPAR (neither ReClock) because I bitstream all my audio to my AVR...

When bitstreaming it wont be possible to alter the audio stream in any way, so it wont be possible use audio renderer to correct the clocks (if they are source of the issue).

Could MPAR help anyway?

For pin pointing the possible source of the issue it could - but if you must use bitstreaming then it wont be able to do anything.

Ok... so I'll try MPAR just disabling SPDIF out, and let's see what happens... if it definitely helps, I can think of using different audio decoder for TV and for offline content (I'm satisfied with offline content behaviour), and then decode DD/DD+ audio pids inside broadcasts and pass plain multichannel PCM to AVR... I don't think I loose quality in the process...

Peque - does it change the stuttering behaviour if you pause TV for short period ?

(Just wondering what the possible differences between running the same graph with GraphStudio and MP might be - the start-up timing might be different, which will change the amount of data buffered in the various filters)

Tony

MMMmm.. It's so sporadic and random, that I don't really think I'm able to see any difference after pausing... I'll test. What's for sure is that MP acts different than GS or any other player in my system... We should be able to find the culprit at least...

Thanks both a lot. Really.

 

[mylle]

dshowhelper v92dwm and NoStopMod50 gives me this error trying to play live tv (UNC path)

2012-03-19 21:51:43.840726 [ERROR][MPMain(1)]: TSReaderPlayer: Exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2012-03-19 21:51:43.852727 [ERROR][MPMain(1)]: TSReaderPlayer:GetInterfaces() failed

any idea?

regards
Jacob

Owlsroost.

Any take on this?

 

[Owlsroost]

dshowhelper v92dwm and NoStopMod50 gives me this error trying to play live tv (UNC path)

2012-03-19 21:51:43.840726 [ERROR][MPMain(1)]: TSReaderPlayer: Exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
2012-03-19 21:51:43.852727 [ERROR][MPMain(1)]: TSReaderPlayer:GetInterfaces() failed

any idea?

regards
Jacob

Owlsroost.

Any take on this?

No idea, but you haven't posted any logs.......

Does it happen always, or just when timeshifting ?

Tony

 

[grubi]

I don't use MPAR (neither ReClock) because I bitstream all my audio to my AVR...

Could MPAR help anyway?

Same for me.

However what I don't understand why in my old days before MP ReClock helped here a lot although I was bitstreaming to an external receiver.

IIRC in the logs of ReClock I saw that it sporadically added (duplicated) or dropped AC3 frames and so you got a smooth motion picture wise. The audio drops or repeats weren't noticable by any chance.

Cheers