This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21376 - Use of last decode timestamp
Summary: Use of last decode timestamp
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-22 17:35 UTC by Cyril Concolato
Modified: 2013-04-08 21:21 UTC (History)
3 users (show)

See Also:


Attachments

Description Cyril Concolato 2013-03-22 17:35:40 UTC
It is not clear why appending a coded frame whose decode timestamp is between the last decode timestamp and last decode timestamp + 100ms should trigger an error. What is the rationale for '100 ms' ?

Also, since the tests are made in decode order, maybe the Append Sequence definition should be clarified to say "monotonically increasing in *decode* time".
Comment 1 Aaron Colwell (c) 2013-03-25 19:25:53 UTC
(In reply to comment #0)
> It is not clear why appending a coded frame whose decode timestamp is
> between the last decode timestamp and last decode timestamp + 100ms should
> trigger an error. What is the rationale for '100 ms' ?

Like the note states, this is to detect out of order appends. 100ms seemed like a reasonable default that allows a little bit of flexibility on how far apart coded frames are.

> 
> Also, since the tests are made in decode order, maybe the Append Sequence
> definition should be clarified to say "monotonically increasing in *decode*
> time".

I'll add this in the next spec update.
Comment 2 Cyril Concolato 2013-03-26 08:09:48 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > It is not clear why appending a coded frame whose decode timestamp is
> > between the last decode timestamp and last decode timestamp + 100ms should
> > trigger an error. What is the rationale for '100 ms' ?
> 
> Like the note states, this is to detect out of order appends. 100ms seemed
> like a reasonable default that allows a little bit of flexibility on how far
> apart coded frames are.
I thought the note was about the first part (decode timestamp < last decode timestamp). It's a bit akward to me to have to rely on hard-coded numbers to detect out-of-order appends. What if you have very low frame rates? Why not have a gap-threshold attribute or use something like last decode timestamp + 2xduration of the previous frame?

> > 
> > Also, since the tests are made in decode order, maybe the Append Sequence
> > definition should be clarified to say "monotonically increasing in *decode*
> > time".
> 
> I'll add this in the next spec update.
Thanks.
Comment 3 Aaron Colwell (c) 2013-03-26 17:58:38 UTC
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/1e6898152c5b

Decode time clarification to Append Sequence added.
Comment 4 Aaron Colwell 2013-04-08 21:21:45 UTC
Change committed.
https://dvcs.w3.org/hg/html-media/rev/f7f2b7226543

Converted 100ms limit to 2x last frame duration limit.