mplayer @1.5.0_0: consider adding libdvdread support

[cybertosher]

I am unable to use mplayer to view DVD files because the version included in the port does not have libdvdread support enabled. I get the following messages when I try to use mplayer with dvdnav://

MPlayer was compiled without libdvdread support.
MPlayer 1.5-14.0.0 (C) 2000-2022 MPlayer Team

[kencu (Ken)]

The mplayer port was trimmed back to a manageable set of defaults and all the rarely-to-never-tested variants were cleaned up here:

[d6e3444351d9e5844a9736c3ac4d0f991a66b920/macports-ports]

all of these options are disabled by default:

3dfx aa alsa apple-ir arts bl bluray caca cddb cdparanoia dart dga1 dga2 direct3d directfb \
directx dvb dvdnav dvdread dxr2 dxr3 esd faac faad fbdev ggi gif gui jack joystick kai kva \
ladspa liba52 libbs2b libdca libdv libnut libvorbis lirc live macosx-finder mad mga mng \
mpg123 musepack nas nemesi ossaudio pulse pvr qtx quartz radio  radio-capture  s3fb sdl \
sgiaudio smb sndio sunaudio svga tdfxfb tdfxvid theora toolame  tv-bsdbt848 tv-dshow \
tv-v4l1 tv-v4l2 twolame v4l2 vdpau vesa vidix vstream wii win32dll win32waveout x11 \
x264 xmga xmms xv xvid xvmc xvr100 zr

I am reluctant to start back down the unsustainable path of adding a large number of variants back in again, and prefer to have one clean port with a reasonable set of defaults. Most MacOS systems don't come with dvd drives any longer, but I'll see if there is a role for dvd support for disc images or similar.

You can set up your own copy of the mplayer port easily in your own local repository <​https://guide.macports.org/chunked/development.local-repositories.html> and adjust the portfile to your own liking quite easily. The mplayer portfile has been simplified now to the point where it is quite approachable for your own desired customizatons.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

all of these options are disabled by default:

3dfx aa alsa apple-ir arts bl bluray caca cddb cdparanoia dart dga1 dga2 direct3d directfb \
directx dvb dvdnav dvdread dxr2 dxr3 esd faac faad fbdev ggi gif gui jack joystick kai kva \
ladspa liba52 libbs2b libdca libdv libnut libvorbis lirc live macosx-finder mad mga mng \
mpg123 musepack nas nemesi ossaudio pulse pvr qtx quartz radio  radio-capture  s3fb sdl \
sgiaudio smb sndio sunaudio svga tdfxfb tdfxvid theora toolame  tv-bsdbt848 tv-dshow \
tv-v4l1 tv-v4l2 twolame v4l2 vdpau vesa vidix vstream wii win32dll win32waveout x11 \
x264 xmga xmms xv xvid xvmc xvr100 zr

If you mean they're disabled by default in the mplayer build system, then that is by itself not good justification for eliminating the ability to use them in MacPorts. It may not even be a good justification for turning those features off by default in MacPorts. MacPorts priorities are not always aligned with those of the upstream projects.

I am reluctant to start back down the unsustainable path of adding a large number of variants back in again, and prefer to have one clean port with a reasonable set of defaults.

"Defaults" is the wrong word there. It implies there is a method for the user to override those defaults. The method to do that in MacPorts is variants, and, after the cleanup, this port doesn't have such variants. Offering a reasonable set of defaults with a way for the user to override them is great.

Most MacOS systems don't come with dvd drives any longer, but I'll see if there is a role for dvd support for disc images or similar.

But users can purchase external USB DVD drives, and older computers, on which MacPorts still runs, have internal DVD drives.

You can set up your own copy of the mplayer port easily in your own local repository <​https://guide.macports.org/chunked/development.local-repositories.html> and adjust the portfile to your own liking quite easily. The mplayer portfile has been simplified now to the point where it is quite approachable for your own desired customizatons.

Developers can copy Portfiles and customize them, hopefully in anticipation of contributing their changes back to us, but modifying Portfiles is not something users should need to do in the normal course of using MacPorts. If they do, it means something is missing from the Portfile that should be added.

I don't know how vital it is to add DVD support to mplayer, but it doesn't seem like it should be too much of an imposition to add a non-default dvd variant to do that.

[kencu (Ken)]

I might have considered enabling dvd support as part of the standard build, if it would build on most to all systems with reasonable dependencies, but I can't personally take this port down the (IMHO) unsustainable path it was on with dozens of untested variants enabling each individual configure option (like the mpv port currently enjoys, with it's numerous open tickets including non-functional dvd reading support I note).

So I will release MPlayer/mplayer-devel back to the pool of openmaintainer ports for others to modify if they are so motivated.

Now I personally think users should be encouraged to make small modifications to portfiles in local repos to enable features they may personally want -- it is the easiest way to get someone started on macports development, to make small mods when they are motivated, and they would likely find it very rewarding. But I have no horse in that race, and don't care about the argument either way.

[herbygillot (Herby Gillot)]

Most users are interested in remaining end users, looking for MacPorts to simply be the vehicle for installing software they're interested in, as an alternative to others such Homebrew. They want MacPorts to just be a tool in their toolbox that they can just use and put away when they need to install software, and not something they have to spend a lot of time on.

Though there are a lot of benefits to having users become familiar with Portfile development, that's actually quite a leap for your average casual user who only cares purely about simply and easily installing the software they want.

I personally think that it's a reasonable expectation to make some subset of MPlayer's myriad features available as variants.

Having to maintain a cadre of local custom Portfiles is a pain, especially as the ports repo gets updated over time, and though it may not feel like it to an experienced maintainer, it's an intermediate-sized cliff to learn what's necessary to get a local ports environment set up and learn everything required to create and modify Portfiles/ports. An experience like that only serves to increase friction and make MacPorts more unattractive in the face of simpler alternatives that provide the kind of customization the user wants while remaining dead-simple to use.

[kencu (Ken)]

MacPorts has a variant problem / addiction. The first step towards recovery from any addiction is to acknowledge there is an issue.

This, for example, is an utterly incomprehensible mess:

% port variants mpv
mpv has the variants:
[+]audiocd: Enable Audio CD support via libcdio-paranoia
[+]bluray: Enable Bluray and AACS/BD+ encryption support
[+]bundle: Enable the optional macOS bundle of mpv
   caca: Enable animated ASCII art video output
   debug: Compile with debugging symbols
[+]dvd: Enable DVD and DeCSS support
   jack: Enable Jack Audio Connection Kit support
[+]libarchive: Enable transparent handling of Zip files and other compressed
               formats
   libmpv: Enable the libmpv library
[+]network: Enable networking support via youtube-dl (supports wide variety of
            pages)
     * conflicts with ytdlp
   openal: Enable OpenAL support
[+]opengl: Enable OpenGL output support. Both the CoreVideo and X11 (GLX)
           outputs are supported
[+]osd: Enable onscreen display and TrueType font support
   printable_doc: Generate printable documents (PDF help)
   pulseaudio: Enable PulseAudio support
   python310: Use Python 3.10 to build mpv and generate man pages
     * conflicts with python311 python38 python39
[+]python311: Use Python 3.11 to build mpv and generate man pages
     * conflicts with python310 python38 python39
   python37: Legacy variant for Python 3.7 mapping to Python 3.8
     * conflicts with python310 python311 python39
     * requires python38
   python38: Use Python 3.8 to build mpv and generate man pages
     * conflicts with python310 python311 python39
   python39: Use Python 3.9 to build mpv and generate man pages
     * conflicts with python310 python311 python38
[+]rubberband: Enable support for the Rubber Band library, adding audio pitch
               and speed control
   screenshot: Enable optional screenshot support
   uchardet: Enable the uchardet encoding detector
   x11: Enable X11 support
   ytdlp: Enable networking support via yt-dlp instead of youtube-dl (supports
          wide variety of pages)
     * conflicts with network

which would be less of a mess if any of the builds were tested with the non-default variants enabled, or the default variant disabled, which the NEVER are.

Nobody can think of that mess as a good user experience, especially for new users. I hope you can agree with that, otherwise we're not even close to the same page.

This is beautiful:

 % port variants MPlayer
MPlayer has the variants:
   universal: Build for multiple architectures

The MPlayer port used to be just as bad as mpv, but because I used MPlayer, I had an interest in cleaning it up and making it work properly on all the systems I use, Tiger through Ventura, and it does. If someone opens a ticket about MPlayer, I know exactly how it is built -- but there are no open tickets.

Having a plethora of messy variants that cannot realistically be tested is just -- asking for trouble, to put it gently. A knowledgeable user should set up the port with the broadly correct set of options enabled, and then maintain that.

It's managable. It's maintainable. It's testable, and the buildbots built it on every system. It's good. There is peace in the universe with that approach. That is the only method I plan to support. In my world, there would be exactly two sets of variants in macports:

1. universal or no
2. x11 or quartz

and all the other variants would be gradually purged out of all the ports.

Now I don't own MPlayer, and as there is disagreement about how it should be managed, I released it back to the pool. Have at it!

[kencu (Ken)]

Regarding the overlay suggestion, my goal here was to empower users to have the versions of ports they might want.

But some might see that as too complex, certainly.