Update ffmpeg to 3.4.2 with vaapi support for intel x64

[hgy59]

Motivation: Support video accelleration API for intel chips
Linked issues: #3207

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

Features

• ffmpeg is built with --enable-vaapi (for x64 archs only)
• libva-utils is included (vainfo and other tools)
• i965 video driver is included
• tested with DS918+ (build for arch-apollolake-6.1 and arch-x64-6.1)

[ymartin59]

OK interesting. But why not implement my proposal to link against Video Station shared libraries already available ?

[hgy59]

@ymartin59 because the VideoStation uses a different version off ffmpeg.
And synology also has installations of different ffmpeg versions (on my DS918+ there are a default ffmpeg and one for AudioStation, MediaServer and VideoStation)

[ymartin59]

@hgy59 My idea #3207 (comment) was to build ffmpeg thanks to "libva*.so" libraries from VideoStation to avoid to rebuild them including kernel modules.
I would try following sequence:

• download VideoStation package from Synology
• extract it into install so that ffmeg CMake finds libva*.so
• add RPATH to CMake options to get binaries able to load VAAPI libraries from /var/packages/VideoStation/target/lib

Just an idea, it may not be successful... Your trial may face troubles to have libraries matching kernel modules.

[hgy59]

@ymartin59 I presume that linking to *.so will not be possible without *.la file (not sure for linux, but on Windows you need the *.def file to link to *.dll)
any linux c/c++ link/libtool guru here?

[hgy59]

@ymartin59 and how to download spk from synology from the build environment?

[m4tt075]

@hgy59 Just googled, but maybe from here?
https://usdl.synology.com/download/Package/spk/VideoStation/?C=M;O=D

[ymartin59]

@hgy59 About libraries, C compiler only requires .h file and .so to link dynamically: https://stackoverflow.com/questions/12237282/whats-the-difference-between-so-la-and-a-library-files
(.a and .la are for static linking)

[MrSpoocy]

I think (if we can) we are avoid to use any lib from Synology. We can see that they use often old lib (ffmpeg, php 5.6) as core. Its better to create own "same" lib, to get the fresh version and newest bugfix.

[ymartin59]

@MrSpoocy I can only agree with you, but concerning hardware-related libraries like "libva*" and "drm" kernel drivers, it sounds wiser to keep in-line with what Synology provides in DSM.

[m4tt075]

@ymartin59 Have you ever had a chance to look into this PR? I think it could be a stepping stone for further updates. Obvisouly biased, benefitting from vapi integration... ;-)

[m4tt075]

@ymartin59 This PR looks very logical to me, but I'm also aware that you looked into an alternative implemenation method. From what you know now, would you still advocate an alternative approach?

[ymartin59]

I still consider that if version provided in DSM "works", there is no need to rebuild or to update - I faced it recently with fuse for sshfs.
If lacking libva headers and so files to compile ffmpeg, spksrc may build same version from sources but no include them in package - so that binaries runs over libraries provided by DSM.

[ymartin59]

A proposal would be to build against VideoStation libva:

/var/packages/VideoStation/target/lib/libva/libva-drm.so.1.4000.0
/var/packages/VideoStation/target/lib/libva/libva-tpi.so.1
/var/packages/VideoStation/target/lib/libva/libva-drm.so.1
/var/packages/VideoStation/target/lib/libva/libva.so.1.4000.0
/var/packages/VideoStation/target/lib/libva/libva-tpi.so
/var/packages/VideoStation/target/lib/libva/libva.so.1
/var/packages/VideoStation/target/lib/libva/libva.so
/var/packages/VideoStation/target/lib/libva/libva-tpi.so.1.4000.0
/var/packages/VideoStation/target/lib/libva/libva-drm.so

So it means VideoStation becomes a required dependency for ffmpeg package, at least for x64 platforms.

To be honest, probably the only reason why I let that PR alone may be jealousy because @hgy59 succeeded to build just one week after I tried myself and failed against intel driver and made my mind to avoid rebuild libva and intel driver...

Really this is a good job and I find no reason (today) not to merge it. I will squash and rebase @hgy59 commits to keep author into #3575.

[m4tt075]

@ymartin59 It takes character to arrive at conclusions like this, and even more so to state them publically. I enjoy being part of this project!
I fully agree with including this PR in our update.

@hgy59 Many thanks for your contributions and your patience!

[ymartin59]

@hgy59 Thanks for your work. It will be included with FFmpeg 4.1 PR #3575 I will take care to keep your author in commits after merge. So I close this one.