forderud@ Thanks for the issue.

Tested the issue on Windows 10 on the reported version 66.0.3359.139 by following the below steps.

1. Downloaded the folder given in step 2.
2. Started the server and entered http://localhost:8080 in chrome.
3. Can view the Directory listing of the folder AppWebStream and on clicking on WebStream.html page, the page is blank.
Attached is the screen cast of the steps followed for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Also adding component Internals>Media>FFmpeg and CC'ing Dev's - dalecurtis@ and wolenetz@ for further help in triaging the issue.

Thanks..

Deleted: 840950.mp4 1.4 MB

	840950.mp4 1.4 MB View Download

Susan:
You'll need to first build the C++ project with Visual Studio 2015 in order to reproduce. Then, run "AppWebStream.exe 8080" to start the reproducer application, before opening http://localhost:8080 in chrome.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

forderud@ Thanks for the update.

As per comment #3, as this issue needs to be tested by building a C++ project with Visual Studio 2015, this is out of scope of triaging at TE end.

Hence adding 'TE-NeedsTriageHelp' label and requesting Dev team to look into the issue and help in further triaging.

Thanks..

Susan:
I can help out triaging the regression myself, if you just can point me in the direction of where to download relevant windows binaries between Chrome 65 and 66 for testing?

Are you an infinite duration in the container? Unless duration is unspecified chrome defaults to requiring at least 4 frames to start playback. I.e. what does ffprobe show for your stream?

dalecur:
The H.264/fMP4 stream is transmitted at 25fps with infinite duration. It would be preferable to get rid of the 4 frame buffering you're mentioning, but I don't think it's the primary problem here.

chrome://media-internals returns the following
render_id: 382
player_id: 0
origin_url: http://localhost:8080/
frame_url: http://localhost:8080/
frame_title: AppWebStreaming
url: blob:http://localhost:8080/fae4317e-dfd8-4faf-b039-f852734d1449
info: Selected GpuVideoDecoder for video decoding, config: codec: h264 format: 1 profile: h264 high coded size: [1920,1200] visible rect: [0,0,1920,1200] natural size: [1920,1200] has extra data? false encrypted? false rotation: 0°
pipeline_state: kSuspended
found_video_stream: true
video_codec_name: h264
debug: Video rendering in low delay mode.
video_dds: false
video_decoder: GpuVideoDecoder
video_buffering_state: BUFFERING_HAVE_ENOUGH
height: 1200
width: 1920
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
duration: unknown

Logs indicate we're in low delay mode, so it should only be waiting for 1 frame at a time. Looks like you're using MSE here, if possible, can you test if you get hangs if you point the <video> tag directly at the stream?

>where to download relevant windows binaries

https://www.chromium.org/developers/bisect-builds-py

I've now tested a bit, an the same problem also occur when pointing the <video> tag directly to the stream. The problem is therefore not limited to just MSE.

It's possible to manually trigger playback from Chrome by enabling "Show controls" and then clicking "play" on the video stream. To me, this sounds like a regression in the "autoplay" functionality, possibly in conjunction with infinite length fMP4 streams...

I've now attempted to run "bisect-builds.py -a win -g 530369 -b 540276" to perform a binary search for the cause of this regression. This works in the sense that Chrome builds are downloaded and launched automatically. However, all of the binaries seem to fail with the following error, regardless of revision:
Uncaught DOMException: Failed to execute 'addSourceBuffer' on 'MediaSource': The type provided ('video/mp4; codecs="avc1.64001F"') is unsupported. at MediaSource.sourceOpen

I'm also unable to activate playback when serving the stream directly through a <video> tag. I've never experienced this error before when using regular Chrome binaries. Are there any limitations or tweaks related to the bisect-builds.py script that I should be aware of?

Indeed, those Chromium snapshots don't have H264 codec present only in Chrome. My suggestion was useless. I guess you can try to "bisect" manually using a third-party portable installer with H264 codec like https://github.com/henrypp/chromium/releases but it doesn't offer the same granularity, unfortunately.

Thank's a lot for the link to the henrypp binaries woxxom! I've now tested them, and managed to shrink down the regression to somewhere within the following range:
* Last good: v66.0.3326.0-r530613
* First bad: v66.0.3342.0-r534891

Changelog for #14 is https://chromium.googlesource.com/chromium/src/+log/66.0.3326.0..66.0.3342.0?n=10000

That's a huge changelog so no obvious CL stand out. FFMPEG was updated in r533516, though, so it might be worth checking FFMPEG directly by opening that stream in ffmpeg.exe or ffprobe.exe in Windows command prompt using builds from https://ffmpeg.zeranoe.com/builds/win64/shared/ (note, the bug might have been fixed in the most recent ffmpeg so try the earlier builds too, maybe even try to bisect them).

I'm a bit reluctant to spending time on FFMPEG here, since I suspect that the problem is on the Chrome side. As mentioned above, I'm able to manually trigger playback by enabling "Show controls" and then clicking "play" in Chrome. After that, everything works perfectly.

To me, this sounds like a regression in the <video> "autoplay" attribute.

Try changing chrome://flags/#autoplay-policy

Thank's a lot for the tip woxxom! Changing the autoplay policy to "no user gesture is required" actually fixed the problem.

Any suggestion for how to make it work out-of-the-box, so that I don't have to convince all users to tweak their Chrome settings?

Deleted: no_user_guesture_required.png 7.8 KB

	no_user_guesture_required.png 7.8 KB View Download

I've now investigated a bit, and it appears like I've been hit be the recent "autoplay" policy changes (https://developers.google.com/web/updates/2017/09/autoplay-policy-changes).

I've managed to "fix" the regression by adding a "muted" attribute to my <video> tag. This work sufficiently good for me for the time being.

Thank's a lot for all the assistance I've got on this issue. Please feel free to close this issue.

Ah great. Looking back did you get a warning message about this in the dev tools console? I thought we were printing such a message when playback is blocked.

I've not seem any warnings in the dev tool console about autoplay being blocked. Maybe this is something that you can look into adding?

I think I'm mistaken. I'll leave it to the autoplay folks to comment.