libmmbd integration with mpv

[MrPenguin]

PS: for whatever reason, after closing MakeMKV and opening it again, it can now somehow process the UHD BD. The KEYDB.cfg is still not present in ~/.MakeMKV, it seems it has just updated "_private_data.tar". So whatever the reason is that it worked with VLC but not mpv, that must have fixed it. But for the next time, how do I trigger a tgz dump?

MakeMKV generates a TGZ dump file whenever it cannot decrypt a disk. By the sound of it, MakeMKV was just using the key from the KEYDB.cfg file and had never bothered checking whether there was also a "hashed key" available too. And apparently there is such a hashed key, which you have just successfully downloaded.

Are you saying that mpv now plays your disk with libmmbd.so.0? Because in that case, we can deduce that libmmbd.so.0 allows an application to read MakeMKV's private "hashed keys" database, but will not trigger an update. Apparently only MakeMKV itself will do that. Also, I am assuming that VLC is "smarter" than mpv .

[tomty89]

Hmm, sounds like whether hashed keys or keydb.cfg is used makes a difference, but that's pretty weird as well since AFAIK if a respective VUK is found for a given disc in both of them, it would be the same key but just stored in different form... (But maybe there are "subtle differences" in the two cases that I'm not aware of...)

Either way, I feel like it might have something to do with bus encryption. Maybe under circumstances the effect of LibreDrive does not effectively kick in...even though I do not have a concrete explanation on how AACS decryption could fails only in the mpv case (since the decryption calls are really made by libbluray, the same library used by both players).

Because in that case, we can deduce that libmmbd.so.0 allows an application to read MakeMKV's private "hashed keys" database, but will not trigger an update.

No that's really not the case. I happen to have tested it yesterday. libmmbd (used in directly by mpv, if it even matters) DOES trigger HK download.

AFAIK, the library really just "implements" a few libaacs APIs, which allows libbluray to "feed" encrypted data to an makemkvcon instance (which libmmbd "spawns") and get the decrypted data back.

[artim]

PS: for whatever reason, after closing MakeMKV and opening it again, it can now somehow process the UHD BD. The KEYDB.cfg is still not present in ~/.MakeMKV, it seems it has just updated "_private_data.tar". So whatever the reason is that it worked with VLC but not mpv, that must have fixed it. But for the next time, how do I trigger a tgz dump?

MakeMKV generates a TGZ dump file whenever it cannot decrypt a disk. By the sound of it, MakeMKV was just using the key from the KEYDB.cfg file and had never bothered checking whether there was also a "hashed key" available too. And apparently there is such a hashed key, which you have just successfully downloaded.

Then I guess it just wasn't created as it hadn't finished the download yet.

Are you saying that mpv now plays your disk with libmmbd.so.0? Because in that case, we can deduce that libmmbd.so.0 allows an application to read MakeMKV's private "hashed keys" database, but will not trigger an update. Apparently only MakeMKV itself will do that. Also, I am assuming that VLC is "smarter" than mpv .

I cannot say if it actually use libmmbd or libaacs. It works both out of the box and with the environment variable, but either way it didn't cause any logs being written to the MakeMKV debug logs.

Also, I am assuming that VLC is "smarter" than mpv

That's the question if there's any additional logic inside VLC.

[MrPenguin]

Hmm, sounds like whether hashed keys or keydb.cfg is used makes a difference, but that's pretty weird as well since AFAIK if a respective VUK is found for a given disc in both of them, it would be the same key but just stored in different form... (But maybe there are "subtle differences" in the two cases that I'm not aware of...)

Every disk has its own Volume Unique Key. By the sound of it, MakeMKV had never previously bothered downloading this VUK into its hashed keys because it was able to load it from the local KEYDB.cfg file instead.

Either way, I feel like it might have something to do with bus encryption. Maybe under circumstances the effect of LibreDrive does not effectively kick in...even though I do not have a concrete explanation on how AACS decryption could fails only in the mpv case (since the decryption calls are really made by libbluray, the same library used by both players).

You would almost certainly need libmmbd to defeat bus encryption when playing the UHD directly, unless you were somehow able to determine the correct RDK to use instead. However, libbluray decrypts AACS by loading an implementation of the libaacs ABI dynamically. This can be either libaacs itself or libmmbd - or perhaps both, depending on how "smart" the playing software is?

[MrPenguin]

I cannot say if it actually use libmmbd or libaacs. It works both out of the box and with the environment variable, but either way it didn't cause any logs being written to the MakeMKV debug logs.

Start playing the movie, and then run

Code: Select all

$ lsof /usr/lib/libmmbd.so.0

.
This should tell you which (if any) processes are currently using it.

[tomty89]

You would almost certainly need libmmbd to defeat bus encryption when playing the UHD directly, unless you were somehow able to determine the correct RDK to use instead.

Yeah I'm aware of that. In fact there's the tricky thing: libbluray would not actually make a explicit "call" to libmmbd / MakeMKV that disables the bus encryption. Rather it is triggered when it makes the `aacs_decrypt_unit` call, which is what libbluray used to "feed" AACS-encrypted data to makemkvcon -- in other words, AFAICT, unlike when you rip a disc, MakeMKV in this case is not responsible for reading the disc. Therefore, if my understanding is correct, it means that the the player / libbluray could have read some data from a disc before the bus encryption is disabled (and feed the bus-encrypted data to makemkvcon).

(In other words, probably it is not really surprising that AACS decryption would fail at the beginning. And perhaps the reason VLC doesn't fail is just because it does not "bail" when there are decryption (really demuxing / decoding; players are somewhat not "aware" of whether there's AACS encryption, AFAIK) failures. However, mpv should be able to play the disc without any problem if it was once successfully played for a short while with VLC -- maybe until the disc is ejected and reinserted -- unless the "early" bus-encrypted data could end up "lingering" in the drive / system buffer...)

(Note that while the current libbluray attempts to load a `aacs_decrypt_bus` "symbol" from the loaded libaacs implementation and has the internal API libaacs_decrypt_bus, it is kind of a bogus one -- at least it is not used at all.)

However, libbluray decrypts AACS by loading an implementation of the libaacs ABI dynamically. This can be either libaacs itself or libmmbd - or perhaps both, depending on how "smart" the playing software is?

All the decryption-related logic is found in libbluray only. AFAIK libbluray will try to use libaacs first and when it fails, it will try libmmbd. (Here "fails" probably does not include decryption failure as observed here, but just up till e.g. required VUK is not found in the KEYDB.cfg.)

[artim]

Start playing the movie, and then run

Code: Select all

$ lsof /usr/lib/libmmbd.so.0

.
This should tell you which (if any) processes are currently using it.

No luck. Neither libmmbd, nor libaacs or libbluray3 (for the latter neither the generic symlinks libbluray.so.3 and libaacs.so.0 nor the specific versions) do show any outpt, neither with VLC nor with mpv.

Also it seems that playback only succeeds after the disk was opened in MakeMKV, without that it will still fail. Possibly libmmbd doesn't put the drive in LibreDrive mode or something like that.

[tomty89]

Also it seems that playback only succeeds after the disk was opened in MakeMKV, without that it will still fail. Possibly libmmbd doesn't put the drive in LibreDrive mode or something like that.

In the case of libmmbd, maybe see if --demuxer-lavf-format=mpegts keeps mpv running even before LibreDrive kicks in.

[artim]

In the case of libmmbd, maybe see if --demuxer-lavf-format=mpegts keeps mpv running even before LibreDrive kicks in.

Nope. Only causes thousands of lines in the logs, rapidly switching between about a dozen

Code: Select all

aacs.c:255: Unable decrypt unit (AACS)!

entries and stuff like

Code: Select all

[ffmpeg/demuxer] mpegts: Could not detect TS packet size, defaulting to non-FEC/DVHS
[ffmpeg/demuxer] mpegts: changing packet size to 204
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 204
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 188
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 188
[ffmpeg/demuxer] mpegts: changing packet size to 204

[MrPenguin]

No luck. Neither libmmbd, nor libaacs or libbluray3 (for the latter neither the generic symlinks libbluray.so.3 and libaacs.so.0 nor the specific versions) do show any outpt, neither with VLC nor with mpv.

Also it seems that playback only succeeds after the disk was opened in MakeMKV, without that it will still fail. Possibly libmmbd doesn't put the drive in LibreDrive mode or something like that.

A few points:

• A UHD cannot decrypt itself, and you only have two key databases available.
• Without the correct RDK, you can only disable bus encryption using LibreDrive.
• The libmmbd.so.0 library works by invoking the makemkvcon.exe binary. All of MakeMKV's "Dark Magic" is contained in / controlled by makemkvcon.exe.

So at the end of the day, there just aren't that many explanations for what could be happening.

I will also point out that trying to play a UHD directly from the drive is a Very Bad Idea, as it will cause unnecessary wear-and-tear on a device that these days will be more difficult to replace. You are strongly advised to back your disk up to a hard drive (either decrypted or still encrypted) and then play that instead, as this will at least remove the bus encryption.

[tomty89]

In the case of libmmbd, maybe see if --demuxer-lavf-format=mpegts keeps mpv running even before LibreDrive kicks in.

Nope. Only causes thousands of lines in the logs, rapidly switching between about a dozen [code}aacs.c:255: Unable decrypt unit (AACS)![/code] entries and stuff like

Code: Select all

[ffmpeg/demuxer] mpegts: Could not detect TS packet size, defaulting to non-FEC/DVHS
[ffmpeg/demuxer] mpegts: changing packet size to 204
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 204
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 188
[ffmpeg/demuxer] mpegts: changing packet size to 192
[ffmpeg/demuxer] mpegts: changing packet size to 188
[ffmpeg/demuxer] mpegts: changing packet size to 204

If you are interested in testing further, you can additionally lower the value of --demuxer-max-bytes= to e.g. below 1MiB (maybe something as extreme as 64KiB which would be 10 AACS "unit", apparently). By default mpv might hold tens to hundreds MiB of cache / "readahead" (although the default is NOT to delay playback until it holds that much).

May as well try --cache=no

[artim]

If you are interested in testing further, you can additionally lower the value of --demuxer-max-bytes= to e.g. below 1MiB (maybe something as extreme as 64KiB which would be 10 AACS "unit", apparently). By default mpv might hold tens to hundreds MiB of cache / "readahead" (although the default is NOT to delay playback until it holds that much).

No success either. The only interesting thing I found was

Code: Select all

[ffmpeg/demuxer] mpegts: PES packet size mismatch
[ffmpeg/demuxer] mpegts: Packet corrupt (stream = 0, dts = 852749608).
[ffmpeg/demuxer] mpegts: probed stream 0 failed
[ffmpeg/demuxer] mpegts: probed stream 1 failed
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 0 (Unknown: none): unknown codec
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 1 (Unknown: none): unknown codec
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 2 (Audio: mp3, 0 channels, 128 kb/s): unspecified frame size
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

Right when I stopped it. I alctually saw more success also adding LIBAACS_PATH=/usr/lib/libmmbd to it, but then it would seemingly only play the 64 kiB/1MiB and then stop:

Code: Select all

LIBAACS_PATH=/usr/lib/libmmbd mpv --demuxer-lavf-format=mpegts --demuxer-max-bytes=1MiB bd://2
[bd] List of available titles:
[bd] idx:   0 duration: 00:00:25 angles:  1 (playlist: 00000.mpls)
[bd] idx:   1 duration: 00:00:14 angles:  1 (playlist: 00004.mpls)
[bd] idx:   2 duration: 01:28:10 angles:  1 (playlist: 00002.mpls)
[bd] idx:   3 duration: 00:00:06 angles:  1 (playlist: 00001.mpls)
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[ffmpeg/demuxer] mpegts: Could not find codec parameters for stream 5 (Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size
[ffmpeg/demuxer] Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
○ --edition=0 'title: 1 (00:00:25.417) (00000.mpls)'
○ --edition=1 'title: 2 (00:00:14.000) (00004.mpls)'
● --edition=2 'title: 3 (01:28:10.625) (00002.mpls)'
○ --edition=3 'title: 4 (00:00:06.965) (00001.mpls)'
● Video  --vid=1               (hevc 3840x2160 24 fps)
● Audio  --aid=1  --alang=  (truehd 8ch 48000 Hz)
○ Audio  --aid=2  --alang=  (ac3 6ch 48000 Hz 640 kbps)
○ Audio  --aid=3  --alang=  (dts 2ch 48000 Hz 768 kbps)
○ Subs   --sid=1  --slang=  (hdmv_pgs_subtitle)
● Subs   --sid=2  --slang=  (hdmv_pgs_subtitle)
Track switched:
 ● Video  --vid=1               (hevc 3840x2160 24 fps)
 ● Audio  --aid=1  --alang=  (truehd 8ch 48000 Hz)
 ○ Audio  --aid=2  --alang=  (ac3 6ch 48000 Hz 640 kbps)
 ○ Audio  --aid=3  --alang=  (dts 2ch 48000 Hz 768 kbps)
 ○ Subs   --sid=1  --slang=  (hdmv_pgs_subtitle)
 ○ Subs   --sid=2  --slang=  (hdmv_pgs_subtitle)
[autoselect_forced_sub] Not found only forced subtitles, try with --script-opts=afs-sub_forced_only=no
Using hardware decoding (vulkan).
AO: [pipewire] 48000Hz 7.1 8ch s32
VO: [gpu-next] 3840x2160 vulkan[p010]
[disc] Too many packets in the demuxer packet queues:
[disc]   video/0: 11 packets, 1152448 bytes
[disc]   audio/1: 0 packets, 0 bytes
[ffmpeg/audio] truehd: Stream parameters not seen; skipping frame.
AV: 00:00:02 / 01:28:10 (0%) A-V:  0.000
Exiting... (End of file)

Upon further investigation, all it needs to play back a UHD BD that wasn't already loaded by MakeMKV is start mpv or vlc with LIBAACS_PATH=/usr/lib/libmmbd set, as long as a hashed key is present for the disk.

[tomty89]

The options / tests are only meant for libmmbd. If LibreDrive not kicking in in time / bus encryption were really the culprit of the issue, libaacs will not work no matter how long you "wait" because it does not attempt to disable bus encryption anyway. (It would work only after you e.g. at least open the disc in MakeMKV once (beforehand).)

Either way my suggestion was probably non-sense anyway. I just realized that I forgot libbluray will "open" the disc with the "loaded libaacs implementation" (before mpv can "ask" libbluray to read AACS-encrypted units from the disc) anyway, and when that is libmmbd, the "opening" should result in LibreDrive kicking in (and would probably "return" only after that has complete). Therefore it's not really expected that libbluray would read units that are further bus-encrypted in that case.

So I'm clueless why you'd get unit decryption errors in some cases (e.g. when KEYDB.cfg is used instead?) even when you are using libmmbd, especially when those cases only occur with mpv. (Btw if KEYDB.cfg is somehow really the culprit, you would probably only bump into the same issue when you play a UHD BD, because AFAIK/IIRC, MakeMKV will never use keys from KEYDB.cfg for AACS 1.0, just like it does not use any hashed keys -- AFAIK -- to deal with that either.)

[artim]

Btw if KEYDB.cfg is somehow really the culprit, you would probably only bump into the same issue when you play a UHD BD, because AFAIK/IIRC, MakeMKV will never use keys from KEYDB.cfg for AACS 1.0, just like it does not use any hashed keys -- AFAIK -- to deal with that either.

Exactly what I've been writing the whole time. No idea how the decryption of normal BDs works but it seems it even succeeds when KEYDB.cfg isn't present (through libmmbd, as in removed from ~/.config/aacs/). Through libaacs (LIBAACS_PATH=/usr/lib/x86_64-linux-gnu/libaacs to make sure) it first struggles with

keydbcfg.c:701: No valid AACS configuration files found
keydbcfg.c:701: No valid AACS configuration files found

but after a few seconds it seem sto use some fallback solution and read it just fine. Though no idea if it just automatically switches to libmmbd.

[tomty89]

No idea how the decryption of normal BDs works

Technically it's somewhat a blackbox since that part of MakeMKV is not open-source. I think it essentially "emulates" a blu-ray player in the case of LibreDrive and calculates / derives the VUK as per how AACS "should work" -- except the "revoking" part(s). (Probably the approach is different with non-LibreDrive -- I'm even more unsure about that.)

Though no idea if it just automatically switches to libmmbd.

Yes libbluray would switch to libmmbd (if it's found on your system) when libaacs fails "early" (e.g. no KEYDB.cfg is found).