Re: Action-28: updated syntax document with time formats

Hi,

Thanks, that is a good summary. I guess my main concern was that the strict
RTSP timecodes are not very succinct, and there might be an expectation
that times like "1:30" should work -- ie. to allow hours to be optional.

(I guess this is the reason that YouTube chose to use separators h,m,s.
"1h30m" and "1m30s" are succinct and unambiguous, but perhaps have some
i18n issues).

I agree that '.' shouldn't be used to separate frames -- frames
should be visually distinct from fractional seconds; so I'm leaning towards
the RTSP syntax, but perhaps it could allow shorter variants.

Here's a new suggestion for a parsing rule to allow hours to be optional:

For the case of frame offsets, perhaps we could simply mandate that if
frames are specified, then hours must also be specified. ie.

1:30 == 1m 30s
1:30:24 == 1h 30m 24s
1:30:24:14 == 1h 30m 24s 14f

ie. if the timecode consists of exactly 3 colon-separated integers, then
it is interpreted as hh:mm:ss. I think this would be a fair disambiguation
because timecodes that include frame offsets are likely to be either
generated by software or written by an advanced user -- someone who actually
cares about frame offsets is probably technically savvy enough to realize
that they need to write a full hh:mm:ss:ff timecode.

For the case of fractional seconds, the presence of the decimal point
makes the meaning clear already, so it's straightforward to make hours
optional:

1:30 == 1m 30s
1:30.24 == 1m 30.24s
1:30:24 == 1h 30m 24s
1:30:24.5 == 1h 30m 24.5s

Also IIRC the current draft allows just seconds to be specified:

30 == 30s
30.5 == 30.5s
150.5 == 2m 30.5s

So, in summary I'm suggesting that we use the existing RTSP syntax (option 1
below), but allow more optional elements and pattern-match on the number
of colon-separated integers: ss, mm:ss, hh:mm:ss, hh:mm:ss:ff.

cheers,

Conrad.

2009/2/5 Jack Jansen <Jack.Jansen@cwi.nl>:
>
> This is a good discussion, let's hope we can come up with the best possible
> rendition of timecodes.
>
> Here are the timecode formats I have encountered in the wild:
>
> 1. hh:mm:ss[:ff[.FF]]. Used by RTSP, SMIL (which picked it up from RTSP, I
> think). Colon-separated except for the field indicator, which is
> dot-separated. Frame and field are optional, hours, minutes and seconds are
> required. RTSP allows single-digit or two-digit numbers for each of the 5
> fields. SMIL requires 2-digit numbers for everything, except the hours,
> which can be any number of digits. There is a good reason for using colon as
> the separator for frames: both specs also allow NPT to be specified in
> hh-mm-ss form, but with fractional seconds. So, npt=01:02:03.5 is the same
> as smpte-30=01:02:03:15. Because the "npt=" bit is optional in both
> languages there's room for confusion if you don't have the dot/colon
> distinction.
>
> 2. hh:mm:ss.xx. Used by many captioning formats, including quicktime text.
> Unfortunately these formats are usually not rigidly standardised. This is
> even true for Quicktime Text: Apple's documentation only consists of
> examples, where the timecodes used always are of the form 01:02:03.000. The
> three digits after the dot seem to indicate milliseconds, but there is other
> (non-apple) documentation floating around on the net that uses examples like
> 01:02:03.15 saying that the 15 is a frame number. Whether the hh/mm/ss
> numbers must be two-digit or not doesn't seem to be specified anywhere.
> Sometimes, comma is also used as a separator, but with unexpected meaning:
> SRT is a fairly popular format that uses hh:mm:ss,fraction. Yes:
> comma-fraction. Wikipedia says this is because the format was initially
> invented in France. Sigh.
>
> I have not been able to dig up a definitive reference from SMPTE on "how to
> write down time codes". They've standardised timecode in bit-formats and
> even in voltage levels and transitions, but not in ASCII. Various vendors
> have used various methods to express the (standardised) bit-format in ASCII,
> but all these seem to differ. I'm also really out of my water here, so I
> have no idea whether the Avid CMX format Conrad mentions is the de-facto
> standard, or whether it's just one of the many competing ways of specifying
> timecodes.
>
> With this mess, it seemed that option (1) was the most rigidly specified
> format, hence I picked that. But: I happen to live in a SMIL-centric part of
> the universe, so if there's another format that is much more commonly used
> we should pick that other format, possibly making sure we rigidly specify it
> if no-one else has done so before.
>
>
> --
> Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
>
>

Received on Wednesday, 25 February 2009 11:50:17 UTC