[Announce] VA-API/VPP Support for vdr-plugin-softhddevice

Just a short summary before upgrading:

Currently I am running the whole thing on a pre-sandybridge system with following versions:
xf86-video-intel 2.99.911 (after 912 XBMC keeps crashing on startup)
libva master
libva-intel-driver master
ffmpeg 2.4.3 (I find the version numbers pretty confusing here, since rofa mentions 1.2.6)

Runs pretty good up to 720p, HQ scaling being only available on 576i. The platform only provides Bob deinterlacer, which is a great improvement compared to no deinterlacing but still lots of micro juddering.

EDIT: 1080i is playing back too slow, loses a/v sync after a few seconds

Tomorrow I will replace the old board with an AsRock Q1900-ITX, and report back what's working there and how.

Now I have replaced board and CPU with a Celeron J1900, with the following observations (versions same as above):

- va-api-glx crashes at startup with an Xorg error message suggesting low resources, but was ok with the old board
- 576i and 720p now both run with HQ scaling (no surprise) and MADI/MCDI, but with MCDI I see stripes in N24's newsticker. Field order has to be set to 2/1, otherwise the picture is juddering pretty badly
- 1080i yet untested
- micro juddering is now negligible, though still present, visible only with very slow motion
- now XBMC crashes (reason yet unknown)

Zitat von LordJaxom

- va-api-glx crashes at startup with an Xorg error message suggesting low resources, but was ok with the old board

How much memory did you allow to the GPU in your BIOS setup? I allowed the maximum of 512MB and this seems to be needed from my experiences up to now. Pay attention to your Mesa version, suggestion is 10.2 or higher.

Zitat von LordJaxom

but with MCDI I see stripes in N24's newsticker.

I faced that to, as I wrote I MADI to MCDI is subtle and N24 ticker is really good with MADI.

You shouldn't face micro judder using "va-api-glx" in 576i, 720p, as I don't see it actually in 1080i. I face micro stutter in all formats using "va-api" on J1800 SoC, albeit the GPU pressure is significant lower compared to "va-api-glx".

Regards
fnu

Zitat von fnu

How much memory did you allow to the GPU in your BIOS setup? I allowed the maximum of 512MB and this seems to be needed from my experiences up to now. Pay attention to your Mesa version, suggestion is 10.2 or higher.

First I had set shared memory to Auto but switched to 512 MB since I suspected the same. Still no luck, but I will check the Mesa version next...

Zitat von Space

But it seems that I have problems with it ... I zapped some time and it worked fine but now the system does not respond any more ... need to dig a little bit deeper into this on the weekend. Back to work now

The problem only seems to show up if I run intel_gpu_top ... seems to be a known issue because the access to the performance registers is not synchronized. System is running stable now for several hours without a hang (without starting intel_gpu_top) ... But the big screen in the living room is blocked so I might not be able to test the 50Hz output this weekend ...

Best regards,

Space

Hello,

i have upgraded to libva-intel-driver-9999, removed the old patch from /etc/portage/patches and changed

EGIT_REPO_URI="git://projects.vdr-developer.org/vdr-plugin-softhddevice.git"

to

EGIT_REPO_URI="git://github.com/pesintta/vdr-plugin-softhddevice.git"

in vdr-softhddevice-9999.ebuild and installed the plugin again.
Now I can no longer select the MADI or MCDI deinterlacer, but according to the log they are supported:

vdr: video/vaapi: created image 720x576 with id 0x0a000001 and buffer id 0x08000001
vdr: video/vaapi: VaapiCreateSurfaces: 720x576 * 9
vdr: video: aspect 10144:5715
vdr: video: aspect output 1920x1082+0+59
vdr: video/vaapi: noise reduction supported
vdr: video/vaapi: 0,00 - 1,00 ++ 0,03 = 0,50
vdr: video/vaapi: deinterlacing supported
vdr: video/vaapi: bob deinterlace supported
vdr: video/vaapi: motion adaptive deinterlace supported
vdr: video/vaapi: motion compensated deinterlace supported
vdr: video/vaapi: sharpening supported
vdr: video/vaapi: color balance supported
vdr: video/vaapi: unsupported filter #05

I also noticed the following error messages at startup:

vdr: [3568] ERROR: unknown config parameter: softhddevice.1080i.FirstField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.1080i.SecondField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.1080i_fake.FirstField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.1080i_fake.SecondField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.576i.FirstField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.576i.SecondField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.720p.FirstField = 0
vdr: [3568] ERROR: unknown config parameter: softhddevice.720p.SecondField = 0

Have I done something wrong?

Zitat von rofafor

My guess is that portage is using the master branch by default, so you'll also have to define the correct branch in the ebuild.

That was it, thanks! After adding

EGIT_MASTER="vpp_menu_integration"

to the ebuild MADI and MCDI are back again.

Using va-api-glx and MCDI the ticker on N24 looks very smooth. However, I have yellow bars on the top and at the bottom if the screen is bigger than the picture. If I click with the mouse to change from fullscreen to window mode, the picture goes black and I have to reattach the plugin. Is this a known issue?

The yellow bars are from DEBUG mode ... check this Post ...

Best regards,

Space

Zitat von Space

The yellow bars are from DEBUG mode ... check this Post ...

Thanks for the hint! Disabling the debug USE flag didn't change anything because the debug option is hardcoded in the Makefile. So I added

sed -i -e 's/CONFIG := -DDEBUG/#CONFIG := -DDEBUG/' Makefile || die "Sed failed!"

to the src_prepare() section of the ebuild. The yellow bars are now gone but the problem that the picture disappears after switching from fullscreen to window mode persists.

Zitat von Space

The problem only seems to show up if I run intel_gpu_top ... seems to be a known issue because the access to the performance registers is not synchronized. System is running stable now for several hours without a hang (without starting intel_gpu_top) ... But the big screen in the living room is blocked so I might not be able to test the 50Hz output this weekend ...

Not sure, but i played also with intel_gpu_top, when i saw the hard freeze.

Johns

Zitat von Space

The yellow bars are from DEBUG mode ... check this Post ...

Yes they are DEBUG.

But i see them, when 1080i is displayed on a 1080p display. There should be no border in this case.
My calculations seems to be 1 off, bad rounding.

Johns

Ok now my next review:

I had to re-install my system since I didn't manage to combine yaVDR 0.5 with versions recent enough to use VA-API, so now I am using gen2vdr with the following versions:

xf86-intel-driver 2.9.917
libva 1.5.0
libva-intel-driver git
ffmpeg 1.2.6-r1
Mesa 10.2.8

...and softhddevice from Antti's master branch (no libavfilter support) with va-api-glx

...on ASRock Q1900-ITX (Intel Celeron I1900 BayTrail)

All field orders are set to 2/1. Resolutions 576i and 720p are running pretty perfectly with HQ / Anamorphic (what's the difference?) scaling and MADI. With MCDI I notice interlace bars and juddering with N24 newsticker, MADI looks very, very good here.

I am having problems displaying 1080i smoothly. With every deinterlacer except Weave, I have video running just a tick too slow, which causes A/V sync getting lost and resynchronization accompanied with a glitch every ten or so seconds. Is the I1900 just too slow to handle proper deinterlacing with 1080i or is there anything I can tune / provide as information to debug? I am afraid I can't run intel_gpu_top (see output below), but CPU usage is around 35%.

intel_gpu_top: .../intel-gpu-tools-1.3/lib/instdone.c:329: init_instdone_definitions: Assertion `(devid == 0x3577 || devid == 0x2562 || devid == 0x3582 || devid == 0x2572)' failed.

But even without proper 1080i deinterlacing I now have a really quite cheap and low-power HD-VDR. Thanks for and keep up the good work!

EDIT: Display is running at 1920x1080@50

Zitat von LordJaxom

HQ / Anamorphic (what's the difference?)

HQ does not just pull the picture of the bigger surface, it does recalculate it proper. The little BayTrail should be able to do HQ, but to be honest I don't see a difference between HQ and normal, also not on GPU load. I'm not sure what that means.

Anamorphic is bullshit, pulling any input ratio to the given output ratio, e.g. 4:3 input to 16:9 output.

Are you sure there was Weave or Bob enabled? I cannot do that here, if I switch to Bop or Weave it looks like MADI, what the look to GPU pressure does commit. I see subtle difference between MADI and MCDI, but overall MADI is very nice output with BayTrail. 1080i doesn't run flawless here, micro stutter here and there, but I would say smooth.

One thing I saw on one of the test, vertical scrolling text on 720p in some graphical fade ins e.g. in the closing credits of a movie, the text looks blurry, washed out, it was not readable.

Regards
fnu

Zitat von LordJaxom

I am afraid I can't run intel_gpu_top (see output below), but CPU usage is around 35%.

Code

intel_gpu_top: .../intel-gpu-tools-1.3/lib/instdone.c:329: init_instdone_definitions: Assertion `(devid == 0x3577 || devid == 0x2562 || devid == 0x3582 || devid == 0x2572)' failed.

You have to use a more current Version from git://anongit.freedesktop.org/xorg/app/intel-gpu-tools to use the tools with Baytrail.

I found the following problem with Baytrail and linux kernel 3.17 or higher that the system ist complete freeze

https://bugs.freedesktop.org/show_bug.cgi?id=88012

Is this a reason to currently tend not to put on this platform?

Sorry for my english

dile

Mod.: The code name is Baytrail ...

Hi,

did you also try to set pci=nomsi in the boot options to see if this helps.

CU
9000h

Just go back to 3.16.7 until it's fixed, it's the last Kernel Version without system freeze and is running without problems on my Asrock Q1900DC-ITX.

Hmm, everything is running quite good here with 3.18 and my ASRock D1800M ...

Regards
fnu

is your System using C6/C7 States?