Bug 195911

Summary: [MSE] Use tolerance in eraseBeginTime
Product: WebKit Reporter: Alicia Boya García <aboya>
Component: MediaAssignee: Alicia Boya García <aboya>
Status: RESOLVED FIXED    
Severity: Normal CC: calvaris, commit-queue, jer.noble, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Description Alicia Boya García 2019-03-18 14:12:34 PDT
https://bugs.webkit.org/show_bug.cgi?id=190085 introduced tolerance when erasing frames during the Coded Frame Processing algorithm in such a way that, in files with less than perfect timestamps, a frame existing before after the current append is not erased accidentally due to small overlaps.

This patch takes care of the opposite problem: we don't want an old frame being accidentally NOT erased by a new one with the same timestamps just because these overlaps make highestPresentationTimestamp very slightly higher than the frame PTS.

This bug in practice causes some frames of the old quality to not be erased when the new quality is appended, resulting in some seemingly still frames from a different quality appearing at some points during WebM video in presence of quality changes.

This bug can be reduced to this minimal test case that illustrates the timestamp imprecission of a typical WebM file:

function sampleRun(generation) {
    return concatenateSamples([
        makeASample(     0,      0, 166667, 1000000, 1, SAMPLE_FLAG.SYNC, generation),
        makeASample(167000, 167000, 166667, 1000000, 1, SAMPLE_FLAG.NONE, generation),
        makeASample(333000, 333000, 166667, 1000000, 1, SAMPLE_FLAG.SYNC, generation), // overlaps previous frame
        makeASample(500000, 500000, 166667, 1000000, 1, SAMPLE_FLAG.NONE, generation),
    ]);
}

After appending this twice it would be expected that the second generation takes fully over the first, since the timestamps are completely the same. Due to the bug, sync frames with an overlap, like the third one in that list, actually persist from the first generation, due to lack of tolerance when comparing the start of a new frame with highestPresentationTimestamp.

This patch introduces the tolerance in that case too to fix this problem.
Comment 1 Alicia Boya García 2019-03-18 14:14:23 PDT
Created attachment 365062 [details]
Patch
Comment 2 WebKit Commit Bot 2019-03-19 07:38:50 PDT
Comment on attachment 365062 [details]
Patch

Clearing flags on attachment: 365062

Committed r243138: <https://trac.webkit.org/changeset/243138>
Comment 3 WebKit Commit Bot 2019-03-19 07:38:52 PDT
All reviewed patches have been landed.  Closing bug.
Comment 4 Radar WebKit Bug Importer 2019-03-19 07:39:20 PDT
<rdar://problem/49018494>