New issue
Advanced search Search tips

Issue 738928 link

Starred by 12 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Red/blue ghosting in camera image on Windows starting at 61.0.3146.0

Project Member Reported by chfremer@chromium.org, Jul 3 2017

Issue description

An example of how the symptoms look can be found towards the end of the screen capture from the report in https://bugs.chromium.org/p/chromium/issues/detail?id=722038#c82

This issue appears to be a regression that was introduced somewhere between 60.0.3092.0 and 61.0.3146.0 but may have been masked by  https://crbug.com/722038 , which was fixed in 61.0.3146.0.

It is not yet determined whether or not this issue affects M60 builds with the fix for  https://crbug.com/722038  applied.
 

Comment 1 by oli...@ubivent.com, Jul 4 2017

seeing this on
Win10 Version 61.0.3147.0 canary (64-Bit)
Logitech C270 Webcam & integrated webcam (DELL Latitude E6520)

Comment 2 by cmor...@cafex.com, Jul 4 2017

Seeing this on:
Windows 7 Pro x64 i3,  Logitech HD C270
Canary Build 61.0.3147.0 (64-bit)

Ghosting appears with fast movement on the camera, usually waving hands. Not sure if the blue/red colours relate to the speed or the skin tone.
I confirm the issue using a logitech pro9000  on canary 61.0.3147 32bits.
Seems that the chroma buffers U and V are delayed by one frame vs luma buffer Y...
Win8.1 Canary 61.0.3147.3 : I observed that the ghosting effect appears only with below urls:

https://webrtc.github.io/samples/src/content/devices/input-output/
or 
https://webrtc.github.io/samples/src/content/getusermedia/gum/

When I checked it on other site like https://webcammictest.com/ or https://www.onlinemictest.com/webcam-test/ it works properly.

Is any problem with webrtc ?
Cc: brandtr@webrtc.org stefan@webrtc.org ilnik@webrtc.org sprang@webrtc.org niklas.enbom@webrtc.org
 Issue webrtc:7940  has been merged into this issue.
Cc: chfremer@chromium.org
Owner: sunn...@chromium.org
Status: Assigned (was: Untriaged)
Labels: -OS-Windows OS-All
Issue 738358 has been merged into this issue.
Project Member

Comment 12 by bugdroid1@chromium.org, Jul 7 2017

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

commit 61b4a9e42d027dd864d70ed52766bba744a899b3
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Fri Jul 07 19:53:08 2017

cc: Explicitly set sync tokens for mailbox resources.

Mailbox resource sync token semantics were recently changed so that an
empty sync token means no synchronization needed. VideoResourceUpdater
creates resources with empty sync tokens and sync tokens are
generated by VideoLayerImpl. That code checks the needs_sync_token state
and does not generate sync tokens.

This CL makes explicitly sets sync tokens for such mailbox resources. It
also includes some cleanup of redundant needs_sync_token state.

R=piman
BUG= 738928 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I5ca66ab689fdee2b1b78eaf2e77bfd2ef1cebe53
Reviewed-on: https://chromium-review.googlesource.com/560736
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485010}
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/layers/heads_up_display_layer_impl.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/layers/texture_layer_impl.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/layers/video_layer_impl.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/resources/resource_provider.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/resources/resource_provider.h
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/resources/resource_provider_unittest.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/resources/video_resource_updater.h
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/media/base/video_frame.cc
[modify] https://crrev.com/61b4a9e42d027dd864d70ed52766bba744a899b3/media/base/video_frame.h

Status: Fixed (was: Assigned)
ghosting and stop of motions as seen here
http://www.maspick.co.il/records/canaryissueswithcamera1.webm
also green light on start of capture
http://www.maspick.co.il/records/greetlight.webm

on windows 10
Version 61.0.3153.0 (Official Build) canary (64-bit)

i had tested 3 different PCs at home with Windows 10 and 
Version 61.0.3153.0 (Official Build) canary (64-bit)

1. Laptop lenovo Y510p with lenovo Easycamera (built-in) + logitech pro 900 (usb)
2. Laptop Lenovo IdeaPad 710 with lenovo EasyCamera (built-in)
3. WorkStation with logitech WEBCAM C200 (usb)

seems that ghosting/delayed motions/green first frame appears only on connected USB cameras described above 
but not for built-in camera which looks to work normal as expected.



Status: Started (was: Fixed)
Seems like the fix didn't work for all cases.

webrtc folks, do you know what's different between various types of cameras? do we use hardware video decoding in some cases and software in others?
This problem reproduces without encode/decode so that's not an issue here, but the format that the camera delivers can vary, it can be i420, MJPEG etc. 
Is there an easy way to test different formats? If not, do we have any of the cameras listed above that I could borrow for debugging?
dannymendelmn@: We checked several different camera models on a Win10 test machine with 61.0.3153.0 and could not see the issue with any of them.

Could you please double check and confirm that you were running 61.0.3153.0 canary build?
Labels: Needs-Feedback
Status: Assigned (was: Started)
Reporting that on current Canary version ( 61.0.3153.0 ) this problem is disappeared. I had this issues at the moment of topic start, and I didn't change the OS or drivers, but now I don't see any issues with that color artifacts.
Labels: -Needs-Feedback
Status: Fixed (was: Assigned)
Marking as Fixed for now. Let's reopen if someone confirms that the bug is still happening.

Sign in to add a comment