To : gstreamer-devel cc : usf-devel@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 http://usf.corecodec.org