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).
mike admin wrote: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).
mike admin wrote: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.
mike admin wrote: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.
mike admin wrote: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.
mike admin wrote: 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 ... ?