On videojs.com the controls on the first user example (The Onion), which uses default controls, look more normal, however the cast button is disappearing a few seconds after the page loads. If, however, I am quick enough I can successfully cast this video.

The disappearance of the Cast button is also new behaviour, so is probably related to the problem on our test page.

Note, that the correct link is crhtmltest.appspot.com/static/video.html (without the 's' after 'html')

+Frank

the incomplete controls are a result of HTMLMediaElement believing that the media cannot be played.  it defaults to a grayed-out play button and empty timeline.  the question is why it can't play.  i'm not aware of any changes that would cause it.

i didn't see this behavior on my N5 with c1a3d8.  it played fine.

please check about://flags to see if 'enable unified media pipeline' is enabled or not.  if not, then please enable it.

once it's enabled, please try again to play.  assuming that it fails, open a new tab with chrome://media-internals and click on the player link.  that will give us some idea about the state of the media pipeline.

As expected, enabling unified media pipeline made no difference.

chrome://media-internals doesn't show any players.

Note that on at least some other pages (e.g. http://mounirlamouri.github.io/sandbox/media-focus.html) everything works fine. For media-focus.html I am seeing players in chrome://media-internals.

Seems like Mounir's page works because it has fallback links to .webm videos (unlike the crhtmltest page). Anything changed recently to stop playing .mp4s?

no changes come to mind that would affect both he old and new pipelines.

that it doesn't work either with or without the unified pipeline, and that it's limited to h264, suggests that it's mediaserver.  the controls behavior would show up if we're getting (e.g.) a state changed back from the web media player indicating that the WMP failed.  it will reset the ui, including clearing the cast button, and continue resource selection.

anything interesting in logcat?  that will tell us if mediaserver is happy or not.

The only potentially interesting things I can see are some messages about missing Android methods:


03-15 16:52:32.061 14825 14838 I dalvikvm: Could not find method android.media.MediaCodecInfo$CodecCapabilities.isFeatureSupported, referenced from method org.chromium.media.MediaCodecUtil.codecSupportsAdaptivePlayback
03-15 16:52:32.061 14825 14838 W dalvikvm: VFY: unable to resolve virtual method 971: Landroid/media/MediaCodecInfo$CodecCapabilities;.isFeatureSupported (Ljava/lang/String;)Z
03-15 16:52:32.061 14825 14838 D dalvikvm: VFY: replacing opcode 0x6e at 0x001e
03-15 16:52:32.061 14825 14838 I dalvikvm: Could not find method android.media.MediaCodecList.<init>, referenced from method org.chromium.media.MediaCodecUtil.getEncoderColorFormatsForMime
03-15 16:52:32.061 14825 14838 W dalvikvm: VFY: unable to resolve direct method 976: Landroid/media/MediaCodecList;.<init> (I)V
03-15 16:52:32.061 14825 14838 D dalvikvm: VFY: replacing opcode 0x70 at 0x000b

The complete logcat for loading the page is attached.

Deleted: logcat.txt 22.3 KB

logcat.txt 22.3 KB View Download

+dalecurtis@chromium.org - removed accidently.

cc:timav, jbudorick@: looks like another case of missing .dex files. We're not sure why this is happening.

This shouldn't be a multidex issue for a couple of reasons:
 - android.media.MediaCodecInfo is a system class?
 - on L+, the platform loads all dexes

MediaCodecInfo is a system class, and MediaCodecInfo$CodecCapabilities.isFeatureSupported is from KK.  weird.

does this happen with the latest canary?  i.e., something not built locally?

I have only seen it with a local build, however the I don't think the canary is new enough; this only started happening when I synced yesterday evening (yesterday morning MTV time) and I had certainly synced on Friday, and possibly earlier on Monday.

Assigning to Dale for triaging and to get more attention :)

abarent: Can you reimage this device? As c#15 and c#16 indicate these are system level classes that are not being found. Are you building with GN or GYP?

also, though we missed a canary, trying with the latest one is still a good idea.

I don't think it is likely to be a device issue; we have seen it on three different devices; an N5 running Android L, an N7 running JB, and one of avayvod@'s devices (I think an N5).

I will, anyway, try reimaging one of these and let you know the result.

I have just discovered that local Linux builds have exactly the same problem, so this certainly isn't a device problem.

It does, however, work on the latest Canary on Android (51.0.2677.0).

crhtmltest works correctly on an Official Chrome build on both Linux and Android. videojs works correctly on an Android Official build, and was never broken on Linux. 

I don't know if crhtmltest ever worked on non-Official builds on Linux.

As such it seems very likely that this was caused by https://codereview.chromium.org/1577433004.

Removing OS-Linux, and reducing priority, but leaving open since we may want to fix https://crhtmltest.appspot.com/static/video.html

Ah yes, you'll need to set proprietary_codecs=true, ffmpeg_branding="Chrome" if you want h264/mp4 support in Chrome on Android now -- this matches the standard Chromium experience.

Does cast support casting vp8/vp9 .webm files? If so we should update the code to support those. I'm hitting this issue too while trying to sanitize the code base of h264/mp4 streams. MediaResourceUrl doesn't consider .webm to be castable IIUC.

> MediaResourceUrl doesn't consider .webm to be castable IIUC.

We should fix that. Cast does support vp8 Webm, but apparently not vp9.

See https://developers.google.com/cast/docs/media

MediaUrlResolver is what I meant actually, but my point stands :)

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/android/java/src/org/chromium/chrome/browser/media/remote/MediaUrlResolver.java&l=233 

Actually Clank will attempt to cast unknown types, the only things it does with the media type are recording statistics and checking that certain known types have CORS headers, so this should not be a problem (although we probably should recognise more types for the statistics).

See MediaUrlResolver.canPlayMedia() ( https://code.google.com/p/chromium/codesearch#chromium/src/chrome/android/java/src/org/chromium/chrome/browser/media/remote/MediaUrlResolver.java&l=196)

Ah, so it shouldn't be an issue then. I'll double check my test changes.

Closing as WontFix given that this is WAI.