BDSup2Sub++ - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP

Yeah, it uses C++11 features of GCC 4.7.x and higher. Clang 4.x would work too. I think the major issue is the non-static data member initialization. That's what bumps the requirements to 4.7.x.

[Selur]

I think the major issue is the non-static data member initialization.

yup. Thanks for the help.

[Music Fan]

Is this program able to convert DVB-SUB (sup extension) to sub/idx or other sup format (Blu-ray) ?
If not, could it be added ?
I know only one program able to make it, ProjectX, but it fails to do it correctly (colors and time-code problems).

[sneaker_ger]

Maybe:

Originally Posted by 0xdeadbeef

Supported Formats

• Blu-Ray SUP: Import (since 1.0) and Export (since 1.6)
• Sony BDN XML: Import and Export (since 3.3.0)
• HD-DVD SUP: Import (since 1.9)
• VobSub (SUB/IDX): Import (since 3.5.0) and Export (since 1.0)
• DVD-SUP (SUP/IFO): import and export (since 3.9.0)

I suggest you simply give it a try.

[TheShadowRunner]

paradoxical, any luck with these problematic SUP?
BDSup2Sub++ crashes during the convertion on my system :/

I've found where the issue is happening. It's a bit tricky figuring out why the problem is happening. I hadn't had a lot of time to debug it, but I'm working on it now.

Ok, I've located and solved the issue. Apparently there was a bug in doing a deep copy of an object that ended up having catastrophic effects down the line. Will post a fixed binary in just a few minutes after I email a patch to the original author.

[TheShadowRunner]

Wow this is awesome paradoxical, thank you VERY much for your time debugging this!

[Selur]

btw. while at it, it would be cool if the progress indication could be send to std::cerr instead of std::cout in command line mode. (std::cout get's delayed and this way monitoring the progress by watching the console output is a pain, since the progress only happens in large chunks,..)

Originally Posted by TheShadowRunner

Wow this is awesome paradoxical, thank you VERY much for your time debugging this!

Hehe, no prob. I was up for the challenge. The biggest challenge was adding enough log lines to isolate the issue. Once that was isolated it was easy to solve.

Originally Posted by Selur

btw. while at it, it would be cool if the progress indication could be send to std::cerr instead of std::cout in command line mode. (std::cout get's delayed and this way monitoring the progress by watching the console output is a pain, since the progress only happens in large chunks,..)

Sure, it's a simple fix. I'll add that into the patch I make and will add that to the binary I make.

[Selur]

Sure, it's a simple fix. I'll add that into the patch I make and will add that to the binary I make.

Nice!! Thanks!

[r0lZ]

Originally Posted by Selur

btw. while at it, it would be cool if the progress indication could be send to std::cerr instead of std::cout in command line mode. (std::cout get's delayed and this way monitoring the progress by watching the console output is a pain, since the progress only happens in large chunks,..)

Sorry, but I disagree. stdout is the correct handle for that kind of information. I use BDSup2Sup++ with a GUI that considers that an error has occurred if something is printed to stderr. Furthermore, it gets the whole content of stderr at the end of the process only. Of course, it is impossible to handle a progressbar that way. (stdout should not be delayed if open the handle in line mode.)

So, IMO, if you really want that, it should be an option of the command line, and still use stdout by default, for compatibility reasons.

Okay, I'll add a commandline option for it which defaults to the original behavior. Sounds like a good compromise.

[Selur]

If in GUI mode, it should not write anything to std.
Adding an additional option to get the progress on std::cerr to allow monitoring the progress with another tool/gui would be fine too.
(It's just bugging me that atm. progress indication like it is done atm. through CLI is not really useable,..)

It doesn't write anything out to a standard stream in GUI mode. It writes everything to the log window.

[r0lZ]

Originally Posted by paradoxical

Okay, I'll add a commandline option for it which defaults to the original behavior. Sounds like a good compromise.

Thanks.

So I added the commandline option "log-to-stderr" otherwise it defaults to the current behavior. New binary can be grabbed from *removed to recompile*.

[Selur]

Thanks!
> The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
-> looks like you compiled it dynamically.

No, I just didn't add the lflags in correctly. Recompiling now.

[Selur]

"Recompiling now. " -> thanks