Excessive framedrops on intel hw
#1
As suggested in the dolby atmos thread I'm starting my own thread about the framedropping issue.

To recap: kodi drops a ton of frames in 24p mode when it shouldn't. The TVs refreshrate matches the source content and the CPU/GPU (core i5-2415M CPU @ 2.30GHz) should be fast enough. Enabling 'sync to display' fixes this, but creates drop in audio for dolby atmos content. The current krypton branch disable audio passthrough in sync-to-display mode to fix this. Though that gives drop-free video and audio, it removes the height channels/objects which are what Dolby Atmos is all about.

The imx6 based cubox kodi install doesn't have this problem with Jarvis 16.rc from openelec, but swapping them isn't an option at this point.

Debug log with framedrops
Debug log with sync-to-display enabled
output of kodi-xrandr during playback

video showing vsync off increasing
Reply
#2
Two things:

a) You seem to have two issues:

Quote:11:35:35 T:140521983453312 INFO: GL: Enabling VSYNC
11:35:35 T:140521983453312 ERROR: GL: Vertical Blank Syncing unsupported

b) You seem to have forced Deinterlacing to "On" especially in the framedrop logfile. Don't do that and keep it on Auto, there is no need to deinterlace progressive content.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#3
Please verify your findings with a Milhouse Build from USB stick to rule out broken userspace (see top of linux thread).
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#4
Going trough the suggestion one at a time.

(2016-04-19, 15:16)fritsch Wrote: [..]

b) You seem to have forced Deinterlacing to "On" especially in the framedrop logfile. Don't do that and keep it on Auto, there is no need to deinterlace progressive content.

Weird, it shows up as 'auto' in Video settings and in the logfile I can only see 'CFFmpegPostproc::Init - skip deinterlacing' when searching for 'interlace'. Anyway, setting it to 'off' seems to have no impact on the framedrops.
Reply
#5
FFmpegPostProc is an indicator when the CPU copy method is used, and ontop would do deinterlacing, which in sum puts additional load on the CPU. Do you have "Prefer VAAPI Render Method" disabled?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#6
(2016-04-19, 15:59)fritsch Wrote: FFmpegPostProc is an indicator when the CPU copy method is used, and ontop would do deinterlacing, which in sum puts additional load on the CPU. Do you have "Prefer VAAPI Render Method" disabled?

Yes, VAAPI Render Method is disabled, it did not work well with full range hdmi output enabled. I'll have to check with krypton, but with Jarvis it didn't seem to have an effect on the framedrop issue.
Reply
#7
For krypton, see: http://forum.kodi.tv/showthread.php?tid=231955 for an explanation why it can be savely enabled.

Edit: Something else that I just realize now. SNB cannot do 23.976 fps ... no matter what the mode tells: http://www.anandtech.com/show/4083/the-s...0-tested/7 ... so something will skip / drop at a point - that in combination with your non working vblank sync also won't make it perfect with PT disabled and ReferenceClock enabled.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#8
After thinking about it - i now understand why your old workaround worked ...

You disabled vsync blank, cause those are totally inaccurate on SNB for 23.976 hz
Then you enabled TearFree in the driver, cause you did not want Tearing.
Additionally you enabled Sync Playback to Display with PT and Audio Drop / Dupe to get a pseudo 23.976 mode done by a host counter which is more exact than your GPU vblank interval :-)

Man - that gets a workaround medal ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#9
(2016-04-19, 15:19)fritsch Wrote: Please verify your findings with a Milhouse Build from USB stick to rule out broken userspace (see top of linux thread).

So running
Code:
LibreELEC (Milhouse) - Version: devel-20160418210418-#0418-gca62a87 [Build #0418]
the problem doesn't seem to be there. So I guess I need to look into the differences between my userspace and the libreelec one. I'm going to start matching the xf86-video-intel revision and settings. I'll post something here if I find the offending difference.
Reply
#10
Another data point: using the same (non-Milhouse) userspace on a bay trail system (minnowboard turbot) doesn't show the problem as severe.
Still tracking down the differences between libreelec and my builds.
Reply

Logout Mark Read Team Forum Stats Members Help
Excessive framedrops on intel hw0