GNOME Bugzilla – Bug 116556
mpeg2subt/subtitle plugins
Last modified: 2004-12-22 21:47:04 UTC
We've currently got three text-on-video overlay plugins: mpeg2subt (overlays mpeg2 subtitles on a mpeg2 image), textoverlay (in the sandbox) and timeoverlay (in HEAD). These need merging in some way. My opinion: * we should merge the text-on-video function of text-/timeoverlay into one that can overlay text on both YUV and RGB frames. * we should move the time-to-text-stream function in timeoverlay into a separate plugin if we want to. * text-on-mpeg2 and mpeg2-subtitle-decoding in mpeg2subt should be separated in two plugins. We might want to move the text-on-mpeg2 into the "general" textoverlay plugin, but I don't think that's really needed. Oh, and, of course, the subtitle plugins need to be moved into HEAD, too, then.
mpeg2subt doesn't overlay text, it overlays run-length encoded subtitle streams. IMO, textoverlay should be moved to ext/pango, and the common bits of textoverlay and timeoverlay be merged into a base class. I'm guessing that the needs for overlaying text will be greater than what can be accomplished in one element. The textoverlay base class should derive from Videofilter. I still need to figure out how to stuff extra pads onto a subclass of videofilter, but I think its possible.
It's for accessibility and portability. We're currently thinking of text on a video as the only thing, but how about text output to a braille reading device as an a11y feature for people that cannot view movies? Or how about text output to festival as a way of implementing artificial karaoke? Or on systems that don't have/support pango (KDE!)? A base class sounds fine, and I'm not saying we should make every single line of code a separate element - let's just try to keep things into our general principle of "everything is a pipeline". :).
sorry, I wasn't questioning the wisdom of having text streams. I was more worried about the (perceived) suggestion that timeoverlay should be replaced with: /- ! timetotext ! -\ ... ! tee textoverlay \------- ! --------/ or something similar. This may be just my personal preference, but I'd like to avoid designs where one element splits a stream into two streams, just to be merged in the next element.