Forgot to attach these screenshots.

Deleted: Screen Shot 2017-03-24 at 12.22.33 PM.png 317 KB

	Screen Shot 2017-03-24 at 12.22.33 PM.png 317 KB View Download

Deleted: Screen Shot 2017-03-24 at 12.22.59 PM.png 168 KB

	Screen Shot 2017-03-24 at 12.22.59 PM.png 168 KB View Download

@Reporter : Thanks filing the issue.We are unable to access the provided URL in comment #0.Could you please provide the valid URL of the issue and elaborate the  step #1 which would help us to triage the issue further.

Thank You!

That sounds like a WontFix but I'm not 100% sure I understood the issue. My understanding is that you are expecting the error event to have a `MediaError` instance. Though, this is not correct per spec. The error event is a regular event. However, the `error` property of the media element should contain the details of the error. In other words, you should be able to do something like:
```js
media.addEventListener('error', e => {
  this.error; // contains the `MediaError`
});
```

Just now noticed, that I didn't pass along the right jsfiddle link and I am not sure about the details of the error event anymore. Let me see if I can get an updated resource URL and reproduce the issue in a fresh fiddle.

So, here's the updated fiddle: https://jsfiddle.net/puka3fr5/
The MediaError is indeed populated correctly. I am not quite sure what haze I was in when originally reporting this bug. That said, the problem that the video does not seem to be playing with "Media Source not supported"-error remains. I'd like to understand what exactly seems to be tripping Chrome here.

The dev tools show a 403 on the video request. Is it because some time passed (and sorry about this) or could that be the reason of the failure?

Yes, the URL will expire. I updated the fiddle with a refreshed URL, that reproduces the issue:
https://jsfiddle.net/dbaulig/puka3fr5/1/

In the original post, media-internals shows at least basic information about why MEDIA_ERR_SRC_NOT_SUPPORTED is emitted:

> error: audio decoder initialization failed
> pipeline_error: decoder: not supported

Tip-of-tree Chrome now contains MediaError.message (as of last Friday), to help expose that information to web apps for aggregation. As to the underlying cause of the decode error, I'll see if I can get more info on that now.

Error 403 is occurring now on the video request for the fiddle in #10, too.

Because of the 403 (#12), I'm not getting the same repro:

In ToT Chrome, I get the 403, with resulting error event: MediaError {code: 4, message: "MEDIA_ELEMENT_ERROR: Format error"}

This is because the media pipeline encountered an error before successfully loading enough to reach HAVE_METADATA (sensibly due to the 403).

Please share a stable URL or fiddle that yields the original repro so we can help investigate the underlying decode error on the stream.

I am already working on getting a new URL. Note that it will be impossible to provide a "stable" URL. Those URLs will expire within approximately 24 hours. I can provide the file instead if that is preferred.

And yes, the 403 response of an expired URL will not contain any media data.

I think the original decode error was due to the bytestream, so yes, if you could provide the file, that would probably be best.

Here's a new URL: https://scontent-sea1-1.xx.fbcdn.net/v/t42.1790-29/18098279_214213002400692_5342188538760790016_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InNkIn0%3D&_nc_log=1&oh=4010b33d5d71ae75b07dcb8aa0b2e6a3&oe=590019C9
Here's the updated fiddle: https://jsfiddle.net/dbaulig/puka3fr5/3/
I'll attach the file.

Deleted: 18098279_214213002400692_5342188538760790016_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InNkIn0%3D&_nc_log=1&oh=4010b33d5d71ae75b07dcb8aa0b2e6a3&oe=590019C9 7.1 MB

18098279_214213002400692_5342188538760790016_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InNkIn0%3D&_nc_log=1&oh=4010b33d5d71ae75b07dcb8aa0b2e6a3&oe=590019C9 7.1 MB Download

@#16, I have a successful repro using the new fiddle on linux. With tip-of-tree Chrome:
MediaError code: 4 message: "DECODER_ERROR_NOT_SUPPORTED: audio decoder initialization failed"

media-internals player log:
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 03	url	https://scontent-sea1-1.xx.fbcdn.net/v/t42.1790-29/18098279_214213002400692_5342188538760790016_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InNkIn0%3D&_nc_log=1&oh=4010b33d5d71ae75b07dcb8aa0b2e6a3&oe=590019C9
00:00:00 553	total_bytes	7424647
00:00:00 553	streaming	false
00:00:00 553	single_origin	true
00:00:00 553	passed_cors_access_check	false
00:00:00 553	range_header_supported	true
00:00:00 665	pipeline_state	kStarting
00:00:00 998	info	FFmpegDemuxer: created video stream, config codec: h264 format: 2 profile: h264 main coded size: [576,360] visible rect: [0,0,576,360] natural size: [576,360] has extra data? true encrypted? false
00:00:01 00	info	FFmpegDemuxer: created audio stream, config codec: aac bytes_per_channel: 4 channel_layout: 3 samples_per_second: 48000 sample_format: 6 bytes_per_frame: 8 seek_preroll: 0ms codec_delay: 0 has extra data? true encrypted? false
00:00:01 02	audio_channels_count	2
00:00:01 02	audio_codec_name	aac
00:00:01 02	audio_sample_format	Float 32-bit planar
00:00:01 02	audio_samples_per_second	48000
00:00:01 02	bitrate	522370
00:00:01 02	found_audio_stream	true
00:00:01 02	found_video_stream	true
00:00:01 02	height	360
00:00:01 02	max_duration	113.774
00:00:01 02	start_time	0
00:00:01 02	time_base	1/90000
00:00:01 02	video_codec_name	h264
00:00:01 02	video_format	PIXEL_FORMAT_YV12
00:00:01 02	video_is_encrypted	false
00:00:01 02	width	576
00:00:01 02	duration	113.774
00:00:01 11	error	audio decoder initialization failed
00:00:01 96	pipeline_error	DECODER_ERROR_NOT_SUPPORTED
00:00:01 98	pipeline_state	kStopping
00:00:01 99	pipeline_state	kStopped

Chrome should support AAC stream playback inside of MP4 containers, correct? What exactly is problematic about this stream?

With a local Debug build of tip-of-tree Chrome on linux, I see the following:
[1:14:0424/114403.799766:ERROR:ffmpeg_audio_decoder.cc(349)] Audio configuration specified 2 channels, but FFmpeg thinks the file contains 1 channels

Daniel, please take a look at the media - it appears even with ffprobe that ffmpeg thinks it is stereo, but upon actual decode attempt, it determines differently. Does this file work on other browsers or media players? Does it work on older Chrome versions?

+dalecurtis@/tguilbert@ in case there's something recently changed around channel mapping/ffmpeg, though due to lack of other similar reports, I suspect the stream itself.

(I've also filed  bug 714730  to help identify this root cause in future without needing a Debug build..)

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

commit 854dede8e4cb7885e803e9e7f3223f00e89a6d38
Author: wolenetz <wolenetz@chromium.org>
Date: Mon Apr 24 22:01:07 2017

MEDIA_LOG FFmpegAudioDecoder::ConfigureDecoder() channel mismatch

 Bug 705038  encountered a case where such channel mismatch occurred, but
logs were insufficient in a release build. This change makes a previous
DLOG instead do a MEDIA_LOG(ERROR) for this specific case.

BUG= 714730 , 705038 

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

[modify] https://crrev.com/854dede8e4cb7885e803e9e7f3223f00e89a6d38/media/filters/ffmpeg_audio_decoder.cc

Glancing at ffmpeg trace for the file, it looks like possibly the channel count in the stsd (2)[a] conflicts with the channel count in the MPEG-4 specific parse later (1)[b]. This appears to resurface later when Chrome attempts to configure the decoder.

FFmpeg maintains internally a decoder context associated with the stream, and when it signalled the context being opened to Chrome, it gives a stereo channel layout, but when later the decoder is being opened to perform actual audio decode, it thinks there is just 1 channel. I suspect this might be due to the earlier mismatch in channel counts during parsing during the initial context open.

[a] https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavformat/mov.c?rcl=28a5cdde5c32bcf66715343c10f74e85713f7aaf&l=1917

[b]
https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavformat/isom.c?q=isom.c&dr&l=539

Since this appears to be a problem with the stream. I'm going to mark this WontFix. Please reactivate or file a new issue if you determine otherwise.
Thanks!

Note that the channel mismatch does not seem to be a problem for other browsers or video players (tested in Firefox and VLC).