RE: Coments - last call draft

Charles,

>> frameRateMultiplier (et al)
>>
...
>> The requirement for most of these timebase attributes only arises
>> by allowing 'dur' as an attribute, since this necessitates the  
>> calculation
>> of effective end values, which in term requires an understanding of
>> framecounting in different timebases.
>>
> It would be helpful if the spec said what happens when the begin/end and
> the dur attributes don't agree.
>
>> Or if it said that you can use begin + dur, and begin + end, but not  
>> begin + end + dur!
>>
>> IMO - drop dur as an attribute - it can be equivalently expressed using
>> begin and end - and the above issues can then be simplified.

>I think it is useful to have dur, so I guess it makes sense that all this  
>stuff is there if you want intrinsic timing with the complexity of TV  
>models.

It is a common mistake to consider a video media element timebase as being
continuous, but this is often not the case. Timecode on video media is
primarily used as a means of identifying frames. In common practice,
timecode is used as a differentiation between programme material and
commercial / filler(10:00:00:00 start cf 01:00:00:00 start). Seeking is a
common operation on video material during transmission.

It is only at the point of viewing that broadcast video appears to have a
continuous timebase - the viewer is unable to 'manipulate' the incoming
stream. Prior to transmission, video media undergoes very many operations
that make the concept of intrinsic timing **almost meaningless** in the
context of an adjunct service like TT.

Even in the scenario where DFXP is used as a true distribution format (i.e.
a wire format), I see little value in DFXP having intrinsic timimg based on
a video media timebase. The obvious requirement for synchronisation between
any associated video media and the DFXP TT content is far more difficult
using an intrinsic timimng model than when using an extrinsic model with
times expressed as 'markers'. Where DFXP is not associated with video media
- a clock based timebase with sufficient precision is all that is required.
Where DFXP is associated with video media that does not carry timecode (or
other markers) - a clock based timebase with sufficient precision is the
best that can be achieved.

So I don't think it makes sense to have this stuff, since I don't think
there is a valid reason for intrinsic timing with TV timebases (this concept
makes no sense to me - how can DFXP use an intrinsic TV timebase). The only
possible justification for supporting an intrinsic TV model timebase is that
it avoids conversions of timebases at the generation point of DFXP - but
this unfortunately pushes that potential conversion onto a User Agent.
Unfortunate - since the User Agent then potentially needs to a) perform the
conversion b) be aware of the timebase of the associated media (which is
probably not known).

regards

John Birch
Senior Software Engineer,
Screen Subtitling Systems Limited,
The Old Rectory, Claydon Church Lane,
Claydon, Ipswich, Suffolk.
IP6 OEQ
 
Tel: +44 1473 831700
Fax:+44 1473 830078
www.screen.subtitling.com 

See us at NAB Las Vegas April 18-21st Stand No. SU8956

This message is intended only for the use of the person(s) ("the Intended
Recipient") to whom it is addressed. It may contain information which is
privileged and confidential within the meaning of the applicable law.
Accordingly any dissemination, distribution, copying or other use of this
message or any of its content by any person other than the Intended
Recipient may constitute a breach of civil or criminal law and is strictly
prohibited. If you are not the Intended Recipient please destroy this email
and contact the sender as soon as possible.

In messages of non-business nature, the views and opinions expressed are the
author's own and do not necessarily reflect the views and opinions of the
Screen Subtitling Systems Limited.

Whilst all efforts are made to safeguard Inbound and Outbound emails, we
cannot guarantee that attachments are Virus-free or compatible with your
systems and do not accept any liability in respect of viruses or computer
problems experienced.