Bug 200457 – Adopt -expectMinimumUpcomingSampleBufferPresentationTime:

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

Adopt -expectMinimumUpcomingSampleBufferPresentationTime:

[Jer Noble]

<rdar://problem/53961130>

[Radar WebKit Bug Importer]

<rdar://problem/53964377>

[Jer Noble]

Created attachment 375584 [details]
Patch

[Jer Noble]

<rdar://problem/53961130>

[Eric Carlson]

Comment on attachment 375584 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=375584&action=review

> Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:1279
> +    if (trackID != m_enabledVideoTrackID)
> +        return;

Nit: canSetMinimumUpcomingPresentationTime has already done this check.

> Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:1292
> +    int trackID = trackIDString.toInt();
> +    if (trackID != m_enabledVideoTrackID)
> +        return;

Ditto

[Jer Noble]

Created attachment 375626 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 375626 [details]
Patch for landing

Clearing flags on attachment: 375626

Committed r248301: <https://trac.webkit.org/changeset/248301>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alicia Boya García]

What is this used for? It seems to be accessible from internals only.

And why are these the expected values of internals.minimumUpcomingPresentationTimeForTrackID(sourceBuffer, 1) in the first two cases in the provided test?

[Jer Noble]

(In reply to Alicia Boya García from comment #9)
> What is this used for? It seems to be accessible from internals only.

It's an implementation detail of AVSampleBufferDisplayLayer. I tried to set up SourceBufferPrivate so that other ports wouldn't need to worry about it.

That said, it allows SourceBufferPrivate to be notified about timing of not-yet-enqueued samples. If you have a hypothetical decoder that won't start decoding samples until just before the earliest enqueued PTS, but only has a short sample queue, it's possible that an not-yet-enqueued sample has a lower PTS than all the enqueued ones, and unless the decoder knows about it, it could drop that sample by not decoding other samples in the queue until after that PTS.
 
> And why are these the expected values of
> internals.minimumUpcomingPresentationTimeForTrackID(sourceBuffer, 1) in the
> first two cases in the provided test?

The mock SourceBuffer's queue depth is set to 3, and the first three samples have PTSs of 0, 2, and 3. So the minimum upcoming un-enqueued PTS is 1. After a seek to PTS of 4, the buffer is flushed and the samples re-enqueued, starting at PTSs of 4, 5, and 6. The minimum upcoming PTS is 8. When a sample with a PTS of 7 is appended, that gets re-calculated and the minimum upcoming PTS is 7.