resize filter

[timtas]

Hi all
I have built 2.6.20 from source and wanted to try the resize filter. I indeed get a filter called:

vdpau: resize

and this also works fine. I just wondered if there is another, non-vdpau resize filter, in case vdpau is not available?

I maybe have to add that I only build against qt5 and not qt4.

[mean]

swresize is the one

[timtas]

Thanks for the info. Does anybody by chance know what swresize needs in order to be built? I don't seem to get it in my build.

[eumagga0x2a]

I'd rather ask what are you doing not to get it (libADM_vf_swscaleResizeQT5.so) built? Please provide some details regarding your build environment and procedure.

qt5 is fine. qt4 is deprecated and doesn't get test coverage anymore, making breakage easily possible.

[timtas]

Basically, I use /bootStrap.bash, with a few modifications due to having X11 stuff not under /usr, but under /opt/X11. Also, I install under /opt/avidemux and not under /usr.
I also added a patch called alsa-nodrain, as I'm using alsa.

I build against qt5 5.8.0 and it runs fine, but I don't seem to get the swresize plugin


sed -i 's,/usr,/opt/avidemux,g' ./bootStrap.bash
sed -i 's,$EXTRA,$EXTRA -DVDPAU_INCLUDE_DIR=/opt/X11/include -DLIBVA_INCLUDE_DIR=/opt/X11/include -DSDL_INCLUDE_DIR=/opt/X11/include -DXVIDEO_INCLUDE_DIR=/opt/X11/include -DXVIDEO_LIBRARY_DIR=/opt/X11/lib/libXv.so,g' ./bootStrap.bash

patch -p1 < /lfs-src/avidemux_2.6.12-alsa-nodrain-1.patch || exit

CXXFLAGS="-g -std=c++11 -Wall -pedantic" export CXXFLAGS
bash ./bootStrap.bash --with-cli

[Jan Gruuthuse]

Code Select Expand

bash bootStrap.bash --deb
and you should install these:
    avidemux3-core-2.#.#--YYMMDD-runtime.deb
    avidemux3-plugins-COMMON-2.#.#-YYMMDD-plugins.deb
    avidemux3-qt5-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-QT5-2.#.#-YYMMDD-plugins.deb
    avidemux3-cli-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-CLI-2.#.#-YYMMDD-plugins.deb
    avidemux3-settings-2.#.#-YYMMDD-settings.deb

If not successful, try: 
Do you have the resize filter when running one of these? http://www.avidemux.org/nightly/appImage_support/

No installation required. More info on Avidemux Universal app

[eumagga0x2a]

Code Select Expand

bash bootStrap.bash --deb
and you should install these:
    avidemux3-core-2.#.#--YYMMDD-runtime.deb
    avidemux3-plugins-COMMON-2.#.#-YYMMDD-plugins.deb
    avidemux3-qt5-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-QT5-2.#.#-YYMMDD-plugins.deb
    avidemux3-cli-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-CLI-2.#.#-YYMMDD-plugins.deb
    avidemux3-settings-2.#.#-YYMMDD-settings.deb

I doubt that Debian packages are useful on a LFS system 

The first patch could be replaced by the --prefix option, I guess. "--with-cli" does nothing, because building CLI is the default.

It would be helpful if you look in /tmp/logbuildPluginsQt5* for anyting resize related after a build as well as preserve the cmake output redirecting stdout and stderr to a file during compilation (trying to build the current trunk instead of release probably wouldn't change things but would reduce testing delta).

[Jan Gruuthuse]

I doubt that Debian packages are useful on a LFS system 

I see.
And (c/sh/w)ould Avidemux Universal app run on Linux From Scratch (LFS)?

[eumagga0x2a]

And (c/sh/w)ould Avidemux Universal app run on Linux From Scratch (LFS)?

Highly likely it would, if the system is really Linux and not some kind of BSD Unix. But who having set up LFS would want to run third-party binaries on it?

[timtas]

And (c/sh/w)ould Avidemux Universal app run on Linux From Scratch (LFS)?

Highly likely it would, if the system is really Linux and not some kind of BSD Unix. But who having set up LFS would want to run third-party binaries on it?

It is really a linux system, but strangely, the Avidemux Universal app does not run:

/tmp/.mount_HrGgJv/AppRun: line 7: 12761 Segmentation fault      ${HERE}/usr/bin/avidemux3_portable $@


The self-compiled version runs fine, I'm only missing the resize plugin (maybe also some others).

[timtas]

Code Select Expand

bash bootStrap.bash --deb
and you should install these:
    avidemux3-core-2.#.#--YYMMDD-runtime.deb
    avidemux3-plugins-COMMON-2.#.#-YYMMDD-plugins.deb
    avidemux3-qt5-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-QT5-2.#.#-YYMMDD-plugins.deb
    avidemux3-cli-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-CLI-2.#.#-YYMMDD-plugins.deb
    avidemux3-settings-2.#.#-YYMMDD-settings.deb

I doubt that Debian packages are useful on a LFS system 

The first patch could be replaced by the --prefix option, I guess. "--with-cli" does nothing, because building CLI is the default.

It would be helpful if you look in /tmp/logbuildPluginsQt5* for anyting resize related after a build as well as preserve the cmake output redirecting stdout and stderr to a file during compilation (trying to build the current trunk instead of release probably wouldn't change things but would reduce testing delta).

Ok, I will try that, then, I guess there is some dependency either missing, or available in the wrong version.


I do install some debian packages, for stuff not available in source, or too big for me to compile (chrome, libreoffice, brother printer drivers), but I generally strive for a self-compiled system.

[timtas]

Code Select Expand

bash bootStrap.bash --deb
and you should install these:
    avidemux3-core-2.#.#--YYMMDD-runtime.deb
    avidemux3-plugins-COMMON-2.#.#-YYMMDD-plugins.deb
    avidemux3-qt5-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-QT5-2.#.#-YYMMDD-plugins.deb
    avidemux3-cli-2.#.#-YYMMDD-runtime.deb
    avidemux3-plugins-CLI-2.#.#-YYMMDD-plugins.deb
    avidemux3-settings-2.#.#-YYMMDD-settings.deb

I doubt that Debian packages are useful on a LFS system 

The first patch could be replaced by the --prefix option, I guess. "--with-cli" does nothing, because building CLI is the default.

It would be helpful if you look in /tmp/logbuildPluginsQt5* for anyting resize related after a build as well as preserve the cmake output redirecting stdout and stderr to a file during compilation (trying to build the current trunk instead of release probably wouldn't change things but would reduce testing delta).

I have tried a new compile, with the same results. What I found out is that it seems that all plugins in avidemux_plugins/ADM_videoFilters6 that have a qt4 directory in the source tree are not built. The qt5 userinterface itself however is built.

What I also did: I copied libADM_vf_swscaleResizeQT5.so from the extracted appimage to my  ADM_plugins6/videoFilters and this worked fine! So I seem not to be missing any dependencies, rather the build system decides not to build those plugins.

I have qt installed in /opt/qt5, maybe that is a problem?

[Jan Gruuthuse]

Perhaps developers will give their comments too. My understanding is avidemux build looks for standard installs like /usr

There could be an issue:

The BLFS editors recommend installing Qt5 in a directory other than /usr, ie /opt/qt5. To do this, set the following environment variable:

....

The BLFS editors do not recommend installing Qt5 into the /usr hierarchy because it becomes difficult to find components and to update to a new version. If you do want to install Qt5 in /usr, the directories need to be specified explicitly. In this case, set QT5PREFIX=/usr and add the following to the configure arguments below:
...

source: linuxfromscratch.org: Installation of Qt5

[eumagga0x2a]

I have qt installed in /opt/qt5, maybe that is a problem?

Inspecting build logs and cmake messages would allow to answer this question. CMakeLists.txt files both in avidemux2/avidemux/qt4 and in avidemux2/avidemux_plugins use the same cmake macros to find qt. It could be an issue though if the fakeroot directory (usually avidemux2/install wasn't deleted between compilation runs. Changes in avidemux2/cmake wouldn't have effect as existing cmake files from the fakeroot folder would be used for building plugins.

[timtas]

I have qt installed in /opt/qt5, maybe that is a problem?

Inspecting build logs and cmake messages would allow to answer this question. CMakeLists.txt files both in avidemux2/avidemux/qt4 and in avidemux2/avidemux_plugins use the same cmake macros to find qt. It could be an issue though if the fakeroot directory (usually avidemux2/install wasn't deleted between compilation runs. Changes in avidemux2/cmake wouldn't have effect as existing cmake files from the fakeroot folder would be used for building plugins.

Ok, I will retry and have a proper look at the install logs. I have looked at the logs and looked out for resize, but not for qt5 in particular.