I can confirm the video is "playing" but all black (as opposed to not playing at all). I can tell because (1) the device won't sleep and (2) the speaker icon appears in the notification area (which, by the way, is another bug, since this video has no audio track, and by no audio track I mean no audio track, not a silent audio)

Hello

Thanks for reporting the issue. We tested this issue on Nexus 5 and your above mentioned 1st scenario, "The first time I hit the play button...back again to a play button," does happen partially but the video does play. The second time the play button is shown in scenario 1, it's grey and the video plays which is all black. 

Can you please attach a bugreport/logcat for the issue? Also, please provide your device details.

> "The first time I hit the play button...back again to a play button," 
> does happen partially but the video does play.

Do you mean you see it white? Because the video is white. 
How long does it play for? The video is 15 seconds long. Maybe we are observing the same thing, only that it's so fast (it plays for a fraction of a second) that it doesn't give me time to realize the video is playing for an instant?
Either way, this behavior is wrong. The video is looped, so it should play forever. Whether it plays for its entire duration or less, it's wrong.


> The second time the play button is shown in scenario 1, 
> it's grey and the video plays which is all black.

If you see it all black, then it's wrong, because the video is all white. So, it seems you are observing the same as me, or in any case, a completely wrong behavior pretty similar to what I observe.

So, I don't get why you need a bugreport/logcat from me, since yours should allow you to investigate the issue pretty much the same as mine.

I will attempt to provide that if I have time to, but I strongly suggest to remove the "needs feedback" status.

I am able to repro this bug. the repro video is at here http://matteosistisette.com/test/stupidchrome/mp4/white.mp4
the behavior on desktop and Android is different. 
However it not repro after enable new rendering. So I think we don't need worry about it.

What do you mean by "enable new rendering"?

@matteo...: do you know how the mp4 file was constructed?

i'm able to repro this on my nexus 5 -- press play, see a black box.  i don't see anything unusual with the play / pause button.  it switches to 'play' and plays at least until the controls fade out a few seconds later.  it does not loop.

from the logs, it tries to play for 30 frames, then fails.  i'm using the unified media pipeline (== "new rendering" in the above discussion), which has a two second deferral or so before signalling the error to higher layers.  that accounts for the difference in the play button behavior -- three seconds is the fade-out time for the controls.  :)

here are some relevant bits from logcat:

I/OMX-VDEC-1080P(  192): component_init: OMX.qcom.video.decoder.avc : fd=22
I/OMX-VDEC-1080P(  192): Capabilities: driver_name = msm_vidc_driver, card = msm_vdec_8974, bus_info = , version = 1, capabilities = 4003000
I/OMX-VDEC-1080P(  192): omx_vdec::component_init() success : fd=22
E/        (  192): not in avi mode

(lots of "not in avi mode" messages)

E/OMX-VDEC-1080P(  192): Input bitstream error for consecutive 30 frames.
E/OMX-VDEC-1080P(  192): 
E/OMX-VDEC-1080P(  192): ERROR: Sending OMX_EventError to Client
E/ACodec  (10159): [OMX.qcom.video.decoder.avc] ERROR(0x80001009)
E/ACodec  (10159): signalError(omxError 0x80001009, internalError -2147483648)
E/MediaCodec(10159): Codec reported err 0x80001009, actionCode 0, while in state 6
E/cr_media(10159): Failed to dequeue output buffer
E/cr_media(10159): java.lang.IllegalStateException
E/cr_media(10159): 	at android.media.MediaCodec.native_dequeueOutputBuffer(Native Method)
E/cr_media(10159): 	at android.media.MediaCodec.dequeueOutputBuffer(MediaCodec.java:1033)
E/cr_media(10159): 	at org.chromium.media.MediaCodecBridge.dequeueOutputBuffer(MediaCodecBridge.java:412)
E/cr_media(10159): 	at org.chromium.content.app.ContentMain.nativeStart(Native Method)
E/cr_media(10159): 	at org.chromium.content.app.ContentMain.start(ContentMain.java:25)
E/cr_media(10159): 	at org.chromium.content.app.ChildProcessService$2.run(ChildProcessService.java:197)
E/cr_media(10159): 	at java.lang.Thread.run(Thread.java:818)
I/NotificationService(  807): cancelToast pkg=org.chromium.chrome callback=android.app.ITransientNotification$Stub$Proxy@42c2744
W/NotificationService(  807): Toast already cancelled. pkg=org.chromium.chrome callback=android.app.ITransientNotification$Stub$Proxy@42c2744
E/chromium( 5589): [ERROR:render_media_log.cc(21)] MediaEvent: PIPELINE_ERROR pipeline: decode error
W/cr_media(10159): calling MediaCodec.release()

> @matteo...: do you know how the mp4 file was constructed?

With this: ffmpeg -loop 1 -i white.png -c:v libx264 -t 15 white.mp4

where white.png was a 50x50px all-white png.

@matteo...: "enable new rendering": go to about://flags, search for 'enable unified media pipeline'.  note that one needs ~m50 chrome for this to be a useful thing to do.

my repro in c#6 was with the unified pipeline enabled on my N5, though.

@yiningc: what device did you use in c#4 when it worked?

starting M50, there is a flag available in chrome://flags "Enables the unified media pipeline on Android". Starting M51, this feature is enabled by default.
Enabling the unified media pipeline will improve Chrome media playback experience on Android. This bug is fixed by enabling unified media pipeline. 

> This bug is fixed by enabling unified media pipeline. 

Not according to comments 6 and 8

yiningc@: it sounds like this is device specific and is broken with the unified meida pipeline on some devices.

On my huawei mediapad without unified pipeline I get a black frame.

With unified pipeline I get a white frame but when I press play the pause button hangs around forever. Not sure why.

On my N5 I see:

04-12 15:04:24.398   207   207 E OMX-VDEC-1080P: Unsupported WxH = (50)x(50) supported range is min(64)x(64) - max(3840)x(3840)

So the h264 decoder on my N5 has a min supported size of 64x64.

Apart from that there's another problem: the video is encoded with profile: h264 High 4:4:4 which is not supported on many devices. See http://developer.android.com/guide/appendix/media-formats.html

If you want a workaround, you could try encoding it using h264 baseline and make it 64x64.

The behavior is still stupidly inconsistent.

- see the erratic behavior of the play/pause button as described in my original report and some other comments
- if a video cannot be decoded, probably an error message should be displayed 
(at the very least to the "console"). Even if that were not the case (not sure what the html specs say), having the controls behave as if the video was playing while an all-black rectangle is shown, is certainly not an acceptable behavior.
- the speaker indicator in the notification area while there's no audio stream is ridiculous.

1) This gets better with the unified media pipeline so it will improve in the coming Chrome releases. If there's a decode error the controls will remain active intentionally in case the error was a transient failure and the user wants to retry.
2) chrome://media-internals should have a message saying there was a decode error (media-internals is unified pipeline only).  There is ongoing work to log errors to the console as well.
3) I don't see this behavior with the unified pipeline. Do you see it with other videos that don't have audio?