[FernetMenta]

I don't agree to the statement that it's not harmful. You can see clearly it the log that the main thread is blocked:
WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

And this happens together with the NEWADDON messages. So my guess is that whatever uses this python script blocks the render thread.

[fritsch]

@FernetMenta:
This "NEWADDON" thingy was fixed lately. See here: 5c61cc2c3ef7b047060742d736fd2a8cc037ae57

---

But you already have that one in your frodo branch, as it is in there.

[FernetMenta]

@fritsch - this removes the log spam but does not stop an addon from going wild.

[fritsch]

You are right of course. I did not see where this TRACE is coming from. Just hides the symptome, by hiding the print - but the blocking issue is still there.

[-EaS-]

What does "prefer VDPAU video mixer" actually do?

YUV to RGB conversion can be done by vdpau video mixer or OpenGL. The mixer supports advanced de-interlacing methods, OpenGL only BOB. The advantage of NOT using the mixer is that it consumes less resources.

When I select AUTO for deinterlace

When choosing AUTO for deinterlace mode (preferred setting), de-interlacing gets kicked in automatically for interlaced material, provided that the flags of the input stream are correct.
AUTO for method is currently the same as temporal.

Thanks, all clear.
Two more questions:

1 - Is it normal that CPU usage is about 10% (or maybe even 20%) higher (on this build?) when using the more advanced VDPAU settings? I see spikes up to about 35% CPU usage (Ivy Bridge Celeron, FF-H264_VDPAU-VDPAU active, so it isn't the CPU doing all the work)

2 - When I access simple OSD elements (like the simple channel list, programm info or the part where audio/video settings etc. can be accessed) the picture remains very 'fluid', but when I press the back button - where more OSD elements appear on screen together with the channel- the image gets a tiny bit jerky, or maybe blurry. Don't know how to describe it excactly. Is that because picture now has to be rendered at the default OSD framerate? (I'm testing all this on a simple 60Hz CRT monitor, while watching 1080i 25fps (vdpau temporal/spatial -> 50fps) satellite channels)

[FernetMenta]

1)
- In order to get the most out of it de-interlacing is run on a separate thread. This might increase CPU a bit but far away from being critical.
- When GPU load increases you would also see an increase of CPU load. The advanced de-interlaing methods of the old code use the minimum of 2 past and 1 future frame. This build uses 4 past and 2 future frames which increaes quality but also GPU load.

2)
You can set "adust display to match video" to start/stop. This method won't switch back to desktop resolution when leaving full screen video. Or simple set desktop resolution to 50Hz.

[-EaS-]

1 - Thanks. I did a restart of xbmc, and cpu usage is now about 6 to 7% with the heaviest settings. So there was probably someting happening in the background all the time when I checked earlier. Besides that: Even if cpu usage was as "high" as mentioned earlier - nothing critical indeed.

2 - Clear!

[gfisher]

Update - trinity a6 5400k apu on testing build 13 24fps is playing well now w/o freeze with *adjust refresh rate to match video* always. But it still has hdmi audio av sync issues on 24fps but adding a 175ms delay for that framerate fixes it in advancedsettings.XML. xubuntu 12.10 desktop with daily system updates.. Lots of kernel updates too.

[gfisher]

@fernet
I noticed on the nvidea thread that you mentioned av sync 23.97fps only on receivers mentioned. I have it on 2 sets. They are both Sony LCD. Maybe that is the issue. The other has win 7 frodo optical to amp no av sync but also to a panny plasma. 30 and 60 fps on the Sony sets do not drift. 24fps does. One is a trinity apu the other a llano a4 apu. Booth frodo and HDMI using set for audio stereo. I can fix the av sync by deselecting adjust refresh to match. Then it defaults 60fps on codec info and its in sync. If you want me to test anything please let me know. Pq/no drops look very good during playback. Adding 150-200 ms delay in advancedsettings.XML it gets close enough. I am using stock xorg and model lines. Never touched them...

[fritsch]

The Delay Calculation within Audio Engine is currently a mess and not really working out nice. If you ask the queue waterlevel while adding packets at the same moment, it cannot work exactly.

That is one point. Second point is, that TVs do something special when running at 24 or 23.976hz to match the refresh rate. Therefore we ship the following advancedsetings.xml with OpenELEC and it works quite well:

Code:

<advancedsettings>
<video>
  <latency>
    <delay>0</delay>
    <refresh>
      <min>23</min>
      <max>24</max>
      <delay>175</delay>
     </refresh>
  </latency>
</video>
</advancedsettings>

[gfisher]

Thanks. I use that exact setting. Agreed- it works very well. For new users it might be nice to include it in the OP guide. Since adjust refresh rate is recommended. Which I 100% agree with. PQ is better for most content for me. G

[wsnipex]

Since many users seem to be fine with it and OE also has it by default, I added it to the howto

[fastmodena]

I am going to try and run this xvba build with an Intel HD2000 on linux mint 14 and cinnamon de. The instructions here for Intel GPU's say Intel open source driver / libva. So I need to install both of those? I can see the files here:

https://01.org/linuxgraphics/downloads/2...ck-release

Do I need to install both the Vaapi-driver-intel 1.0.19 (which I assume is the open source driver) and Libva 1.1.0?

It also mentions Kernel 3.6.5, If I update kernel to say 3.8 will these already be included?

Any other help? Thanks!

[gradinaruvasile]

I dont think you need this build for Intel GPUs. But it should work nonetheless.

vaapi is NOT THE driver. THE driver is the one that is started with your graphical interface (x server).

You need libva and the intel-vaapi driver. Vaapi is the framework (provided by the libva library) that allows the access to the video cards hw decode features, the intel-vaapi driver is the glue that plugs the actual intel drivers hw decoding capabilities in the framework that in turn is accessed by xbmc (or other players such as vlc).

Vaapi accepts all backends (nvidia/vdpau, amd/xvba, intel/?), but in the case of nvidia and amd their native decode methods can be used directly for much better result than used through vaapi.

Succesive kernels improve features. Only in isolated cases features are removed (such as when something is really old or broken).
Intel drivers improved much in newer kernels.

[gfisher]

Wsnipex. Thanks for adding that 24fps av sync fix. I am sure it will make this xbmc Linux experience better for all. Keep up the great work. Both of my sets respond well to it. G