goncharov@ Thanks for the issue.

Tested this issue on Windows 10 and Ubuntu 14.04 on the reported version 64.0.3282.186 and the latest Canary 67.0.3362.0 by following the below steps.

1. Launched Chrome and played the video demo.mp4 on chrome and couldn't observe any Green artifacts while the video is playing.
2. On opening the file init-seg.m4s file, can observe the error 'This file contains no playable streams'.
Also unable to view the attached frame1.mp4 video.
Attached is the screen shot for reference.

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

Also request you to provide a URL where this issue can be reproduced which will help in further triaging.

Thanks..

Deleted: error occured 818827.png 92.6 KB

	error occured 818827.png 92.6 KB View Download

Hello Susan,

Thanks for your feedback.
This is MSE specific issue. The point is that video frames must be packed individually into mp4 segments (or at least each segment must contain only part of a GOP) and appended to media source buffer. If I put all such segments into single mp4 file and assign that file as a source for video element, then the issue is not reproduced.

As you requested, I've created a test page for demonstration http://dev.wmspanel.com/test.html

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

I also attach mp4 file which contains init segment and one frame media segments for further reference.

Deleted: test.mp4 3.7 MB

	test.mp4 3.7 MB View Download

Able to reproduce the issue on Ubuntu 17.10 using chrome latest stable #65.0.3325.146 and latest canary #67.0.3365.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Issue is not seen in OS-Win and OS-Mac.

+matt,chris

I'll take a look soon. Thanks for reporting.

@#5 : simply playing that mp4 (via src=, not MSE), by clicking on the play button in crbug.com in Chrome M64 on linux reproduces green artifacts (ffmpeg demuxer + ffmpeg video decode). It could be that ffmpeg is confused by the fragmented media stream. I'll try with extra logging and with MSE shortly to see if I can figure out what's happening.

There is at least some fix needed in current upstream ffmpeg. When playing #5 with ffplay using sanitizer tooling, there are some problems reported. I'll follow-up with upstream along with further investigation.

I've reported the sanitizer errors to upstream ffmpeg (Michael). I'll follow-up during/after the current ffmpeg roll to see if those were the reason for the artifacts.

Hello Matthew,

Thanks for shedding some light on this problem.

@#7 : My observation is different. I've reproduced the issue in Win10 using Chrome and Edge browsers. It's not Linux specific.

Best regards,
Andrew

@#15: I don't know about Edge, but when you reproduced the issue on Win10 using Chrome, what video decoder does chrome://media-internals show the player using? If FFmpegVideoDecoder, that would be similar to what's observed on Linux that I reported to upstream ffmpeg in #14.

Michael's alignment fix is in upstream review (Note, this should fix the alignment warning found with ffplay; I was unable to reproduce such warning with instrumented media_pipeline_integration_fuzzer.)
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226386.html

goncharov@: I've tried playing (src=) them test.mp4 from #5 on both M64 (linux) and current tip-of-tree (early M67, linux): it no longer reproduces green in tip-of-tree, but there is a video glitch at about that point. This makes me suspect the content. Does your issue reproduce on M65? It doesn't appear to be specific to MSE (from the M64 repro of plain src=test.mp4).

@#16 : Green artifacts on Win10 Chrome are different. They occupy almost all space (attached a screenshot). The decoder isn't FFmpeg. 

render_id: 17
player_id: 6
origin_url: http://dev.wmspanel.com/
frame_url: http://dev.wmspanel.com/test.html
frame_title: 
url: blob:http://dev.wmspanel.com/8580cd80-6584-422d-bae2-601041e36da0
info: Effective playback rate changed from 0 to 1
pipeline_state: kPlaying
found_video_stream: true
video_codec_name: h264
debug: Video rendering in low delay mode.
video_dds: false
video_decoder: GpuVideoDecoder
seek_target: 6.921
video_buffering_state: BUFFERING_HAVE_ENOUGH
height: 720
width: 1280
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: PAUSE
duration: unknown

Deleted: chrome_win10.png 32.7 KB

	chrome_win10.png 32.7 KB View Download

@#17: I still think that the issue is MSE specific, because I wasn't able to reproduce it with src= video tag. That's why I've created a test case http://dev.wmspanel.com/test.html, please take a look (there is 10Mb js file containing frames, so it can take a little while).

The issue is still reproducible in Chrome M65 (both Win and Linux). The content is recorded via FFmpeg (codec copy) from a ground drone. I suspect that content is not ideal, because re-encoding it via FFmpeg fixes the problem. But it's played well in Firefox, Safari and VLC.

It's also played well in Chrome if single segment contains natural number of GOP's. If the content is really bad, then there shouldn't be such a difference. What do you think?

The NextAction date has arrived: 2018-03-15

wolenetz@ A gentle ping !!!

Request you to please provide an update on this bug.

Thanks.

Looking further now that Chromium M67 trunk contains the M67 ffmpeg roll.

I'm seeing some differences in ffmpeg decode log messages of #19's MSE test versus upstream ffmpeg's ffplay of #5's test.mp4.

They could indicate errors in the encoded h264 and/or framing of the MSE bytestream. Or possibly there is some difference in decoder context's error_concealment setting in MSE vs plain src= in Chromium.

I'll continue looking into these dimensions tomorrow.

Adding 'TE-NeedsTriageHelp' to move this issue out of TE Unconfirmed triaging bucket, as the issue is reproduced at TE end and confirmed the same in Comment #6.

Thanks..

Sheriffing now - will look further next week.

Hello wolenetz@

Could you please let me know if there's any update on this issue?

Thank you