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 24854 - [MSE] Coded Frame Algorithm and erroneous abort case
Summary: [MSE] Coded Frame Algorithm and erroneous abort case
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: CR
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-28 09:49 UTC by Cyril Concolato
Modified: 2014-04-02 15:20 UTC (History)
3 users (show)

See Also:


Attachments

Description Cyril Concolato 2014-02-28 09:49:04 UTC
I think I found a problem in the Coded Frame Algorithm.

Consider the following scenario:
A video sequence has 2 I frames with PTS 0 and 1.
The video is segmented with 1 frame per segment. 
The segments are appended (in sequence mode) in the reverse order (Frame PTS 1 and then frame with PTS 0), in order to play the video backwards.

The coded frame algorithm will behave as follows:
For frame with PTS 1:
- steps 1 to 1.3 run normally
- the test in step 1.4 will pass because group start timestamp (GSTS) was set to 0 when changing the mode to sequence
- step 1.4.1 will set timestampOffset (TSO) to -1=0-1
- step 1.4.4 will unset GSTS
- step 1.5.1 will change the PTS from 1 to 0=1+(-1)
- the rest of the algorithm will run without problem
- step 1.21 will set the group end timestamp (highest end presentation timestamp) to 1

now for frame with PTS 0:
- steps 1 to 1.3 run normally
- step 1.4 will not apply because GSTS is unset
- step 1.5 will apply because TSO is -1
- step 1.5.1 will change PTS from 0 to -1=0+(-1)
- step 1.5.3 will abort the algorithm because PTS is -1 < presentation start time which is 0

I think this is an error. If this test is not applied, the rest of the algorithm can run and produce the expected result, as follows:
- step 1.7 will apply because last decode timestamp (LDTS) was set for the first append to 0 and -1 < 0
- the "sequence" part of step 1.7.1 will apply and set GSTS to 1=PTS(0)+dur(1)
- step 1.7.6 will loop back to step 1.1
- step 1.4 will apply now that GSTS is set
- step 1.4.1 will now set TSO to 1=1-0
- step 1.5.1 will set the PTS to 1=0+1
and the rest will behave normally.

I think the test in step 1.5.3 is useful but should be applicable only in "segments" mode because in this case, if the PTS is negative it will be detected as a discontinuity by step 1.7 as described above. 

So, I suggest changing changing step 1.4 and 1.5 as follows (or similar):

1.4 If mode equals "sequence" and group start timestamp is set, then run the following steps:
1.4.1 Set timestampOffset equal to group start timestamp - presentation timestamp.
1.4.2 Set highest presentation end timestamp equal to group start timestamp.
1.4.3 Set the need random access point flag on all track buffers to true.
1.4.5 Unset group start timestamp.
1.4.6 Add timestampOffset to the presentation timestamp.
1.4.7 Add timestampOffset to the decode timestamp.
1.5 otherwise if mode equals "segments" and timestampOffset is not 0, then run the following steps:
1.5.1 Add timestampOffset to the presentation timestamp.
1.5.2 Add timestampOffset to the decode timestamp.
1.5.3 If the presentation timestamp or decode timestamp is less than the presentation start time, then run the end of stream algorithm with the error parameter set to "decode", and abort these steps.
Comment 1 Aaron Colwell 2014-04-01 23:20:59 UTC
Changes committed
https://dvcs.w3.org/hg/html-media/rev/d471a4412040

I moved the timestamp check down a few steps. It shouldn't have been a substep of 1.5 anyways since I wanted the code to error out for negative timestamps in ALL cases.