Bugzilla Bug 203594

`emerge mplayer` pulls in media-libs/x264-svn if the "x264" USE flag is
enabled, however it's not actually used if the "encode" USE flag is also
enabled.

From the ebuild (mplayer-1.0_rc2_p24929);
        if use encode; then
                use aac || myconf="${myconf} --disable-faac"
                use dv || myconf="${myconf} --disable-libdv"
                use x264 || myconf="${myconf} --disable-x264"
        else
                myconf="${myconf} --disable-mencoder --disable-libdv
--disable-x264 \
                        --disable-faac"
        fi

Interestingly, I have mplayer installed on two boxes, both with x264 in USE but
only one with encode.
x264-svn is pulled in in both cases, but as you can see it's disabled if
mencoder isn't built, however `ldd /usr/bin/mplayer` on the box with encode in
USE shows that the mplayer binary is actually linked to libx264.so as well as
mencoder, suggesting the possiblity that mplayer itself makes use of it even
without mencoder.

I suggest either changing the ebuild to depend on x264-svn if the x264 USE flag
is enabled irrespective of whether or not encode is also enabled, OR changing
the depends so x264-svn is only pulled in if the encode flag is enabled as well
as x264.

Reproducible: Always

That should read "however it's not actually used UNLESS the "encode" USE flag
is also enabled.

Reopen with a patch or something instead of this messy description.

Fair enough, I'll attach a patch to mplayer-1.0_rc2_p24929.ebuild so it only
pulls in x264-svn if the encode USE flag is also active.

Anyway, even if mplayer is compiled with libx264 support it still uses ffmpeg's
ffh264 for playback by default.

Created an attachment (id=139540) [details]
patch to fix the x264svn RDEPEND

Thanks, much more clear now... :)

Fixed in CVS, thanks