This adds optional support for vlc's ffmpeg codec plugin Reproducible: Always Steps to Reproduce: depends on "USE avi"; there should ideally have an "USE divx" IMHO
Created attachment 10407 [details] this is the ebuild
try a ./configure -h and i see a lot of possible USE variables. XVID, ffmpeg, v4l, faad, theora, tarkin, vorbis and wxwindows.
i submitted an updated ebuild here http://bugs.gentoo.org/show_bug.cgi?id=15916 (some parts of which have already been commited to the offical portage ebuild) which added support for all the libs i could already find in the portage tree things like theora were a pain to compile and didn't have existing ebuilds so i didn't bother about them, but the ffmpeg support is very important IMO it makes vlc much more useful. The wxwindows stuff is a little difficult as certain versions have problems. IIRC vlc fails with wxwindows + gtk2
Created attachment 11473 [details] new dvd package that vlc uses As a videolan developer i'm trying to get a more up to date build of vlc running. All the following is necesarry, or higly desireable for vlc 0.5.3 libdvdplay is a new library that handles dvdmenu's. it depends on libdvdread. It's a very simple ebuild, should be very very easy to add. btw. vlc 0.5.2 with USE dvd should be build with this as well.
Created attachment 11474 [details, diff] a mpeg1 and mpeg2 decoder used by vlc. vlc needs this library from version 0.5.3 and up to decode mpeg video. support for vlc's own library was dropped. It is a cvs version, because this version is much better then the current release. the corresponding release of this cvs version will be in about two weeks, when vlc 0.5.4 will be released as well. It's very stable in this form. it hasn't required cvs commits in over two weeks now. (and this is under heavy development) ;) because it's cvs, it not compiled as a shared library, just to be sure programs don't break. sdl and x11 support are disabled, because /libvo/configure file is broken and this is actually for mpeg2dec which is kinda the test program for libmpeg2. libmpeg2 does not need it at all. I marked it as patch because i saw the previous mail didn't come true
Created attachment 11475 [details, diff] ffmpeg build the current ffmpeg is getting quite old. a cvs version is better suited in many cases
Created attachment 11477 [details, diff] ffmpeg diff a diff that goes with the new ffmpeg build
Created attachment 11483 [details, diff] a new vlc ebuild version 0.5.3 this vlc ebuild is for 0.5.3, it uses several new use variables. it also requires several updated libraries, like ffmpeg-cvs and libmpeg2-cvs to which it statically links. it should be noted that without specifying at least a few USE variables, the user is possible to build a pretty useless version of vlc. vlc is highly modular, and unlike mplayer, does not contain it's own version of most of the libraries. actually, i have just noticed some potential problems with static linking with ffmpeg /usr/lib/libavcodec.a(oggvorbis.o)(.text+0x3f2):/var/tmp/portage/ffmpeg-0.4.6.20030304/work/ffmpeg-cvs-2003- 03-04/libavcodec/oggvorbis.c:211: undefined reference to `vorbis_synthesis_pcmout' /usr/lib/libavcodec.a(oggvorbis.o)(.text+0x4b1):/var/tmp/portage/ffmpeg-0.4.6.20030304/work/ffmpeg-cvs-2003- 03-04/libavcodec/oggvorbis.c:217: undefined reference to `vorbis_synthesis_read' /usr/lib/libavcodec.a(oggvorbis.o)(.text+0x4d8):/var/tmp/portage/ffmpeg-0.4.6.20030304/work/ffmpeg-cvs-2003- 03-04/libavcodec/oggvorbis.c:208: undefined reference to `vorbis_synthesis_blockin' and similiar errors for ffmpeg. not sure how to solve them. maybe symbolic linking is better afterall. a cvs build will always stay masked, so i don't really think it's a big problem.
small note to notify ppl by mail of this change. it appears they are not sent when you make changes to a bugreport from within a inline frame (guided format search results ;)
OK, i changed some things, and to make it easier, i put the stuff on a website. http://sidekick.student.utwente.nl/videolan/gentoo/ It works like a charm with this ;)
And it's me again. ;) i saw libdvdplay is in portage now. I also realized that my previous work on the vlc ebuid wasn't really great, because it could mess up current installations of other software. (bear with me, i'm pretty new on this ebuild stuff ) I realized that this wasn't too nice. So i redisigned the ebuild to 'include' ffmpeg and libmpeg2 and statically link to them, without actually installing any components of them. this should keep current installations in order. i have learned some things (like emake is really not a good idea with our make proces, since it is parallel, and our make cannot deal with that at all.) i've also realised that bootstrapping and autoconf automake is a bad idea, since our system require quite recent versions of automake and autoconf which some might not have. The make proces will automatically call either of those when this is really necesarry, and will use them in the appropriate way. Furthermore, the version on my page http://sidekick.student.utwente.nl/videolan/gentoo/ is now tailered towards 0.6.0 (previously called 0.5.4). it's also in our CVS now. Hope this helps you as much as it helps me ;)
vlc-0.6.0 is currently in portage with the aforementioned ffmpeg support. It is currently marked ~ until full compatibiliy testing is done with the newer libmpeg2 and ffmpeg builds. Please test.
thank you, I will test it thoroughly this week - if you don't hear from me, I found no problems :-)
vlc-0.6.2 has been in portage for a while now with no bug reports. marking stable for x86.
