[MPlayer-users] compile failed

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Sep 29 09:02:57 EEST 2017


On 27.09.2017, at 18:28, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 25 Sep 2017 00:24:45 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> On 24.09.2017, at 05:02, Masaru Nomiya <nomiya at galaxy.dti.ne.jp> wrote:
>> 
>>> Hello,
>>> 
>>> I got the very latest svn head, then tried to compile.
>>> But, I got errors;
>>> 
>>> thread -ldl -rdynamic -L/usr/lib64 -L/opt/kde3/lib64 -L/usr/local/lib64 -ldvdnav -lpthread   -lm   -ltwolame -lfaac -lx264 -lpthread -lmp3lame
>>> ffmpeg/libavcodec/libavcodec.a(v4l2_m2m_dec.o): In function `v4l2_receive_frame':
>>> /tmp/nom/mplayer/ffmpeg/libavcodec/v4l2_m2m_dec.c:157: undefined reference to `ff_v4l2_context_dequeue_frame'  
>> 
>> Strange, is this on Linux? Either way I expect it is fixed by disabling these files as they caused issues on non-Linux systems, so they are disabled for now.
>> They won't be interesting for the vast majority of users anyway.
> 
> That makes me wonder why MPlayer _still_ uses the frankenstein approach
> of an "in-tree" FFmpeg with its build system partially replaced. It
> seems to cause regressions every other week.
> 
> Wouldn't it be much easier to default to an external FFmpeg?

Only changing the default would mean it still needs to be fixed, thus not any less effort...
In exchange, it would mean having to do a proper version check and supporting multiple FFmpeg versions, which is quite some effort.
Though that doesn't mean that it might not make sense to change the default anyway.


More information about the MPlayer-users mailing list