The video sometimes will become green on chromebook OS 51 and 52
Reported by
pan.dev....@gmail.com,
Jul 21 2016
|
|||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Platform: 8530.6.0 - dev-channel enguarde Example URL: thinclient13.webex.com Steps to reproduce the problem: 1. Host starts a meeting in thinclient13.webex.com site through PC (mac/windows) with webex pc client. 2. Browser client joins in meeting using chromebook 3. Host join video and audio, host mute himself, let the meeting last more than 1 hour 4. Check the video whether normal at chromebook side What is the expected behavior? The video should be normal at chromebook side What went wrong? The video some times will turn green for 5 or 10 or 20 sec Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? Yes Chrome version: 52 Channel: dev OS Version: Flash Version: The green screen issue, has no specific steps, just that it will happen at random times for short interval.
,
Jul 25 2016
Couple updates: - I am able to reproduce the problem with custom CrOS Release build on Pixel. CrOS debug build is hitting unrelated checks and restarts manually. I still couldn't find a way around it. - To get logs, I piped everything in related files to LOG(ERROR). That is the attached file ui.LATESTgreen near 123016-123017. However, these logs are way too long to parse. - I piped only DVLOG(1) and DVLOG(2) to LOG(ERROR). That gives a much cleaner log. The gren pixelation happens with the following error line: ERROR:h264_decoder.cc(1164)] Handling frame_num gap: 353->355
,
Jul 25 2016
,
Jul 25 2016
,
Jul 26 2016
Would you perhaps be able to dump and attach a sample stream that causes this issue please? Thank you.
,
Jul 28 2016
Hi Pawel, Attached is the un-encrypted stream sent by our conferencing server to Chromebook, Chrome book showed massive green screen overlay on top of another video. This pcap has a dummy UDP and IP headers with dummy source and destination IPs. You can decode them as RTP in wireshark. These video packets are captured just before the server performs encryption and sends out the packets,
,
Jul 29 2016
Attaching the raw H264 stream from capture above.
,
Aug 1 2016
Thanks, unfortunately the content of the frames seems to be corrupted, which could be the reason for the issues in this bug, or perhaps it didn't extract correctly from the capture file? Could someone perhaps confirm the raw stream in #7 is what we are indeed sending, and/or attach another sample of a raw stream?
,
Aug 1 2016
,
Aug 1 2016
I can confirm that the stream is corrupted also when playing with VLC and openH264.
,
Aug 3 2016
As the stream appears to be corrupted, could we perhaps ask for another sample stream, ideally in form of a raw H264 Annex-B stream please? Thank you.
,
Aug 3 2016
Certain clarification regarding the earlier sent stream which was actually not corrupted but the video sender was under a network impairment. The reason for that was the green screen issue is easy to reproduce under such lossy network. The switching of resolution are also a consequence of that. The fact that the stream was playable through H264 player (vlc) but looked pixellated is also a consequence of change in network condition. In any case I am uploading fresh captured streams. One stream is what the conferencing server is sending to Firefox and another is what its sending to Chromebook. In this setup also, like last one the sender (which is webex pc client) is under certain network impairment. But the quality of stream received by Firefox and Chromebook endpoints are same. The viodeo stream will switch resolution a number of times, but that's normal as we adjust resolutions depending on the network conditions. The chromebook video stream starts 15-20 seconds before the firefox stream, so you can align them accordingly for a comparative view. The difference in observed videos was that on Chromebook, I saw couple of times this green screen appearing, but Firefox never shows such a thing. Firefox would occasionally freeze a frame for couple of seconds, while Chromebook shows a heavy green screen overlay. Chromebook shows heavy amount of pixelated video/half blurred video while the Firefox has a more consistent way of occasionally showing the last decoded frame and resuming the frame decoding. There was minimum or no amount of pixelation and no green screen on Firefox.
,
Aug 3 2016
We can discuss this tmrw, but the attached files still gives lots or corruption and decoder errors also for software decode: [h264 @ 0x7f81acc1b800] non-existing PPS 36 referenced [h264 @ 0x7f81acc1b800] decode_slice_header error [h264 @ 0x7f81acc1b800] non-existing PPS 36 referenced [h264 @ 0x7f81acc1b800] decode_slice_header error [h264 @ 0x7f81acc1b800] non-existing PPS 36 referenced [h264 @ 0x7f81acc1b800] decode_slice_header error [h264 @ 0x7f81acc1b800] non-existing PPS 36 referenced [h264 @ 0x7f81acc1b800] decode_slice_header error [h264 @ 0x7f81acc1b800] no frame! ... [h264 @ 0x7f81acc19e00] reference picture missing during reorder [h264 @ 0x7f81acc19e00] Missing reference picture [h264 @ 0x7f81acc19e00] reference picture missing during reorder [h264 @ 0x7f81acc19e00] Missing reference picture [h264 @ 0x7f81acc19e00] reference picture missing during reorder ...
,
Aug 9 2016
Adding this to the bug as well. After the discussing this I think the problem is that by design the decoder will get corrupt data from time to time. Packet loss that occurs between the Webex client and the Webex server will be invisible to the receiving Chrome client since the Webex server rewrites RTP sequence numbers without the loss. The software implementations also gives errors and shows some corruption, but they are not as bad as the hardware decoder (probably no error concealment whatsoever). Pawel, is it possible to return an error for frames that doesn't have any valid reference frame? We still would need to allow gaps in sequence numbers when there is a valid reference frame (i.e. temporal scaling).
,
Feb 17 2017
,
Mar 18 2017
Activating. Please assign to the right owner and the appropriate priority.
,
Apr 12 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 12 2018
this bug has been stale for > 1 year. I'll close it. If any of you think it worth to be kept, please reactivate and reassign to appropriate owner. thanks |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by emir...@chromium.org
, Jul 21 2016Components: Blink>WebRTC>Video OS>Kernel>Video
Labels: M-51 M-52
Owner: kcwu@chromium.org
Status: Assigned (was: Unconfirmed)