ffmpeg plugin not loading with 8.6b

[redtux]

When I try to play any files depending on ffmpeg module the module fails to load with an undefined reference error to avcodec.

This means that mp2 audio, FMP4 (avi) fails to play.

This is with both rpms and a compiled version of 8.6b

this is outputof ffmpeg -i

FFmpeg version SVN-r9165, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --prefix=/usr --libdir=/usr/lib --mandir=/usr/share/man --incdir=/usr/include/ffmpeg --enable-libmp3lame --enable-libogg --enable-libvorbis --enable-libfaad --enable-libfaadbin --enable-libfaac --enable-xvid --enable-x264 --enable-liba52 --enable-liba52bin --enable-pp --enable-shared --enable-swscaler --enable-x11grab --enable-pthreads --enable-encoder=theora --enable-gpl --disable-debug
libavutil version: 49.4.0
libavcodec version: 51.40.4
libavformat version: 51.12.1
built on Jun 4 2007 22:25:27, gcc: 4.1.2 20070502 (Red Hat 4.1.2-12)


any ideas

[Jean-Baptiste Kempf]

Yes, for 0.8.6b you need an older ffmpeg.
FOr trunk, ffmpeg-trunk is fine.

[redtux]

Any idea how much older?

[kmf31]

Any idea how much older?

Maybe 6 months ? According to my experience with a self compiled ffmpeg version from svn.

However, if you compile ffmpeg yourself it will also work with the latest version, if you disable the "swscale" feature (not using "--enable-swscaler" when doing ./configure for ffmpeg).

If your version of vlc is using a shared version of ffmpeg (of libavcodec etc.) and not a static version then it will be enough to recompile (with "--enable-shared" !!) and reinstall ffmpeg and carefully erase all old versions in case you install in a different tree (for exemple if you install ffmpeg in /usr/local/lib/ be careful to erase its previous installation in /usr/lib/...).

If your version of vlc uses a static version of ffmpeg you also need to recompile vlc after installation of ffmpeg but since in your previous ffmpeg version there is "--enable-shared" I believe this is not the case. vlc seems to use a dynamic (shared) version of ffmpeg.

In case if you want to compile the latest vlc-0.9.0-svn version yourself than you have also to erase or rename the header file for swscale (after installation of ffmpeg) and which is:
/usr/local/include/ffmpeg/swscale.h
or:
/usr/include/ffmpeg/swscale.h
(depending on the installation tree). This file, if it exists, make the ./configure script of vlc-0.9.0-svn wrongly believe that you have swscale in ffmpeg which will give a problem even if ffmpeg is compiled withouth swscale support.
For compiling vlc-0.8.6b this is not necessary but it is still a good idea to remove this header file.


In short: remove, disable, deactivate, destroy, annihilate, exterminate in ffmpeg erverything which has the name "swscale" in it

and then it should be okay with vlc. In my case the swcale broke the use of h264 and wmv3 codec in vlc, however mpeg2 still worked correctly.

[Jean-Baptiste Kempf]

Good answer.
I built Win32 0.8.6b with r8407, FYI.

@kmf31: VLC does NOT use ffmpeg for MPEG-2 decoding.

[redtux]

Should have been clearer I meant mpeg layer 2 (ie: mp2 audio)

[redtux]

Maybe 6 months ? According to my experience with a self compiled ffmpeg version from svn.

However, if you compile ffmpeg yourself it will also work with the latest version, if you disable the "swscale" feature (not using "--enable-swscaler" when doing ./configure for ffmpeg).

If your version of vlc is using a shared version of ffmpeg (of libavcodec etc.) and not a static version then it will be enough to recompile (with "--enable-shared" !!) and reinstall ffmpeg and carefully erase all old versions in case you install in a different tree (for exemple if you install ffmpeg in /usr/local/lib/ be careful to erase its previous installation in /usr/lib/...).

If your version of vlc uses a static version of ffmpeg you also need to recompile vlc after installation of ffmpeg but since in your previous ffmpeg version there is "--enable-shared" I believe this is not the case. vlc seems to use a dynamic (shared) version of ffmpeg.

In case if you want to compile the latest vlc-0.9.0-svn version yourself than you have also to erase or rename the header file for swscale (after installation of ffmpeg) and which is:
/usr/local/include/ffmpeg/swscale.h
or:
/usr/include/ffmpeg/swscale.h
(depending on the installation tree). This file, if it exists, make the ./configure script of vlc-0.9.0-svn wrongly believe that you have swscale in ffmpeg which will give a problem even if ffmpeg is compiled withouth swscale support.
For compiling vlc-0.8.6b this is not necessary but it is still a good idea to remove this header file.


In short: remove, disable, deactivate, destroy, annihilate, exterminate in ffmpeg erverything which has the name "swscale" in it

and then it should be okay with vlc. In my case the swcale broke the use of h264 and wmv3 codec in vlc, however mpeg2 still worked correctly.

So if I understand correctly does neither version of vlc work with a swscaler enabled version of ffmpeg, or does 0.9 work with swscaler, but you have to rename swscale.h before compiling vlc?

[kmf31]

@kmf31: VLC does NOT use ffmpeg for MPEG-2 decoding.

Okay, indeed I verified with "-vvv" and a mpeg2 file. There is also libmpeg2.

Maybe if libmpeg2 is absent vlc tries to fall back to ffmpeg ?

Sometimes there is also the issue of mpeg2 encoding (for streaming) and here it is ffmpeg which is used.

I would think that mp2 (the audio part of mpeg2) should work even with a "buggy" ffmpeg but maybe one needs for this a working version of libmpeg2 and/or liblame ?

In any case, it is a good think to compile ffmpeg without swscale.

[kmf31]

So if I understand correctly does neither version of vlc work with a swscaler enabled version of ffmpeg, or does 0.9 work with swscaler, but you have to rename swscale.h before compiling vlc?

My personal experience was the following:

1) If I compile (a recent svn-version of) ffmpeg with "--enable-swscale" then both vlc-0.8.6b and vlc-0.9.0-svn do not work with mpeg4-h264 nor wmv3 but still with mpeg2 (but this is not astonishing if vlc uses libmpeg2 for mpeg2 and not ffmpeg).

2) If I compile ffmpeg without "--enable-swscale" then vlc-0.8.6b works with h264 and wmv3 but not the latest vlc-0.9.0-svn. Here one sees in the ./configure logs that vlc-0.9.0-svn tries to verify if he can enable swscale in vlc (which only seems to exist in vlc-0.9.0-svn but not in vlc-0.8.6b). He finds the header file swscale.h for ffmpeg (which was installed despite the non-activation of swscale in ffmpeg) and activates "swscale" in vlc.

3) I compile ffmpeg without "--enable-swscale" and after installation of ffmpeg I remove or rename the header file "swscale.h". Then I recompile vlc-0.9.0-svn and now the ./configure of vlc does not activate swscale in vlc since he does not find the header file and afterwards also h264 and wmv3 work in vlc-0.9.0-svn.


I suppose that swscale is supposed to be a useful feature for the future versions of ffmpeg and vlc-0.9.0 but for the moment there are still bugs and it is not yet working. In particular swscale is by default not enabled in ffmpeg. However, I am not at all expert for this and I am only mentionning my personnal experience with compiling ffmpeg and vlc and this has cost me some time before realizing to avoid swscale.

[Jean-Baptiste Kempf]

Should have been clearer I meant mpeg layer 2 (ie: mp2 audio)

mp2 audio is decoded by libmad
mpeg-2 video is decoded by libmpeg2

[Jean-Baptiste Kempf]

@kmf31: VLC does NOT use ffmpeg for MPEG-2 decoding.

Okay, indeed I verified with "-vvv" and a mpeg2 file. There is also libmpeg2.

Maybe if libmpeg2 is absent vlc tries to fall back to ffmpeg ?

Sometimes there is also the issue of mpeg2 encoding (for streaming) and here it is ffmpeg which is used.

I would think that mp2 (the audio part of mpeg2) should work even with a "buggy" ffmpeg but maybe one needs for this a working version of libmpeg2 and/or liblame ?

In any case, it is a good think to compile ffmpeg without swscale.

Exact, if libmpeg2 is absent, the fallback is on ffmpeg.
MPEG-2 audio is readed by libmad, and the fallback is also on ffmpeg, IIRC.

Exact, don't use swscale with VLC.

[Jean-Baptiste Kempf]

[
1) If I compile (a recent svn-version of) ffmpeg with "--enable-swscale" then both vlc-0.8.6b and vlc-0.9.0-svn do not work with mpeg4-h264 nor wmv3 but still with mpeg2 (but this is not astonishing if vlc uses libmpeg2 for mpeg2 and not ffmpeg).

2) If I compile ffmpeg without "--enable-swscale" then vlc-0.8.6b works with h264 and wmv3 but not the latest vlc-0.9.0-svn. Here one sees in the ./configure logs that vlc-0.9.0-svn tries to verify if he can enable swscale in vlc (which only seems to exist in vlc-0.9.0-svn but not in vlc-0.8.6b). He finds the header file swscale.h for ffmpeg (which was installed despite the non-activation of swscale in ffmpeg) and activates "swscale" in vlc.

3) I compile ffmpeg without "--enable-swscale" and after installation of ffmpeg I remove or rename the header file "swscale.h". Then I recompile vlc-0.9.0-svn and now the ./configure of vlc does not activate swscale in vlc since he does not find the header file and afterwards also h264 and wmv3 work in vlc-0.9.0-svn.


I suppose that swscale is supposed to be a useful feature for the future versions of ffmpeg and vlc-0.9.0 but for the moment there are still bugs and it is not yet working. In particular swscale is by default not enabled in ffmpeg. However, I am not at all expert for this and I am only mentionning my personnal experience with compiling ffmpeg and vlc and this has cost me some time before realizing to avoid swscale.

1. yes
2.3. There is a patch on the mailing list to correct this misbehaviour. It is not yet in the trunk.
I never make install ffmpeg, so no .h problems. I just use --with-ffmpeg-tree=

[redtux]

Thanks for this. What I eneded up doing is:

created a fresh set of ffmpegvlc rpms installing ffmpeg in /usr/local without swscale

setup v simple bash script with two lines - export LD_LIBRARY_PATH=/usr/local/lib; /usr/bin/vlc

then call this instead of vlc

this makes 8.6b work again

need to grab qt4-devel before I can have another go at compiling trunk

will need to set include path before compiling

O/T - does setting C_INCLUDES_PATH mean that this is read before /usr/include or after

[Jean-Baptiste Kempf]

the header thing should be fixed in trunk