• 1
  • 151
  • 152
  • 153(current)
  • 154
  • 155
  • 342
Intel VAAPI howto with Leia v18 nightly based on Ubuntu 18.04 server
(2015-12-01, 01:09)m_gl Wrote:
(2015-11-28, 17:05)fritsch Wrote: Here we go:

New builds - using ffmpeg 2.8.3 - please check if everything is still in sync - also check if the lag - you might have experienced while watching a video in the menus is now gone, please.

I am a little late...

I´ve got jerky playback with 25fps files. Btw actually i do not use passtrough ;-) and sync to display activated.
Log: http://xbmclogs.com/p2t25ocjn

Build: OpenELEC-Generic.x86_64-6.0-devel-20151127190458 is fine
Build: OpenELEC-Generic.x86_64-6.0-devel-20151128154847 is jerky

Hope that helps.

Thanks for the report - does creating /storage/.config/xorg.conf with the following content restore the 20151127 behaviour?:
Code:
Section "Device"
  Identifier  "Device0"
  Driver      "intel"
  VendorName  "INTEL Corporation"
  Option "TearFree" "false"
EndSection
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2015-12-01, 10:18)fritsch Wrote:
(2015-12-01, 00:38)BigL-New Wrote: UPDATE: Why you say that intel_hdmi->color_range_video is never used? It is used in default case (INTEL_BROADCAST_RGB_VIDEO):

+ case INTEL_BROADCAST_RGB_VIDEO:
+ intel_hdmi->color_range_auto = false;
+ intel_hdmi->limited_color_range = true;
+ intel_hdmi->color_range_video = true;
break;
default:

In all other cases intel_hdmi->color_range_video is set to false.

Yeah - but which part of the driver actually cares? Which part asks: if color_range_video == true -> don't scale?
I don't know exactly. But I've checked (reboot to kernel with my modified patch) an definitely there is big difference between Full Range and Limited Range. With Limited Range colours are much brighter than with Full Range. But it's rather that with Limited Range colours are OK and with Full Range colours are too dark. It can bee seen on calibration patterns:

Full Range - all blacks are 100% black (even these above 16) but whites are 100% white starting from 232
Limited Range - blacks below 16 are 100% black and but whites are 100% white starting from 250

So as you can see your new patch is much better, with Full Range i've perfect colours :-)
Reply
If your TV is dump and Limited Range there won't be a difference between xrandr: Full + kodi limited and xrandr: Video 16:235 and kodi limited.

xrandr: Limited Range 16:235 we have discussed now a lot does scaling by itself. This in combination with kodi's limited will produce gray for black and light gray for white.

Video Limited 16:235 xrandr setting will set Limited Infoframe _but_ won't scale colors and just let them passthrough.

As you see in my patch the (limited && !video_range) -> don't scale
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2015-12-01, 10:19)fritsch Wrote:
(2015-12-01, 01:09)m_gl Wrote:
(2015-11-28, 17:05)fritsch Wrote: Here we go:

New builds - using ffmpeg 2.8.3 - please check if everything is still in sync - also check if the lag - you might have experienced while watching a video in the menus is now gone, please.

I am a little late...

I´ve got jerky playback with 25fps files. Btw actually i do not use passtrough ;-) and sync to display activated.
Log: http://xbmclogs.com/p2t25ocjn

Build: OpenELEC-Generic.x86_64-6.0-devel-20151127190458 is fine
Build: OpenELEC-Generic.x86_64-6.0-devel-20151128154847 is jerky

Hope that helps.

Thanks for the report - does creating /storage/.config/xorg.conf with the following content restore the 20151127 behaviour?:
Code:
Section "Device"
  Identifier  "Device0"
  Driver      "intel"
  VendorName  "INTEL Corporation"
  Option "TearFree" "false"
EndSection

Created the xorg.conf, it is working, playback is fine.
Reply
Nice -> https://github.com/fritsch/OpenELEC.tv/c...3cafa6d1c9

will remove that with next build ... it "fixed" gui limited to 25 fps issue when having a 50i video in the background - though I exactly feared things like that.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
I would rather disable triple buffers than making it worse with tearfree. Throwing away frames at a different stage just to see the silly fps counter lying is no solution at all.

EDIT: also note that the introduced latency of frametime DOES harm. You notice on a/v sync and on GUI responsiveness.
Reply
In my tests:

Code:
Section "Device"
  Identifier  "Device0"
  Driver      "intel"
  VendorName  "INTEL Corporation"
  Option "TripleBuffer" "false"
EndSection

did not make any difference, sadly.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
It cures a/v sync because Kodi assumes double buffers NOT triple. Your work around sacrifices a/v sync for the sake of a more or less unimportant use case. There ore only a few dialogs where fps drops down and only when playing SD on lower end systems. Do you really think this is more important than a/v sync?
btw: I noticed improvement on my 1820T with double buffers. System Info does not drop to 25 fps.
Reply
Intel driver does default TRIPLE buffering NOT Double. You had TripleBuffers on, on your system enabled - until I told you about the defaults two days ago.

And your "Do you really think" - comment is fully out of context. The "Tearfree" was a blind test - as the developer told me: it does not influence full screen swaps at all - the blind test told us now otherwise ... and it will be off again.

Also: Users need solutions for running a browser next to kodi - for watching amazon prime / netflix / whatever ... choose between TearFree and compositing :-).

TripleBuffering is default on windows (Aero) and will be default on everything wayland - we can make a double buffer dance when this happens - but we need to cope with that in the future.

Edit: Yeah, just tested all combinations. If a browser is relevant to you - you won't get the tearing fixed at all, when TearFree is off. TearFree On instead will harm kodi (as seen above). So there is no nice solution available to get both, e.g. perfect kodi playback and DRM content via external providers through browser.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
You words and your actions are two different stories. Nobody needs triple buffering on OpenElec: https://github.com/fritsch/OpenELEC.tv/c...3cafa6d1c9

I am not saying that double buffers is the one and only way. I am just against pretending that an issue is "fixed" that is not the case at all. Much better solution is to detect if a system runs triple or double buffers and adjust to it.
Reply
OpenELEC ships a browser ... chromium ...

Edit: Action: https://github.com/fritsch/OpenELEC.tv/c...283b4004d7 <- revert (done > 60 minutes ago - after getting the test results)
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
THe version of Chromium in the openelec repository is broken.
This one is working
Quote:http://openelec.tv/forum/128-addons/7664...est-stable
Reply
yes, if the chromium is used under openelec "tearfree on" is necessary. sadly i have also to switch to limited colors when browser is started because otherwise the browser is outputting in full range color.

btw: with OE r21585 audio are on many tv channels with dolby 2.0 not synced with picture. also is audio dolby 2.0/5.1 not in sync if there are errors in streams. on satellite this sometimes happend. is that already known or are logs necessary?
Reply
(2015-12-02, 01:12)the-dreamer Wrote: yes, if the chromium is used under openelec "tearfree on" is necessary. sadly i have also to switch to limited colors when browser is started because otherwise the browser is outputting in full range color.

btw: with OE r21585 audio are on many tv channels with dolby 2.0 not synced with picture. also is audio dolby 2.0/5.1 not in sync if there are errors in streams. on satellite this sometimes happend. is that already known or are logs necessary?

For the first part: Does that mean your past 25 fps issues were all caused cause you already had TearFree enabled?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
Currently uploading new builds:
Changelog:
- Disable Tearfree as it failed and was proven to introduce sync errors
- Disable TripleBuffer as kodi uses a double buffer by default

For the future, everyone with sync problems also provide Xorg.0.log please - if TearFree is used - we already know it's the driver that is causing it.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
  • 1
  • 151
  • 152
  • 153(current)
  • 154
  • 155
  • 342

Logout Mark Read Team Forum Stats Members Help
Intel VAAPI howto with Leia v18 nightly based on Ubuntu 18.04 server18