Hi, I was trying to update mplayer and most of the problems I am having are due to using shared ffmpeg, which is discouraged and unsupported by upstream. The latest error is: libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No such file or directory when trying to build 20120204 snapshot. Looking at the svn log, this was added in revision 34243 (from 20111023). This all seems to indicate that trying to use system ffmpeg is an uphill battle which will always going to keep our mplayer behind, as well as piss upstream off when we come asking for help. The alternative would be to switch to mplayer2. What are your opinions?

W dniu 26.02.2012 11:18, Nicolas Chauvet pisze: > 2012/2/26 Julian Sikorski <belegdol(a)gmail.com&gt;: >> Hi, >> >> I was trying to update mplayer and most of the problems I am having are >> due to using shared ffmpeg, which is discouraged and unsupported by >> upstream. The latest error is: >> >> libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No >> such file or directory >> >> when trying to build 20120204 snapshot. Looking at the svn log, this was >> added in revision 34243 (from 20111023). This all seems to indicate that >> trying to use system ffmpeg is an uphill battle which will always going >> to keep our mplayer behind, as well as piss upstream off when we come >> asking for help. >> The alternative would be to switch to mplayer2. What are your opinions? > > I have no problem with moving to mplayer2 unless it's tight to > switching to libav over ffmpeg. But I don't think it  would be > related. > Is there any drawback to moving to mplayer2 ? Well, I am not sure really. The last release was almost a year ago, but the git has been relatively active: http://git.mplayer2.org/mplayer2/ mplayer has a much bigger developer base, though. > > The current situation cannot hold any longer given that even for minor > ffmpeg update, I need to rebuild mplayer anyway. So given that's not > supported upstream I cannot see any reason to continue with this > situation. > > Thx for working on this. > > Nicolas (kwizart) > I'd say the best solution would be to build mplayer using internal ffmpeg, and then offer mplayer2 as an alternative. I have a working spec for mplayer w/ internal ffmpeg, it only does not build on rawhide due to gcc-4.7 shenaningans.

W dniu 26.02.2012 12:49, Nicolas Chauvet pisze: > 2012/2/26 Julian Sikorski <belegdol(a)gmail.com&gt;: >> W dniu 26.02.2012 11:18, Nicolas Chauvet pisze: >>> 2012/2/26 Julian Sikorski <belegdol(a)gmail.com&gt;: >>>> Hi, >>>> >>>> I was trying to update mplayer and most of the problems I am having are >>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>> upstream. The latest error is: >>>> >>>> libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No >>>> such file or directory >>>> >>>> when trying to build 20120204 snapshot. Looking at the svn log, this was >>>> added in revision 34243 (from 20111023). This all seems to indicate that >>>> trying to use system ffmpeg is an uphill battle which will always going >>>> to keep our mplayer behind, as well as piss upstream off when we come >>>> asking for help. >>>> The alternative would be to switch to mplayer2. What are your opinions? >>> >>> I have no problem with moving to mplayer2 unless it's tight to >>> switching to libav over ffmpeg. But I don't think it would be >>> related. >>> Is there any drawback to moving to mplayer2 ? >> >> Well, I am not sure really. The last release was almost a year ago, but >> the git has been relatively active: >> >> http://git.mplayer2.org/mplayer2/ >> >> mplayer has a much bigger developer base, though. >>> >>> The current situation cannot hold any longer given that even for minor >>> ffmpeg update, I need to rebuild mplayer anyway. So given that's not >>> supported upstream I cannot see any reason to continue with this >>> situation. >>> >>> Thx for working on this. >>> >>> Nicolas (kwizart) >>> >> I'd say the best solution would be to build mplayer using internal >> ffmpeg, and then offer mplayer2 as an alternative. I have a working spec >> for mplayer w/ internal ffmpeg, it only does not build on rawhide due to >> gcc-4.7 shenaningans.

> > No, one need to make a decision, those are not parallel installable IIRC. > > > Nicolas (kwizart). > Ah, indeed. Then I'm in favour of mplayer w/ internal ffmpeg.

Julian

On 02/26/2012 10:02 AM, Sérgio Basto wrote: > On Sun, 2012-02-26 at 13:20 +0100, Julian Sikorski wrote: >> W dniu 26.02.2012 12:49, Nicolas Chauvet pisze: >>> 2012/2/26 Julian >>> Sikorski&lt;belegdol(a)gmail.com&gt;: >>>> W dniu 26.02.2012 11:18, Nicolas Chauvet pisze: >>>>> 2012/2/26 Julian >>>>> Sikorski&lt;belegdol(a)gmail.com&gt;: >>>>>> Hi, >>>>>> >>>>>> I was trying to update mplayer and most of the problems I am >>>>>> having are >>>>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>>>> upstream. The latest error is: >>>>>> >>>>>> libmpdemux/mp_taglists.c:27:34: fatal error: >>>>>> libavformat/internal.h: No >>>>>> such file or directory >>>>>> >>>>>> when trying to build 20120204 snapshot. Looking at the svn log, >>>>>> this was >>>>>> added in revision 34243 (from 20111023). This all seems to >>>>>> indicate that >>>>>> trying to use system ffmpeg is an uphill battle which will always >>>>>> going >>>>>> to keep our mplayer behind, as well as piss upstream off when we >>>>>> come >>>>>> asking for help. >>>>>> The alternative would be to switch to mplayer2. What are your >>>>>> opinions? >>>>> I have no problem with moving to mplayer2 unless it's tight to >>>>> switching to libav over ffmpeg. But I don't think it would be >>>>> related. >>>>> Is there any drawback to moving to mplayer2 ? >>>> Well, I am not sure really. The last release was almost a year ago, >>>> but >>>> the git has been relatively active: >>>> >>>> http://git.mplayer2.org/mplayer2/ >>>> >>>> mplayer has a much bigger developer base, though. >>>>> The current situation cannot hold any longer given that even for >>>>> minor >>>>> ffmpeg update, I need to rebuild mplayer anyway. So given that's not >>>>> supported upstream I cannot see any reason to continue with this >>>>> situation. >>>>> >>>>> Thx for working on this. >>>>> >>>>> Nicolas (kwizart) >>>>> >>>> I'd say the best solution would be to build mplayer using internal >>>> ffmpeg, and then offer mplayer2 as an alternative. I have a working >>>> spec >>>> for mplayer w/ internal ffmpeg, it only does not build on rawhide >>>> due to >>>> gcc-4.7 shenaningans. > yeah so lets build it for F-16 without gcc.-4.7 . > > >>> No, one need to make a decision, those are not parallel installable >>> IIRC. >>> >>> >>> Nicolas (kwizart). >>> >> Ah, indeed. Then I'm in favour of mplayer w/ internal ffmpeg. > Obviously, they suggest use internal ffmpeg , as all others who ship > internal software . But first I'd like to know if you try with new > ffmpeg-0.10 which have new x264 , or stable ffmpeg from rpmfusion , in > F-16 environment . > Other thing that would be nice is a link for "mplayer 20120204 > snapshot". My problem with using internal ffmpeg is that it balloons mplayer up to about 50 mb from it's current 3.7 mb. I've gotten mplayer to build using an external ffmpeg EXCEPT for the very last step where it actually links mplayer to the ffmpeg libraries. There's a problem with the Makefile. I filed this bug report with the mplayer group: http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2043 They closed it because it didn't have enough information. I was going to reopen it and add the missing information. I just hadn't gotten that far yet. Joseph D. Wagner

2012/2/26 Julian Sikorski&lt;belegdol(a)gmail.com&gt;: > Hi, > > I was trying to update mplayer and most of the problems I am having are > due to using shared ffmpeg, which is discouraged and unsupported by > upstream. The latest error is: > > libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No > such file or directory > > when trying to build 20120204 snapshot. Looking at the svn log, this was > added in revision 34243 (from 20111023). This all seems to indicate that > trying to use system ffmpeg is an uphill battle which will always going > to keep our mplayer behind, as well as piss upstream off when we come > asking for help. > The alternative would be to switch to mplayer2. What are your opinions? I have no problem with moving to mplayer2 unless it's tight to switching to libav over ffmpeg. But I don't think it would be related. Is there any drawback to moving to mplayer2 ?

Julian Sikorski wrote: > I was trying to update mplayer and most of the problems I am having are > due to using shared ffmpeg, which is discouraged and unsupported by > upstream. The latest error is: > > libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No > such file or directory > > when trying to build 20120204 snapshot. Looking at the svn log, this was > added in revision 34243 (from 20111023). This all seems to indicate that > trying to use system ffmpeg is an uphill battle which will always going > to keep our mplayer behind, as well as piss upstream off when we come > asking for help. I don't think bundling is an acceptable solution, especially with something like FFmpeg which has security updates quite frequently.

W dniu 27.02.2012 07:16, Ralf Corsepius pisze: > On 02/27/2012 02:55 AM, Kevin Kofler wrote: >> Julian Sikorski wrote: >>> I was trying to update mplayer and most of the problems I am having are >>> due to using shared ffmpeg, which is discouraged and unsupported by >>> upstream. The latest error is: >>> >>> libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No >>> such file or directory >>> >>> when trying to build 20120204 snapshot. Looking at the svn log, this was >>> added in revision 34243 (from 20111023). This all seems to indicate that >>> trying to use system ffmpeg is an uphill battle which will always going >>> to keep our mplayer behind, as well as piss upstream off when we come >>> asking for help. >> >> I don't think bundling is an acceptable solution, especially with >> something >> like FFmpeg which has security updates quite frequently. > > +1 > > Ralf > > Well, I tried building it using system ffmpeg and have not succeeded yet. I am really not sure if going against upstream is the smart choice here, given that, at least in my case, I am going to need them to fix bugs. Help in unbundling ffmpeg is welcome.

W dniu 27.02.2012 07:16, Ralf Corsepius pisze: > On 02/27/2012 02:55 AM, Kevin Kofler wrote: >> Julian Sikorski wrote: >>> I was trying to update mplayer and most of the problems I am having are >>> due to using shared ffmpeg, which is discouraged and unsupported by >>> upstream. The latest error is: >>> >>> libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No >>> such file or directory >>> >>> when trying to build 20120204 snapshot. Looking at the svn log, this was >>> added in revision 34243 (from 20111023). This all seems to indicate that >>> trying to use system ffmpeg is an uphill battle which will always going >>> to keep our mplayer behind, as well as piss upstream off when we come >>> asking for help. >> >> I don't think bundling is an acceptable solution, especially with >> something >> like FFmpeg which has security updates quite frequently. > > +1 > > Ralf > > Well, I tried building it using system ffmpeg and have not succeeded yet. I am really not sure if going against upstream is the smart choice here, given that, at least in my case, I am going to need them to fix bugs. Help in unbundling ffmpeg is welcome.

W dniu 27.02.2012 13:20, Ralf Corsepius pisze: > On 02/27/2012 12:40 PM, Julian Sikorski wrote: >> W dniu 27.02.2012 07:16, Ralf Corsepius pisze: >>> On 02/27/2012 02:55 AM, Kevin Kofler wrote: >>>> Julian Sikorski wrote: >>>>> I was trying to update mplayer and most of the problems I am having >>>>> are >>>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>>> upstream. The latest error is: >>>>> >>>>> libmpdemux/mp_taglists.c:27:34: fatal error: >>>>> libavformat/internal.h: No >>>>> such file or directory >>>>> >>>>> when trying to build 20120204 snapshot. Looking at the svn log, >>>>> this was >>>>> added in revision 34243 (from 20111023). This all seems to indicate >>>>> that >>>>> trying to use system ffmpeg is an uphill battle which will always >>>>> going >>>>> to keep our mplayer behind, as well as piss upstream off when we come >>>>> asking for help. >>>> >>>> I don't think bundling is an acceptable solution, especially with >>>> something >>>> like FFmpeg which has security updates quite frequently. >>> >>> +1 >>> >>> Ralf >>> >>> >> Well, I tried building it using system ffmpeg and have not succeeded >> yet. I am really not sure if going against upstream is the smart choice >> here, given that, at least in my case, I am going to need them to fix >> bugs. >> Help in unbundling ffmpeg is welcome. > > Where can I find your *.specs/*srpms? > > Ralf > > The current version (with bundled ffmpeg) is here: https://share.ols.inode.at/IJM7N7JP71NCU8DVTA2JEFWKL3YC3V1LEMR3TBRZ it fails to build on Fedora 17 and above due to [1]. Julian [1] https://ffmpeg.org/trac/ffmpeg/ticket/1024

W dniu 27.02.2012 13:20, Ralf Corsepius pisze: > On 02/27/2012 12:40 PM, Julian Sikorski wrote: >> W dniu 27.02.2012 07:16, Ralf Corsepius pisze: >>> On 02/27/2012 02:55 AM, Kevin Kofler wrote: >>>> Julian Sikorski wrote: >>>>> I was trying to update mplayer and most of the problems I am having >>>>> are >>>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>>> upstream. The latest error is: >>>>> >>>>> libmpdemux/mp_taglists.c:27:34: fatal error: >>>>> libavformat/internal.h: No >>>>> such file or directory >>>>> >>>>> when trying to build 20120204 snapshot. Looking at the svn log, >>>>> this was >>>>> added in revision 34243 (from 20111023). This all seems to indicate >>>>> that >>>>> trying to use system ffmpeg is an uphill battle which will always >>>>> going >>>>> to keep our mplayer behind, as well as piss upstream off when we come >>>>> asking for help. >>>> >>>> I don't think bundling is an acceptable solution, especially with >>>> something >>>> like FFmpeg which has security updates quite frequently. >>> >>> +1 >>> >>> Ralf >>> >>> >> Well, I tried building it using system ffmpeg and have not succeeded >> yet. I am really not sure if going against upstream is the smart choice >> here, given that, at least in my case, I am going to need them to fix >> bugs. >> Help in unbundling ffmpeg is welcome. > > Where can I find your *.specs/*srpms? > > Ralf > > Here is the spec in the shared ffmpeg version - it fails to build due to internal.h inclusion. You need to comment out the gui building - I have not figured out why it fails yet. https://share.ols.inode.at/72IFK6BJDE97LBN2C2AP6PEJ7XMW5F7AHPQ3V2L0 Julian

Julian Sikorski wrote: > To be more verbose, gui fails to build due to ff_png not being returned > by objdump on libavcodec.so. I have no idea why, since according to > rpmfusion build logs both ffmpeg-0.8.9-1.fc17 and ffmpeg-0.10-1.fc18 > were built with png support. I think this might be an outdated test in configure. There are ff_png private functions in libavcodec, but no public ones, so there's no reason for it to exist in libavcodec.so. And mplayer does not try to call ff_png anything. The GUI built and seems to run fine for me after commenting out the configure test.

On Mon, 2012-02-27 at 14:10 +0100, Julian Sikorski wrote: > W dniu 27.02.2012 13:54, Julian Sikorski pisze: >> W dniu 27.02.2012 13:20, Ralf Corsepius pisze: >>> On 02/27/2012 12:40 PM, Julian Sikorski wrote: >>>> W dniu 27.02.2012 07:16, Ralf Corsepius pisze: >>>>> On 02/27/2012 02:55 AM, Kevin Kofler wrote: >>>>>> Julian Sikorski wrote: >>>>>>> I was trying to update mplayer and most of the problems I am having >>>>>>> are >>>>>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>>>>> upstream. The latest error is: >>>>>>> >>>>>>> libmpdemux/mp_taglists.c:27:34: fatal error: >>>>>>> libavformat/internal.h: No >>>>>>> such file or directory >>>>>>> >>>>>>> when trying to build 20120204 snapshot. Looking at the svn log, >>>>>>> this was >>>>>>> added in revision 34243 (from 20111023). This all seems to indicate >>>>>>> that >>>>>>> trying to use system ffmpeg is an uphill battle which will always >>>>>>> going >>>>>>> to keep our mplayer behind, as well as piss upstream off when we come >>>>>>> asking for help. >>>>>> >>>>>> I don't think bundling is an acceptable solution, especially with >>>>>> something >>>>>> like FFmpeg which has security updates quite frequently. >>>>> >>>>> +1 >>>>> >>>>> Ralf >>>>> >>>>> >>>> Well, I tried building it using system ffmpeg and have not succeeded >>>> yet. I am really not sure if going against upstream is the smart choice >>>> here, given that, at least in my case, I am going to need them to fix >>>> bugs. >>>> Help in unbundling ffmpeg is welcome. >>> >>> Where can I find your *.specs/*srpms? >>> >>> Ralf >>> >>> >> Here is the spec in the shared ffmpeg version - it fails to build due to >> internal.h inclusion. >> You need to comment out the gui building - I have not figured out why it >> fails yet. >> >> https://share.ols.inode.at/72IFK6BJDE97LBN2C2AP6PEJ7XMW5F7AHPQ3V2L0 >> >> Julian >> >> > To be more verbose, gui fails to build due to ff_png not being returned > by objdump on libavcodec.so. I have no idea why, since according to > rpmfusion build logs both ffmpeg-0.8.9-1.fc17 and ffmpeg-0.10-1.fc18 > were built with png support. this look like issues with new version of libpng on F-17 , try add png-devel in BuildRequires (just a guesse in dark) . > > Julian >

On Mon, Feb 27, 2012 at 8:47 AM, Julian Sikorski <belegdol(a)gmail.com&gt; wrote: [SNIP] > I just changed the way ffmpeg support is queried since it was patched > anyway and now everything builds. Please test as I do not have a F-17 > machine set up. Does the previous download link you posted have this change? I have F17 in a virtual machine I can test with when I get home from work. Richard

On Mon, 2012-02-27 at 15:47 +0100, Julian Sikorski wrote: > W dniu 27.02.2012 15:43, Sérgio Basto pisze: >> On Mon, 2012-02-27 at 14:10 +0100, Julian Sikorski wrote: >>> W dniu 27.02.2012 13:54, Julian Sikorski pisze: >>>> W dniu 27.02.2012 13:20, Ralf Corsepius pisze: >>>>> On 02/27/2012 12:40 PM, Julian Sikorski wrote: >>>>>> W dniu 27.02.2012 07:16, Ralf Corsepius pisze: >>>>>>> On 02/27/2012 02:55 AM, Kevin Kofler wrote: >>>>>>>> Julian Sikorski wrote: >>>>>>>>> I was trying to update mplayer and most of the problems I am having >>>>>>>>> are >>>>>>>>> due to using shared ffmpeg, which is discouraged and unsupported by >>>>>>>>> upstream. The latest error is: >>>>>>>>> >>>>>>>>> libmpdemux/mp_taglists.c:27:34: fatal error: >>>>>>>>> libavformat/internal.h: No >>>>>>>>> such file or directory >>>>>>>>> >>>>>>>>> when trying to build 20120204 snapshot. Looking at the svn log, >>>>>>>>> this was >>>>>>>>> added in revision 34243 (from 20111023). This all seems to indicate >>>>>>>>> that >>>>>>>>> trying to use system ffmpeg is an uphill battle which will always >>>>>>>>> going >>>>>>>>> to keep our mplayer behind, as well as piss upstream off when we come >>>>>>>>> asking for help. >>>>>>>> >>>>>>>> I don't think bundling is an acceptable solution, especially with >>>>>>>> something >>>>>>>> like FFmpeg which has security updates quite frequently. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Ralf >>>>>>> >>>>>>> >>>>>> Well, I tried building it using system ffmpeg and have not succeeded >>>>>> yet. I am really not sure if going against upstream is the smart choice >>>>>> here, given that, at least in my case, I am going to need them to fix >>>>>> bugs. >>>>>> Help in unbundling ffmpeg is welcome. >>>>> >>>>> Where can I find your *.specs/*srpms? >>>>> >>>>> Ralf >>>>> >>>>> >>>> Here is the spec in the shared ffmpeg version - it fails to build due to >>>> internal.h inclusion. >>>> You need to comment out the gui building - I have not figured out why it >>>> fails yet. >>>> >>>> https://share.ols.inode.at/72IFK6BJDE97LBN2C2AP6PEJ7XMW5F7AHPQ3V2L0 >>>> >>>> Julian >>>> >>>> >>> To be more verbose, gui fails to build due to ff_png not being returned >>> by objdump on libavcodec.so. I have no idea why, since according to >>> rpmfusion build logs both ffmpeg-0.8.9-1.fc17 and ffmpeg-0.10-1.fc18 >>> were built with png support. >> >> this look like issues with new version of libpng on F-17 , try add >> png-devel in BuildRequires (just a guesse in dark) . >> >>> >>> Julian >>> >> > I just changed the way ffmpeg support is queried since it was patched > anyway and now everything builds. Please test as I do not have a F-17 > machine set up. I will test it on F16 , but where the all the things, ffmpeg, mplayer etc src.rpm ? how I can view list of yours packages in share.ols.inode.at ? , by date ?

we need to see what you change (in patches) to approve and commit in a 2nd phase. So a complete list of what is new or altered patches is also welcome .

Thanks, > Julian >

W dniu 27.02.2012 16:00, Sérgio Basto pisze:

> we need to see what you change (in patches) to approve and commit in a > 2nd phase. > > So a complete list of what is new or altered patches is also welcome . Output of cvs diff -u is attached - I was working on mplayer/F-17 since kwizart deleted the spec from devel.

Julian Sikorski wrote: > Hi, > > I was trying to update mplayer and most of the problems I am having are > due to using shared ffmpeg, which is discouraged and unsupported by > upstream. The latest error is: > > libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No > such file or directory > > when trying to build 20120204 snapshot. Looking at the svn log, this was > added in revision 34243 (from 20111023). This all seems to indicate that > trying to use system ffmpeg is an uphill battle which will always going > to keep our mplayer behind, as well as piss upstream off when we come > asking for help. > The alternative would be to switch to mplayer2. What are your opinions? It looks like the internal.h change was just in response to changes in ffmpeg rather piling on further internal linkage. The previous mplayer package in rpmfusion included libavformat/riff.h which simply provided the AVCodecTag struct (looks like a trimmed down version of ffmpeg's riff.h). Anyway, mp_taglists.c says it's including internal.h to get that symbol and if I provide a ffmpeg/libavformat/internal.h that has only that symbol (everything else ripped out) then mplayer compiles and links succesfully (and seems to work). I tried a more recent mplayer snapshot but that failed to build as mplayer has added bits to use (public) bits from ffmpeg that were added after ffmpeg 0.10. It looks like that change landed in mplayer on Feb 14. http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/2012-February/043662.html

Julian Sikorski wrote: > Hi, > > I was trying to update mplayer and most of the problems I am having are > due to using shared ffmpeg, which is discouraged and unsupported by > upstream. The latest error is: > > libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No > such file or directory > > when trying to build 20120204 snapshot. Looking at the svn log, this was > added in revision 34243 (from 20111023). This all seems to indicate that > trying to use system ffmpeg is an uphill battle which will always going > to keep our mplayer behind, as well as piss upstream off when we come > asking for help. > The alternative would be to switch to mplayer2. What are your opinions? It looks like the internal.h change was just in response to changes in ffmpeg rather piling on further internal linkage. The previous mplayer package in rpmfusion included libavformat/riff.h which simply provided the AVCodecTag struct (looks like a trimmed down version of ffmpeg's riff.h). Anyway, mp_taglists.c says it's including internal.h to get that symbol and if I provide a ffmpeg/libavformat/internal.h that has only that symbol (everything else ripped out) then mplayer compiles and links succesfully (and seems to work). I tried a more recent mplayer snapshot but that failed to build as mplayer has added bits to use (public) bits from ffmpeg that were added after ffmpeg 0.10. It looks like that change landed in mplayer on Feb 14. http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/2012-February/043662.html

Hi, I was trying to update mplayer and most of the problems I am having are due to using shared ffmpeg, which is discouraged and unsupported by upstream. The latest error is: libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No such file or directory when trying to build 20120204 snapshot. Looking at the svn log, this was added in revision 34243 (from 20111023). This all seems to indicate that trying to use system ffmpeg is an uphill battle which will always going to keep our mplayer behind, as well as piss upstream off when we come asking for help. The alternative would be to switch to mplayer2. What are your opinions? Regards, Julian