Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support playback through unbuffered ranges, and allow app to provide buffered gap tolerance #160

Open
davemevans opened this issue Sep 12, 2016 · 8 comments

Comments

@davemevans
Copy link

commented Sep 12, 2016

In order to support use cases such as trick play, as well as very low latency playback, it may sometimes be useful to be able to allow the media time to keep incrementing at all costs whether or not there is any media to be played.

Ways in which I can imagine this working could be:
a) signal a SourceBuffer as potentially containing sparse data and not to stall the timeline during unbuffered ranges (exact behaviour to be defined eg hold last frame)
b) explicitly 'append' an 'empty' range

I appreciate that this may be better solved by the media element, or at application level, but I think it is at least worth considering in MSE.

I intend this is to be considered a VNext use case.

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

@bbcrddave I understand there is a use-case for this for live services, where the desired behaviour when the buffer runs empty is not to fall behind "real-time" but to pause and then jump forward once new data is available.

But could you elaborate on the trick play and low latency playback use-cases ?

@jyavenard

This comment has been minimized.

Copy link

commented Sep 12, 2016

sounds similar to #21
(and #133)

@davemevans

This comment has been minimized.

Copy link
Author

commented Sep 12, 2016

The 'low-latency' use case is essentially the problem you describe where data may not be available in time for whatever reason and staying at the live edge is deemed more critical than having moving pictures. My choice of words was poor because this isn't about decode latency (so not the same as #21 etc) but staying at the live edge at all times.

For trick play, it may be difficult to download data required to maintain the buffer as playback speed increases. It may be useful to append only some segments (every xth for example), despite the potential UX problems, or even partial segments where possible, and leave gaps in the buffer which are played through.

@wolenetz wolenetz added this to the VNext milestone Sep 12, 2016
@wolenetz

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

Thank you for filing this issue. While partially a duplicate of #133 and #21, I'll keep this one independent in VNext to support the specific use case mentioned here.

@jdsmith3000

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

I think we generally agree there may be a need for low latency. I can also imagine that trick play might benefit from skipping segments during appends, but as you note, the app could probably do this perhaps just as well. Can you provide evidence of issues here that are difficult to solve with the current MSE API?

@chanceym

This comment has been minimized.

Copy link

commented Jan 29, 2018

Using MSE to broadcast live video streams has great potential but lacks some key features that must be addressed to really be a viable solution. First the ability to skip over missing frames (play through gaps) is a key feature that would need to be addressed. Second the ability to append sourcebuffers with video data received from one of many video sources (passing the permission from one participant to another to transmit video), currently I have to tare-down a sourcebuffer and rebuild it every time the video is passed, causing a flash (no desirable). I tried using 'Sequence' mode to solve these issues, but got unexpected video drift that was worse than what I tried to solve.

@wolenetz wolenetz changed the title Support playback through unbuffered ranges Support playback through unbuffered ranges, and allow app to provide buffered gap tolerance Mar 21, 2019
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 21, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}
aarongable pushed a commit to chromium/chromium that referenced this issue Mar 22, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 23, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 24, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991
mykmelez pushed a commit to mykmelez/gecko that referenced this issue Apr 25, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991
mykmelez pushed a commit to mykmelez/gecko that referenced this issue Apr 25, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991
marcoscaceres added a commit to web-platform-tests/wpt that referenced this issue Jul 23, 2019
This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#643473}
@michaeljweaver

This comment has been minimized.

Copy link

commented Jul 26, 2019

@wolenetz do you know if this feature request will be included in the work being done for the referenced #232 ?
That's tracked by https://bugs.chromium.org/p/chromium/issues/detail?id=963717

@wolenetz

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2019

#232 is for modes. This (#160) is to let app see precisely what each SourceBuffer thinks is a gap (perhaps also expanding on that with the ability to inspect buffered ranges at the track level, for instance, for multi-track SourceBuffers), and to let apps specify:

  1. How much tolerance the MSE-extended HTMLMediaElement.buffered will have to be able to coalesce any SourceBuffer gaps (e.g. "play through any gap that is smaller than 0.75 seconds") and not stall,
  2. and/or what HTMLMediaElement playback will do when it encounters a gap (after (1)'s coalescence, if any) with a buffered range later (such as play silence for missing audio, frozen last frame for missing video while letting clock advance at playbackRate? Or seek to the next point where all active tracks have buffered media? Or seek to the earliest next point where an active track has buffered media (e.g. for commonly jagged A/V segment buffered range starts) and play silence/last frame for any other track until it also gets buffered.

This has been discussed multiple times (FOMS 2018, FOMS NYC March 2019, various F2F including recent TPAC Sep 2019 media WG F2F), and will likely become a vNext feature to incubate soon.

gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: fc846bf83bfdae75b97fec2fb139b4b88dc9be7f
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: c679de39ad4dbaafeee76985263d5c11c07de772
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: fc846bf83bfdae75b97fec2fb139b4b88dc9be7f
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: c679de39ad4dbaafeee76985263d5c11c07de772
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: fc846bf83bfdae75b97fec2fb139b4b88dc9be7f
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
…work with MseBufferByPts, a=testonly

Automatic update from web-platform-tests
MSE: Fix mediasource-changetype-play to work with MseBufferByPts

This web-platform-test exercises changeType as it splice-overlaps
pairs of audio or video media streams at varying offsets in the
presentation timeline. Splice-overlapping an out-of-order decode stream
(such as the test AVC MP4 media) at arbitrary times can, per spec, drop
significant decode dependencies from a partially-overlapped GOP such
that a buffered range gap could result.

This change is more careful about where it performs splice-overlaps when
the overlapped media is out-of-order-decode, adjusting the splice point
to be at or very near to the next overlapped keyframe. This prevents
removing out-of-order non-keyframes and their dependents from the
overlapped media such that no buffered range gap nor playback stall
should result.

Note that Chromium is sensitive to such out-of-order buffering overlaps
with the new, compliant, MseBufferByPts behavior. Fixing
w3c/media-source#160 could greatly simplify
this problem by allowing apps to explicitly control how the
user agent behaves at these small gaps.

BUG=807793

Change-Id: I020e244c230756eaa1804f81b58a577124a6a28b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1428601
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#643473}

--

wpt-commits: 27ad6759d421b95b4572f20cabaeb750b3eb9799
wpt-pr: 15991

UltraBlame original commit: c679de39ad4dbaafeee76985263d5c11c07de772
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.