Bug 238004 - New port: multimedia/makemkv video converter reading from DVD and Bluray
Summary: New port: multimedia/makemkv video converter reading from DVD and Bluray
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Rodrigo Osorio
Depends on:
Reported: 2019-05-20 19:04 UTC by Felix Palmen
Modified: 2020-04-05 15:16 UTC (History)
4 users (show)

See Also:

add multimedia/makemkv (16.70 KB, patch)
2019-05-20 19:04 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.94 KB, patch)
2019-05-22 16:40 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.94 KB, patch)
2019-06-10 08:55 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.46 KB, patch)
2019-06-16 13:20 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.49 KB, patch)
2019-06-16 13:29 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.52 KB, patch)
2019-08-20 16:57 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.75 KB, patch)
2019-09-03 10:10 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (16.75 KB, patch)
2019-09-22 13:44 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (21.43 KB, patch)
2020-03-26 07:37 UTC, Felix Palmen
no flags Details | Diff
add multimedia/makemkv (22.78 KB, patch)
2020-04-04 12:41 UTC, Felix Palmen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Palmen 2019-05-20 19:04:56 UTC
Created attachment 204487 [details]
add multimedia/makemkv

Unfortunately, this port leaves out the MakeMKV GUI. Although the GUI can be built with a few patches on FreeBSD, it's useless because makemkvcon (the closed source Linux binary) won't run in "guiserver" mode. See <https://www.makemkv.com/forum/viewtopic.php?f=3&t=19486> for my attempt to get upstream help with that.

Still, after being on the wanted ports list for so long, I think console-only usage is better than nothing, and it works quite well for me.
Comment 1 Felix Palmen 2019-05-22 16:40:50 UTC
Created attachment 204545 [details]
add multimedia/makemkv

Small improvements:

- add hint to pkg-message about needed permissions of /compat/linux/tmp, so makemkvcon runs as non-root
- linted manpage
Comment 2 Felix Palmen 2019-06-10 08:55:25 UTC
Created attachment 204939 [details]
add multimedia/makemkv

Update to new upstream version 1.14.4

I also noticed poudriere testport issues
> Warning: you need USES=ssl
This is probably bogus, the port only links OpenSSL from the linux-c7 ports.
Comment 3 Sergey A. Osokin freebsd_committer 2019-06-14 00:29:10 UTC
Hi Felix,

so pretty impressive job, thanks very much for sharing this!

I've got next question when I've done with my review of your job, it is related to '/opt' the port uses.  Can we avoid this by moving needful binaries to another location?  FreeBSD Handbook basically recommends to use ${PREFIX} for most cases, so that would be great to improve the port.

Please let me know if you have any questions.

Again, well done!  Thanks very much!
Comment 4 Felix Palmen 2019-06-14 05:18:39 UTC
Hello Sergey,

The "makemkvcon" binary uses /sys/bus/scsi (which isn't provided by linsysfs) to find optical drives. Therefore I included a script to fake the relevant structure based on camcontrol output. I can't do that in the original location, because that wouldn't work on machines that have linsysfs mounted. The pathname used must not be longer than the original because I'm patching it into the makemkvcon binary with sed.

/opt/makemkv looked like an obvious choice, as I could put almost everything right there and people will know it's a software package with its own directory. Maybe /compat/linux/opt/makemkv would be a better choice, but I'm not sure it's a good idea to put files there that don't come from a linux-c* port?

I could also separate the linux binaries and libs (putting them in their "standard" dirs) from the faked sysfs parts. But then, where to put the latter? /etc/makemkv would be short enough, but the generated files neither are really "configuration" nor do they belong to base ...

I'll gladly try to incorporate better ideas of course :) thank you very much.

Best regards
Comment 5 Felix Palmen 2019-06-16 13:20:47 UTC
Created attachment 205124 [details]
add multimedia/makemkv

After some brief email discussion about using /opt (which definitely isn't an ideal solution), I think I came up with the best alternative here.

The faked sysfs entries are now created in ${LINUXBASE}/etc/makemkv, everything else goes to its normal destination in ${LOCALBASE}. The libraries are installed to ${LOCALBASE}/lib/makemkv, to avoid cluttering the normal lib dir with "foreign" (Linux) libs.

This also allows for easy migration away from "faking" sysfs stuff, once linsysfs(5) supports the files needed for makemkvcon.
Comment 6 Felix Palmen 2019-06-16 13:29:04 UTC
Created attachment 205127 [details]
add multimedia/makemkv

Sorry for the noise, accidentally uploaded a patch missing my last bugfix.

This one is fine and works.
Comment 7 Felix Palmen 2019-07-03 16:29:57 UTC
Any news on this? If there's anything else I could (or should) improve, please let me know, thanks!

BR, Felix
Comment 8 Johannes Jost Meixner freebsd_committer 2019-08-02 12:45:57 UTC
Hi Felix,

I've looked through the attachment a bit and have some questions:

* Why do you bundle OpenSSL -- twice, once with 1.0.1e (available in ports, security/linux-c6-openssl within the CentOS 6 userland) and once with 1.0.2k (available in ports, security/linux-c7-openssl within the CentOS 7 userland)?
* Related: Have you considered submitting ports for ffmpeg (based on the CentOS RPMs in "EPEL") and fdk-aac (maybe via RpmFusion) ?

Now, to the Makefile.
I'm a bit wormed by calling configure three times in pre-configure, and even calling `make` there. This will probably go away once the prerequisites are outsourced, right?

Comment 9 Felix Palmen 2019-08-02 13:01:40 UTC
- OpenSSL is NOT bundled, it's just downloaded and extracted, so the correct headers can be used during compilation. The libraries provided by linux ports are linked.

- for the same reason, providing packages for ffmpeg / fdk-aac would only complicate things. they would be in different versions, depening on the linux port version installed, ffmpeg would not link fdk-aac (as recommended by makemkv), of course they would not include headers either and makemkv is typically tested against the latest versions of ffmpeg. I think static linking is pretty appropriate here.
Comment 10 Felix Palmen 2019-08-20 16:57:37 UTC
Created attachment 206736 [details]
add multimedia/makemkv

build was broken by r506352, so here's an updated patch.

BR, Felix
Comment 11 Felix Palmen 2019-09-03 10:10:43 UTC
Created attachment 207137 [details]
add multimedia/makemkv

I received a report that building fails with linux-c6, this is because the gcc in linux-c6 doesn't understand -fstack-protector-strong.

So, here's another update fixing this, also changed the rules to use the CFLAGS for the static libs as well and build everything verbose.

BR, Felix
Comment 12 Felix Palmen 2019-09-22 13:44:26 UTC
Created attachment 207714 [details]
add multimedia/makemkv

Update to new upstream version 1.14.5

Tested building in poudriere and ripping with my own bluray discs, works fine.
Comment 13 Rodrigo Osorio freebsd_committer 2019-11-10 07:00:16 UTC
Hi Felix,

The MAKEMKV and FDK licenses looks very restrictives but I can't get the reason why. Apparently some Linux distributions has available packages for this port.

 * https://aur.archlinux.org/packages/makemkv/
 * https://packages.gentoo.org/packages/media-video/makemkv

It will be nice if we can clarify the situation, because right now, by default, poudriere doesn't build the package.
Comment 14 Felix Palmen 2019-11-10 09:16:31 UTC
Hi Rodrigo,

The MakeMKV EULA is even linked in the gentoo package:


There's one sentence that may allow building a package for binary redistribution:

> In addition, as a special exception, you may extract and repackage
> Linux-specific part of the Software for the purpose of creating a
> distribution-specific package, as long as program files and this license
> remain unchanged.

I'm not sure whether this is applicable to FreeBSD as well, I'm not a lawyer... but I assume it isn't because I have to patch the Linux binary in order to make it work on FreeBSD:

		${PATCHELF_CMD} --set-rpath ${PREFIX}/lib/makemkv \
		${REINPLACE_CMD} -e 's:/sys/bus/scsi:/etc/makemkv/:' \

At least this second patch is inevitable right now, as FreeBSD's sysfs emulation doesn't have /sys/bus/scsi (therefore the port includes a script to generate a fake tree in /etc/makemkv).

As of now, the GENERIC FreeBSD kernel doesn't include emulation of Linux 'sg' devices, so you have to build your own kernel to use MakeMKV anyways. Therefore, I don't think having to build the port yourself is a relevant burden.

As for the fdk-aac license, it's possible to build MakeMKV without fdk-aac, but it's needed for the full featureset. I didn't implement an option so far. As far as I understand it, *this* license would allow distribution of binary packages, just not selling them.

> right now, by default, poudriere doesn't build the package.

I guess you mean because of the MakeMKV EULA restrictions? There's also a build problem when some other packages are installed, so I should add some BUILD_CONFLICTS, see here:


I still have to identify what exactly to put there. But this shouldn't affect building in poudriere.

BR, Felix
Comment 15 Felix Palmen 2020-03-26 07:37:50 UTC
Created attachment 212721 [details]
add multimedia/makemkv

New upstream version 1.15.0

This one brought a new problem: The closed-source makemkvcon utility now needs a C++ library providing CXXABI_1.3.9, which the libstdc++ from linux-c7 packages doesn't.

At the moment, the only workaround is to compile a libstdc++ from GCC sources, which requires building of a whole temporary GNU toolchain targeting Linux. This requires some more ugly hacks, so I'd understand if the port in the current state can't be accepted. Unfortunately, unless either makemkv (by providing a FreeBSD binary) or the Linuxulator ports move, there's no other solution to have makemkv work on FreeBSD.
Comment 16 Rodrigo Osorio freebsd_committer 2020-04-01 07:13:57 UTC
I just installed the last version in an FreeBSD 12.1-RELEASE amd64, and I have the following issues:

- All commands with makemkvcon ends with a cor dump
- I didn't find the correct way to access the /dev/cd0 disk
  I try: disc:0, dev:/dev/cd0
- after mounting /dev/cd0 in /mnt/cd
  I try `makemkvcon info dev:/mnt/cd` returns the following:

  > MakeMKV v1.15.0 linux(x64-release) started
  > Profile parsing error: default profile missing, using builtin default
  > The program can't find any usable optical drives.
  > Opening files on harddrive at /mnt/video_ts/
  > Opening files on harddrive at /mnt/video_ts/
  > Calculated BUP offset for VTS #2 does not match one in IFO header.
  > Calculated BUP offset for VTS #3 does not match one in IFO header.
  > Calculated BUP offset for VTS #5 does not match one in IFO header.
  > Calculated BUP offset for VTS #6 does not match one in IFO header.
  > Complex multiplex encountered - 13 cells and 528 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided.
  > Title #1 was added (80 cell(s), 1:55:08)
  > Complex multiplex encountered - 13 cells and 525 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided.
  > Angle #2 was added for title #1
  > Complex multiplex encountered - 13 cells and 522 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided.
  > Angle #3 was added for title #1
  > Title #8 has length of 1 seconds which is less than minimum title length of 120 seconds and was therefore skipped
  > Error 'Posix error - Input/output error' occurred while reading '/mnt/video_ts/VTS_04_4.VOB' at offset '4096'
  > ....
  > Failed to open disc
  > Total 0 titles
  > Segmentation fault (core dumped)

  When /mnt/cd has multiple video_ts.bup    vts_*.bup  vts_*.vob.

I also found this page useful https://www.makemkv.com/developers/usage.txt
Comment 17 Felix Palmen 2020-04-01 07:19:55 UTC
There's a manpage included with this port ;) makemkvcon always dumps core, at least only after finishing its work. Try the following for info about the current disk:

    makemkvcon info disc:0

and the following to backup title 0:

    makemkvcon mkv disc:0 0 .

Of course, your kernel must be compiled with `device sg` -- the included `update-makemkv-drives` script will tell you so if necessary.
Comment 18 Rodrigo Osorio freebsd_committer 2020-04-01 07:48:37 UTC
(In reply to Felix Palmen from comment #17)

Thanks for your quick reply, I will rebuilding my kernel and try again.
Comment 19 Felix Palmen 2020-04-01 08:09:36 UTC
and then re-run `update-makemkv-drives` -- this script is the "magic trick" to create the necessary sysfs-entries for makemkvcon to find the drive, and it's run automatically on install and *should* give a meaningful diagnostic if the kernel misses sg devices.

Of course this is pretty cumbersome right now, maybe I'll try to contact the author again about an official FreeBSD version soon.
Comment 20 Rodrigo Osorio freebsd_committer 2020-04-01 15:01:36 UTC
(In reply to Felix Palmen from comment #19)

Ok now it works fine, I probably will come back to you
today with some suggestions and improvements to better
help and guide our fellow users.

Thanks for your support.
-- rodrigo
Comment 21 Rodrigo Osorio freebsd_committer 2020-04-04 11:04:22 UTC
Hi Felix,

In response to your PM, here a few things I think we can change to help
future makemkv FreeBSD users:

 * Switch the license flag from no-auto-accept to auto-accept if you
   wanna have makemkv available in the pkg official repos. Otherwise
   people have to build the package on their own poudrière.

 * Indicate that a custom kernel is required in the pkg-descr file,
   to avoid back an forth when running the tool for the first time.
   Something like the following will be sufficient to me:

   Known issues:
   To find a drive on FreeBSD, part of Linux' sysfs must be faked.
   The script `update-makemkv-drives'has to be used to fake it.

   A custom FreeBSD kernel with sg devices is required to use makemkv.
   See https://www.freebsd.org/doc/handbook/kernelconfig-building.html
   to know how to build your kernel end add the "device  sg" line.

   Something like this can be also added to the manpage.

 * Maybe like other tools who has pre-run conditions we can install
   makemkvcon in /usr/local/share/makemkvcon/ and have a
   /usr/local/bin/makemkvcon shell script who calls update-makemkv-drives
   when required. This is _not_ mandatory but could helps.

Apart from that I have no objections to commit the port.
Comment 22 Felix Palmen 2020-04-04 11:38:18 UTC
(In reply to Rodrigo Osorio from comment #21)

Thanks Rodrigo.

Unfortunately, the only bullet point I can do something about is your second one. I agree it would be helpful to learn about the requirement to compile a custom kernel before building and installing the port :) Give me some time to update my patch please!

As for the license, this was already discussed earlier in this PR. The current terms of the MakeMKV EULA wouldn't allow distributing the package, as it contains a modified version of the makemkvcon binary (We need rpath to find libraries, this could still be considered ok as it only modifies the ELF header, but we also need to patch the path where makemkvcon looks for the sysfs entries to detect drives ...) So IMHO, this can, at this time, only be a "build-it-yourself" port.

About your final suggestion, `update-makemkv-drives` needs root privileges to write the fake sysfs entries to ${LINUXBASE}/etc/makemkv. We're not free to choose a user-writable path here, because the path (as seen by a Linux binary) must be no longer than the original `/sys/bus/scsi`, so binary patching of makemkvcon works correctly, plus it must be the same path for all users as it is hardcoded into the makemkvcon binary. Therefore I think that running `update-makemkv-drives` during installation is the best option (and telling the local admin to re-run it manually when the optical drive configuration changes).
Comment 23 Felix Palmen 2020-04-04 12:41:16 UTC
Created attachment 213053 [details]
add multimedia/makemkv

Here's my take on better user guidance as suggested.

The diff to the previous patch can also be found at https://github.com/Zirias/zfbsd-ports/commit/316a88763511181314de9e8fe83dbb2d2c5acaa3 which might be easier to read.
Comment 24 Rodrigo Osorio freebsd_committer 2020-04-05 15:12:49 UTC
Committed, thanks.
Comment 25 commit-hook freebsd_committer 2020-04-05 15:16:28 UTC
A commit references this bug:

Author: rodrigo
Date: Sun Apr  5 15:09:58 UTC 2020
New revision: 530792
URL: https://svnweb.freebsd.org/changeset/ports/530792

  New port: multimedia/makemkv a CLI video converter from DVD

  This port is CLI only and leaves out the MakeMKV GUI, because
  makemkvcon (closed source Linux binary) won't run in guiserver

  Also, as described in the pkg-message, it requires a custom
  FreeBSD kernel with the Linux SCSI generic drivers and has to
  be build by the final user to comply with the license terms.

  Work is ongoing with the author to have a FreeBSD native version
  of this port in the future.

  PR:		238004
  Submitted by:	Felix Palmen <felix@palmen-it.de>