W3C home > Mailing lists > Public > public-tt@w3.org > January 2004

Re: [tt-af-1-0-req] Some (late) comments on the requirements

From: Luke-Jr <luke-jr@cox.net>
Date: Wed, 21 Jan 2004 17:43:51 +0000
To: Johnb@screen.subtitling.com
Cc: public-tt@w3.org
Message-Id: <200401211743.57263.luke-jr@cox.net>

Hash: SHA1

On Wednesday 21 January 2004 01:36 pm, Johnb@screen.subtitling.com wrote:
> Luke et al,
> > > Basically you say "the video file that goes with the timed text will
> > > also be paused". In a broadcast environment this is not possible. You
> > > CANNOT stop the video..... E.g. It is coming off a server, through an
> > > MPEG encoder and up to a satellite.
> > Ah, I was assuming you were doing the subtitles at the same place the
> > video was being broadcast originally.
> We are, the subtitles are inserted over the top of a video broadcast at the
> point of broadcast.
> (Termed 'playout' subtitling).
In which case you can tell when the video is stopped and pause the subtitles 
at that same time, no? Or are commercials actually in the source material 
(video tape/file)?
> > Personally, I would suggest seperating parts
> > of a TT file into scenes and marking subtitles with (very accurate)
> > percentages through the video. Then it would be easy to  adjust to
> > different source files or media.
> Hmmm...  There seems to be a misunderstanding here.
> How would a subtitle inserter detect the start of a scene?
Default times for the start/end of scenes can be set and on top of that 
specific times or frames for a particular MD5. If there is no MD5 match for 
the source, default times could be adjusted if a scene change was detected 
near the default. For live-encoded stuff, you'd probably need to use the 
defaults, though.
> Basically the broadcaster has video and audio on a tape or video server.
> In accordance with a schedule of programming, the tape gets played (or the
> server is started).
In the latter case, I would suggest muxing the TT so the server provides it 
> As the program plays out, the timecode on the video signal is monitored.
> At the correct points in the program, the subtitles are inserted.
> This has to be a real time rendering process. (although we can and do
> pre-render in anticipation of the next insertion event).
If you have the content prior to the broadcast, you could probably add some 
kind of identification (similar to MD5 for video files) to use non-default 
> If the broadcaster chooses to interupt his program with an advert, or
> public service announcement, then the station automation system switches
> across to a different
> video segment. When the adverts finish, the previous program resumes from
> where it left off.
Why can't the subtitle be paused during this time? If the subtitles are added 
at the original broadcast point, this shouldn't be an issue.
> The only clues the subtling inserter has are the timecode of the video, and
> an indication
> from the automation system that the program has changed.
If the automation system can tell the subtitling program, it should be able to 
handle it.
> This is not like producing a media clip, where the subtitles are added
> against a media clip
> of known duration (in play time terms),
I would suggest against doing that anyway. It is better to add a TT stream to 
the container and have the video player render it (though that would involve 
converting the percentages to actual times).
> since the time required to air an entire program
> will depend on how many advert breaks the broadcaster chooses to have. This
> may differ from channel to channel and possibly at different times of day.
Consider the subtitle times as program times, not as air time. Just because 
the subtitle file is 23 minutes long doesn't mean when it's played it needs 
to complete all at once.
> 8 foreground colours works fine for Teletext subtitling, in fact not all 8
> are commonly used. In fact, a **lot** of subtitling is done with just white
> on black.
A lot of subtitling is done using 24-bit RGB values, also.
> I doubt you'd make much headway in getting consumers to move away from DVD
> now...
> A new standard would have to offer significant advantages over DVD.
Better video quality isn't a significant advantage?
Even if not, enough things being released in only a new format usually can 
supply a reason to use it. The few people I know who don't care about video 
quality would have stayed with VHS if it weren't that some media (in addition 
to DVD-only releases, a lot of people prefer to author VideoCDs over VHS 
tapes) can only be played with a DVD player.
Version: GnuPG v1.2.3 (GNU/Linux)

Received on Wednesday, 21 January 2004 12:48:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:00 UTC