[gst-devel] Re: subtitle elements

[ChristianHJW]

To : gstreamer-devel
cc : usf-devel at freelists dot org


Gustavo J. A. M. Carneiro wrote:
>>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.

Please allow me to tell you how its handled in matroska files :

Currently with AVI, if the subs stream is muxed into the file ( bad bad 
bad :( ), it has to be done this way, so the parser has to detect what 
type of subtitle stream it is ( text, SSA, ASS, etc. ). For this very 
reason VobSub, the most used subtitles editor on Windows, will write a 
tag line into the subs stream on the very beginning as a kind of identifier.

In matroska we have specific codec ID's ( full list is here : 
http://cvs.corecodec.org/cgi-bin/cvsweb.cgi/~checkout~/matroska/doc/website/specs/codex.html?rev=HEAD&content-type=text/html 
) to identify the subtitle stream type from the track header, namely

S_TEXT/ASCII
S_TEXT/UTF8
S_ASS
S_SSA
S_USF
S_IMAGE/BMP
S_IMAGE/PNG

( more to come ).

This is making us a lot of problems for our DirectShow parser filter, as 
stupid DShow only knows one type of subtitle streams also. We decided 
now to 'extend' Dshow a bit here ( ;) ) and agreed with Gabest, the 
author of VobSub who is also the developer of DVobSub, the most used 
DShow based subtitlte display filter, to add new 'media subtypes' to 
DirectShow to make a 'cleaner' solution here in future.

Just FYI :)

Christian
http://www.matroska.org
http://usf.corecodec.org