[Bug 21376] Use of last decode timestamp

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21376

--- Comment #2 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 March 2013 08:09:50 UTC