ffmpeg: update to 4.3.1

[th0ma7]

Motivation: Migrate package to new major version 4.3.x along with optionnally:

• Intel 20Q2 driver set
• Enable OpenCL video stabilization filter (postponed to a later commit)
• Enable ZeroMQ support

Linked issues: N/A

Checklist

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

Changes

• Update x264 to July 2nd git hash and use github mirror
• Update libva and libva-utils to version 2.8.0
• Update gmmlib to version 12.2.2
• Update intel-media-driver to version 12.2.0
• Update intel-media-sdk to version 12.2.1
• Update libaom to version 2.0.0
• Update SVT-AV1 to version 0.8.4
• Update SVT-HEVC to version 1.5.0
• Update x265 to version 3.4
• Add libzmq version 4.3.2

Fixes merged upstream - Patches removed

• tvheadend-ffmpeg.libx265.patch - Merged upstream with https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3670a10c2d69dfb125ad1fe53fe8eddd9a687166
• Intel Media Driver 20Q1: issue error: deleting ‘void*’ is undefined [-Werror] intel/media-driver#907 fixed with intel/media-driver@88769b2
• Intel Media Driver 20Q1: -DCMAKE_CXX_FLAGS='-std=c++11' not honored anymore intel/media-driver#906 fixed with intel/media-driver@34815b3
• Intel Media SDK 20Q1: build issue using gcc 4.9.3 Intel-Media-SDK/MediaSDK#2100 fixed with gcc 4.93 build fix for issue #2100 Intel-Media-SDK/MediaSDK#2117

Pending upstream patch fix/merge

• tvheadend-ffmpeg.vaapi_encode.patch - Does not apply as-is anymore, seeking for advice for merging upstream through https://trac.ffmpeg.org/ticket/8765

[jeff12302000]

Will the new release support the DS920+ ?

[th0ma7]

Will the new release support the DS920+ ?

From my reading DS920+ is quite similar to 918+ using an intel x64 processor. So yes, it will become available in time once the PR is ready for release (work in progress currently).

[hgy59]

Will the new release support the DS920+ ?

From my reading DS920+ is quite similar to 918+ using an intel x64 processor. So yes, it will become available in time once the PR is ready for release (work in progress currently).

The arch geminilake needs to be included in the generic x64 builds.
Since the merge of #4000 (1st Jun 2020) the build for arch-x64 includes geminilake.
All x64 arch packages in the synocommunity package repo need an update to include the geminilake arch for newer Models (DS720+, DS420+, DS220+ and DS920+ so far).

[hgy59]

@th0ma7 If you want that the github action to detect the changes on your branch only, you have to rebase your branch before pushing your changes.
Otherwise all the changes on the master, since you created your branch, will be detected as changes too. Therefore the github build action for your last commit builds all the python packages.

[th0ma7]

@th0ma7 If you want that the github action to detect the changes on your branch only, you have to rebase your branch before pushing your changes. Otherwise all the changes on the master, since you created your branch, will be detected as changes too. Therefore the github build action for your last commit builds all the python packages.

Thnx for the info, I'll make use of rebasing more often then. I'm also interested in learning a bit more on this PR #4049 which tries to address this.

[hgy59]

Thnx for the info, I'll make use of rebasing more often then. I'm also interested in learning a bit more on this PR #4049 which tries to address this.

@th0ma7 I will merge #4049 shortly and with this, a rebase to master will not be required for PRs anymore (for Pull Requests)

[hgy59]

@th0ma7 just for the case you wondered about cancelled github build actions on this branch. I did this manually as I saw that you added other commits that triggered the build again.

I propose that everybody cancels there triggerd builds as soon as enough information is available.

IMHO it is worth to avoid wasting CPU resources (even these are free for open source projects here).
Another atempt would be to stop the build on the first error, but this would stop at unsupported archs too. So it might be that the effective package is never built due to failures in packages that are not supported or have similar dependencies.

[th0ma7]

@th0ma7 just for the case you wondered about cancelled github build actions on this branch. I did this manually as I saw that you added other commits that triggered the build again.

I propose that everybody cancels there triggerd builds as soon as enough information is available.

IMHO it is worth to avoid wasting CPU resources (even these are free for open source projects here).
Another atempt would be to stop the build on the first error, but this would stop at unsupported archs too. So it might be that the effective package is never built due to failures in packages that are not supported or have similar dependencies.

A manual trigger could be interesting... or a commit based trigger?

[th0ma7]

@hgy59 can we mark a package as broken? Such as chromaprint currently so it doesn't build?

[th0ma7]

@ymartin59 and @hgy59 I would need your advice on this one...

In order to enable OpenCL video stabilization filter I need both the Intel Graphic Compile (igc) and llvm.
Compiling the two represent an astonishing download size & compute time (possibly from native/* path).
Shouldn't I instead add them directly in the docker dependencies as this is solely for Intel cpu?

[hgy59]

@ymartin59 and @hgy59 I would need your advice on this one...

In order to enable OpenCL video stabilization filter I need both the Intel Graphic Compile (igc) and llvm.
Compiling the two represent an astonishing download size & compute time (possibly from native/* path).
Shouldn't I instead add them directly in the docker dependencies as this is solely for Intel cpu?

Just out of my brain:

• create a dedicated repository for all ffmpeg stuff with it's own Dockerfile and move all ffmpeg related packages over there (i.e. synocommunity/spksrc-ffmpeg).
• optionally move only intel related ffmpeg stuff to an extra repo and keep ffmpeg here but without any intel specific optimizations.

[th0ma7]

* create a dedicated repository for all ffmpeg stuff with it's own Dockerfile and move all ffmpeg related packages over there (i.e. synocommunity/spksrc-ffmpeg).
* optionally move only intel related ffmpeg stuff to an extra repo and keep ffmpeg here but without any intel specific optimizations.

I'd rather not pursue the OpenCL option than migrate to a dedicated repository... Perhaps DSM7 will bring LLVM and igc. But why do you not consider adding llvm to the docker image (igc could probably be compiled)?

[th0ma7]

@hgy59 how much storage gets allocated when a build start? And is it for the entire build or per-arch specific?
Currently testing building llvm + igc to get functional OpenCL for Intel platforms and getting an idea of its total size.

[ymartin59]

@th0ma7 May you please include link to FAQ in package description according to #4053 comments

[th0ma7]

@th0ma7 May you please include link to FAQ in package description according to #4053 comments

@ymartin59 done! Let me know if wording needs adjusting.

Also friendly reminder to publish ffmpeg 4.2.3 (#3965) with tvheadend (#4005) which has proven to be quite stable for me. Feel free to bump package revision +1 to superseed experimental packages available in my personnal github.

[th0ma7]

@hgy59 I'm starting to really much enjoy the github-action feature, really nice work!
Would there be a way to mark a package as "broken" so it doesn't build unecesseraely (e.g. chromaprint)?

[th0ma7]

@ymartin59 Thnx for the approval, had to fix conflicts after merging ffmpeg 4.2.4 update while rebasing against master.
I would really much like to see a ffmpeg 4.2.4 released before pushing this one in (along with tvheadend #4062 ).
Any chance to get that moving along?
And if so, should I wait before merging this one?

Lastly, the OpenGL part will need to be postponed to a later time as it requires a lot of efforts and unsure of the end-result.