bdsup2sub++ - convert and tweak bitmap subtitles.

[mini-moose]

Originally Posted by paradoxical

Yeah it didn't take anywhere near that long and that's with quite a few things running at the same time.

here are the switches I used:

--palette-mode keep --resolution 720 --fps-target keep --filter mitchell

So it seems I was subtracting time wrong using my clock so I did one more test run after warming up the JVM so it can hotspot things:

Java version 5.1.1: 4 minutes 55 seconds.
Current 1.0.1 build of ++: 4 minutes 35 seconds.

So it's about a 7-8% difference once I warmed up the JVM. And again, this is on a 2.3ghz quad core i7 Ivy Bridge. So, I don't know why you got nearly 29 minutes. That's pretty insane. Maybe the difference is running it via CLI. I did my runs via the GUI. I can test that.

[mini-moose]

Originally Posted by paradoxical

I don't know why you got nearly 29 minutes. That's pretty insane. Maybe the difference is running it via CLI. I did my runs via the GUI. I can test that.

yes pretty insane indeed. and there's nothing else running that
takes any cpu cycles. I did try the gui too for a bit and it reached about 15% after 5 mins so pretty much on track to the same processing time.

Okay, so there is something weird going on on your end especially if you aren't running anything else. Just to give you an idea of my system at the moment, I'm playing CounterStrike: Global Offensive and running a Windows VM in Parallels that is doing some BD Reauthoring. So it's not a lightly tasked system while doing the tests.

Also, via CLI gave me a time about 5 seconds off from the GUI in the ++ version.

[Selur]

Thanks for the new binaries, btw. you might want to add a '(Mac OS X 10.7+)' or something to the mac to avoid confusion.

[mini-moose]

Originally Posted by paradoxical

Okay, so there is something weird going on on your end especially if you aren't running anything else.

yes indeed weird. I just tried again. Same thing. Tried the java and it did it in like 2-3 mins..

also the gui shows a very erratic behaviour for me. It's not unique to the latest version - maybe the 3rd one described below is, others were happening before too. I usually don't use the gui.

upon launch, console window flashes for a sec but I think that was discussed before.

when I try to load a sup I get this several times:
http://i.imgur.com/y5jIYos.jpg

and when I try to save/export this pops up several times:
http://i.imgur.com/zNT4cmj.jpg

I have to close this window and try save again quite a few times till I manage to get it working.

[Music Fan]

Originally Posted by Music Fan

Now it works with the long file name while I didn't change anything.

I had the same problem today with the same file : first it crashed, then I retried and it worked.

Originally Posted by Selur

Thanks for the new binaries, btw. you might want to add a '(Mac OS X 10.7+)' or something to the mac to avoid confusion.

Done. Wish I could make it compile to 10.6 but the #ifdef effort would be enormous to allow that.

Originally Posted by mini-moose

yes indeed weird. I just tried again. Same thing. Tried the java and it did it in like 2-3 mins..

I don't know what to tell you. I ran it a few times again this morning with less system load and both are in the 2-3 min ballpark with the Java still about 10% slower.

Originally Posted by mini-moose

also the gui shows a very erratic behaviour for me. It's not unique to the latest version - maybe the 3rd one described below is, others were happening before too. I usually don't use the gui.

upon launch, console window flashes for a sec but I think that was discussed before.

when I try to load a sup I get this several times:
http://i.imgur.com/y5jIYos.jpg

and when I try to save/export this pops up several times:
http://i.imgur.com/zNT4cmj.jpg

I have to close this window and try save again quite a few times till I manage to get it working.

Can't say I've ever seen anything like either of those screenshots on any OS I've run it on. And yeah, the console issue is something that can't be fixed in the application. I release the console as fast as is possible. It's purely a Windows issue with respect to Qt. Neither OS X or any of the *nix systems do it. Again, the only way to fix this is either on Qt's end or to make separately-compiled applications. Neither are very likely.

Originally Posted by Music Fan

I had the same problem today with the same file : first it crashed, then I retried and it worked.

I opened it 20 times in a row and none of the times it crashed. Comparable link paths as I said yesterday. As I said, the application does nothing but pass the file path on to the QFile constructor. Any path length issues would come down to OS limits and on Windows that is 260 characters IIRC.

So good news for you mini-moose. After more investigation, I've isolated the speed issue and it's a total facepalm moment on my part. That Windows binary was compiled with -O0, no optimization, and debug symbols and I forgot to revert these when I compiled it for posting. The binary has now been replaced with the proper release build. That was why you saw vastly different results than when I was testing on my Mac Mini. Now, it's still slower to output since neither the Java or ++ is not detecting the image area properly, it's saying the entire 1920x1080 area is the "image area" which is not right, which accounts for why it takes longer than other BDSups to convert and output that I've tested. That I will investigate and try to track down.

Edited to add:

mini-moose where did you get that file from?

So I have a fix that will find the image area in the case of a pathological subtitle file like you sent me mini-moose. To find the image area doesn't increase processing time much more than not doing it. The best you can do with subtitles such as that is to load it, resave it without scaling, then scale. Or just accept that the time it takes to do the bounds checking and scaling.

[mini-moose]

Originally Posted by paradoxical

So good news for you mini-moose. After more investigation, I've isolated the speed issue and it's a total facepalm moment on my part. That Windows binary was compiled with -O0, no optimization, and debug symbols and I forgot to revert these when I compiled it for posting. The binary has now been replaced with the proper release build.

Edited to add:

mini-moose where did you get that file from?

ok I will reget it and test!
what file? the sup or the binary I used?

That "english.sup" file that you posted in the other thread. That thing is something pathological. Looks like it was output incorrectly. It's got no data for image offset, etc so both the ++ version and Java see each subtitle image as the full 1920x1080 frame. That's why processing it is sooo slow.

And actually my post right above you was incorrect. Finding the image area before scaling reduces the time to save to about 24.5 seconds rather than it taking a couple of minutes. If you wait a few mins I'll post a new test version for you with the fix for that case in it.

[mini-moose]

Originally Posted by paradoxical

That "english.sup" file that you posted in the other thread. That thing is something pathological. Looks like it was output incorrectly. It's got no data for image offset, etc so both the ++ version and Java see each subtitle image as the full 1920x1080 frame. That's why processing it is sooo slow.

it's from some horror movie blu-ray. I find that those sort of odd sups are often found on horror movies (usually colored too, yellow in this case). If you load it on something like SupRip you will see the letters are very tiny. When converted to vobsubs they look the normal size.

Ran the sup again with the new version and it took around 4mins (resized to 1280x720 with Mitchel).

I'm quite relieved to see it wasn't my system to blame
thanks!

edit: tried the gui now too and at least on first try it didn't display the symptoms I described earlier.

It'll take you far less than that once I finish compiling a new version with a fix for it. Went from ~3 minutes to ~24 seconds.

Here is a test version with that fix. I checked some other BDSups to make sure nothing got regressed with the fix and I didn't see anything, but if you see that it broke anything please let me know. Won't compile another "official" version till I finish the other issues slated for 1.0.2 release on the issue tracker.

[mini-moose]

Originally Posted by paradoxical

Here is a test version with that fix.

nice one it took 22secs with resize to 720p and 12secs for 1080p (1080 is always faster).

one thing I want to ask - the last lines on cmd output is
Decoding frame 1145/1269 at offset 01ad769b
There were 144 warnings
There were 1048 warnings

As I said before I have 0 understanding but shouldn't it end with
1269/1269 ?

also a small request if possible. Can you tag the archive and binary with some sort of version number? It can get a little messy when there are several versions around.

Originally Posted by mini-moose

nice one it took 22secs with resize to 720p and 12secs for 1080p (1080 is always faster).

one thing I want to ask - the last lines on cmd output is
Decoding frame 1145/1269 at offset 01ad769b
There were 144 warnings
There were 1048 warnings

As I said before I have 0 understanding but shouldn't it end with
1269/1269 ?

I'll look into it. There was an issue like that with the GUI's progress bar stalling then immediately finishing even the processing was fine that I fixed a while back.

Originally Posted by mini-moose

also a small request if possible. Can you tag the archive and binary with some sort of version number? It can get a little messy when there are several versions around.

Yeah with 1.0.2 I'll put version in the archive name. The application itself always has the version number in the title.

[mini-moose]

Originally Posted by paradoxical

Yeah with 1.0.2 I'll put version in the archive name. The application itself always has the version number in the title.

ok. I usually just rename them myself, cause if I have a few versions like in this case and I want to be able to compare their performance it's easier to have the exe tagged differently. This way I can have all of them running from the same location (since I use a .bat to call them).

another small note: the 101 fixed .sub is 6.2mb (like the java output) and the test version .sub is 4.4mb. Whether it means anything..I have no idea

It's due to the fix I made. The test version crops the bitmap to the image area like would happen with any other SUP instead of it being the full 1920x1080 frame.

[mini-moose]

Originally Posted by paradoxical

It's due to the fix I made. The test version crops the bitmap to the image area like would happen with any other SUP instead of it being the full 1920x1080 frame.

ok cool, just pointing out differences in case they have some meaning. You will need feedback from the more advanced users regarding potential issues.

At the time it was discussed the ++ version will be able to eventually generate 3D subs too from 3D sourced sups. Is that something you're planning to look into ?