Avidemux Forum

Hello,
running a Raspberry Pi 4, I would like to use Avidemux on it.
As I did not find a package for Raspbian Buster on the download page, I downloaded the source files for 2.7.4 and tried to compile it myself.
That failed for building the Qt5 part. Does anybody of you have experience with this combination?
Was anybody successful in compiling Avidemux with Raspbian Buster?

Quote from: Lonerider on August 20, 2019, 10:13:33 PM
I downloaded the source files for 2.7.4 and tried to compile it myself.
That failed for building the Qt5 part.

Would you please post the error / compress and attach the resulting /tmp/logbuildQt5?

Sure. Here they are.

Thank you. It looks like Avidemux uses very old OpenGL functions not supported by OpenGL ES 2.0 in Raspberry Pi.

Thanks for this hint. That seems to be a greater problem of Raspbian Buster, which contains the newest libraries, whereas some applications use older ones.
Do you know a way to get older libraries, especially Open GL, running on Raspbian Buster?

No, unfortunately not. Regarding the Avidemux side, someone should take this problem field, I don't have resources for that. Patches as always welcome.

Hi, if someone is still interested I've compiled avidemux 2.7.4 on my pi 4 for raspbian and ubuntu 19.10 and seems working fine.
Deb files download at:
https://www.dropbox.com/sh/h51e5yo1eoz4wu5/AAA27WopwD932fQQimaVJ5F5a?dl=0

Quote from: ro59 on February 02, 2020, 11:22:10 PM
Hi, if someone is still interested I've compiled avidemux 2.7.4 on my pi 4 for raspbian and ubuntu 19.10 and seems working fine.

Does this apply to the git master without any modifications too?

In raspbian, linux kernel 4.19.93-v7l+ and gcc (Raspbian 8.3.0-6+rpi1) 8.3.0, using the qt4 flag everything is ok.
Using Qt5 errors arise compiling avidemux_2.7.4/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_dummyWidget.cpp from line 12: glMatrixMode(GL_PROJECTION); because the compiler doesn't find definition of this class.
So I added in line 1 of Q_dummyWidget.h
#include "GL/gl.h"
#include "GL/glu.h"
and fixed the problem.

For the ARM64 version many changes in conditional compiling not the code itself.

Quote from: ro59 on February 03, 2020, 10:54:27 AM
In raspbian, linux kernel 4.19.93-v7l+ and gcc (Raspbian 8.3.0-6+rpi1) 8.3.0, using the qt4 flag everything is ok.

Forcing use of deprecated (and effectively unsupported) qt4 for GUI disables OpenGL (apart from missing out on some maybe useful stuff here and there), so this fits into picture.

QuoteUsing Qt5 errors arise compiling avidemux_2.7.4/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_dummyWidget.cpp from line 12: glMatrixMode(GL_PROJECTION); because the compiler doesn't find definition of this class.
So I added in line 1 of Q_dummyWidget.h
#include "GL/gl.h"
#include "GL/glu.h"
and fixed the problem.

Inclusion of the latter is for sure redundant (Avidemux uses only gluErrorString() in avidemux/qt4/ADM_openGL/src/ADM_openGl.cpp:62), the former is included by QOpenGLWidget via QtGui/qopengl.h, but on non-ES2 platforms only, so this change makes sense for Raspberry Pi, which is GLES2. Does OpenGL in Avidemux (video output and video filters based on OpenGL) work on raspbian then?

QuoteFor the ARM64 version many changes in conditional compiling not the code itself.

-v please. Could you eventually submit (or just post here) a patch against the current git (it has been a long time since 2.7.4), please?

activating OpenGl result in a green screen and the message:"Shader was not compiled succesfully" so I think there is something wrong in the library, so I'll try to explore what works and what doesn't in pi's OpenGl.
Xvideo display is the only working and all not OpenGL plugins seems usable.

For the ubuntu version I must reinstall because the sd card broke, then I'll submit the patch

Restored Ubuntu and recompiled avidemux 2.7.4.
OpenGl works.
Attached changes to original files.

Assuming that the check for arm64 used in cmake/admDetermineSystem.cmake:75 works, please try whether the following patch fixes the cmake part (I didn't add GL includes). It would be great if you perform your testing not on 2.7.4 but instead on git master.

The check for amd64 works and the patch fixes too.
Installed git master, now I'm going to check....

Avidemux 2.7.5 compiled and working!  :)
note: adm_cpu_arm64 better all in uppercase ADM_CPU_ARM64

Debs may be downloaded at this link:
https://www.dropbox.com/sh/1eurpo4lrphzzf0/AAAVfjDISjTuRLDX-TVBJbgSa?dl=0

Quote from: ro59 on February 06, 2020, 10:29:48 AM
Avidemux 2.7.5 compiled and working!  :)

Good, do we need the inclusion of GL/gl.h in Q_dummyWidget?

Quotenote: adm_cpu_arm64 better all in uppercase ADM_CPU_ARM64

Sure, it is just an inconsistency in the contribution which added ARM64 support (https://github.com/mean00/avidemux2/commit/ab6d0dcc31642c140ec2dcd0abbc620f8267413e) in the first place (cmake commands are case insensitive, but arguments and variables are not).

Did you try to build and to run the resulting Avidemux from git master on Ubuntu only or on Raspbian Buster as well?

(Not that I want to shred your SD card, all I/O intensive operations should be performed on external storage anyway.)

For the inclusion of GL/gl. h I have to compile the Raspbian Buster...

In order to limit i/o intensive operation moved the system on a iscsi drive on my nas server!

I've pushed the fix (https://github.com/mean00/avidemux2/commit/aac9d5f795ea0af1e8fd54613d7e4c2fdad343bd) including the Q_dummyWidget part, assuming it would be either necessary or at worst harmless.

Thank you very much for your input.

Raspbian Buster compile but OpenGl doesn't work.
In the pushed fix the inclusion of GL/gl.h requires de definition of ADM_CPU_ARMEL instead of ADM_CPU_ARM64

avidemux_plugins/ADM_audioDecoders/ADM_ad_mad/CMakeLists.txt

#include "config.h"
#ifdef USE_OPENGL
#include <QOpenGLWidget>
#ifdef ADM_CPU_ARMEL
  #include "GL/gl.h" // not included via QOpenGLWidget on ES2 platforms
#endif
#include "Q_dummyWidget.h"
#include "ADM_default.h"

Thanks for the support.

This means that Raspbian is not arm64 which is also what https://lb.raspberrypi.org/forums/viewtopic.php?t=243664 (https://lb.raspberrypi.org/forums/viewtopic.php?t=243664) states. I've pushed a build fix (https://github.com/mean00/avidemux2/commit/8cfc82240f8bfcf57f2237e15bfef3ea0105ee78).

It would be interesting to identify the reason why OpenGL doesn't work if this is limited to Avidemux only.

Quote from: eumagga0x2a on February 06, 2020, 09:28:54 PM
It would be interesting to identify the reason why OpenGL doesn't work if this is limited to Avidemux only.

Yes, I'll try to dig inside the code....

Quote from: eumagga0x2a on August 21, 2019, 05:23:53 AM

Quote from: Lonerider on August 20, 2019, 10:13:33 PMI downloaded the source files for 2.7.4 and tried to compile it myself.
That failed for building the Qt5 part.

Would you please post the error / compress and attach the resulting /tmp/logbuildQt5?

I am trying to download 275 for my pi4 and compile it or download a complied version... can you help

Quote from: Deepchaos on November 22, 2020, 08:21:20 PMI am trying to download 275

Only the latest git (and to some extent the last release) is supported. Install git, clone the repository (https://github.com/mean00/avidemux2), then try to setup the build environment by running makeAppImageBusterMinimal.sh with the option --setup-only:

sudo apt-get update
sudo apt-get install git
git clone https://github.com/mean00/avidemux2.git
NB: Please clone to a directory which is located NOT on the SD card to reduce wear.

cd avidemux2
bash makeAppImageBusterMinimal.sh --setup-only
This should install build dependencies. I don't know whether it will work, this script is completely untested on RasPi (trying to install nv-codec-headers is pointless on ARM, you should comment out lines 100 – 104 of the script). If you get any errors, please stop and ask.

Once build dependencies are installed, run

bash bootStrap.bash --with-system-libass --with-system-libmad
to compile Avidemux. If this succeeds, copy run_avidemux_template.sh as "avidemux-qt", edit avidemux-qt to match the location of the build directory, copy the edited file to a directory in your $PATH and make it executable.

If everything goes well, you should be able to run Avidemux by executing

avidemux-qt
in terminal.

I also tried to get avidemux to work on a Raspberry Pi 4 and followed eumagga0x2a's steps.

To get avidemux to work some additional changes were necessary:
git submodule update --init --recursivecmake/admFFmpegBuild_native.cmake - comment out line 8 - 13
However there are many video files that cause avidemux to force close.

Quote from: lab257.4 on November 28, 2020, 08:35:49 AMTo get avidemux to work some additional changes were necessary:

Code Select Expand

cmake/admFFmpegBuild_native.cmake - comment out line 8 - 13

A patch for cmake/admMainChecks.cmake to disable check for NVENC headers would be more straightforward, IMHO:

diff --git a/cmake/admMainChecks.cmake b/cmake/admMainChecks.cmake
index 7acac7365..965d80ab9 100644
--- a/cmake/admMainChecks.cmake
+++ b/cmake/admMainChecks.cmake
@@ -165,10 +165,10 @@ IF(NOT PLUGINS)
 INCLUDE(admCheckMiscLibs)
 INCLUDE(FindThreads)
 
-    if (NOT APPLE)
+if (NOT APPLE AND NOT ADM_CPU_ARMEL)
         INCLUDE(admCheckNvEnc)
         checkNvEnc()
-    endif (NOT APPLE)
+endif (NOT APPLE AND NOT ADM_CPU_ARMEL)
 #INCLUDE(admCheckXvba)
 #checkXvba()
 ENDIF(NOT PLUGINS)

makeAppImageBusterMinimal.sh installs a lot of stuff useless on ARM.

Quote from: lab257.4 on November 28, 2020, 08:35:49 AMHowever there are many video files that cause avidemux to force close.

Do these videos trigger a crash on ARM only or on x86 (on x86_64) as well? If the former, please launch avidemux3_qt5 on Raspberry Pi on command line and provide the console output from the session ending in crash, else please provide a video causing a crash as a sample via WeTransfer, Mega, Dropbox or Google Drive.

Sorry, it took a while to find out what's wrong.

First I enabled the debugger. Changed line 38 in run_avidemux_template.sh:
gdb --args "${HERE}/bin/avidemux3_qt5" --portable "$@"Start the script again:
bash run_avidemux_template_gdb.shType run in gdb:
runAnd got the following error after opening most of my test videos:
Thread 1 "avidemux3_qt5" received signal SIGBUS, Bus error.
0xb4ae668c in ff_yuv420p_to_rgba_neon ()
  from /home/pi/avidemux2/install/usr/lib/libADM6swscale.so.5
As I read "neon" in the function name I thought about cpu instructions and messed with Edit->Preferences->CPU .
Unchecking 'Enable 3DNOWEXT' actually solved the problem.

I've tried only a few videos so far and each of them was loading and saving as mkv container including x264 or 265 also worked.

Thank you very much for your analysis. Indeed, Avidemux probes CPU capabilities only for the x86 architecture (https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_core/src/ADM_cpuCap.cpp) and enables blindly everything known from x86 by default on ARM as no probing is performed. The value of AV_CPU_FLAG_3DNOWEXT is the same as AV_CPU_FLAG_NEON (libavutil/cpu.h), so by accident enabling 3DNOWEXT enables NEON (why the latter doesn't work in libswscale on RP4 is beyond my very limited knowledge). Patch welcome!

Quote from: eumagga0x2a on December 01, 2020, 03:02:57 PMenabling 3DNOWEXT enables NEON (why the latter doesn't work in libswscale on RP4 is beyond my very limited knowledge).

It is probably assembly code for ARMv7 NEON, ie 32-bit.  RPi4 has a 64-bit ARMv8 CPU.  It has both instruction sets, but code can only use one.  If one compiles ADM as 64-bit then you can run not ARMv7 NEON instructions.

I assume a recent ffmpeg would have up-to-date ARMv8 Advanced SIMD asm code for useful functions.

Quote from: eumagga0x2a on December 01, 2020, 03:02:57 PMIndeed, Avidemux probes CPU capabilities only for the x86 architecture [...] and enables blindly everything [...] on ARM

I think I've got it wrong. Avidemux doesn't forcefully enable any CPU-specific assembly in FFmpeg, it rather disables features which are disabled via Preferences.

Quote from: xyzzy on December 03, 2020, 09:16:41 AMIt is probably assembly code for ARMv7 NEON, ie 32-bit.  RPi4 has a 64-bit ARMv8 CPU.

lscpu on my Raspberry Pi 4 (not available for experiments) reports

Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500.0000
CPU min MHz:         600.0000
BogoMIPS:            108.00
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
So probably not the version B (https://www.raspberrypi.org/products/raspberry-pi-4-model-b/specifications/)? Therefore, it looks legitimate that NEON is enabled by FFmpeg. It doesn't help to explain why ff_yuv420p_to_rgba_neon crashes, though.

Any progress on this? I have a Raspberry 4 (rev.B) and saw the compiling instructions on the Avidemux web site, tried following them pretty much from the top and on-forward, but the bash script that is said to create .deb installation packages when being run with '--deb' does not do that. I have searched through the entire folder and no .deb files are to be found. I just want a basic Avidemux installation. Also, some of the libraries (libfaac and libaften, IIRC) is not available in the Raspian repos, but I'm guessing I should be able to pull through without them.

Cheers!

Please post the command line and the output of bootStrap.bash script.

Packaging as deb only helps to remove Avidemux later as the packages are low quality (no dependency tracking). If Avidemux doesn't need to be available for all users of the system, you can run it without installation from the build directory (see the template for the wrapper script run_avidemux_template.sh (https://github.com/mean00/avidemux2/blob/master/run_avidemux_template.sh).

I've been using Avidemux on a Pi400 for some time now without major issues. However, having just upgraded to 2.8.0 - and discovered this thread - I thought I ought to chuck in a few observations!

First of all, my default "go to" system is Slackware64-current (the development branch) on x86_64 machines. There is an unofficial port of this for the Pi (and similar) machines called "slarm64". An official port is on the way, but not ready yet. In the meantime, slarm64 fills the gap and is indistinguishable for all practical purposes.

Slackware's package manager is a bit different from .deb or .rpm in that it does no dependency tracking. The upside of this is that you rarely get into "dependency hell"! The downside is that it is up to you to ensure you have all required dependencies installed!

For ease of building, I wrote a slackbuild script - modifying an existing script - to build avidemux. Building avidemux into a slackware .tgz install-able file is easy this way. Avidemux is built *without* any packaging being selected into a "dummy" install from whence a slackpkg can be created using existing tools. This could easily be modified to create a .deb or .rpm by using checkinstall (for instance) instead of slackware's makepkg.

Here is the slackbuild script:

#!/bin/sh

# Copyright 2008, 2009, 2010, 2011  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


PKGNAM=avidemux
VERSION=2.8.0
BUILD=${BUILD:-1}

# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
  case "$( uname -m )" in
    i?86) export ARCH=i486 ;;
    arm*) export ARCH=arm ;;
    # Unless $ARCH is already set, use uname -m for all other archs:
      *) export ARCH=$( uname -m ) ;;
  esac
fi

CWD=$(pwd)
TMP=${TMP:-/tmp}
PKG=$TMP/package-$PKGNAM
rm -rf $PKG
mkdir -p $PKG

# We don't need to do anything about setting CFLAGS or libdirs as the internal
#avidemux build script does this for us.

cd $PKG
tar xvf $CWD/avidemux_$VERSION.tar.gz || exit 1
cd avidemux_$VERSION || exit 1

export CXXFLAGS=-std=c++11

chmod +x bootStrap.bash

./bootStrap.bash ##--debug # We don't need to set any options here.


find $PKG/avidemux_$VERSION/install | xargs file | grep -e "executable" -e "shared object" | grep ELF \
  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

  mkdir -p $PKG/avidemux_$VERSION/install/install
  cat $CWD/slack-desc > $PKG/avidemux_$VERSION/install/install/slack-desc

cd $PKG/avidemux_$VERSION/install
/sbin/makepkg -l y -c n $TMP/avidemux_$VERSION-$ARCH-$BUILD.txz

So far so good!

However, one downside of the Pi is that the processor is a little under-powered for video processing using software encoders / decoders. In theory, the SOC can do hardware encoding / decoding, but at present this appears to be a black art! However, the V4l libraries do offer a sort of hardware encode / decode option which considerably reduces the processor load.

My ffmpeg-4.4.1 install detects these:

ffmpeg -codecs | grep H.26
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 11.2.0 (GCC)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-4.4.1/html --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-gpl --enable-version3 --enable-avresample --arch=aarch64 --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-gnutls --enable-libass --enable-libbluray --enable-libcaca --enable-libcdio --enable-frei0r --enable-openal --enable-libopus --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libmp3lame --enable-opencl --enable-opengl --enable-libopenjpeg --enable-libpulse --enable-libsmbclient --enable-libxml2 --enable-librsvg --enable-libdrm
  libavutil      56. 70.100 / 56. 70.100
  libavcodec    58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter    7.110.100 /  7.110.100
  libavresample  4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample  3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
 DEV.L. flv1                FLV / Sorenson Spark / Sorenson H.263 (Flash Video) (decoders: flv ) (encoders: flv )
 DEV.L. h261                H.261
 DEV.L. h263                H.263 / H.263-1996, H.263+ / H.263-1998 / H.263 version 2 (decoders: h263 h263_v4l2m2m ) (encoders: h263 h263_v4l2m2m )
 D.V.L. h263i                Intel H.263
 DEV.L. h263p                H.263+ / H.263-1998 / H.263 version 2
 DEV.LS h264                H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m ) (encoders: libx264 libx264rgb h264_v4l2m2m h264_vaapi )
 DEV.L. hevc                H.265 / HEVC (High Efficiency Video Coding) (decoders: hevc hevc_v4l2m2m ) (encoders: libx265 hevc_v4l2m2m hevc_vaapi )
 ..V.L. vvc                  H.266 / VVC (Versatile Video Coding)

NOTE: the v4l2m2m options

Unfortunately, avidemux doesn't appear to pick these up by default. Looking at my ffmpeg configuration, I have an option "--enable-libv4l2" set, which is where I assume the m2m encode / decode comes from.

I must admit that I've got so used to building automatically from a script that I've forgotten how to pass this option to avidemux's ffmpeg build! Perhaps someone could jog my memory!  ;)

Oh, and under slarm64, OpenGl is found by Avidemux.

Hope this helps / is of interest!

Quote from: pchristy on January 02, 2022, 12:34:58 PMmust admit that I've got so used to building automatically from a script that I've forgotten how to pass this option to avidemux's ffmpeg build!

FFmpeg hw accel related build options are set in cmake/admFFmpegBuild_native.cmake, but it is not done just by enabling the backend in FFmpeg.

OK, I can see that I probably need to add something like:
if (USE_LIBV4L2)
    xadd(--enable-libv4l2)
    set(FFMPEG_DECODERS ${FFMPEG_DECODERS} h264_v4l2m2m hevc_v4l2m2m)
    set(FFMPEG_ENCODERS ${FFMPEG_ENCODERS} h264_v4l2m2m hevc_v4l2m2m)
endif (USE_LIBV4L2)
(Ignoring for the moment that hevc probably doesn't work - just future proofing! ;) )

but then there must be something (possibly in bootStrap.bash?) to trigger this option. Bearing in mind that the v4l2m2m is an external option, I'm having a little difficulty figuring out how to do this!

In the meantime, I had a look at my x86_64 ffmpeg, and that also has the m2m options built in (Intel graphics - which are actually extremely good for video processing!). My avidemux build does not have it as an option, though it did pick up the Intel hardware options.

Perhaps this is something that avidemux should incorporate by default? It looks as if it is becoming a realistic alternative to vaapi and vdpau, if I'm reading things right...

Cheers,

The CMake variable USE_LIBV4L2 needs to be set and the infrastructure in Avidemux to actually use these FFmpeg features needs to be written.

Quote from: eumagga0x2a on January 04, 2022, 07:58:08 PMThe CMake variable USE_LIBV4L2 needs to be set and the infrastructure in Avidemux to actually use these FFmpeg features needs to be written.

I think you've found your first task for the New Year!

 ;D  ;D  ;D

Is the .deb packages (linked on a Dropbox on page I think 2 in this thread) worth downloading? I mean, will they install without hassle on a Raspberry Pi 4 with a Buster-based Raspian OS, or will I need to do compiling and stuff myself, like you tutor later in this thread? I'm hoping the former will work! ;)