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

[jaymode]

I believe that I am also suffering from this issue. I am running the latest SVN. This happens on Live TV (MPEG-2 from tuners and H.264 from HD-PVR). Outside of Mediaportal, system playback is fine.

System Specifications:
AMD Phenom II X3 710
nVidia GeForce 8300 (also tried ATI Radeon 4350)
4GB Ram
Windows 7 Home Premium 32-bit
Hauppauge HVR-2250
Hauppauge HVR-1800
Hauppauge HD-PVR

All drivers are up to date. Using Windows 7 built-in decoders.

I tried using the Morpheus_XX dll posted earlier and playback was better, but still not very good. With the patched dll's, video playback would be smooth for 5 seconds, slow down/stutter for a few seconds, be smooth for 5 more seconds, etc.

With the unpatched dll's, video playback was very jerky (almost like CPU @ 100% utilization, but was only at 16%).

 

[OnkelChris]

AW: Problems with dropping frames with EVR

will do some more tests with my living room MP. Seems that my GeForce 8300 is not capable of my HD samples... (but there is a bit of improvement with the dshowhelper from this thread and the new revision also did a bit of improvement)

 

[VASkO]

"keep mediaportal on top" option started to steal focus, so I had to turn it off and the issue is back. stuttering and dropping frames. strange, it didn't steal focus the first time, I turned it on and lasted so for 3 days.
anything new on this issue? is it under inspection? every other media player plays any media type perfectly on this same setup.

 

[Scythe42]

Frame dropping is a symptom not the problem. You can't solve this issue by disabling frame dropping as audio and video will run out of sync. The problem is that frames are coming late from the mixer and/or painting the frame takes too long.

The provided DLL does nothing more than disabling frame dropping. Of course you don't see any dropped frame when frame dropping is disabled and every frame is rendered.

But that's not a solution as audio and video are not in sync anymore. And when running higher Hz than fps you will see accelerated playback for some segments because of a higher number of vsyncs. Both are as bad as dropped frames.

The only reason for dropping frames is to keep audio in video in sync. Late frames must be dropped, there is no way around it. They have a time stamp, they need to be presented at that time for everything being in sync. Once the time is gone it makes no sense to render them as audio and video slowly drift apart for every late frame that is rendered when it shouldn't.

The main cause for MP's bad playback performance has not been identified yet and it's very likely outside the EVR presenter what you can see from logs that show the "frames from the past" message. This means a frame was late from the mixer or painting of the last frame took too long so that the next frame is now late...

 

[OnkelChris]

AW: Problems with dropping frames with EVR

lol guys... these are my results:

Livingroom HTPC with ION 330, 2GB RAM and MP 1.0.2: Everything running smooth and HD playback is no problem.

Testmachine with Athlon X2 4600, GeForce 8300 onboard, 2GB RAM and MP 1.1.0: HD seems to be not playable.

--> unfortunately, my graphicscard (8300) seems not to be capable of playing back my HD samples. Try the following:

1. Run MP in window mode with a 16:9 skin (Autosize window to skin)
2. Play movie
3. exit MP
4. start MP
5. resize MP to a smaller window
6. run movie

--> after step 5, the movie runs smooth and in sync. For those where the video plays fine in step 2, try running MP in Fullscreen. If there is stutter in fullscreen, then it seems that the hardware is not capable.

RESULT OUTSIDE MP:

Whenever I run graphedit with the graph captured from MP, the window starts in a small frame. Resizing the small movie window to fit the screen -> Audio/Video totally out of sync after some seconds.
--> MP has to drop frames, that Audio/Video is in sync.


For all those who followed my steps and have the same result --> Upgrade

I feel like

:sorry: for crying and devs for MP
I will shut down my testmachine and be back at testing, when it is upgraded...

 

[tourettes]

This means a frame was late from the mixer or painting of the last frame took too long so that the next frame is now late...

If painting takes too long then we can see it from the ! -stats (green line?)

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

lol guys... these are my results:

Performance issue indeed is one likely cause for the dropped frames, but I bet it wont explain all the cases. Also you need to remember that MP uses more GPU / CPU as it has GUI that needs to be mixed into the video (or actually the other way around) and MP's skin engine needs to do extra work when comparing to MPC-HC or WMP as the video frame needs to be handled as a texture (involes at least one extra copy step). Main reason to this was to reduce the flickering ATI users are seeing. So at some degree you can blame ATI on the CPU / GPU requirements on MP

 

[Scythe42]

If painting takes too long then we can see it from the ! -stats (green line?)

Yes, should be the green one. On my system painting takes 5-6ms. Now with a 50Hz file each framein is displayed for 20ms. We schedule each frame 1/4 of display time in advance (5ms in the 50Hz case) before presentation time. Close call.

So even though if you don't see very high painting times (sometimes I see 70ms if something blocks MP on my box), it can already be too late. Especially when painting takes longer than the vblank lasts, which means good-bye for the next frame...

Maybe we should go to 1/3 or even 1/2 in advance. But that might hog more CPU power...

Ccorrection to the last post:
When you have too large painting times you only see a "dropping frame" message in the log. A "scheduling sample from the past" should only shown up on start of playback; if the mixer ran out of samples for some time; if the splitter/tsreader delivered single frames too late for processing compared to their time stamp.

BTW: I don't use MP to watch TV. Can someone recommend a DVB-C USB tuner so I can make some test with live TV? Only have cable and it's crypted...

 

[gemx]

But is some more CPU power really a problem for the "machine" used?

I think it's worth a try since i also suffer from dropped frames quite often - could you point me to a section in the sourcecode were i can adjust the prescheduling time (currently 1/4 set it to...)?

 

[gemx]

Is Scheduler.cpp -> SchedulerThread(void* param) the correct place ?