www.makemkv.com

MakeMKV support forum
It is currently Mon Jul 23, 2018 6:12 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Feb 04, 2018 9:29 am 
Offline

Joined: Mon Dec 04, 2017 11:26 am
Posts: 8
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.


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 04, 2018 3:01 pm 
Offline

Joined: Thu Dec 07, 2017 11:46 pm
Posts: 5
Hello,

the problem is described here: https://forum.kodi.tv/showthread.php?tid=189402&pid=2676853#pid2676853.

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

Joniw


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 08, 2018 2:41 pm 
Offline

Joined: Wed Nov 26, 2008 2:26 am
Posts: 3387
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...


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 10, 2018 8:29 pm 
Offline

Joined: Thu Dec 30, 2010 7:51 pm
Posts: 15
mike admin wrote:
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.
mike admin wrote:
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.
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...
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.
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. 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.
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...

dgktkr


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 19, 2018 12:43 pm 
Offline

Joined: Mon Mar 19, 2018 10:29 am
Posts: 1
dgktkr wrote:
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 ... ?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group