I've added a Wireshark log that shows that Chromium on Android is ignoring the 401 Unauthorized response even though the first request from browser did have the credentials. I assume this happens since the Android MediaPlayer is used internally and there simply is no transfer of the credentials from the browser to the MediaPlayer but I could be wrong.

So what happens when I set the the src property of the video element is:

1) I get a request to the correct URL with digest headers and a byte range 0-1, I respond
2) I get a new request to the correct URL without digest parameters that keeps on retrying

Sadly this works fine on Firefox on the same device.

Deleted: chromium_initial_request.jpg 260 KB

	chromium_initial_request.jpg 260 KB View Download

Deleted: chromium_ignore_401.jpg 656 KB

	chromium_ignore_401.jpg 656 KB View Download

If you go into chrome://flags and enable "unified media pipeline" is your issue resolved?

I'll try that tomorrow, but sounds promising. If it does work may I inquire why this is not on by default? Since I assume we then must advise all users of our product to toggle this flag? Is my assumption about the issue being related to the usage of the native Android media player correct?

It's under development now, we hope to make it default sometime during M50, but we want to avoid regressing any of the existing Android playback experiences.

Sadly I dont have this feature available under "chrome://flags" on Chrome 48.0.2564.95 on Android.

What I have in that tab is:

Override software rendering list
Enable experimental canvas features
Disable accelerated 2D canvas
Enable display list 2D canvas
Composited render layout borders
FPS counter
Disable support for WebRTC hardware video decoding
Disable support for WebRTC hardware video encoding
Enable support for WebRTC Stun origin header
Disable WebAudio
Enable fast tab/window close
Disable hyperlink auditing
Enable Contextual Search
Show Autofill predictions
Experimental QUIC protocol
Alternative Services
Disable Media Source API
Disable Encrypted Media Extensions
Enable prefixed Encrypted Media Extensions
Disable latest stable JavaScript features
Enable Experimental JavaScript
Enable GPU rasterization
GPU rasterization MSAA sample count
Enable slimming paint phase 2
Enable experimental Web Platform features
Enable Web Bluetooth
Enable spell checking
Disable touch adjustment
Enable password generation
Enable force-saving passwords
Enable affiliation based matching in password manager
Use Google Payments sandbox servers
Enable large icons on the New Tab page
Touch text selection strategy
Enable navigation tracing
Substring matching for Autofill suggestions
Enable managed bookmarks for supervised users
Enable Google Payments card saving checkbox
Enable Offline Auto-Reload mode
Only Auto-Reload visible tabs
Enable Show Saved Copy Button
Default tile width
Default tile height
Disable gesture requirement for media playback
Enable TCP Fast Open
Spelling Feedback Field Trial
Enable WebGL Draft Extensions
Enable new profile management system
Enable identity consistency between browser and cookie jar
Enable Accessibility Tab Switcher
Enable the Physical Web
Enable zero-copy rasterizer
Disable the pull-to-refresh effect
Enable Enhanced Bookmarks
Reader Mode triggering
Enable Reader Mode Button Animation
Number of raster threads
Enable single-click autofill
Enable Site Engagement Service
Disable support for Cast Streaming hardware video encoding
Prefetch search results
Disable threaded scrolling
Enable EmbeddedSearch API
Enable distance field text
Drop sync credentials from password manager
Autofill sync credential
Enable the experimental Credential Manager API
Reduce default 'referer' header granularity
Credit card scanning
Enable seccomp-bpf renderer sandbox
Enable support for hover capable touchscreens
Fill passwords on account selection
Make non-secure origins as non-secure
Enable out of process iframes
Clear data savings on startup
Allow invalid certificates for resources loaded from localhost
Bypass user engagement checks
Use Chrome Sync sandbox
Enable child account detection
Child account SafeSites filtering
Autofill suggestions as keyboard accessory view
Document scrolling element interoperability
Emphasize titles in the omnibox dropdown
Enable negotiation with DTLS 1.2 for WebRTC
Enable WebVR
V8 caching mode
Enable Clear browsing data counters
Android phone page loading progress bar animation
Enable offline pages
Low priority iframes
Show popular sites on the New Tab page
use Android Midi API
Enable custom layouts for Web Notifications
Disable auto-hiding the toolbar on large tablets

And then there is a list of unavailable experiments, but the unified media pipeline is also not there.

Ok I took the Chromium-Dev app, and that had the flag. Enabling the flag seems to partially help, the authorization headers are now sent, but the playback stalls (however the same stream works on Desktop Chrome). I've attached the the media internals log but I assume this behavior could be related to https://bugs.chromium.org/p/chromium/issues/detail?id=584203.

Deleted: media-internals.pdf 42.0 KB

media-internals.pdf 42.0 KB Download

So I did a little more debugging - it seems that with the unified media pipeline the url plays fine if entered directly into the adrress bar, however when we use it inside a HTML5 video player inside a page and subscribe to HTML5  media events nothing happens.

You can inspect this by opening the url http://mp4durationissue-rudolfsbundulis.rhcloud.com/ in Desktop Chrome and Android Chrome. Desktop Chrome propely triggers events while on Android nothing happens.

Oh sorry I didn't notice what version you were on. You'll need to install "Chrome Dev" for Android to get this feature (or wait for your version to update to 49).

Well that was no big issue, I realized it quite fast. The main question troubling me is why the HTML5 events are not fired because the unified pipeline does not get me much further in the current state.

Whoops, sorry missed your follow up comments when replying. That's very strange that it works on desktop but you're not getting the events on Android (since they should be the same path). It's possible Android's MediaCodec does not like the video for some reason.

=> chcunningham@ since he's looking at the other issue already.

Attaching this image with consoles from both desktop and remote Android Chrome instances. Looking at the man in the video it is visible that the on desktop the file has played fine but on Android it has not even begun even though autoplay is set (hope this image at least helps to provide some proof that the issue is valid).

If there is anything more I can provide I'd be glad to help.

Oh autoplay is disabled on android, so you'll always have to tap play to make it happen. That's  issue 178297 .

Ok, I'll check if a manual trigger of play makes it work on both.

Sorry for the amount of comments but I'd really like to dig to the bottom of this.

I tried calling play() on canplay event but I get the "play() can only be initiated by a user gesture" error in the console. So this means there is no way to automatically make a stream play?

Deleted: gesture_error.jpg 305 KB

	gesture_error.jpg 305 KB View Download

Ok, again, toggling the appropriate flag in chrome://flags solves it.

As long as the unified media pipeline becomes the default setting some time in the future I'm quite happy, but are there any plans to change the need for the user gesture?

As for this bug I guess it can be closed.

Re: #15

> but are there any plans to change the need for the user gesture?

We are actively considering how we can remove the requirement for user gesture. Meanwhile, we did propose adding a Promise<> to the play() call[1] that will ship in M50[2] to ensure that we are closing the feedback loop whenever you call play(). 

[1] https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-play
[2] https://www.chromestatus.com/feature/5920584248590336

Thanks. 

Marking bug as "Won't Fix" as it works as intended today.