- From: Dave Singer <singer@apple.com>
- Date: Wed, 19 Feb 2003 12:04:22 -0800
- To: Jean-Claude Dufourd <jean-claude.dufourd@enst.fr>, public-tt@w3.org
Hi JC! At 20:54 +0100 2/19/03, Jean-Claude Dufourd wrote: >Dear all, > >Going back to a conceptual level, John Birch's requirements are: >1- a movie constituted of a video stream and an audio stream and a >subtitles stream and a timecode stream. If we are talking about discontinuous 'tags' it is much better to talk about it as a timecode stream, in my opinion. >(actually, possibly many audio and subtitles), should be playable in >sync, whatever part is played in whatever sequence >2- a movie should be playable according to an edit list ah, it's more subtle. He wants to be able to edit, not the whole layup, but just the a/v/timecode part, and then lay in the text stream, and still have it line up with the right timecodes. > >1 seems a TT requirement, whereas 2 does not. 2 is more of a >requirement on the player. Right ? I see 2 very much as a composition (temporal composition) requirement. > >If that is so, then considering 1, I prefer putting the >synchronization in a file defining the composition of streams, >rather than having it specified in the subtitles stream. >So I'd vote for the SMIL2.0-like solution (with adjusted/clarified >semantics if needed) > >Now, just a word about playing a movie according to an edit list. I >question the relevance of requirement 2. >Given that all videos encodings I know use I (key or intra-coded) >frames and non-I (frames you cannot start decoding at, you have to >go back to the previous I frame), I have doubts about the >feasibility, with current machines, of playing a stream according to >an edit list that is not aligned with I frames. Since cuts would >statistically not be aligned with I frames, a new cut set would >require partial reencoding of the video. So the automatic adjustment >of the subtitles stream seems reasonable. The same adjustment may be >needed for the audio streams. > >Best regards >JC -- David Singer Apple Computer/QuickTime
Received on Wednesday, 19 February 2003 15:05:24 UTC