Re: [Bino-list] SubTitles?

[Joe]

Hi!

Sorry for the delay, last few days were too busy.

Dne 3/22/2011 10:15 PM, Martin Lambers napsal(a):
> On 21/03/11 18:13, Martin Lambers wrote:
> > On 21/03/11 17:42, Joe wrote:
> > > > > I agree with breaking subtitle list into subtitle_box that will hold
> > > > > only one subtitle and will be buffered in the same way as video or audio
> > > > > frames/blobs.
> > > > > > - The subtitle reading/decoding is separated into threads just like
> > > > > > video and audio reading/decoding.
> > > > > I will redo your patch on top of my branch and unify processing of
> > > > > audio, vide and subtitles. I will also move font rendering from
> > > > > video_output to subtitles decoding thread. Is it what you want?
> > > > That's not necessary; my patch was just a rough sketch. The font
> > > > rendering should stay in video_output, it should not go into a separate
> > > > thread.
> > > I don't get this. Font rendering (creating ARGB image from textual data)
> > > is the only time consuming operation that can be done during subtitle
> > > decoding. Otherwise subtitle decoding thread will only memcpy text from
> > > packet to subtitle_box. If separate subtitles decoding thread should be
> > > created, I don't get why font should be rendered elsewhere. I suggest in
> > > decoding thread to create subtitle_box, render text using QT into buffer
> > > inside subtitle_box and in video_output only blend the buffer with
> > > left/right image.
> > With decoding, I mean the work done by ffmpeg. In the simplest case, it
> > is just copying of text (possibly with character set conversion). For
> > image subtitles, it will be decoding an image with
> > avcodec_decode_subtitle2 and converting it to a format suitable for
> > textures. The rendering part is font rendering + texture blending; this
> > should be done in video_output as it is now, because this depends on
> > output parameters (font, size, subtitle depth) and potentially the
> > dimensions of the video frame (for image subtitles). These are things
> > that the media object does not know about (and should not need to know).
> A little progress: with the attached patch (based on your code, but with
> the aforementioned changes), subtitles are now read, decoded, and
> assigned to the correct video frames. But they are not rendered yet,
> just printed to the console for debugging.
Great! I have almost done the same thing last week, but did not have 
enough time to finish it, so I will push your changes to github repo. I 
will try to modify rendering path to correctly blend subtitle buffer 
into output textures.
> Now the bad news: there seems to be a library that implements SSA/ASS
> subtitle rendering: libass<http://code.google.com/p/libass/>. I just
> learned about its existence today. It seems like the correct way to
> render SSA/ASS subtitles since this is a sophisticated format that would
> be to complex to implement from scratch inside Bino (see the
> specification linked on the project page). Yet another subtitle
> rendering approach... but I don't see an easy way around this.
AFAIK mplayer use libass for rendering only when you choose it. By 
default only simple subtitle drawing is used that does not honor special 
subtitles formating. Rendering using QT could be done in the same way by 
ignoring (stripping) formating tags from subtitles. I have personally 
never met subtitles with something fancier than just <i> tag for Italic 
font and tag for bigger font and QT has support for drawing formated 
text, so these simple (and I think the only used) formating tags could 
be easily supported.

Of course libass could be an option. I use mplayer with subtitles almost 
every day and ASS rendering provides no advantage for me. But I could be 
bad sample of users.

Bye,
Joe.