Avidemux 2.7.8 package for Ubuntu focal+ @xtradeb

[xtradeb]

Hi!

I have packaged Avidemux 2.7.8 for Ubuntu (focal+) and made it available in the usual place (https://launchpad.net/~xtradeb/+archive/ubuntu/apps).

As requested by eumagga0x2a, I have also included the "nv-codec-headers" to add NVENC video encoder plugins for NVIDIA graphics.

Let me know if you come across anything I might need to adjust.

Cheers!
Jhonny Oliveira @ xtradeb

[eumagga0x2a]

The patches in debian/patches raise some questions. You have disabled the obsolete avidemux-2.7.6-external-libass.patch patch, but how does it happend that 03-ADM_audiofilter-normalize-missing_pow10f_function.patch doesn't cause a build failure (it actually reverts a fix for compilation with glibc >= 2.27)? Why is 04-xvid-detection.diff necessary? It removes a test for the presence of a function Avidemux actually uses in its Xvid encoder plugin.

By the way, the patch 02-alsa_output.diff, which is not very relevant nowadays as Avidemux uses PulseAudio by default, points to a real bug in Avidemux: the name of the preference in DIA_prefs.cpp is wrong (DEVICE_AUDIO_ALSA_DEVICE instead of AUDIO_DEVICE_ALSA_DEVICE).

As requested by eumagga0x2a, I have also included the "nv-codec-headers" to add NVENC video encoder plugins for NVIDIA graphics.

Thank you, please add the upstream patch https://github.com/mean00/avidemux2/commit/d7ecad79c55e6c21d6462bc69d2d0491efe3c184 to fix a bug I accidentally created during code deduplication and didn't notice until after release :-/

I would also recommend inclusion of the patch https://github.com/mean00/avidemux2/commit/991bd96c4b729e62300caf87ff343b046f41616f

Thank you.

[xtradeb]

Hi!

I usually inherit all patches from version to version, except the ones that were already applied or do not apply anymore in a simple way. I'm not sure if I fully understood your comments, nevertheless, I released a new version (~xtradeb3) with the following patches:

Disabled:
- avidemux-2.7.6-external-libass.patch - did not apply anymore
- 03-ADM_audiofilter-normalize-missing_pow10f_function.patch - based on your comments
- 02-alsa_output.diff - based on your comments
- 04-xvid-detection.diff - based on your comments

New enabled:
- ffNvEnc_Resolve_name_clash_between_H264_and_HEVC_encoders.patch
- Qt_Ensure_text_margins_in_current_time_display_are_zero.patch

Let me know if this is inline with your recommendations.

By the way, is there anything we can do to start using distro provided libraries and get rid of these lintian errors?
E: libavidemux6: embedded-library usr/lib/x86_64-linux-gnu/libADM6avutil.so.56: libavutil
E: libavidemux6: embedded-library usr/lib/x86_64-linux-gnu/libADM6postproc.so.55: libpostproc
E: libavidemux6: embedded-library usr/lib/x86_64-linux-gnu/libADM6swscale.so.5: libswscale

Cheers!
Jhonny

[eumagga0x2a]

Thank you, why keeping obsolete patches in the package? All packaging stuff should be kept in a public-readable git (or mercurial, or ...) repository, so that all changes are transparent and can be easily rolled back if necessary.

At least on Fedora, any changes to a package like adding a new upstream patch mandate a version bump. Is it different on Debian and derivatives?

By the way, is there anything we can do to start using distro provided libraries and get rid of these lintian errors?

Avidemux needs to access some internal structures and functions in FFmpeg libs or someone needs to reimplement all the sophisticated logic in Avidemux. Apart from that, this is completely unfeasible to deal with potential issues which may arise from using a FFmpeg version different from one Avidemux was developed for (even simply configured in a different way). Additionally, using external FFmpeg libs brings no advantages on macOS and Windows. That said, using a stock FFmpeg is not feasible in the medium term, IMHO.

Reducing use of deprecated FFmpeg functions is very much a high priority task, however.

[xtradeb]

Hi!

Thank you, why keeping obsolete patches in the package?

As I said, I was not 100% sure I understood what you meant. So, to be safe, I kept them around. I will remove them next iteration.

All packaging stuff should be kept in a public-readable git (or mercurial, or ...) repository,

I plan to do that (and a couple of other things), I just didn't get there yet... :-)

any changes to a package like adding a new upstream patch mandate a version bump. Is it different on Debian and derivatives?

You are totally right, I forgot about that, it should have been "-2~xtradeb2" not "-1~xtradeb3".

Cheers!
Jhonny