Re: HTML 5, SMIL, Video

On Fri, Feb 19, 2010 at 11:34 PM, Geoff Freed <geoff_freed@wgbh.org> wrote:
> On 2/18/10 6:52 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
>
> <snip>
>
>
>> Ease of authoring can’t really be used as a basis for its consideration.
>>  John F made an excellent point the other night:  unless they’re just
>> inserting occasional blocks of text, most people who write captions will
>> not
>> be writing them by hand with NotePad or TextEdit, they’ll use an
>> application
>> like MAGpie, Subtitle Workshop or a broadcast-level suite to create and
>> format them.
>
> There are more srt files available on the Web than DFXP files. In
> fact, I have found it really difficult to find DFXP files in use in
> the wild. A list of such would be really helpful for implementation
> purposes. You'd be amazed how many people create srt files by hand or
> with a simple application that is available for free from the
> Internet. If you search for "subtitles" on Google, almost the whole
> first page points to sites that provide subtitles in srt format or to
> free software to create them, e.g.
> http://www.opensubtitles.org/
> http://www.jubler.org/
> http://subscene.com/
> http://www.allsubs.org/
> http://www.divxsubtitles.net/
> http://www.podnapisi.net/
> http://www.mysubtitles.com/
> I wasn't able to find a single site that offers DFXP or SmilText files.
>
> GF:  Believe me— I’m well aware of all the caption formats that are
> available and in use, SRT or otherwise.
>   There are tools that create DFXP
> captions— MAGpie (
> http://ncam.wgbh.org/invent_build/web_multimedia/tools-guidelines/magpie )
> springs immediately to mind— and user agents that implement DFXP (CCforFlash
> (
> http://ncam.wgbh.org/invent_build/web_multimedia/tools-guidelines/ccforflash
> ), ccPlayer (
> http://ncam.wgbh.org/invent_build/web_multimedia/tools-guidelines/ccplayer )
> and Adobe’s support for DFXP in Flash (
> http://w1000.mv.us.adobe.com/accessibility/products/flash/captions.html ).
>  If you want to judge the quality of SRT based on sheer numbers, SRT wins.
>  But counting the number of SRT implementations vs DFXP or other formats
> doesn’t necessarily create a good argument for the *quality* of SRT, which
> is of concern.

Having just text and no other markup can be an advantage, because then
you can control everything from the webpage. As such, I would not
judge SRT to be of minor quality.

It is clear that DFXP has a large number of features that SRT does not
have and that professional subtitling/captioning requires, which is
the reason for having both, DFXP and SRT file support as proposed
baselines. I don't think we need to discuss DFXP and SRT here any
further and would prefer we focus the discussion on smilText.



>> From my perspective, SmilText or profile of DFXP (or both) would be best
>> as
>> a recommended caption-text format.  That’s not to say we shouldn’t include
>> SRT in the list, but I just don’t think it should be the primary
>> recommendation.
>
> There is no primary recommendation. Right now DFXP and srt stand on
> the same line and both should be implemented. But an srt
> implementation will be trivial and for DFXP we may still need to come
> up with a common profile. So, there is work to be done and it will
> definitely take longer to have more than just basic DFXP support.
>
> GF:  I realize that I may not win any converts in the argument of SRT vs
> DFXP, but I do wish that others would take into account a long-range view,
> as Dick describes in his recent post to the list.  SRT is fine right now,
> but we already have at hand other formats, wrung through the standards
> process, that do both simple and complex things that will satisfy authors
> that want to create both simple and complex captions, subtitles, or
> whatever, and will probably satisfy these needs for a long time.  Why waste
> time now on hauling SRT up through an RFC?

Because it's a minimal effort and I can do it in an afternoon. How
long will it take to create DFXP profiles? When can we expect a
baseline DFXP profile that is as simple to implement as SRT? I think
you are fighting something that will actually help the DFXP cause:
once SRT support has been implemented into browsers and all the
fundamental technical issues have been addressed, it will be easier to
extend that to DFXP. Also, once people see SRT working in browsers,
they will ask: so what about richer text presentations - can we get a
richer format? This will all support the cause of DFXP. However, as
long as there is no specification of DFXP that has been published as
W3C recommendation, and as long as the simpler profiles have not been
developed, you are fighting for something that is a moving target for
the browser vendors and that is really difficult to implement
completely. I think it would make sense to start working on profiles.
That will hold back DFXP more than anything SRT will do.


Best Regards,
Silvia.

Received on Saturday, 20 February 2010 04:35:25 UTC