Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Ted Lum]

On 8/15/2017 9:43 AM, Reindl Harald wrote:



Am 15.08.2017 um 04:00 schrieb Ted Lum:

On 8/14/2017 4:49 AM, Carl Eugen Hoyos wrote:


If you want any of the external dependencies of FFmpeg (like
x264 or in your case libopenjpeg) linked statically, remove the
.so symlink from the x264/libopenjpeg or the /usr/local/lib*
directory.


Carl Eugen


Thanks. The problem really is more with OpenJPEG. They were messing 
with the build flags in response to a users "enhancement request". It 
seems like you can't really disable building and installing the 
shared libraries. So, if you want a static link you just have to 
delete them. Everything is working as expected now.


well, and that's why building packages
go back in the thread where i showed you how to get x264 static linked

the way it's built it never collides with the system packages and the 
way it's linked in the ffmpeg build it's using the correct library


after that setup works you just replace the tarball and change 
versions in the spec files and build the stuff just in the right 
order, reproduceable forever


[root@buildserver:~]$ rpm -q --filesbypkg 
x264-latest-0.152.2851-1.fc25.20170703.rh.x86_64

x264-latest   /usr/local/x264/libx264.a
x264-latest   /usr/local/x264/x264.h
x264-latest   /usr/local/x264/x264_config.h
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Dude, I don't have a problem with libx264, and I never did. Always 
worked perfectly. I have no idea what you're talking about.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 15.08.2017 um 04:00 schrieb Ted Lum:

On 8/14/2017 4:49 AM, Carl Eugen Hoyos wrote:


If you want any of the external dependencies of FFmpeg (like
x264 or in your case libopenjpeg) linked statically, remove the
.so symlink from the x264/libopenjpeg or the /usr/local/lib*
directory.


Carl Eugen


Thanks. The problem really is more with OpenJPEG. They were messing with 
the build flags in response to a users "enhancement request". It seems 
like you can't really disable building and installing the shared 
libraries. So, if you want a static link you just have to delete them. 
Everything is working as expected now.


well, and that's why building packages
go back in the thread where i showed you how to get x264 static linked

the way it's built it never collides with the system packages and the 
way it's linked in the ffmpeg build it's using the correct library


after that setup works you just replace the tarball and change versions 
in the spec files and build the stuff just in the right order, 
reproduceable forever


[root@buildserver:~]$ rpm -q --filesbypkg 
x264-latest-0.152.2851-1.fc25.20170703.rh.x86_64

x264-latest   /usr/local/x264/libx264.a
x264-latest   /usr/local/x264/x264.h
x264-latest   /usr/local/x264/x264_config.h
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Ted Lum]

On 8/14/2017 4:49 AM, Carl Eugen Hoyos wrote:


If you want any of the external dependencies of FFmpeg (like
x264 or in your case libopenjpeg) linked statically, remove the
.so symlink from the x264/libopenjpeg or the /usr/local/lib*
directory.


Carl Eugen


Thanks. The problem really is more with OpenJPEG. They were messing with 
the build flags in response to a users "enhancement request". It seems 
like you can't really disable building and installing the shared 
libraries. So, if you want a static link you just have to delete them. 
Everything is working as expected now.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 14.08.2017 um 16:56 schrieb Carl Eugen Hoyos:

2017-08-14 16:49 GMT+02:00 Reindl Harald :



Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:


2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos :


2017-08-14 11:04 GMT+02:00 Reindl Harald :


frankly without -ffat-lto-objects libx264 and/or the comibnation of
static
libx264 and static ffmpeg just don't build


The option should not be needed if your toolchain correctly supports
lto (and it is not needed here). Is it possible that you have to add it
because your build is not really an lto build (since something in your
toolchain - like ar - destroys the lto information but thanks to this
option,
compilation succeeds)?


I can confirm that the reason you "need" -ffat-lto-objects is that you
are not actually building with lto.

The sad thing is that the optimized h264 cabac reader cannot be
compiled with (static) lto. I don't remember the details atm but I
suspect you have to disable this optimization in the source code to
use lto, it may be better performance-wise to not use lto at all
(depending on your exact needs).

This bug cannot be worked around with -ffat-lto-objects (you would
see the same issue I do if you would actually compile with lto)


well, then i still guess other parts off mpeg can be still lto-optimized
and only x264 isn't


Nothing above was related to x264 but to the hevc and the h264 decoder.

The work-around for the cabac issue is using --enable-pic, I am not
sure if this has negative effects (speed-wise), a performance test
would be necessary


as you can see in the rpm spec (relevant part quoted again below) this 
is alreayd enabled and that's in fact part of the hardening stuff


%build 



mkdir generic 



pushd generic 



../configure \ 



 --prefix=%{_prefix}/local \ 



 --bindir=%{_prefix}/local/bin \ 



 --mandir=%{_prefix}/local/man \ 



 --extra-cflags="-I%{_prefix}/local/x264 %{optflags} -Ofast -ffast-math 
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops 
-fno-strict-aliasing -flto -fno-fat-lto-objects -fuse-ld=gold 
-fuse-linker-plugin -Wa,--noexecstack" \ 



 --extra-ldflags="-I%{_prefix}/local/x264 -L%{_prefix}/local/x264 -ldl 
-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack %{optflags} 
-Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign 
-minline-all-stringops -fno-strict-aliasing -flto -fno-fat-lto-objects 
-pie -fPIE -fuse-ld=gold -fuse-linker-plugin -Wa,--noexecstack" \

 --enable-lto \
 --ar=gcc-ar \
 --ranlib=true \
 --enable-nonfree \
 --enable-gpl \
 --enable-pic \
 --enable-version3 \
 --enable-libmp3lame \
 --enable-libtheora \
 --enable-libx264 \
 --enable-libx265 \
 --enable-libvpx \
 --enable-openssl \
 --enable-static \
 --enable-runtime-cpudetect \
 --disable-amd3dnow \
 --disable-amd3dnowext \
 --disable-avdevice \
 --disable-debug \
 --disable-devices \
 --disable-ffplay \
 --disable-ffprobe \
 --disable-ffserver \
 --disable-htmlpages \
 --disable-hwaccels \
 --disable-iconv \
 --disable-libdc1394 \
 --disable-libfreetype \
 --disable-libgsm \
 --disable-libopencore-amrnb \
 --disable-libopencore-amrwb \
 --disable-libopencv \
 --disable-libopenjpeg \
 --disable-libopus \
 --disable-librtmp \
 --disable-libschroedinger \
 --disable-libspeex \
 --disable-libvorbis \
 --disable-libxvid \
 --disable-podpages \
 --disable-postproc \
 --disable-protocol=gopher \
 --disable-shared \
 --disable-txtpages

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Carl Eugen Hoyos]

2017-08-14 16:49 GMT+02:00 Reindl Harald :
>
>
> Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:
>>
>> 2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos :
>>>
>>> 2017-08-14 11:04 GMT+02:00 Reindl Harald :

 frankly without -ffat-lto-objects libx264 and/or the comibnation of
 static
 libx264 and static ffmpeg just don't build
>>>
>>> The option should not be needed if your toolchain correctly supports
>>> lto (and it is not needed here). Is it possible that you have to add it
>>> because your build is not really an lto build (since something in your
>>> toolchain - like ar - destroys the lto information but thanks to this
>>> option,
>>> compilation succeeds)?
>>
>> I can confirm that the reason you "need" -ffat-lto-objects is that you
>> are not actually building with lto.
>>
>> The sad thing is that the optimized h264 cabac reader cannot be
>> compiled with (static) lto. I don't remember the details atm but I
>> suspect you have to disable this optimization in the source code to
>> use lto, it may be better performance-wise to not use lto at all
>> (depending on your exact needs).
>>
>> This bug cannot be worked around with -ffat-lto-objects (you would
>> see the same issue I do if you would actually compile with lto)
>
> well, then i still guess other parts off mpeg can be still lto-optimized
> and only x264 isn't

Nothing above was related to x264 but to the hevc and the h264 decoder.

The work-around for the cabac issue is using --enable-pic, I am not
sure if this has negative effects (speed-wise), a performance test
would be necessary.

In any case, -ffat-lto-objects is never necessary, it only hides the
fact that you are not using lto although using -flto (and friends)
while you would get a compilation error otherwise.

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 14.08.2017 um 16:41 schrieb Carl Eugen Hoyos:

2017-08-14 13:51 GMT+02:00 Carl Eugen Hoyos :

2017-08-14 11:04 GMT+02:00 Reindl Harald :

frankly without -ffat-lto-objects libx264 and/or the comibnation of static
libx264 and static ffmpeg just don't build


The option should not be needed if your toolchain correctly supports
lto (and it is not needed here). Is it possible that you have to add it
because your build is not really an lto build (since something in your
toolchain - like ar - destroys the lto information but thanks to this option,
compilation succeeds)?


I can confirm that the reason you "need" -ffat-lto-objects is that you
are not actually building with lto.

The sad thing is that the optimized h264 cabac reader cannot be
compiled with (static) lto. I don't remember the details atm but I
suspect you have to disable this optimization in the source code to
use lto, it may be better performance-wise to not use lto at all
(depending on your exact needs).

This bug cannot be worked around with -ffat-lto-objects (you would
see the same issue I do if you would actually compile with lto)


well, then i still guess other parts off mpeg can be still lto-optimized 
and only x264 isn't

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 14.08.2017 um 13:51 schrieb Carl Eugen Hoyos:

2017-08-14 11:04 GMT+02:00 Reindl Harald :

frankly without -ffat-lto-objects libx264 and/or the comibnation of static
libx264 and static ffmpeg just don't build


The option should not be needed if your toolchain correctly supports
lto (and it is not needed here). Is it possible that you have to add it
because your build is not really an lto build (since something in your
toolchain - like ar - destroys the lto information but thanks to this option,
compilation succeeds)?

In any case: How exactly (without a script) can I reproduce?


the mail you responded to contains the whole rpm-spec you quoted from 
and frankly i have no intention to even consider runnign any 
confgure/make call outside a buildroot



- it took my a lot of time to
figure out how to get all this crap built

a) static at all


Your binaries are not static.
(ldd would show no useful output for a static binary, see below)


what the hell - read the whole thread

they *are* static in context libx264 is static linked and there are not 
ffmpeg libraries - and that's what i explained the OP - for a *complete 
static* build you need to handle every library as i did with libx264


the whole intention of the way i build is having the latest ffmpeg with 
the latest x264 in a single binary and don't clash with distribution 
x264/ffmpeg packages - there was never and is no intention to build 
every depending library at my own from source



b) lto enabled


--enable-lto


c) hardened


--toolchain=hardened
fine that every second project invents his own configure flags which 
mangle around with LDFLAGS/CFLAGS, i recently had to puke about MariaDB 
in that context adding unwanted other flags like -g1 overriding a 
explicit -g0 and so on

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Carl Eugen Hoyos]

2017-08-14 11:04 GMT+02:00 Reindl Harald :
> frankly without -ffat-lto-objects libx264 and/or the comibnation of static
> libx264 and static ffmpeg just don't build

The option should not be needed if your toolchain correctly supports
lto (and it is not needed here). Is it possible that you have to add it
because your build is not really an lto build (since something in your
toolchain - like ar - destroys the lto information but thanks to this option,
compilation succeeds)?

In any case: How exactly (without a script) can I reproduce?

> - it took my a lot of time to
> figure out how to get all this crap built
>
> a) static at all

Your binaries are not static.
(ldd would show no useful output for a static binary, see below)

> b) lto enabled

--enable-lto

> c) hardened

--toolchain=hardened

Carl Eugen

$ file ffmpeg
ffmpeg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, stripped
$ ldd ffmpeg
not a dynamic executable
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 14.08.2017 um 10:53 schrieb Carl Eugen Hoyos:

2017-08-13 15:29 GMT+02:00 Reindl Harald :


  --extra-cflags="%{optflags} -Ofast -ffast-math -funsafe-math-optimizations
-Wno-pointer-sign -minline-all-stringops -fno-strict-aliasing -flto
-ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin" \
  --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
%{optflags} -Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
-minline-all-stringops -fno-strict-aliasing -flto -ffat-lto-objects
-fuse-ld=gold -fuse-linker-plugin" \


Just to make sure: Binaries with such excessive extra-flags
cannot be used for bug reports, a default build will be requested.

(configure options both for lto builds and more "secure" binaries
exist, if -Ofast has any testable advantage with FFmpeg, *please*
report this, same for fat-lto.)


frankly without -ffat-lto-objects libx264 and/or the comibnation of 
static libx264 and static ffmpeg just don't build - it took my a lot of 
time to figure out how to get all this crap built


a) static at all
b) lto enabled
c) hardened

[root@rh:~]$ /usr/bin/hardening-check /usr/local/bin/ffmpeg
/usr/local/bin/ffmpeg:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Carl Eugen Hoyos]

2017-08-13 15:29 GMT+02:00 Reindl Harald :

>  --extra-cflags="%{optflags} -Ofast -ffast-math -funsafe-math-optimizations
> -Wno-pointer-sign -minline-all-stringops -fno-strict-aliasing -flto
> -ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin" \
>  --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
> %{optflags} -Ofast -ffast-math -funsafe-math-optimizations -Wno-pointer-sign
> -minline-all-stringops -fno-strict-aliasing -flto -ffat-lto-objects
> -fuse-ld=gold -fuse-linker-plugin" \

Just to make sure: Binaries with such excessive extra-flags
cannot be used for bug reports, a default build will be requested.

(configure options both for lto builds and more "secure" binaries
exist, if -Ofast has any testable advantage with FFmpeg, *please*
report this, same for fat-lto.)

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Carl Eugen Hoyos]

2017-08-12 22:27 GMT+02:00 Moritz Barsnick :
> On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

>> staticyes
>> sharedno
>
> Well, either something is going wrong during the configure or linking
> process, or you are not using that ffmpeg binary.

(Nothing is "wrong" with the linking process: All linkers I know of
prefer dynamic libraries they find over static libraries in the same
directory - which makes sense.)

FFmpeg - as probably any other open source project - can be built
as a completely static binary but this is not related to above output
of configure nor to any configure option, it is a function of your
toolchain (and/or the toolchain-specific options that you pass to
configure).

The options --enable-shared and --disable-static (--disable-shared
and --enable-static being the default as can be seen above) only
control how the libav libraries that are shipped with FFmpeg are
built: Either only as static libraries (this is the default and it makes
testing easier because you can run the resulting ffmpeg binary
from the built directory without installing it as I alwas do) or only
as shared library or both.

If you want any of the external dependencies of FFmpeg (like
x264 or in your case libopenjpeg) linked statically, remove the
.so symlink from the x264/libopenjpeg or the /usr/local/lib*
directory.

If you want a truly static ffmpeg binary, consider using musl,
note that 32bit musl is NOT supported by FFmpeg and this is
not documented (FFmpeg developers are against documenting
this), and you may not immediately notice, the build process
works fine.

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 13.08.2017 um 15:19 schrieb tlum:

On 8/13/2017 6:58 AM, Reindl Harald [via FFmpeg-users] wrote:
Lets try and keep this topic on the topic of linking the static
libopenjp2.a and away from religious dogma please.


you did not provide any useful informations how you built excatly


Correct me if I'm mistaken, but AFAIK, ffmpeg does not maintain an
srpm?. In any event, that would be tricky to do for static builds, given
the licensing


what the hell has licensing with rpmbuild to do?

don't be silly - there is no legal differnce between let spit "make 
install" directly into the system or in the buildroot - licensing is all 
about distribution and what let you imagine that that case affects 
distribute your own self built package to your own servers - it's all 
about "can i distribute that package for other people"



So that leaves us with guides like this one
https://trac.ffmpeg.org/wiki/CompilationGuide/Centos .


no, that leaves you with "write a spec is not rocket science"


Your constructive feedback is appreciated


just build and link the library proper, see example for x264 and that 
way i can install ffmpeg-libs from fedora-repos for software linked 
agianst it and my /usr/bin/ffmpeg is finally always the latest version 
for CLI



[builduser@testserver:/rpmbuild/SPECS]$ cat x264-latest.spec
%globalsnapshot 20170629

Summary:   H264/AVC video encoder (static build)
Name:  x264-latest
Version:   0.152.2851
Release:   1%{?dist}
License:   GPLv2+
Group: System Environment/Libraries
URL:   https://www.videolan.org/developers/x264.html
Source0:   x264-%{snapshot}.tar.xz
Source1:   x264-snapshot-latest.sh
BuildRequires: yasm

%description
x264 is a free library for encoding H264/AVC video streams, written from 
scratch


%prep
%setup -q -n x264-%{snapshot}

%build
./configure \
 --prefix=%{_prefix}/local \
 --exec-prefix=%{_prefix}/local \
 --bindir=%{_prefix}/local/bin \
 --libdir=%{_prefix}/local/lib64 \
 --includedir=%{_prefix}/local/include \
 --extra-cflags="%{optflags} -Ofast -ffast-math 
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops 
-fno-strict-aliasing -flto -ffat-lto-objects -fuse-ld=gold 
-fuse-linker-plugin" \
 --extra-ldflags="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro 
-Wl,-z,noexecstack %{optflags} -Ofast -ffast-math 
-funsafe-math-optimizations -Wno-pointer-sign -minline-all-stringops 
-fno-strict-aliasing -flto -ffat-lto-objects -fuse-ld=gold 
-fuse-linker-plugin" \

 --enable-lto \
 --enable-static \
 --enable-pic \
 --enable-strip \
 --disable-avs \
 --disable-cli \
 --disable-ffms \ 



 --disable-gpac \ 



 --disable-lavf \ 



 --disable-opencl \ 



 --disable-swscale 



%{__make} %{?_smp_mflags} 






%install 



make install DESTDIR=%{buildroot} 



rm -rf %{buildroot}%{_prefix}/local/bin/ 



rm -rf %{buildroot}%{_prefix}/local/lib64/pkgconfig/x264.pc 



mkdir %{buildroot}%{_prefix}/local/x264/ 



mv %{buildroot}%{_prefix}/local/lib64/libx264.a 
%{buildroot}%{_prefix}/local/x264/
mv %{buildroot}%{_prefix}/local/include/x264.h 
%{buildroot}%{_prefix}/local/x264/
mv %{buildroot}%{_prefix}/local/include/x264_config.h 
%{buildroot}%{_prefix}/local/x264/
strip --strip-unneeded --strip-debug 
%{buildroot}%{_prefix}/local/x264/libx264.a


%files
%{_prefix}/local/x264/libx264.a
%{_prefix}/local/x264/x264.h
%{_prefix}/local/x264/x264_config.h

%changelog
* Thu Jun 29 2017 Reindl Harald 
- update to upstream snapshot 0.152.2851


[builduser@testserver:/rpmbuild/SPECS]$ cat ffmpeg-latest.spec
%globalsnapshot 20170607

Summary:   Audio/Video-Encoder (static build)
Name:  ffmpeg-latest
Version:   3.3.2
Release:   1%{?dist}
License:   GPLv3+
Group: Applications/Multimedia
URL:   http://ffmpeg.org/
Source0:   ffmpeg-%{snapshot}.tar.xz
Source1:   ffmpeg-snapshot-latest.sh
BuildRequires: bzip2-devel
BuildRequires: imlib2-devel
BuildRequires: lame-devel
BuildRequires: libtheora-devel
BuildRequires: x264-latest
BuildRequires: x265-devel
BuildRequires: zlib-devel
BuildRequires: libvpx-devel
BuildRequires: openssl-devel
BuildRequires: yasm
Provides:  ffmpeg
Obsoletes: ffmpeg

%description
FFMpeg is a complete and free Internet live audio and video broadcasting 
solution for Linux


%package   manpages
Group: Manpages
Summary:   Manpages for ffmpeg-latest
BuildArch: noarch
%description   manpages

%prep
%setup -q -n ffmpeg-%{snapshot}

%build
mkdir generic
pushd generic
../configure \
 --prefix=%{_prefix}/local \
 --bindir=%{_prefix}/local/bin \
 --mandir=%{_prefix}/local/man \
 --extra-cflags="-I%{_prefix}/local/x264 %{optflags} -Ofast -ffast-math 
-funsafe-math-optimizations 

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[tlum]

On 8/13/2017 6:58 AM, Reindl Harald [via FFmpeg-users] wrote:
>
>
> Am 13.08.2017 um 02:59 schrieb tlum:
>
> > On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:
> >>
> >> Am 13.08.2017 um 02:23 schrieb Ted Lum:
> >>> I'm sure there is only one copy of all the executables. They are
> >>> actually deployed to /root/bin so they're kept highly isolated 
> from the
> >>> rest of the system.
> >>>
> >>> So, we have:
> >>>
> >>> [root@san1srvp01 ~]# which ffmpeg
> >>> /root/bin/ffmpeg
> >>
> >> jesus christ don't run *especially* codec software as root - that's 
> what
> >> /usr/local is for - let me guess - you fire also "make" as root?
> >>
> >> and since making /root readable for others is also a terrible idea
> >> there's no business for /root/bin at all
> >
> > It's a build VM. I spin them up from and image, do what I've got to do,
> > and then generally destroy them
>
> that don't justify root as nothing justify root for non administrative
> commands, frankly some software out there even refuses ./configure as
> root for that reason
>
> > It's also generally a terrible idea to
> > install compilers and development libraries on production systems, 
> hence
> > the build environment.
>
> yes, hence a proper build system is using something like "rpmbuild"
> which always starts in a clean buildroot adn even don't need root
> permission for "make install"
>
> > Production deployment is a lot more controlled and standardized as you
> > might expect
> i strongly doubt that starting with that the environments are completly
> different and the lack of a proper buildsystem is the root cause of the
> thread topic "libopenjp2.so.7: cannot open shared object file"
>
> rpmbuild would have generated proper dependencies to begin with

Lets try and keep this topic on the topic of linking the static 
libopenjp2.a and away from religious dogma please.

Correct me if I'm mistaken, but AFAIK, ffmpeg does not maintain an 
srpm?. In any event, that would be tricky to do for static builds, given 
the licensing. So that leaves us with guides like this one 
https://trac.ffmpeg.org/wiki/CompilationGuide/Centos .

Your constructive feedback is appreciated.
>
> [harry@srv-rhsoft:~]$ rpm -q ffmpeg-latest
> ffmpeg-latest-3.3.3-1.fc25.20170730.rh.x86_64
> ___
> ffmpeg-user mailing list
> [hidden email] 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email]  with 
> subject "unsubscribe".
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680909.html
>  
>
> To unsubscribe from ffmpeg built static, yet "libopenjp2.so.7: cannot 
> open shared object file", click here 
> .
> NAML 
> 
>  
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean. 



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





--
View this message in context: 
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680910.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 13.08.2017 um 02:59 schrieb tlum:

On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:


Am 13.08.2017 um 02:23 schrieb Ted Lum:

I'm sure there is only one copy of all the executables. They are
actually deployed to /root/bin so they're kept highly isolated from the
rest of the system.

So, we have:

[root@san1srvp01 ~]# which ffmpeg
/root/bin/ffmpeg


jesus christ don't run *especially* codec software as root - that's what
/usr/local is for - let me guess - you fire also "make" as root?

and since making /root readable for others is also a terrible idea
there's no business for /root/bin at all


It's a build VM. I spin them up from and image, do what I've got to do,
and then generally destroy them


that don't justify root as nothing justify root for non administrative 
commands, frankly some software out there even refuses ./configure as 
root for that reason



It's also generally a terrible idea to
install compilers and development libraries on production systems, hence
the build environment.


yes, hence a proper build system is using something like "rpmbuild" 
which always starts in a clean buildroot adn even don't need root 
permission for "make install"



Production deployment is a lot more controlled and standardized as you
might expect
i strongly doubt that starting with that the environments are completly 
different and the lack of a proper buildsystem is the root cause of the 
thread topic "libopenjp2.so.7: cannot open shared object file"


rpmbuild would have generated proper dependencies to begin with

[harry@srv-rhsoft:~]$ rpm -q ffmpeg-latest
ffmpeg-latest-3.3.3-1.fc25.20170730.rh.x86_64
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[tlum]

On 8/12/2017 8:28 PM, Reindl Harald [via FFmpeg-users] wrote:
>
> Am 13.08.2017 um 02:23 schrieb Ted Lum:
> > I'm sure there is only one copy of all the executables. They are
> > actually deployed to /root/bin so they're kept highly isolated from the
> > rest of the system.
> >
> > So, we have:
> >
> > [root@san1srvp01 ~]# which ffmpeg
> > /root/bin/ffmpeg
>
> jesus christ don't run *especially* codec software as root - that's what
> /usr/local is for - let me guess - you fire also "make" as root?
>
> and since making /root readable for others is also a terrible idea
> there's no business for /root/bin at all

It's a build VM. I spin them up from and image, do what I've got to do, 
and then generally destroy them. It's also generally a terrible idea to 
install compilers and development libraries on production systems, hence 
the build environment.

Production deployment is a lot more controlled and standardized as you 
might expect.
> ___
> ffmpeg-user mailing list
> [hidden email] 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email]  with 
> subject "unsubscribe".
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680907.html
>  
>
> To unsubscribe from ffmpeg built static, yet "libopenjp2.so.7: cannot 
> open shared object file", click here 
> .
> NAML 
> 
>  
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





--
View this message in context: 
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895p4680908.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 13.08.2017 um 02:23 schrieb Ted Lum:
I'm sure there is only one copy of all the executables. They are 
actually deployed to /root/bin so they're kept highly isolated from the 
rest of the system. 


So, we have:

[root@san1srvp01 ~]# which ffmpeg
/root/bin/ffmpeg


jesus christ don't run *especially* codec software as root - that's what 
/usr/local is for - let me guess - you fire also "make" as root?


and since making /root readable for others is also a terrible idea 
there's no business for /root/bin at all

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Ted Lum]

On 8/12/2017 4:27 PM, Moritz Barsnick wrote:

On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

Wow, how did you manage to compose this email? See here, this is what
the users get:
http://ffmpeg.org/pipermail/ffmpeg-user/2017-August/036951.html

I can see it here though:
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-quot-libopenjp2-so-7-cannot-open-shared-object-file-quot-td4680895.html
Yea... terribly sorry about that. First time using that gateway... I had 
no I idea it was going to munge it like that. Promise I won't do that again.



I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
build, still I'm getting:

ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open 
shared object file: No such file or directory

So apparently, ffmpeg isn't static after all.
Well, in one sense it is, because most of the other libraries don't even 
build shared versions, so I know it does link and work with the static 
libraries. In another sense it's not, because C and C++ programs with 
dependencies on glibc aren't really static. My limited understanding is 
that it's kind of a hybrid.



ffmpeg is being configured like so:

PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure 
--prefix="$HOME/ffmpeg_build" \
   --extra-cflags="-I$HOME/ffmpeg_build/include" 
--extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" \
   --bindir="$HOME/bin" --pkg-config-flags="--static" \
   --enable-gpl \
   --enable-libfdk_aac \
   --enable-libfreetype \
   --enable-libmp3lame \
   --enable-libopus \
   --enable-libvorbis \
   --enable-libvpx \
   --enable-libx264 \
   --enable-libx265 \
   --enable-nonfree \
   --enable-libvidstab \
   --enable-libfontconfig \
   --enable-libfribidi \
   --enable-libass \
   --enable-libopenjpeg

[...]

configure confirms:

configure confirms:

staticyes
sharedno

Well, either something is going wrong during the configure or linking
process, or you are not using that ffmpeg binary.

What does
$ which ffmpeg
$ file ffmpeg
$ ldd ffmpeg
and finally
$ ffmpeg
say?
I'm sure there is only one copy of all the executables. They are 
actually deployed to /root/bin so they're kept highly isolated from the 
rest of the system. Since I've had so many problems with duplicate 
dependencies, combing the system for them is one of the first 
troubleshooting steps. I'm not opposed to shared libraries, what I'm 
opposed to is installing a shared library that didn't come from a 
repository in an rpm using yum. Otherwise, I find you tend to end up 
with a lot of stray, unmanaged, dependencies causing conflicts, and it 
makes it difficult to deploy applications when dependencies aren't 
readily available. When I'm forced to, I'll do an rpmbuild and drop them 
on the local repository so they're at least managed, deconflicted, and 
easy to deploy, but I'd rather manage one build than one build + a bunch 
of single use dependent libraries... economies of scale come from 
actually sharing shared objects.


So, we have:

[root@san1srvp01 ~]# which ffmpeg
/root/bin/ffmpeg

[root@san1srvp01 ~]# file /root/bin/ffmpeg
/root/bin/ffmpeg: ELF 64-bit LSB executable, x86-64, version 1 
(GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 
2.6.32, BuildID[sha1]=293e48bcdcde80eed190f5514bde9862cc3a6195, stripped


[root@san1srvp01 ~]# ldd /root/bin/ffmpeg
linux-vdso.so.1 =>  (0x7ffe2937)
libdl.so.2 => /lib64/libdl.so.2 (0x7ff19d75e000)
libass.so.5 => /lib64/libass.so.5 (0x7ff19d534000)
libm.so.6 => /lib64/libm.so.6 (0x7ff19d231000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 
(0x7ff19cff4000)

libfribidi.so.0 => /lib64/libfribidi.so.0 (0x7ff19cddb000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x7ff19cb34000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7ff19c82b000)
librt.so.1 => /lib64/librt.so.1 (0x7ff19c623000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7ff19c406000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x7ff19c1e)
liblzma.so.5 => /lib64/liblzma.so.5 (0x7ff19bfba000)
libz.so.1 => /lib64/libz.so.1 (0x7ff19bda3000)
libc.so.6 => /lib64/libc.so.6 (0x7ff19b9e2000)
/lib64/ld-linux-x86-64.so.2 (0x7ff19d96d000)
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x7ff19b789000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x7ff19b55e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff19b348000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x7ff19b01)
libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x7ff19ade3000)

I am using some shared libraries:

fribidi-0.19.4-6.el7.x86_64 : Library implementing the Unicode 
Bidirectional Algorithm

Repo: @base
Matched from:
Filename: /usr/lib64/libfribidi.so.0
Filename: /usr/lib64/libfribidi.so.0.3.3

fribidi-devel-0.19.4-6.el7.x86_64 : Libraries 

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Reindl Harald]

Am 12.08.2017 um 22:27 schrieb Moritz Barsnick:

On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
build, still I'm getting:

ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open 
shared object file: No such file or directory


So apparently, ffmpeg isn't static after all


it's nearly impossible to get it completly static, most distributions 
just don't ship the needed static bits of libraries


that below is a "static" ffmpeg while x264 is in fact static linked 
because built so at my own but doing that for the rest is more or less 
impossible or not worth the work


people really should stick at distribution packages or when build at 
their own get some basics right


[harry@srv-rhsoft:~]$ ldd /usr/local/bin/ffmpeg
linux-vdso.so.1 (0x7ffc4f3c9000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f599217c000)
libvdpau.so.1 => /lib64/libvdpau.so.1 (0x7f5991f78000)
libva.so.1 => /lib64/libva.so.1 (0x7f5991d58000)
libva-x11.so.1 => /lib64/libva-x11.so.1 (0x7f5991b52000)
libX11.so.6 => /lib64/libX11.so.6 (0x7f5991813000)
libva-drm.so.1 => /lib64/libva-drm.so.1 (0x7f599161)
libssl.so.10 => /lib64/libssl.so.10 (0x7f599139e000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x7f5990f3d000)
libx265.so.79 => /lib64/libx265.so.79 (0x7f59909ea000)
libvpx.so.4 => /lib64/libvpx.so.4 (0x7f59905e1000)
libm.so.6 => /lib64/libm.so.6 (0x7f59902d8000)
libtheoraenc.so.1 => /lib64/libtheoraenc.so.1 (0x7f5990097000)
libtheoradec.so.1 => /lib64/libtheoradec.so.1 (0x7f598fe7c000)
libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x7f5994132000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x7f598fc56000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x7f598fa46000)
libz.so.1 => /lib64/libz.so.1 (0x7f598f83)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f598f619000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f598f3fb000)
libc.so.6 => /lib64/libc.so.6 (0x7f598f035000)
/lib64/ld-linux-x86-64.so.2 (0x7f5993fde000)
libXext.so.6 => /lib64/libXext.so.6 (0x7f598ee23000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x7f598ec1d000)
libdrm.so.2 => /lib64/libdrm.so.2 (0x7f598ea0c000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x7f598e7e4000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 
(0x7f598e597000)

libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7f598e2b1000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7f598e0ad000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7f598de7c000)
librt.so.1 => /lib64/librt.so.1 (0x7f598dc74000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x7f598da69000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f598d6e1000)
libogg.so.0 => /lib64/libogg.so.0 (0x7f598d4da000)
libmvec.so.1 => /lib64/libmvec.so.1 (0x7f598d2b)
libgomp.so.1 => /lib64/libgomp.so.1 (0x7f598d082000)
libXau.so.6 => /lib64/libXau.so.6 (0x7f598ce7e000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 
(0x7f598cc6f000)

libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7f598ca6b000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f598c85)
libselinux.so.1 => /lib64/libselinux.so.1 (0x7f598c629000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x7f598c3b7000)
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[Moritz Barsnick]

On Fri, Aug 11, 2017 at 16:27:16 -0700, tlum wrote:

Wow, how did you manage to compose this email? See here, this is what
the users get:
http://ffmpeg.org/pipermail/ffmpeg-user/2017-August/036951.html

I can see it here though:
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-quot-libopenjp2-so-7-cannot-open-shared-object-file-quot-td4680895.html

> I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
> build, still I'm getting:
>
> ffmpeg: error while loading shared libraries: libopenjp2.so.7: cannot open 
> shared object file: No such file or directory

So apparently, ffmpeg isn't static after all.

> ffmpeg is being configured like so:
>
> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure 
> --prefix="$HOME/ffmpeg_build" \
>   --extra-cflags="-I$HOME/ffmpeg_build/include" 
> --extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" \
>   --bindir="$HOME/bin" --pkg-config-flags="--static" \
>   --enable-gpl \
>   --enable-libfdk_aac \
>   --enable-libfreetype \
>   --enable-libmp3lame \
>   --enable-libopus \
>   --enable-libvorbis \
>   --enable-libvpx \
>   --enable-libx264 \
>   --enable-libx265 \
>   --enable-nonfree \
>   --enable-libvidstab \
>   --enable-libfontconfig \
>   --enable-libfribidi \
>   --enable-libass \
>   --enable-libopenjpeg
[...]
> configure confirms:
> 
> configure confirms:
>
> staticyes
> sharedno

Well, either something is going wrong during the configure or linking
process, or you are not using that ffmpeg binary.

What does
$ which ffmpeg
$ file ffmpeg
$ ldd ffmpeg
and finally
$ ffmpeg
say?

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] ffmpeg built static, yet "libopenjp2.so.7: cannot open shared object file"

[tlum]

I'm having trouble adding OpenJPEG to my ffmpeg build. I'm doing a static
build, still I'm getting:



This is on my build machine which has built a working ffmpeg a few times in
the past. I'm a CentOS shop and try to make it a point not to build/install
shared libraries that are not is the distro's repository, so, I'm always
doing a static build of ffmpeg and the dependencies I'm enabling.

The snapshot I'm using is: N-86964-gf357104
OpenJPEG is: 2.2.0

OpenJPEG is built with:



It seems to build both lib types:



It also appears to install both targets:




...and it has in fact installed both libraries:




ffmpeg is being configured like so:



configure confirms:




But the resulting binaries throw the shared library error. Without
--enable-libopenjpeg it works fine... aside from the fact that #6375 broke
it with just about every file I have.




--
View this message in context: 
http://www.ffmpeg-archive.org/ffmpeg-built-static-yet-libopenjp2-so-7-cannot-open-shared-object-file-tp4680895.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".