Hm, ok, I analyzed it and the problem stems from an invalid size entry at offset 0x1081d:
Code:
0x10800:
000001BA pack ID
400000000000 (invalid) system clock reference
000000 (invalid) multiplexer rate
00 (invalid) stuffing info
000001BD subpacket ID
07EC (valid) packet length
8080 packet type
05 210241F0C1 PTS
20 Stream ID
07E4 (invalid) Subpicture size in bytes (offset: 0x1081d + 0x7e4 = 0x011001)
07C6 (valid) Offset to control header
Apart from the fact that the info in the pack header is invalid (which is irrelevant for the subtitle info though), the main problem is that the subpicture size given (0x7e4) is simply one byte too large. That's why BDSup2Sub assumes that the control buffer is incomplete and continues with the next pack which is however the wrong decision in this case.
Anyway: although IMHO this is a bug in the stream, the next version will have a workaround for this issue. Already works locally but it's nearly 2 o'clock in the morning around here and I'm too tired to release an update right now, so you'll have to wait a few hours while I get a nap.
If you can't wait, you could also try to patch the size at offset 0x1081d from 0x7e4 to the correct value of 0x7e3. Haven't tested this, but in theory, this should work with the current version of BDSup2Sub.