[other] Problems with dropping frames with EVR (2 Viewers)

[OnkelChris]

AW: Problems with dropping frames with EVR

attached you'll find logs with a lot of scheduling sample from the past - (i think this should be dropped frames or otherwise audio and video get's out of think)

2010-02-08 19:10:50.411595 [ERROR][MPMain(1)]: TvPlugin and TvServer don't have the same version.
TvServer Version: 1.0.4.24975
TvPlugin Version: 1.0.4.24980

Shouldn't this be the same version?

 

[disaster123]

AW: Problems with dropping frames with EVR

OnkelChris
it should but it doesn't matter if there are no changes in the server arch. Look in SVN these 5 changes are absolutely irrelevant

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

@belcom
already tried that - also i'm using Maya instead - but there were more german people in the svn thread who have this problem... really strange. No idea what to check.

Maya uses HTPCInfo plugin? It is know to cause dropped frames (please disable that plugin while testing). Author will fix the plugin in future releases.

Maya uses infoservice, which as I understand is NOT the same as HTPCinfo.

Oh, sorry for mixing up the plugins. Not sure which one that problematic one was/is But in any case no 3rd party plugins should be used (and that means no skins that reguire plugins) when troubleshooting something like dropped frames or stuttering playback.

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

attached you'll find logs with a lot of scheduling sample from the past - (i think this should be dropped frames or otherwise audio and video get's out of think)

Correct. Each late sample rendered instead of dropped in such cases introduces a desync of audio and video of the frame duration time (20ms at 50Hz). A solution is not about handling late samples differently but making sure they don't arrive late in the first place.

"Scheduling samples from the past" indicate that a thread didn't wake up in time because other threads are interfering or painting the last frame took too long. You can spot this when the sleep time is larger than the amount of ms a sample is late as in the example logs. In theory it should have been possible to present the frame on time but something prevented this.

There should be an absolute minimum of these messages. If you have a lot of them something seriously is wrong with the scheduling on the affected machine. You usually have a this for the first few frames when a direct show graph starts or after pausing/resuming, which is perfectly ok.

In theory you could re-schedule samples multiple times instead of only once up some part of the presentation time delta for rendering. But this will break the 1:2 fps/Hz ratio scenario and introduces stuttering at non 1:1 fps/Hz playback. So it's a trade off with MP1 at the moment. You have 1:1 application very smooth and seriously break 1:2 applications or vice versa. Or you try to find a middle ground that introduces as few problems as possible for most of the machines and applications.

Also LiveTV seems to be way more affected at the moment for yet unknown reasons.

In regards to sync glitches: you can safely ignore them. It's just for informational purposes that something is not optimal but it doesn't result in stuttering or dropped frame. It's from an theoretic point of view. Also drifting lines in the graph are nothing to worry about as long as this is happening slowly. Extreme jumping lines with huge number of dropped frames pointing to a general issue affecting all machines.

 

[tourettes]

Still waiting the patch to arrive

 

[OnkelChris]

AW: Problems with dropping frames with EVR

attached are the changes in a patch file... Please don't blame me. I am just at the very beginning...

Also tried different code changes, but nothing seems to really help...

gemx:
Can't reproduce your issue.

So if anybody could provide a recorded HD sample 1080i wihich is about 30 seconds, this would be great!

 

[tourettes]

It plays 1080i Live-Tv absolutely smooth (much better than SVN one) BUT it seems to freeze every 15-20 seconds for 1-2 seconds. Between these freezes it works great.

Freezing is most likely happening because audio and video sync is drifting (late frames arent dropped by the patch).

 

[OnkelChris]

AW: Problems with dropping frames with EVR

if we drop late frames, video on my system is endless stuttering... this modifications are just the beginning of my investigations. I'm trying to get rid of the stuttering without "hacking" your nice peace of code

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

if we drop late frames, video on my system is endless stuttering... this modifications are just the beginning of my investigations. I'm trying to get rid of the stuttering without "hacking" your nice peace of code

You need to drop the late frames, otherwise video and audio sync will drifts slowly apart. Just read Scythes post it will explain it.

 

[OnkelChris]

AW: Problems with dropping frames with EVR

i read his post (and understood), but I can't see any out of sync on my system... don't know how it is when watching 2 hours LiveHD, but all stuff I played had no problems with sync