MP1 EVR Presenter/dshowhelper community development (1 Viewer)
- Thread starter Owlsroost
- Start date
Denmark
55f seems to work (crash was related to the .NET itself - it was some internal .NET error, hopefully the missing update sorted out that one...). Also havent seem the stalled video again.
Now I have been experimenting with the 92 DWM and non-DWM versions. To be honest I get really bad results with those. They both are unusable on GT9500 + older AMD 2.0Ghz dual core.
92 DWM
92 DWM
non-DWM is better of those two since it wont have the juddering without dropped frames "effect" the DWM has. When compared to 55f the 92 has around 50 to 60x times more dropped frames!
The code between the previous dshowhelper.dll that I have been working with and the 92 one has had so much changes that I don't know even where to start to look for the root of the issue.
So, where to start to look for the fix? 92 is so bad on the setup I have that it just cannot be used at all.
Now I have been experimenting with the 92 DWM and non-DWM versions. To be honest I get really bad results with those. They both are unusable on GT9500 + older AMD 2.0Ghz dual core.
92 DWM
- lot of dropped frames
- random judder (not seen as dropped or late frames) - looks like few frames aren't rendered at all (AERO skips those?)
- non 1:1 material has random way of repeating the frames (not constant one per second on 23.976 to 50 - it could be no or up to three repeated frames per second) - this looks worser to eyes than the pattern that 55f has.
- Paint times are much longer than with 55f (has the target v-sync changed? It could explain it probably)
92 DWM
- lot of dropped frames
this looks worser to eyes than the pattern that 55f has. - Paint times are much longer than with 55f (has the target v-sync changed? It could explain it probably)
non-DWM is better of those two since it wont have the juddering without dropped frames "effect" the DWM has. When compared to 55f the 92 has around 50 to 60x times more dropped frames!
The code between the previous dshowhelper.dll that I have been working with and the 92 one has had so much changes that I don't know even where to start to look for the root of the issue.
So, where to start to look for the fix? 92 is so bad on the setup I have that it just cannot be used at all.
Attachments
Few questions after a quick peek into the code.
Shouldn't that be same as the real display has? In my case 720.
What is the benefit of using WaitFor...() instead of Sleep(). Timers Tutorial - CodeProject . We probably should check queue timers or multimedia timers. WaitFor...() is probably as inaccurate as the Sleep().
Locks in MyQueue - why those were removed? Wont it now open a window to present same sample twice when there are multiple thread working with the same data structure?
Code:
m_maxVisScanLine = 1080;Shouldn't that be same as the real display has? In my case 720.
Code:
m_dummyEventWhat is the benefit of using WaitFor...() instead of Sleep(). Timers Tutorial - CodeProject . We probably should check queue timers or multimedia timers. WaitFor...() is probably as inaccurate as the Sleep().
Locks in MyQueue - why those were removed? Wont it now open a window to present same sample twice when there are multiple thread working with the same data structure?
- Thread starter
- #1,366
Hi Tourettes,
The queue locking is done elsewhere - it seemed pointless to leave the locking code in MyQueue as well.
The multimedia timers are deprecated by MS (I took them out of EVR presenter ages ago, when the Scheduler moved to using WaitForMultipleEvents), and yes, the 'dummyEvent' timers are just used as an alternative to Sleep() (never been sure which is the more accurate.....)
'm_maxVisScanLine' is set to the correct value when the refresh rate estimator runs (the raster details are in the evr.log - see 'Max visible scanline:' etc)
The v-sync target is a little bit later on v0092, but there are some fairly experimental mods in that version, so you might want to try v0084 to see if that's any better ?
(and/or v0088 or v0088a or v0089/v0089a )
EDIT: v0088/v0088a is the last version before I started playing around with changes to try and improve things for BBC HD DVB-T2 channel in the UK, but I'm not sure now if it really makes a difference so I might revert those changes back - they are probably the cause of the the uneven 24Hz frame repeat issue you are seeing
Tony
The queue locking is done elsewhere - it seemed pointless to leave the locking code in MyQueue as well.
The multimedia timers are deprecated by MS (I took them out of EVR presenter ages ago, when the Scheduler moved to using WaitForMultipleEvents), and yes, the 'dummyEvent' timers are just used as an alternative to Sleep() (never been sure which is the more accurate.....)
'm_maxVisScanLine' is set to the correct value when the refresh rate estimator runs (the raster details are in the evr.log - see 'Max visible scanline:' etc)
The v-sync target is a little bit later on v0092, but there are some fairly experimental mods in that version, so you might want to try v0084 to see if that's any better ?
(and/or v0088 or v0088a or v0089/v0089a )
EDIT: v0088/v0088a is the last version before I started playing around with changes to try and improve things for BBC HD DVB-T2 channel in the UK, but I'm not sure now if it really makes a difference so I might revert those changes back - they are probably the cause of the the uneven 24Hz frame repeat issue you are seeing
Tony
Tony,
Can you elaborate on what things you mean for BBC-HD here? I'm seeing some issues on it and wondered if they're the same, or I have more tracking down to do in my setup.
Basically, the easiest way for me to see is wait until BBC News comes on BBC1 HD (I assume this is the same as BBC HD with regards to encoding) late at night, then watch the ticker. Most of the time, it runs smooth, but occasionally, it will look juddery for a period of time, almost like the deinterlacing isn't quite right - and then after some random period of time, it will fix itself and go back to being perfectly smooth.
I took a recording of it and it happens in the recording at exactly the same place every time. Is this the sort of thing you're referring to?
I have previously tried just about every dshowhelper posted here but they all exhibit the same behaviour.
- Thread starter
- #1,368
It's specifically BBC HD (not BBC1 HD) on terrestial (DVB-T2) - it uses experimental H264 encoding which switches between 50i and 25p dynamically depending on picture content. It's a pain because some codecs don't handle it correctly (PDVD11 seems to be the best I've tried), and dshowhelper can cause stutters after the 50i/25p transitions while it adapts to the new frame rate.
Your problem sounds different - can you post a screen capture with the render stats displayed (Shift + 1 (!)) when it's happening ?
Tony
Well how annoying, I now can't reproduce it all of a sudden. I did spend last night upgrading 1.2.0RC to 1.2.1 though, in the process nuking all the fiddling I've done with MediaPortal Audio Renderer and various dshowhelpers. If I can get it to happen again I'll report back. I guess I should be happy it's gone but the cause is still unknown.
Edit: new post..
Weirder and weirder, it's back. Without any configuration changes. Now I'm really confused about what made it go away for seemingly an hour.
Anyway:
http://kojan.telon.net/bbcnews_juddering.png
http://kojan.telon.net/bbcnews_no_juddering.png
The first one has the judder present and the second one, shortly afterwards, it's gone again.
For completeness, the ts too:
http://kojan.telon.net/bbcnews.ts