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)]

Herby, you are no doubt right.

I aim for fewer variants, but I may be in the minority here.

Just trying to keep things manageably simple, but that is my tendency.

[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.