Re: HTML 5, SMIL, Video

Hi John,

On Fri, Feb 19, 2010 at 1:12 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Silvia Pfeiffer wrote:
>
> While the standards/policy wonk in me is solidly behind DFXP and smilText,
> the reality is as Silvia says: in the wild (especially in non-english
> countries) .SRT has made huge strides and inroads, thanks in large part to
> bootleg movies/bit torrent/etc. 'Kids' create subtitles to redistribute
> with those bootleg movies, and funny enough sometimes those bootleg
> subtitles in .SRT emerge before the studio's 'official' subtitle track
> appears. (And it's those 'kids' who are going to ultimately take
> captioning outside of "have to" and move it into "want to", so I really
> don't want to lose them)
>
> From an implementation perspective, I would hate to frustrate captioning
> (as opposed to subtitles, but for those 'kids' they are the same thing -
> and let's not have that discussion here <grin>) on simply the grounds of
> political rightness. Yes, DFXP and smilText have advantages, and are W3C
> Recommendations, but if we get the RFC for .SRT authored then, while I
> would encourage the use of DFXP, I wouldn't halt progress because somebody
> is using .SRT - my personal bottom line is that we just want more videos
> captioned - period.
>
> The automated system we've created here at Stanford spits out DFXP and SRT
> files, and the 'copy and paste' code we supply authors references the XML
> file (over the SRT file), but enough people on campus told me they wanted
> SRT as well that we just went ahead and did it. Computationally, it cost
> me nothing more to provide.
>
> In a conversation with Ken Harrenstien (Google/YouTube), I asked him about
> a 'preferred' format for YouTube - as many of the videos being produced
> here on campus end up living at YouTube. His answer both surprised me and
> made me laugh: none of the formats made a difference to him, as he was
> converting the files to a proprietary time-format, so it didn't matter.
> Start and End time were all he needed. (BTW, I believe the reason why most
> campus folks asked me for SRT, is that YouTube was suggesting that this
> was the format to use - even though ultimately to Google it didn't/doesn't
> matter) Now I don't agree with Ken's 'solution' either, but really,
> outside of some styling considerations (which DFXP's XML format will
> facilitate) all that we really need at the most basic level is start and
> end, so, the pragmatist in me says - hey, the kids are using it (SRT)
> today, let's encourage them to keep up the good work (let's build on
> inertia, not fight it).

I couldn't agree more. Thanks, John, for bringing in a practitioner's
pragmatic view.


>> Is there a reason that both SmilText and DFXP should be recommended?
>> The examples at http://www.w3.org/TR/SMIL3/smil-text.html look a lot
>> like some of the examples in DFXP.
>
> Turn it around - is there a reason why we cannot support SmilText along
> with DFXP and SRT?

The discussion of a baseline formats is one of "how much extra code do
we want the browser vendors to have to write and ship". For image
formats, it meant supporting now probably three formats (png, jpg, and
png), which is triple the code than a single format. For video for
some browsers it means supporting both Ogg and MP4, which is double
the code. A single format is always preferable over several formats -
makes for more compatibility and easier tools, too.

Now, in our case, we are talking about srt and DFXP. Because srt is so
simple, the extra code required for its support is minimal (as you
noticed when you put srt support into your systems). Also, srt and
DFXP basically satisfy two different audiences: srt for "the folks out
there" and DFXP for the professionals. I don't think what SmilText
brings to this mix that would make it important to support - other
than if we regarded it as a simple profile of DFXP and professionals
would use it over the full DFXP. What argument would warrant the
inclusion of the extra code into browsers?

Cheers,
Silvia.

Received on Friday, 19 February 2010 03:30:53 UTC