[gst-devel] subtitle elements

[Gustavo J. A. M. Carneiro]

A Qua, 2003-05-14 às 08:00, Thomas Vander Stichele escreveu:
> Hi,
> 
> I'm testing out and working on Gustavo's excellent subtitle plugins in
> gst-sandbox.  Nice work Gustavo !

  Thanks!  Don't call them excellent, because they still suck.  For
example, Portuguese (ISO_8859-1) subtitles don't display well because of
converting accented characters to UTF-8.  I don't know why... 

> 
> I've added a typefind function to the SubParse element and that works 
> too now.
> 
> (btw, I noticed I had a gst-typefind.c lying around in my
> gstreamer/tools dir, which does what the name suggests.  Is it OK if I
> add this to CVS ?)
> 
> Now I need to add what kind of types it actually discovers :)
> So I'm taking suggestions for possible mime types for the subtitle
> formats.
> 
> Right now, SubParse detects SubRip and mdvdsub formats.
> 
> Some possibilities would be:
> - all of them are text/plain, with properties encoding="utf-8",
> format=(whatever)
> - make one mime type for each of these formats, which would probably
> make them application/x-gst-sub-subrip and so on

  First option if you want the subtitle element to have the burden of
detecting the subtitle format, by content.
  Second option if the upstream element (the source element) should be
the one to discover the subtitle format.
  *However*, for mime-type detection to be correct, a content match is
going to be required, since subtitle extensions are most of the time
incorrect anyway.  To do content match, the source element (filesrc,
most of the time) has to know a lot about subtitle formats.  You have to
keep a registry of regular-expression => mime-type mappings, and make it
accessible in all gstreamer sources: filesrc, gnome-vfs-src (or whatever
it's called), etc.
  So, I think it makes more sense to have subtitle detection by content,
and in the subtitle parser element itself, instead of spreading the
details of subtitle detection along multiple elements.
  Also, answering Ronald's subsequent email, I think it makes more sense
to keep all subtitle parsers in the same element, otherwise it leads to
a duplication of code.  You'll notice that subtitle parsing is fairly
simple.
  So this is my point of view, but whatever the gstreamer developers
decide is fine by me, really!

> 
> I'm leaning towards the second in this case, personally,
> but others might have a better clue as to what to use.
> Also, the textoverlay plugin is taking in text/x-pango-markup.  I don't
> know if this is an official MIME type ? Otherwise, since textoverlay is
> using pango, this is a good choice IMO.  I'm wondering if it might be
> good to make textoverlay accept both x-pango-markup and general
> text/plain, and make the subparse element serve the most appropriate one
> of these two.

  I made up the text/x-pango-markup MIME type, I don't know if it
exists.  Anyway, the x- part already implies that this is not a
registered MIME type, I think.

> 
> 
> Gustavo, a few questions:
> 
> a) when running with output colorspace ! xvideosink disable-xv=true, the
> text is not displayed correctly (I have dark italic shadows offset to
> the right of the text).  Might be a colorspace issue or you not properly
> checking the colorspace being used ? If you want I can make a
> screenshot.

  Without doing that experiment (when I get home I'll try), I think this
is the result of YUV complications.  I think there must be some bug in
the blitter, my fault.  If you comment these lines...

	DUFFS_LOOP(
	{
	    v = *bitp;
	    if (v) {
		*p = v;
-		if (!skip_y) {
-		    u_p[0] = u_p[u_plane_size] = 0x80;
-		}
	    }

...the problem should disappear, with unfortunate consequence of not
changing the color of the text.  You see, it's the U and V pixel values
that are causing those shadows.
   If only we could work in RGB color space.  I work in YUV only
because, at the time, the colorspace plugin seemed to not work, or else
I was doing something wrong, which is very likely given my inexperience
in gstreamer programming :)

> b) I don't see why you would use x0 and y0 as arguments - can I change
> them to x and y ?

  x0 and y0 are old habits of mine.  I don't mind changing to x and y.

-- 
Gustavo João Alves Marques Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>