[Bug 24854] New: [MSE] Coded Frame Algorithm and erroneous abort case

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

            Bug ID: 24854
           Summary: [MSE] Coded Frame Algorithm and erroneous abort case
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: cyril.concolato@telecom-paristech.fr
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

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.

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

Received on Friday, 28 February 2014 09:49:05 UTC