Avidemux Forum

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 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 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 states. I've pushed a build fix.

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, 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? Therefore, it looks legitimate that NEON is enabled by FFmpeg. It doesn't help to explain why ff_yuv420p_to_rgba_neon crashes, though.