Improving EVR renderer playback quality (3 Viewers)

[MPUserFromGER]

AW: Improving EVR renderer playback quality

First of all I would like to thank everybody who is involved in this!
I started the original thread months ago but in the last 2 weeks you guys made really a great progress.

I tested all dlls and they work more or less the same for me.
However dll #1 and 2 do crash MP reproducible after few channel changes!

Please note that I am on WinVista and use Cyberlink 7.3 codecs (my sytem specs differ a little bit because I have 2 installations on this PC).

Also, my audio drps are still there... so maybe they are a different issue...

 

[Chimen]

CPU: AMD 64 3500+
GPU: NVIDIA 8600GT
Driver: 196.21
Windows 7 64bit
Using SVN: 24975
Using Microsoft DTV-DVD Video Decoder with MPC - MPA Decoder Filter.

Here are my results:

For me there is no difference between the 4 dll's. All works great except for 1080i 25 fps.
I have tested with:
SD live-tv
HD live-tv (720p 50 fps)
MKV-HD 720p 23.976 fps
MKV-HD 1080p 23.976 fps
DVD 25 fps
DVD 50 fps

However, there is a differnce compared to the dll in latest svn (24975)
I have a recorded 1080i file that plays @ 25fps that stutters heavily with all 4 dll's from this thread.

Unwatchable.
It don't do that with latest svn.

BUT
The latest svn however drops quite a lot frames with HD live-tv (720p 50fps), but all 4 dll's dropps almost no
frames.

Conclusion: for me the latest svn works better with my 1080i recording.
But worse with hd-live tv 720p 50 fps. (watchable tough, around 20 dropped frames/min)

If only my 1080i recording wouldn't stutter that much with theese dll's it wold be great, because they really
improve other hd-playback!

 

[OnkelChris]

AW: Improving EVR renderer playback quality

MPUserFromGER and all other:
Try to use skin Blue3(Wide) and no plugins (except those, delivered with MP).

 

[tourettes]

0002696: Fine tune EVR renderer scheduling parameters for lower end GPU/CPU - MediaPortal Bugtracker

Based on current testing results the DLL #2 is now in use in SVN. Please still continue the testing and if somehow some other DLL gets a big lead over #2 we can start to use it.

Thanks for all the people who have been testing so far.

 

[grubi]

AW: Improving EVR renderer playback quality

It cannot be stressed enough what tourette already stated multiple times:

Disable all 3rd party plugins

I just made some tests with the latest HTPCinfo plugin and it definitely causes a huge amount of dropped frames even on faster PCs.

grubi.

 

[MLH01]

0002696: Fine tune EVR renderer scheduling parameters for lower end GPU/CPU - MediaPortal Bugtracker

Based on current testing results the DLL #2 is now in use in SVN. Please still continue the testing and if somehow some other DLL gets a big lead over #2 we can start to use it.

Thanks for all the people who have been testing so far.

tourettes and others who have helped with this.

Will there be any information posted about the 4 different versions? I'm interested to find out about the changes

MLH01.

 

[te3hpurp]

0002696: Fine tune EVR renderer scheduling parameters for lower end GPU/CPU - MediaPortal Bugtracker

Based on current testing results the DLL #2 is now in use in SVN. Please still continue the testing and if somehow some other DLL gets a big lead over #2 we can start to use it.

Thanks for all the people who have been testing so far.

tourettes and others who have helped with this.

Will there be any information posted about the 4 different versions? I'm interested to find out about the changes

MLH01.

+1

I'd like also to know what parameters to tweak and short explanation.
I might want to build special version for my HW. And probably some others want that too.

Regards,

 

[grubi]

AW: Improving EVR renderer playback quality

For me things are not that easy as they seemd to be at first.

I thought it would be a good idea to give a try for the most popular dll at first which seems to be version 2.
I also only tested live TV which seems to be the most picky part.

Version 2:
------------
Dropped frames on ARD HD: about 1 frame every 5.000 frames.
Dropped frames on VOX SD: about 1 frame every 5.000 frames.

Version 1:
------------
Dropped frames on ARD HD: about 1 frame every 20.000 frames.
Dropped frames on VOX SD: about 1 frame every 20.000 frames.


So I thought every thing is quite well.
But when I then watched a movie on VOX SD later I noticed some visual oddities which were
not present in the previous version of the dll and which are not reflected by the framedrop ratio statistic.

About 6 times within that movie I got a sequence lasting for 1 to 3 seconds which looks like slow motion.
From the appearance it looks similar to when you switch channels until picture and sound are in snyc.
When verifiying the dropped frame statistic I saw that this was not caused by any dropped frames.

So I will give dll version 1 a try and look how things evolve.

Here are some facts of the testing environment:

CPU: Intel E4400
GPU: Radeon HD2600 XT
RAM: 2 GB
OS: Win7 Enterprise X32
Sound: Realtec HDA
TV-Card: Floppy DVB-C
Provider: Kabel Deutschland
Display: Plasma 50"
Video Mode: 1080p/50

Edit: Seems that the slomo problem is codec related (combining MS video codec with ffdshow audio codec).
Switching everything to MS seems to solve the problem.

 

[Scythe42]

Over 50 downloads but only a few reported their results. So don't complain later...

Will there be any information posted about the 4 different versions? I'm interested to find out about the changes MLH01.

Very simple changes. The idea was to give the CPU/GPU as much time as possible. Therefore we removed the fixed window in GetCurrentStimeStamp(). A sample is now rendered as soon as possible when it is due in a vsync cycle. The other change is just the denominator in the thread scheduler. For a 1:2 fps/Hz ratio the timings where left untouched as is works well for 25fps. Please note that 29,97fps at 59.940Hz (aka NTSC) has some stuttering. But this rate should only show up in some obscure TV rips or with bad de-interlacing.

DLL 1: uses 1/4
DLL 2: uses 1/8
DLL 3: is a build by disaster with a fixed maximum 6ms window (similar to 1/3) and a sleep instead of rescheduling based on older SVN version.
DLL 3: uses 1/3

There isn't much difference between DLL 1 and DLL 2 in regards to ms. The poll proves that giving more rendering time up the maximum before other problem can come up gives slower CPUs more room to breathe.

The EVR code is explained in the other thread in details, so please don't ask questions here. There isn't much room for improvement here a the problem lies in the painting itself and not in EVR presenter (see detailed discussion in other thread).

If you want to build your own feel free to do so. But please DO NOT spam the threads with new dshelpers and different timings. I will deleted them because this causes too much confusion. Better take it private if you want to do your own tests.

If you come up with something that really improves things for all users please submit a patch.

Related thread for discussion: https://forum.team-mediaportal.com/mediaportal-1-1-0-beta-1-454/problems-dropping-frames-evr-74360/

 

[tCC]

Re: AW: Improving EVR renderer playback quality

Edit: Seems that the slomo problem is codec related (combining MS video codec with ffdshow audio codec).
Switching everything to MS seems to solve the problem.

the slomo problem is a lot of out of sync glitches and everything is played back at 33fps (press shift+1 to see both when the slomo is happening), very annoying indeed!