Updating mplayer: how about using bundled ffmpeg?

Julian Sikorski belegdol at gmail.com
Mon Feb 27 13:08:20 CET 2012


W dniu 26.02.2012 20:44, Joseph D. Wagner pisze:
> 
> 
> 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<belegdol at gmail.com>:
>>>>> W dniu 26.02.2012 11:18, Nicolas Chauvet pisze:
>>>>>> 2012/2/26 Julian
>>>>>> Sikorski<belegdol at gmail.com>:
>>>>>>> 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
> 
> 
How did you solve the internal.h in mp_taglists.c issue?

Regards,
Julian



More information about the rpmfusion-developers mailing list