Bluray playback script for VLC/HandBrake/Kodi on Windows

[steo86]

Hello, any News about this?
kodi 18 still crashing when clicking on index.bdmv with linked libbdplus/libaacs.so to makemkv. Kodi 17.6 still working.

[joniw]

Hello,

the problem is described here: https://forum.kodi.tv/showthread.php?ti ... pid2676853.

Unfortunately i was not able to compile libmmbd under windows so i am still waiting for a fix from the developers.

Joniw

[mike admin]

This is a very had fix. The bug is really in (new) libbluray architecture and in how xbmc calls it. Instead of passing any sort of device handle, xbmc passes null to libbluray and provides FS callbacks. This is very bad, as both libbluray and libaacs can not possibly get an underlying scsi device handle and can only access disc fs via file callback API. The whole situation is ugly, as libbluray does not have an API where you can submit both device handle and callback access API - an app has to choose between scsi access and UDF support. Very ugly...
Even without MakeMKV in picture, vanilla libbluray will never work with xmbc when used with host certs and processing keys, until the libbluray frontend will be fixed.
Anyway, this is a bug in libmmbd. The simple and correct fix would be to display message "callback-only mode not supported" and exit instead of crashing. The proper workaround is to detect that while the library is fed by fs callback functions, in reality they just are wrappers to a real device that can be accessed. This can be done, but this requires both libmmbd and makemkv changes. This is on the list, but I can't promise it the next version.
If xbmc developers are interested in a "real" proper fix, they probably should work with libbluray devs. The changes should be minimal. All "open" API calls map to a single internal "open" function that takes all required parameters. It is just there is no public API that calls this function with all parameters - you can specify either one half or another. Again, extremely ugly design decision...

[dgktkr]

This is a very had fix. The bug is really in (new) libbluray architecture and in how xbmc calls it.

Agreed.

The libbluray code seems to reveal that, in the past, an effort was made to make it compatible with libmmbd. The recent addition of bd_open_files() (libbluray v1.0.2) seems to break that compatibility.

Instead of passing any sort of device handle, xbmc passes null to libbluray and provides FS callbacks. This is very bad, as both libbluray and libaacs can not possibly get an underlying scsi device handle and can only access disc fs via file callback API.

By scsi device handle, do you mean something like "/Volumes/Disc_Title" (for MacOS)? Couldn't that C string be recovered if libmmbd used aacs_set_fopen() to receive the C++ string object handle that libbluray provides as the second parameter, convert it back to a C string and incorporate that into a libmmbd AACS context structure?

I believe the way the vanilla libbluray does it is to assign a handle, a C++ string object, as a member of an AACS context structure, which is passed to aacs_open_device(). libmmbd doesn't accommodate that, because its AACS context structure is opaque and doesn't publish the names of its members.

The whole situation is ugly, as libbluray does not have an API where you can submit both device handle and callback access API - an app has to choose between scsi access and UDF support. Very ugly...
Even without MakeMKV in picture, vanilla libbluray will never work with xmbc when used with host certs and processing keys, until the libbluray frontend will be fixed.

In my setup with vanilla libbluray and a compiled libaacs grabbed from the internet, Kodi v18 plays aacs protected blurays if KEYDB.cfg is installed in the proper place.

Anyway, this is a bug in libmmbd. The simple and correct fix would be to display message "callback-only mode not supported" and exit instead of crashing. The proper workaround is to detect that while the library is fed by fs callback functions, in reality they just are wrappers to a real device that can be accessed. This can be done, but this requires both libmmbd and makemkv changes. This is on the list, but I can't promise it the next version.
If xbmc developers are interested in a "real" proper fix, they probably should work with libbluray devs. The changes should be minimal. All "open" API calls map to a single internal "open" function that takes all required parameters.

If I understand you correctly, I've tried that, and it allows playing of blurays with Kodi v18 and MakeMKV v1.12.0. What I did was change bd_open_files() in Kodi and libbluray code in about 1/2 dozen places to accept an ASCII C string like "/Volumes/Disc_Title" as a device path and pass it through the function call sequence so that aacs_open_device() has a good non-NULL path to work with.

I don't have comprehensive enough knowledge of Kodi to know if this breaks something.

It is just there is no public API that calls this function with all parameters - you can specify either one half or another. Again, extremely ugly design decision...

dgktkr

[ytrewq]

By scsi device handle, do you mean something like "/Volumes/Disc_Title" (for MacOS)? Couldn't that C string be recovered if libmmbd used aacs_set_fopen() to receive the C++ string object handle that libbluray provides as the second parameter, convert it back to a C string and incorporate that into a libmmbd AACS context structure?

I believe the way the vanilla libbluray does it is to assign a handle, a C++ string object, as a member of an AACS context structure, which is passed to aacs_open_device(). libmmbd doesn't accommodate that, because its AACS context structure is opaque and doesn't publish the names of its members.

No. libbluray doesn't provide any C++ string object there. Maybe Kodi provides, but relying on that would break other applications. That pointer is application-specific and may as well point to sftp session or something completely different. It is opaque on purprose. One can't make any assumptions on what it points to (even NULL would be perfectly valid).

The whole situation is ugly, as libbluray does not have an API where you can submit both device handle and callback access API - an app has to choose between scsi access and UDF support. Very ugly...

UDF support is built in libbluray and handled automatically if the disc is not mounted (or bd_open was given a path to .iso image file).

Those filesystem callbacks are meant to be used when there is no BD device at all, and files can't be accessed from the filesystem. For example, when playing BD directory structure over sftp/nfs/smb or from .rar archive. There's no need for those callbacks if the device can be accessed directly.

Usually such discs are already decrypted. If not, playback can't be guaranteed. libaacs works without the device only if the keys are already known - ex. were cached earlier. So, it is technically possible to play encrypted, ripped disc or even a disc from a remote BD drive over network. I don't think this is very common, so this kind of feature is more likely useful for automatic regression testing.

Well, there's another, rare corner case where libaacs does not need the device. It is possible to have AACS enabled disc without content encryption. This is indicated in AACS CCI data. With such discs libaacs does not need the device, as there's nothing to decrypt. But libbluray won't know this until it tries to play the disc (CCI is handled by libaacs). Before anyone asks: no, I haven't seen such discs in the wild (except few "home made" ones).

Anyway, this is a bug in libmmbd. The simple and correct fix would be to display message "callback-only mode not supported" and exit instead of crashing.

Yes, also the aacs.h shipped with libmmbd allows NULL as device.
Still, we can't blame libmmbd on this crash. libaacs API was long undocumented, and support for NULL device was added later than aacs_open2(). libbluray should somehow check if the library used can handle NULL device.

The proper workaround is to detect that while the library is fed by fs callback functions, in reality they just are wrappers to a real device that can be accessed. This can be done, but this requires both libmmbd and makemkv changes. This is on the list, but I can't promise it the next version.

How would that be possible ? By using the callbacks to read some files and comparing those with the ones in local drive ? That seems quite hackish...

I don't think there's need for any workarounds. Those functions are not meant to be used with a real device. There's nothing libmmbd should do when passed those callbacks (unless it can decrypt the disc without a device).
To be fully compatible with libaacs it could calculate disc ID hash or parse CCI data. But it should not try to access any device. If device needs to be accessed, it is explicitly given to libaacs / libmmbd.

If xbmc developers are interested in a "real" proper fix, they probably should work with libbluray devs. The changes should be minimal. All "open" API calls map to a single internal "open" function that takes all required parameters.

It is just there is no public API that calls this function with all parameters - you can specify either one half or another. Again, extremely ugly design decision...

I don't see any need for callbacks when the device can be accessed directly ?

If it is a real disc in real device, the library needs to access the device directly anyway. If it can issue SCSI ioctls, it can perfectly well read the files too. If Kodi is using a real device it can simply pass that to libbluray. There shouldn't be any need to compilcate this by using callback functions for filesystem access. Unless I'm missing something obvious ... ?

[joniw]

Hello,

with version 1.14.0 it is working with Kodi again.

with regards

Joniw

[mike admin]

Also, it is backwards-compatible. Meaning you can take libmmbd from 1.14.0+ and use older version of MakeMKV. There is generally no reason to do this, but you can.

[onland]

I was wondering if anyone had any success using LIBMMBD.DLL under VLC-Player 3.X to substitute for LIBACCS.DLL and LIBBDPLUS.DLL. While this solution works great under earlier versions of VLC-Player 2.X, it seems that version 3.X doesn't even recognize these DLLs. I'm running his under a Win-32 environment and would like to make it work for VLC-Player 3.X since it supports BD menus.

[CryptMan]

Fantastic news!

I can confirm that it is working again, many, many thanks to all who made this possible again.

Best regards.