error in random access to time observations

[jpiesing]

There is an error in the observations for "random access to time" in 8.4.5.2 due to it referencing 8.2.5.2.

The error concerns video startup delay. The referenced text from 8.2.5.2 is as follows.

Video start-up delay: The start-up delay should be sufficiently low. As user agents may pre-load the first frame, the time to first frame is not relevant, but what is relevant is that once hitting play, the second frame is rendered within the considered start-up delay. In addition, there may be missing frames at start up. Hence, TR [k, x] – Ti < TSMax where x is the first detected frame change after the play() event.

In "random access to time", the time is specified as not being the start of a CMAF fragment. That means the MSE implementation probably needs to find the start of the previous fragment, start decoding there but discard the video until the specified seek time is reached. For this decoding, decoders may be able to decode faster than real time but equally may not.

Hence the permitted video start-up delay needs to be increased by the time from the start of the segment containing random_access_time to random_access_time.

@yanj-github

[jpiesing]

April 10th meeting Example: Assume 2s CMAF fragment size. Seeking to 8s is seeking to the start of a fragment. Seeking to 9s probably means implementations seeking to 8s and playing / discarding the video from 8s to 9s. The decoder startup time needs to take account of the video that is played/discarded. Anything less than realtime should be a pass. Do we have a maintenance issue? I believe the fragment duration is parameterized or communicated from the content.

Next steps: Wait for Resillions input

[yanj-github]

Hi @jpiesing, we need to change OF to measure start up delay differently (or use extended tolerance) for random access to time test. I would suggest to update spec wording so that what is pass and fail is clear. For start up delay in the example, are you saying the detected delay should be compared with TSMax + (9-8)s? For duration it checked against the detected 1st frame to last frame so I think it would not impact. For every sample should be rendered, do we need pass frames between video from 8s to 9s?

[jpiesing]

Hi @jpiesing, we need to change OF to measure start up delay differently (or use extended tolerance) for random access to time test. I would suggest to update spec wording so that what is pass and fail is clear. For start up delay in the example, are you saying the detected delay should be compared with TSMax + (9-8)s?

Yes.

For duration it checked against the detected 1st frame to last frame so I think it would not impact. For every sample should be rendered, do we need pass frames between video from 8s to 9s?

No. Those must be a fail.

[jpiesing]

Here is a proposal for the change to the specification. Add text to 8.4.5.2 as shown in italics.

8.4.5.2 Video

If the track is a video track, then the following additional observations are expected: See clause 8.2.5.2. _Additionally the maximum permitted video start-up delay, TSMax, shall be increased by random_accesstime - tk[k,r].

The following note or some variation on it may also be considered.

NOTE: This enables implementations that start decoding from tk[k,r] at normal speed and discard the decoded data until random_access_time is reached. Since the decoded data is being discarded, implementations decoding at faster than normal speed are also possible.

@haudiobe What do you think of the above? How would you like to improve it?

[jpiesing]

Implemented in Draft-CTA-5003-Ae-v2.04.

[haudiobe]

DPCTF

• proposed implementation is agreed.