I've only just joined the forums, but I've been using MakeMKV for a little while and I have to say it's my favourite application. I've been through my modest library and submitted a dozen and some BD+ dumps for the magic to be done. I have to say that the procedure works really well and means only a few days of not being able to watch a certain disc. I noticed that in my collection it only seems to be (the majority of) Fox and MGM titles which are BD+ protected. Everyone else seems to be using AACS only. That might save people some time when determining which titles to try in their drives to aid the BD+ decryption cause.
Unlike some people, I have no interest in keeping a permanent archive of my BDs on the hard drive... I'd need at least 5TB so far and it's just not practical. It's much more convenient to just pick up the disc and play it... and maybe convert it to mp4 for iPhone playback when there isn't a 'digital copy' included.
Of course because I'm only interested in watching the titles, it means a decode cycle every time I watch, which is why I have been really pleased with AnyDVDHD when booting to Windows to watch BDs. I'm not a fan of booting out of MacOS though and that's why I'm falling in love with MakeMKV. I think it could be even better though.
The profile of the app is that it will read (and the output file size is shown as increasing) reaching about 4x speeds on my Mac Mini but then all processing will stop, the CPU usage will fall to 0 and the write buffers purge at just over 30Mb/s before the app continues to process. It repeats this pattern until the file is completely processed. If it could continue its reading and processing while the write buffers were flushing then we'd be away and running and might get up to the 6x speeds my reader is capable of.
The app is using blocking write calls and writes are in the same thread as the processing, this is why when the buffers fill, the app pauses (waiting for write to return) rather than keeping those buffers filled and writing out at maximum speed all the time.
Active app profile: (# calls)
Code: Select all
semaphore_wait_trap 15351 kevent 2291 sem_wait$NOCANCEL$UNIX2003 2289 mach_msg_trap 1554 AES_decrypt 951 AES_cbc_encrypt 112 __memcpy 57 memchr 40 write 36 0x6730 29 semaphore_signal_trap 26 pthread_setspecific 19 0x5c531 15 AES_set_decrypt_key 10 AES_set_encrypt_key 6 io_connect_method 6
Code: Select all
semaphore_wait_trap 5796 kevent 828 sem_wait$NOCANCEL$UNIX2003 828 write 828
You're already using Grand Central Dispatch (whether you know it or not) for part of the job (I think just for the disc read and UI though?) the rest of it is using old school unix blocking IO. If you rearrange your workflow you could really improve this app's performance (at the moment, my CPUs are only about 40% used during a rip and writes are bursting for around 10s at a time every 30s.
In my day job, I help diagnose performance issues with internet apps written in Java on giant server farm installations... I hope this has been helpful and not too much like teaching granny to suck eggs.
Thanks again for a really useful application.