New issue
Advanced search Search tips

Issue 871929 link

Starred by 1 user
Status: Fixed
Owner:
wolenetz@chromium.org
Closed: Aug 7
Cc:
sande...@chromium.org
foolip@chromium.org
wolenetz@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Blink WPT mediasource-changetype-util.js uses "video/<bytestream>;..." for audio codecs/streams

Project Member Reported by wolenetz@chromium.org, Aug 7 
Initially reported in https://github.com/web-platform-tests/wpt/issues/12336

tl;dr: Some user agents ignore codec parameters and use just the mimetype to determine whether or not the type is supported. In FF case, video/webm may be unsupported on slower machine. The fix is simple: make the audio stream mime-type audio/<bytestream> since the test media is all single-track (not muxed AV).
Project Member

Comment 1 by bugdroid1@chromium.org, Aug 7 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf7763086306bb1af0edb891b5f7c7c8096620ca

commit bf7763086306bb1af0edb891b5f7c7c8096620ca
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Tue Aug 07 22:26:43 2018

MSE: Make changeType-play layout tests' audio mime-type be audio-specific

If using video/webm for an audio codec/stream, some user agents will say
the type is unsupported where otherwise it would be if it were
audio/<bytestream-format> for the same codec/stream.

This change makes the types in audio test metadata match the stream types
more closely (audio/webm;... and audio/mp4;...).

This change also includes a drive-by comment addition to help ensure the
audioOnlyTypes in mediasource-util.js remain correct relative to
the changeType tests' assumptions that none of the audioOnlyTypes
generate timestamps automatically.

BUG= 871929 
WPT issue https://github.com/web-platform-tests/wpt/issues/12336

Change-Id: I768035b817ad46f9f17f7dc681c3f9f5c1dad8e4
Reviewed-on: https://chromium-review.googlesource.com/1166030
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581369}
[modify] https://crrev.com/bf7763086306bb1af0edb891b5f7c7c8096620ca/third_party/WebKit/LayoutTests/external/wpt/media-source/mediasource-changetype-util.js
[modify] https://crrev.com/bf7763086306bb1af0edb891b5f7c7c8096620ca/third_party/WebKit/LayoutTests/external/wpt/media-source/mediasource-util.js

Comment 2 by foolip@chromium.org, Aug 7 

Thank you wolenetz@ for tackling that, and so fast :)

Comment 3 by wolenetz@chromium.org, Aug 7 

:)

Regarding the travis-ci error upstream at https://github.com/web-platform-tests/wpt/pull/12345, can it be rerun? I think the getvideoplaybackquality failure is unrelated and that test may perhaps be flaky on FF.

Comment 4 by wolenetz@chromium.org, Aug 7 

Ah - I see the Chromium CL's merge triggered another round upstream of the travis-CI checks, currently in-progress. If they fail, what's the mechanism to trigger yet another round of checks?

Comment 5 by foolip@chromium.org, Aug 7 

If you have write access to a repo you can also restart Travis jobs. You do have write access so you should be able to follow the link to Travis, log in with your GitHub account, and then restart there.

Comment 6 by wolenetz@chromium.org, Aug 7 

@#5 thank you, apologies if that was FAQ :)

Comment 7 by wolenetz@chromium.org, Aug 7

Status: Fixed (was: Started)
Closing this. May reopen if the upstream issue wasn't fixed by this CL (eg if travis-ci was truly regressed by it, or if the CL didn't fix the issue FF reported).
►

Sign in to add a comment