Asked video team for help with triaging and whether or not this is a bug.

+foolip@
This was most likely caused by the fix to  crbug.com/403710 .

foolip@: Do you think this is a bug?
The fix consisted in starting to play the video element without waiting for the first video frame. In some cases this means that video size will be zero while audio is already playing. This intended to address problems when the first video frame never came (e.g., because the camera is used by another application).

I guess this is a spec question about the semantics of onplay.

We can change the test to just retry until videoWidth and videoHeight goes nonzero. If we choose that route, you really should inform carefully about this in release notes and on webrtc-discuss as it constitutes a significant change in behavior.

https://codereview.chromium.org/2123133003/ will make the test retry.

According to the spec, we should move to state HAVE_METADATA once we know the dimensions of the video. Thus, I'll revert the fix to  crbug.com/403710  until we are able to find a better solution to the problem of a stream with audio but no video.

https://html.spec.whatwg.org/multipage/embedded-content.html#ready-states

HAVE_METADATA (numeric value 1)
Enough of the resource has been obtained that the duration of the resource is available. In the case of a video element, the dimensions of the video are also available. No media data is available for the immediate current playback position.

Guido and I have discussed and concluded that the root problem here is a mismatch of models. Media elements are (mostly) designed for playback of pre-recorded content over a (TCP) network, so it has only one readyState even though there may be multiple tracks. MediaStreams, on the other hand, have individual tracks with a readyState on each MediaStreamTrack.

In mapping a MediaStream's over readiness to HTMLMediaElement, the choice is to either require all tracks to be ready, or just one. Neither choice is going to always make sense, so at the end of the day some additional bit of API is probably needed. Details very fuzzy.

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

commit 20dbd3b5467a741c7eafe1b1365b0d05361e6bc3
Author: guidou <guidou@chromium.org>
Date: Thu Jul 07 12:35:56 2016

Revert of Do not wait for first video frame to start playing audio in a MediaStream. (patchset #2 id:20001 of https://codereview.chromium.org/2108153002/ )

Reason for revert:
According to the spec, we should switch state to HAVE_METADATA only after we know the dimensions of the video.
See  crbug.com/625943 

Original issue's description:
> Do not wait for first video frame to start playing audio in a MediaStream.
>
> BUG= 403710 
>
> Committed: https://crrev.com/7161bf0bd58551daac1aa486ca9bb13376efbbec
> Cr-Commit-Position: refs/heads/master@{#402845}

TBR=tommi@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 403710 , 625943 

Review-Url: https://codereview.chromium.org/2124013003
Cr-Commit-Position: refs/heads/master@{#404138}

[modify] https://crrev.com/20dbd3b5467a741c7eafe1b1365b0d05361e6bc3/content/renderer/media/webmediaplayer_ms.cc
[modify] https://crrev.com/20dbd3b5467a741c7eafe1b1365b0d05361e6bc3/content/test/data/media/getusermedia.html

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

commit 36b4a432027b5634fce7c4a5566b86694f750ac4
Author: phoglund <phoglund@chromium.org>
Date: Thu Jul 07 13:29:29 2016

Make video quality test fail cleaner if video hasn't started yet.

Video must be playing when the onplay handler gets called, and
the test detects that. This patch makes the test fail faster in
that situation though; it used to return still-capturing up to
timeout when capturing had already failed. This change will
make it immediately return failure.

BUG= 625943 

Review-Url: https://codereview.chromium.org/2123133003
Cr-Commit-Position: refs/heads/master@{#404145}

[modify] https://crrev.com/36b4a432027b5634fce7c4a5566b86694f750ac4/chrome/test/data/webrtc/video_extraction.js

Your change meets the bar and is auto-approved for M53 (branch: 2785)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit f3131b3567fcf1600f7f6ebb44ac56e658ba1b55
Author: Guido Urdaneta <guidou@chromium.org>
Date: Mon Jul 11 15:28:35 2016

Revert of Do not wait for first video frame to start playing audio in a MediaStream. (patchset #2 id:20001 of https://codereview.chromium.org/2108153002/ )

Reason for revert:
According to the spec, we should switch state to HAVE_METADATA only after we know the dimensions of the video.
See  crbug.com/625943 

Original issue's description:
> Do not wait for first video frame to start playing audio in a MediaStream.
>
> BUG= 403710 
>
> Committed: https://crrev.com/7161bf0bd58551daac1aa486ca9bb13376efbbec
> Cr-Commit-Position: refs/heads/master@{#402845}

TBR=tommi@chromium.org
BUG= 403710 , 625943 

Review-Url: https://codereview.chromium.org/2124013003
Cr-Commit-Position: refs/heads/master@{#404138}
(cherry picked from commit 20dbd3b5467a741c7eafe1b1365b0d05361e6bc3)

Review URL: https://codereview.chromium.org/2138813002 .

Cr-Commit-Position: refs/branch-heads/2785@{#80}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/f3131b3567fcf1600f7f6ebb44ac56e658ba1b55/content/renderer/media/webmediaplayer_ms.cc
[modify] https://crrev.com/f3131b3567fcf1600f7f6ebb44ac56e658ba1b55/content/test/data/media/getusermedia.html