Arch Linux

a) can be fixed
b) "Won't Implement" because of http://bugs.archlinux.org/task/7943#comment22688

building ffmpeg with --enable-swscaler breaks sound output of mp4 files, even without using vlc at all.

I cannot get xvid files to be read since last update of ffmpeg. I have to use mplayer :(

Related to this ?!

Paul, the rebuild of ffmpeg with swscaler means that vlc is broken for good, and there is nothing I can do about fixing it.

See also  FS#8531  about weirdness of --enable-swscaler change.

IMHO the issue with swscaler must be resolved, since it renders vlc unusable with the majority of video material out there.
I think the way to keep everyone satisfied is to compile vlc statically against a swscaler-less ffmpeg tree (see `--with-ffmpeg-tree' configure option). I will try it tomorrow at work to see if it works and how big an impact it has on the package size.

Static linking works fine here, with the downside of an added 4,5 MB installed size (~ +25%). Attached is the relevant PKGBUILD for those willing to test it. Beware that the patch attached to the original bug report is needed, renamed as ffmpeg-20071204.patch.

Update: it seems that with ffmpeg-20071204 vlc ignores the video bitrate transcoding option [1] and streams with enormous bitrates (~6 Mbps for a 640x480 MPEG-4 stream). The issue was resolved by compiling against the ffmpeg-20070505 tree, the previous version of ffmpeg in Arch Linux.

Summary: it seems that recent ffmpeg breaks a lot of stuff in vlc. I have read that some of these problems have been ironed out in the vlc 0.9 development branch, but it seems that vlc 0.8.x still needs a relatively old version of ffmpeg to function properly. So, in a nutshell, if a newer version of the ffmpeg shared libraries is definitely needed, then compiling vlc staticaly against an older ffmpeg tree is probably the best solution.


[1] The same problem appears here as well: http://forum.videolan.org/viewtopic.php?f=2&t=42133

jacko from the forums mentioned that adding --diable-swscaler fixes this with the 20071204 version. Can someone verify?

It fixes the ffmpeg-vlc compatibility issue (and possibly breaks other apps), nevertheless vlc does not work properly; ffmpeg simply ignores the video bitrate setting during transcoding within vlc, and this happens in both, my Arch box and my Debian box with ffmpeg 20071204. It seems that there are basic API changes in this ffmpeg revision that make it incompatible with vlc. See my previous comments on this topic.

Just to bring this into the record here-- we specifically added the --enable-swscaler in response to this request:

http://bugs.archlinux.org/task/7943

After some thought, it seemed like holding back those wanting newer ffmpeg features for too long in order to prevent breaking vlc, especially when it appears the vlc coders are writing 9.0 which works with ffmpeg, was not the Arch way. However, I'm totally open to reconsidering this if there's new input we didn't consider before.

This scenario points out why it would be useful for ffmpeg to have actual releases. If you expect developers of dependent software to guess which featureset to rely upon, they will choose differently, and upgrading will break some things and fix others in ways that are hard to predict.

is there a possibility to have a vlc-devel pkg that provides a working 0.9.0 ? is the devel tree usable already? i tried to compile the vlc-nightly in AUR but it fails building real enabled.

@paul: I was thinking the same thing. This is the VLC developers fault and there's nothing we can do if they make crappy software. Issues like these are valid reasons in my book to search out alternative applications. Application 'foo' breaks a lot? Guess I'll go try 'bar' instead.

@phrakture: I think your judgement towards VLC is unfair; it's not their fault if ffmpeg has no official releases and no stable API[*] and obviously they cannot guarantee that VLC will compile against *any* SVN revision of a project they themselves do not have any control over. MPlayer (the creators of ffmpeg themselves) include an ffmpeg tree *integrated* in mplayer's source tree, so I expect having to do the same with VLC wouldn't make it any "crappier" than MPlayer, would it?

Bottomline: it's been 10 days since the ffmpeg update and /usr/lib/vlc/codecs/libffmpeg_plugin.so *still* links with absent versions of libx264 and libavformat, thus making vlc virtually unusable for any ordinary media playback and leaving "extra" in an inconsistent state. VLC, despite being "crappy", has a big community of users and happens to be the best streaming-video solution available on all major platforms. I have pointed out a solution that has worked for me fine sofar and could - at least temporarily, until vlc 0.9 is out or a different decision is made - solve the problem without compromising on the system's ffmpeg package. However no-one seems to have paid any attention to it. Is *this* the Arch way? (really, no offence intended here)

[*] Hint: the fact that the so-version of libavformat changed between 20070505 and 20071204 should have warned us of a potential API breakage.

As I tried to suggest above, I *do* sympathize with both sides in this debate, even though I think ffmpeg must not stagnate because of incompatibilities of third-party software with newer versions. I am in favor of the solution apoikos proposed, at least as a temporary band-aid.

Unless someone here objects, I will rebuild vlc sometime tomorrow (Sunday 2/2) with the statically linked older ffmpeg. This is clearly only making things better in the moment, and we can continue a debate about this while vlc users are happily vlc-ing.

Apoikos, if you have further tweaked the PKGBUILD at all since you posted above, please repost here today so I can use the latest when I build/release tomorrow.

This is the last PKGBUILD that I used.

okay, as vlc maintainer I should add my two cents at least. First, I was sick for the majority of the week, so I'm sorry for not responding. I'm on Pauls side with that issue, if we can build a static version I'm fine with it. However I like to point out, that vlc is not really a joy to maintain at the moment. On top of the ffmpeg issue, there are reoccuring incompatibilities with wxwidgets etc. I'm aware that most issues will be gone with the 0.9 devel version(will use QT). But for now I can only recommend to stay away from vlc and use either xine or mplayer based packages.

since i need from time to time unicast streaming and vlc is the easiest way to do this, i checked vlc-nightly (in AUR unsupported) and made it work. now it builds fine and in theory i can put it in [unstable] as a temporal replacement for vlc for the people who need vlc full functionallity (ffmpeg support) but do not mind it being a little bit more unstable. what do you think? i'm not going to host it just for 2 or 3 people, but only if there is the need (its big and compiles slow).

Built tonight but got a lot of namcap warnings. It looks like these are probably plugins and so not required as runtime depends, but shouldn't they be makedepends? Otherwise different people building the package could end up with different sets of functionality.

vlc E: Dependency detected and not included (speex) from files ['usr/lib/vlc/codec/libspeex_plugin.so']
vlc E: Dependency detected and not included (gnome-vfs) from files ['usr/lib/vlc/access/libaccess_gnomevfs_plugin.so']
vlc E: Dependency detected and not included (libnotify) from files ['usr/lib/vlc/misc/libnotify_plugin.so']
vlc E: Dependency detected and not included (lirc-utils) from files ['usr/lib/vlc/control/liblirc_plugin.so']
vlc E: Dependency detected and not included (sdl_image) from files ['usr/lib/vlc/codec/libsdl_image_plugin.so']
vlc E: Dependency detected and not included (libmpcdec) from files ['usr/lib/vlc/demux/libmpc_plugin.so']
vlc E: Dependency detected and not included (libmodplug) from files ['usr/lib/vlc/demux/libmod_plugin.so']

And are there any other plugins in use that may not be in the depends array and so I might not have gotten in my build?

those should be fine, since vlc works without those dependencies just the plugins won't work. THe depends list is long enough though without them :P
But the list looks proper to me as they are all in the makedepends array

actually the only thing in vlc-nightly that i seem to fail getting is real support. when i enable it, it fails compiling (x86_64 20080201) probably because of some missing lib. everything else works more or less (vlc 0.9.0 segfaults sometimes instead of shutting down gently, but only while closing it, so i do not mind while it is working for the things i need)

@Apollon: We have three or four issues in this bug report. Only one of them really has to do with ArchLinux and that is lost in massive amounts of text describing upstream bugs. I think if this was explained more plainly it could have been covered much sooner.

I've released vlc 0.8.6d-2 which includes the static ffmpeg.

This is intended at least as a bandaid. I'll leave it up to Tobias what to do from here, but in the short term, please report in here whether or not this makes vlc in [extra] usable again.

It's alive! Thank you Paul!
VLC works just like before.