FFMPEG and TVH 2022Q3 update

[th0ma7]

Description

The initial intent was to fix build failure since we updated to newer Debian build image. TVH update to git hash 52c3ed3 from Nov. 10th 2022 and lso includes libhdhomerun update. While at it I faced other build failures due to git package downloads affecting sha1sum of the resulting files. In turn while fixing it I ended-up doing a full upgrade of FFMPEG to 4.4.3 and all its dependencies.

Fixes #5494

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[th0ma7]

@hgy59 I won't update openjpeg to avoid collisions against our PR

[hgy59]

@hgy59 I won't update openjpeg to avoid collisions against our PR

You already updated openjpeg to v2.5,0 with #5323 (didn't you?)
There is no update on cross/openjpeg since then and the fixes (in #5492 and #5496) are already merged.
What am I missing?

[th0ma7]

@hgy59 you are totally right, no further update needed, sorry for the noise.

[hgy59]

@th0ma7 FYI I cancelled two github build action runs of this PR (the queue of build jobs is growning)...

[th0ma7]

@th0ma7 FYI I cancelled two github build action runs of this PR (the queue of build jobs is growning)...

Anyway I intend to rebase against master once #5497 is merged (along with your already merged #5496). Also I just hapen to have received a different fix approach for intel-media-driver intel/media-driver#813 (comment) using this patch intel/media-driver#1545

[iHaveAstream]

Hi,

first of all, many thanks for your continuous efforts in supporting TVH on DS. Really appreciate that.
But due to some changes I had to switch from TVH on DS to another (patched) version that I've compiled and which I'm currently running on a dedicated Debian VM in order to be able to also watch CAID 098D channels thru OSCam.
In REL notes of your recent version you mention that libdvbcsa got patched/updated, but how about TVH itself?
Yesterday I tried to watch a related channel, OSCam shows in its log that everything goes well (TVH also), but the result is "no image" in Kodi or just black image in VLC player.

Did I miss something or is this release not capable handling this?
Ideally I want to move back to TVH on DS, rather than operating it on a dedicated VM.

Thank you!

[th0ma7]

In REL notes of your recent version you mention that libdvbcsa got patched/updated, but how about TVH itself? Yesterday I tried to watch a related channel, OSCam shows in its log that everything goes well (TVH also), but the result is "no image" in Kodi or just black image in VLC player.

@iHaveAstream thnx for reporting your issue. A few things:

1. Can you please open-up an issue in github so I can track down the problem with you? This will allow me to better understand your NAS architecture and al.
2. In the meantime you can always backup your TVH configuration, uninstall and re-install the previous version
3. As for the libdvbcsa I myself haven't had any issue with it. Normally it's api is the same to the other version although it provide x64 and arm7-8 hardware acceleration which should help performance. Again, knowing more about your usecase and NAS arch in a seperate issue will help greatly.

Note that if need be and for the same of debugging I can easily provide you with a rebuild of TVH using prior version of libdvbcsa to confirm if the issue is there or rather with some odd recent change in TVH.

[iHaveAstream]

@th0ma7
thanks for your reply!
Shall I open an issue as type "Bug Report" then?

FYI:
I'm referring to patched libdvbcsa from https://github.com/glenvt18/libdvbcsa/commits/aae3d0c and TVH 4.3 patch from https://github.com/tvheadend/tvheadend/commits/1295dd2

With those two I was able to compile a TVH that can work with OSCam (1.20 build 11714) to watch CAID 098D channels, but this now runs on Debian VM.

The topic in general is discussed in here: https://www.linuxsat-support.com/thread/153679-oscam-icam-tvheadend/?postID=684146#post684146

[th0ma7]

I re-re-read about this. It isn't a bug but rather a missing feature. Let me see what I can do for that. And yes, please open-up an issue related to that so I can make a reference to it later. Cheers!

[th0ma7]

@iHaveAstream and it seems I'm block from downloading no more than 2x files per day. I'm missing libdvbcsa_v2.patch.zip from page 8.

[hgy59]

@th0ma7 is this really required?
IMHO it makes no sense to have two TLS libraries as default in curl (openssl and gnutls).
This blows up the curl package (I already tried to minimize it, by adding the curl libraries by default and make the curl executable optional).

Asking, as I am building an update for git, while it fails now for arch-ppc853x-5.2, since gnutls >= 3.7.4 is in the dependencies.

if tvh really requires to build libcurl with gnutls, libssh2 zstd and libwebsockets and curl build does not autodetect such dependencies, we need to enhance cross/curl for advances configuration (as we do for cross/busibox, cross/pcre2, et al.)

What's your opinion?

[th0ma7]

we could probably play with the build order to ensure gnutls gets built before curl and therefore allowing it to autodetecting it and link to it without having to specifying it. As such a normal curl build would not make use of it. Would that make sense?