PDA

View Full Version : .ssa support for Submux/DirectVobSub?


Mentar
16th February 2002, 08:09
Maybe I'm overlooking something, but is it possible to submux .ssa into an .avi somehow? Submux seems to reject it. I've also tried to "trick" it by renaming the .ssa file to .srt, hoping that since it's just a text file too it would work, but not so ... ;)

I know that DirectVobSub can render .ssa pretty perfectly. So is there a technical reason why it couldn't be submuxed? .srt is okay, but .ssa simply offers more opportunities to control and preselect the output.

Gabest, you'd make several people (especially me) very happy if you could please code some .ssa support for submux :D

gabest
16th February 2002, 16:30
The problem is the AVI format itself. A codec must be able to render each media sample separately, there are no keyframes for text data. So, if I placed the style info at the beginning of the avi only in the first sample and somebody opened and seeked into the avi without running it from the start, then I would be left with just the raw text data. The same applies to the language info of the current srt solution, I have to add this field into every sample just to be able display it in the menu correctly. You could ask why I can't add the style info to every sample as well then. The reason is that the renderer of ssa is pretty static. That means it has to precalculate a lots of things at the beginning and I can just simply add more and more styles or even subtitle lines to it.

Taranli Maren
16th February 2002, 18:13
maybe instead it would be possible to store dvobsub properties somehere in the avi, so it knows how to play the srt. The main problem with muxed subs is that it seems to always play back (for me at least) white with no border, which is extremely hard to see on most animes. All that would really be needed would be a font, size, outline/shadow, thickness and color tag (maybe italics and secondary color as well)

Taran'li Maren

Mentar
16th February 2002, 19:06
gabest: I understand that it would be an incomplete implementation, but in my most humble opinion it would still be a giant improvement. Effectively, the output from submux is the end product, there's going to be no postprocessing afterwards. It's just going to be played back.

Now I can't see that the video wouldn't at least be started during replay, which would enable the player to read at least the initial definitions - and those should be enough. If the user then jumps to a different spot, the definitions would still be available - or do I overlook something?

It might be incomplete, but I think that it would work in 99.9% of all cases - and this is alot!

Alternatively, the solution outlined by Taranli Maren would also be a giant step ahead. Basically, what would be extremely helpful would be to somehow be able to make basic text output definitions for textual subs (I'd also add placement to the properties listed by Taranli Maren) and mux it so that it would be chosen by default.

Could that be possible? It would REALLY be extremely useful!