http://go/chrome-androidlogs1/6/642988

Added files:
Playyoutube.log
playYoutube.mp4

I don't think  you can enable Spitzer on JellyBean devices at present. Do you mean it plays when you disable Spitzer in M52/M53? This should be the default state actually.

What is version of the device that you can reproduce this issue on? Seems like this might be another instance of YouTube serving 3gp/mpeg4 to Chrome 52+. +strobe.

ramine: Can you post the user agent of the device?

Uploaded user agent screen shot at:
http://go/chrome-androidlogs1/6/642988

Device:Samsung Galaxy Tab 3
Android version: KOT49H

Oh, so this is running Kitkat.

Can you please capture the media-internals for this player. Close all tabs, open a tab and repro the issue, open a new tab to chrome://media-internals, click the button for the youtube.com player and screenshot the log. 

Added log file: 642988.log and playerInfo.log

http://go/chrome-androidlogs1/6/642988 as requested.

Great, thanks. So this is src= h264. It should work and it plays fine on my N6.

Could this be related to issue 643721?

I don't see this issue on Nexus7(tablet)+Android 4.4.4. There is no problem to play youtube free video or paid video.

-rvg since it doesn't matter.

i don't see any attempt to get a 264 decoder in the log.  just a vorbis decoder and an encoder.

seems like AVDA didn't try, or the log snippet missed it.

similar issue on Galaxy tab 4 7.0 Nook (KOT49H) running Chrome "54.0.2840.18"

Can you capture the chrome://media-internals for that device when playback fails?

Please find mediaInternals.txt  @

http://go/chrome-androidlogs1/6/642988

Hmm, this is strange we'll need to borrow one of those devices to get a closer look. timav@ do you have any time to look into this? If not can you mail one of those devices to Seattle for a little while?

Actually looks like I can order one for $79 and have it here by monday, will just do that.

If I can't repro it'd be nice if timav@ can poke at the device if he has time :)

Sorry, earliest can be Monday...

Hmm, Galaxy Tab 3 came in w/ JellyBean and YouTube plays fine. timav@ can you take a look when you have a chance?

I will take a look when I get device(s).

Accelerated video decode is disabled on this device in software-rendering_list_json.cc "MediaCodec on Vivante hangs in MediaCodec often"
https://cs.chromium.org/chromium/src/gpu/config/software_rendering_list_json.cc?rcl=0&l=1169

From chrome://gpu:
OS: Android 4.4.2
Vendor - 0x0 [Vivante Corporation], Device=0x0 [Vivante GC1000]

How are we supposed to play H264?

Hmm, are we reporting support for it in canPlayType/isTypeSupported? I would expect this device to fallback to WMPA for src= and report H264 unsupported for MSE.

The flag switches::kDisableAcceleratedVideoDecode is set, you were right, and thus media::HasPlatformDecoderSupport() returns false.

In the test the h264 url looks like this:
url:https://r6---sn-n4v7sn7s.googlevideo.com/videoplayback?requiressl=yes&signature=BA91DACC4631B19F985E0419FA29135BF3FDA666.47E2884D3EB205E5764FA8F3E1871BFB10B92C81&sver=3&mn=sn-n4v7sn7s&mm=31&id=o-AJQoUE5mgESq7cvC3lH4NfxhibhQD42Q33N_8_7EdF3X&lmt=1473745788638769&ip=2620%3A0%3A1000%3Afd1f%3Ad452%3Af5a2%3A6d77%3A8197&pl=50&dur=193.886&mv=m&source=youtube&ms=au&ei=eEzYV9iNJonX-gP6orjwBg&sparams=dur%2Cei%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&expire=1473814744&upn=8RxLySBBdng&key=yt6&mt=1473792533&ipbits=0&initcwndbps=8972500&mime=video%2Fmp4&itag=18&ratebypass=yes&cpn=HbVri1WMPk1bwvgY

The function UseWebMediaPlayerImpl()
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?rcl=0&l=800
only consults it, however, if the url ends up with ".mp4". After that suffix test the YouTube played the video (with WMPA).

It seems we do analyze the actula stream type from the leading bytes, only later, in MultibufferDataSource here:
https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?rcl=0&l=370  ?

Oops, sorry, it should be "After that suffix test is removed the YouTube played the video"

Also, I did not find canPlayType/isTypeSupported or what role do they play, please send a link.

Yeah that's what I was afraid the issue might be. I think the !HasPlatformDecoderSupport and contains(mp4) is rare enough that we should be able to just do that. We'll be replacing that with tguilbert@'s Mojo Media Player soon anyways.

If HasPlatformDecoderSupport() is false, isTypeSupported() and canPlayType() should correctly report false; that code is here:
https://cs.chromium.org/chromium/src/media/base/mime_util_internal.cc?l=536
https://cs.chromium.org/chromium/src/media/filters/stream_parser_factory.cc?l=346

Can you double check what the result of document.createElement('video').canPlayType('video/mp4') is on this device? If it's what I think it is, it looks like YouTube doesn't check canPlayType() for h264 when falling back to their older player. Possibly because they don't have a non-h264 stream for this clip.

document.createElement('video').canPlayType('video/mp4') returns "maybe" when I do it in the inspection console.

Hmm, that's not correct. It should be returning false in this case; see line 605 in mime_util_internal.cc. Can you add some logging there to see what value it thinks it has for has_platform_decoders? It's possible this is being initialized too early (it's a singleton).

Actually I guess that doesn't specify a codec, so maybe might be an okay response. How about 'video/mp4; codecs="avc1"' ?

+ddorwin for commentary on c#28, c#29.

I'd guess if c#29 returns false that YouTube isn't querying with codecs.

I wonder if we should add MimeUtil::H264 as the default codec for video/mp4.

https://cs.chromium.org/chromium/src/media/base/mime_util_internal.cc?l=785

#29: empty string, which means false and is expected, I guess.

#27: This is expected. We support the container.

#29: 'video/mp4; codecs="avc1"' isn't really valid and will at best return "maybe". Use "avc1.42E01E" instead. (Not really relevant here, but FYI)

#32: I don't think we should change the overall behavior since that is not really specified anywhere. However, we could change specific checks for handling, for example, blacklisting to also check for H.264. (I don't think that applies in this case, though.) We could also check whether _any_ video codecs supported in MP4 are available, but this would be an intervention and probably still not strictly spec-compliant. (In theory, there could be metadata, though maybe 'audio/mp4' would be more appropriate.)

#34: This is unexpected for me. H.264 decoding is supported (by WMPA) and canPlayType() is effectively for src= playback. We are currently telling any app that is correctly checking for the codec that this device cannot play H.264, likely meaning the user will not get any video. As demonstrated by the original bug, though, H.264 is *not* guaranteed to be supported since we depend on the URL. Thus, returning "" may be more correct. Also, if we do make a change, we need to ensure that MSE continues to return false. See issue 587303 for the interaction with MimeUtil.

Even if we make such changes, I don't think that will resolve the original issue. We could come up with YouTube-specific fixes, and that might be sufficient, but it would be better if we could make Chrome correctly handle this without relying on the extension.

#34: I meant "expected" in reply to #28, Dale expected it to return false.

#35: Thank you for the explanation. I see that ideally we should return "probably" for H.264. It seems for this we need to determine the proper type of the stream before switching between WMPI and WMPA, which is not a small refactoring?

Thanks David. I think the two changes we should make are:
1. Change UseWebMediaPlayerImpl() to use contains(). This is low impact since most devices have platform codecs.
2. Change IsCodecSupportedOnPlatform() to always return true for H264; this doesn't affect MSE since it uses its own checks in StreamParserFactory.

As a clarification does the spec actually say that we should report maybe for a supported container with no supported codecs? I.e. it's precise about the definition of support meaning it can be demuxed versus demuxed and decoding?

As long as #2 doesn't affect EME, which cannot use WMPA. I'd feel better if we could limit this to the WMPA fallback logic somehow.

https://html.spec.whatwg.org/multipage/embedded-content.html#dom-navigator-canplaytype says:
>The canPlayType(type) method must return the empty string if type is a type that the user agent knows it cannot render...; it must return "probably" if the user agent is confident that the type represents a media resource that it can render if used in with this audio or video element; and it must return "maybe" otherwise.

Without knowing the codec, I don't think the UA can be confident that it can render the resource. I don't think the UA can know that it cannot render it either. Thus, "otherwise."

Ah good point on EME, change #2 above should instead be if (!is_encrypted) return true else return has_platform_decoders.

Well, h264 is the only video codec we support in mp4 (at least today), so by that statement it sounds like we should say it's unsupported.

What if an app used "video/mp4" for an audio-only file or an audio file with timed text? (I'm not sure that's legal/recommended or likely, but it's something to consider.)

If you did go that route, I'd recommend checking all MP4 video codecs rather than specifically checking H.264. (As a practical matter, there will be another video codec soon:  issue 580623 .)

That seems like audio/mp4, but I see your point. The other fixes seem sufficient for now then -- I'll see what YT thinks about specifying a codec when they run these checks.

timav@ feel free to make the changes recommended above or assign back to me and I'll pick it up this week.

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

commit 8cda8cd5f2766bb31636ebba30fca01d64d97f46
Author: timav <timav@chromium.org>
Date: Fri Sep 16 20:32:48 2016

Look into full URL spec to see whether it is MP4

On certain Android devices MediaCodec is blacklisted.
To support H264 we fall back to MediaCodec, and we
decide whether this is H264 by looking at URL.

This CL improves that decision making: before we only
checked whether the path suffisc was ".mp4", now we look
for "video/mp4" in the whole URL spec as well.

In addition this CL makes canPlayType() return
"probably" for H264 codec.

BUG= 642988 

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

[modify] https://crrev.com/8cda8cd5f2766bb31636ebba30fca01d64d97f46/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/8cda8cd5f2766bb31636ebba30fca01d64d97f46/media/base/mime_util_internal.cc

timav@ merge?

Oops, sure

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

commit f2d0438963f2df69d0ebc397a76270af8ef93052
Author: Tima Vaisburd <timav@chromium.org>
Date: Mon Sep 19 23:41:58 2016

[Merge M54] Look into full URL spec to see whether it is MP4

On certain Android devices MediaCodec is blacklisted.
To support H264 we fall back to MediaCodec, and we
decide whether this is H264 by looking at URL.

This CL improves that decision making: before we only
checked whether the path suffisc was ".mp4", now we look
for "video/mp4" in the whole URL spec as well.

In addition this CL makes canPlayType() return
"probably" for H264 codec.

BUG= 642988 
TBR=timav

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

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

Cr-Commit-Position: refs/branch-heads/2840@{#431}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/f2d0438963f2df69d0ebc397a76270af8ef93052/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/f2d0438963f2df69d0ebc397a76270af8ef93052/media/base/mime_util_internal.cc

Verified fix in '54.0.2840.33' chrome beta on Galaxy Tab 4 7 and Galaxy Tab 3 /KOT49H

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

commit f2d0438963f2df69d0ebc397a76270af8ef93052
Author: Tima Vaisburd <timav@chromium.org>
Date: Mon Sep 19 23:41:58 2016

[Merge M54] Look into full URL spec to see whether it is MP4

On certain Android devices MediaCodec is blacklisted.
To support H264 we fall back to MediaCodec, and we
decide whether this is H264 by looking at URL.

This CL improves that decision making: before we only
checked whether the path suffisc was ".mp4", now we look
for "video/mp4" in the whole URL spec as well.

In addition this CL makes canPlayType() return
"probably" for H264 codec.

BUG= 642988 
TBR=timav

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

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

Cr-Commit-Position: refs/branch-heads/2840@{#431}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/f2d0438963f2df69d0ebc397a76270af8ef93052/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/f2d0438963f2df69d0ebc397a76270af8ef93052/media/base/mime_util_internal.cc