How to get more debug info about MEDIA_ERR_SRC_NOT_SUPPORTED ?

[roxlu]

Hi,

I'm working on a project where we stream H264 encoded video with Intel Quick Sync to a media server  280x720@{60,30} fps. 

Then we open this stream in Chrome using DASH as transport. Though I'm receiving a  MEDIA_ERR_SRC_NOT_SUPPORTED and 

I'm trying to find out what is causing this error. When I encode using libx264,  Chrome is able to dislay the video stream.  When I use 

VideoToolbox on Mac to decode the H264 stream that I encode with Quick Sync (Windows) it works great as well. It looks like the 

H264 stream that is generated by Quick Sync is correct; I can parse it with h264parser, open in it Elecard StreamEye and can decode

it with VideoToolbox (on mac). 

Though as it seems that the h264 stream is correct I'm trying to get some more info about what is causing the MEDIA_ERR_SRC_NOT_SUPPORTED

error. I've tried to run Chrome with --enable-logging --v=1, but this just gave me a couple lines of output;  I would expect that --enable-logging would 

give me a lot more information but it doesn't (not on Mac and not on Windows).

Can someone point me in a direction where I can look to get more information about why I'm getting this MEDIA_ERR_SRC_NOT_SUPPORTED error?

Thanks!

Kind regards,

roxlu 

[Matthew Wolenetz]

Hi roxlu,

Does chrome://media-internals show any corroborating error, debug, or info messages for the player experiencing MEDIA_ERR_SRC_NOT_SUPPORTED? We've been adding more verbose messages to release builds in the form of chrome://media-internals player logs.

If you are ok sharing a sample stream, please open a bug at crbug.com with repro steps and let us know the bug ID here for us to help you investigate.

More detail:

MEDIA_ERR_SRC_NOT_SUPPORTED occurs in Chrome when media resource failed to load or the given URL could not be resolved. We may not yet have enough logging detail in chrome://media-internals for each vector to this error, though there could be some better info there than exposed via --enable-logging.

Matt

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Diederick Huijbers]

Hi Matt,

Thanks for your reply. I'll check this first thing tomorrow morning! I hope I can find a bit more info. What does "failed to load" mean? Does that mean the chrome failed to get any data at all? Or can it also mean that the data which was received couldn't be used by the decoder? If the problem is that Chrome isn't receiving any data at all, then it will be easy to fix. 

Best

roxlu

Op di 10 nov. 2015 om 01:00 schreef Matthew Wolenetz <wole...@chromium.org>:

[Matthew Wolenetz]

I can help narrow your search and my answers if you help me understand if this is plain <video src="some url">, <video ...> <source "some url">, or <video> video.src=createObjectUrl(some mediasource object). IOW, is this regular URL playback or a playback involving usage of the Media Source Extensions API?

Thanks,

Matt

[roxlu]

Hi Matthew,

Thanks for your reply. Yes we're using the Media Source Extension through dash.js. And yep, I can share the stream. Though I want to inspect it a bit further. I'm going to setup a development environment so I can see where exactly this issue occurs. Any pointers where I should start? I would think this is is a good start. 

This is the output from the chrome://media-internals tab:

Player Properties:

render_id: 74

player_id: 0

pipeline_state: kStopped

event: WEBMEDIAPLAYER_DESTROYED

url: blob:http%3A//stream.localhost/ecd481b1-949f-461c-9f14-72c10b8af742

duration: 9223372036854.775

info: Video codec: avc1.42020

found_video_stream: true

video_codec_name: h264

video_dds: false

video_decoder: GpuVideoDecoder

error: Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf

pipeline_error: pipeline: decode error

Logs

00:00:00 00 pipeline_state kCreated

00:00:00 00 event WEBMEDIAPLAYER_CREATED

00:00:00 00 url blob:http%3A//stream.localhost/ecd481b1-949f-461c-9f14-72c10b8af742

00:00:00 06 pipeline_state kInitDemuxer

00:00:00 06 duration 9223372036854.775

00:00:00 43 info Video codec: avc1.42020

00:00:00 43 found_video_stream true

00:00:00 43 video_codec_name h264

00:00:00 43 pipeline_state kInitRenderer

00:00:00 43 video_dds false

00:00:00 43 video_decoder GpuVideoDecoder

00:00:00 43 pipeline_state kPlaying

00:00:00 120 error Failed to prepare AVC sample for decode

00:00:00 120 error Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=inf

00:00:00 120 pipeline_error pipeline: decode error

00:00:00 120 pipeline_state kStopping

00:00:00 121 pipeline_state kStopped

00:00:00 129 event WEBMEDIAPLAYER_DESTROYED

I hope this provides a bit more info. The logs tell me that parsing of the stream failed. I'm going to hunt down where this log comes from.

Thanks,

Diederick

Op dinsdag 10 november 2015 01:34:35 UTC+1 schreef Matthew Wolenetz:

[PhistucK]

Before getting the code or building (unless you already have - and maybe even if you already have), you can use cs.chromium.org to quickly search the codebase.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Diederick Huijbers]

Thanks PhistucK!

* What a great, helpfull community!

[Diederick Huijbers]

Okay, I’ve got a build of Chromium with h264 support using ffmpeg. I found the file where the issue occurs. To get me started with the code, I was wondering how do now what stream_parser is used? Can someone maybe give me a short intro how streams are handled so I can debug this issue?

Thanks

roxlu

[roxlu]

I just found the issue and wanted to share it. 

The Intel Meda SDK (Quick Sync encoder), uses mfxBittream objects to store the h264 output stream. The h264 bitstream that Quick Sync generates (using my parameters) contains 4 byte annex-b headers. I rewrite these annex-b headers to AVC headers but I used the 'DataLength' member of the mfxBitstream. This "DataLength" member is the size of the data the encoder generates, including the 4 byte annex-b header. So I fixed this issue by subtracting 4 bytes from the DataLength.  This is the line in avc.cc which actually failed. It would have been helpfull if this showed an error message.

Thanks!

Op dinsdag 10 november 2015 14:47:01 UTC+1 schreef roxlu:

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Matthew Wolenetz]

That's great sleuthing to find the problem with your stream! Thankfully, chrome://media-internals had enough to point you in the right general direction (mp4 stream parsing failed around an AVC sample).

I'll see what I can do to add some more fine-grained logging as you suggest here: https://code.google.com/p/chromium/codesearch#chromium/src/media/formats/mp4/avc.cc&sq=package:chromium&type=cs&l=39

Do you still need a primer on the stream parsing implementation in Chromium MSE? It seems you discovered what you needed fairly rapidly.

Matt

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.