Adopt -expectMinimumUpcomingSampleBufferPresentationTime:
<rdar://problem/53961130>
<rdar://problem/53964377>
Created attachment 375584 [details] Patch
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
Created attachment 375626 [details] Patch for landing
Comment on attachment 375626 [details] Patch for landing Clearing flags on attachment: 375626 Committed r248301: <https://trac.webkit.org/changeset/248301>
All reviewed patches have been landed. Closing bug.
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?
(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.