- From: <bugzilla@jessica.w3.org>
- Date: Fri, 28 Feb 2014 09:49:04 +0000
- To: public-html-media@w3.org
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 on the CC list for the bug.
Received on Friday, 28 February 2014 09:49:05 UTC