Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1508706 - No longer works with USB webcam 19ff:0103 , error "Tried to capture in BGR3, but device returned format YUYV"
Summary: No longer works with USB webcam 19ff:0103 , error "Tried to capture in BGR3, ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: v4l-utils
Version: 27
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F27FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2017-11-02 01:39 UTC by Adam Williamson
Modified: 2017-11-15 20:15 UTC (History)
10 users (show)

Fixed In Version: v4l-utils-1.12.5-5.fc27 v4l-utils-1.12.5-5.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-08 22:11:05 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
V4L2 log requested by hans (329.90 KB, text/plain)
2017-11-02 19:15 UTC, Adam Williamson 		no flags Details
View All

Description Adam Williamson 2017-11-02 01:39:27 UTC 
I have a USB webcam, USB ID 19ff:0103 (it's branded 'Rocketfish'). Cheese used to work fine with this, I think at least up to Fedora 26, but I've just tried using it with current Fedora 27 - with cheese-3.26.0-1.fc27.x86_64 - and it runs, but doesn't read anything from the webcam (it just shows 'There was an error playing video from the webcam'). The console shows this:

libv4l2: error set_fmt gave us a different result then try_fmt!
libv4l2: error set_fmt gave us a different result then try_fmt!

(cheese:23681): cheese-WARNING **: Device '/dev/video0' cannot capture in the specified format: gstv4l2object.c(3640): gst_v4l2_object_set_format_full (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin35/GstV4l2Src:v4l2src1:
Tried to capture in BGR3, but device returned format YUYV

Proposing as a Final blocker per criterion "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" - a webcam app that can't read anything from the webcam clearly doesn't have working 'basic functionality'. Of course, whether this is accepted as a blocker will depend on whether this problem would affect all or many webcams, or if there's something weird about mine. It'd be good to have reports from other testers.
Comment 1 sumantro 2017-11-02 11:12:57 UTC 
My Creative Technology USB powered web cam doesnt work as well.
Comment 2 Stephen Gallagher 2017-11-02 12:56:13 UTC 
I can confirm it works fine on the integrated camera in my Lenovo P50:
              *-usb:1
                   description: Video
                   product: Integrated Camera
                   vendor: SunplusIT Inc
                   physical id: 8
                   bus info: usb@1:8
                   version: 0.12
                   capabilities: usb-2.00
                   configuration: driver=uvcvideo maxpower=500mA speed=480Mbit/s
Comment 3 Kamil Páral 2017-11-02 17:20:55 UTC 
Discussed during blocker review [1]:

RejectedBlocker AcceptedFreezeException (Final) - this seems to be hardware dependent, so far about 20% of tested cameras were affected. We think this is a low enough failure rate to not consider this a release-blocking issue, but important enough to be worth an FE if the release slips.

[1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/
Comment 4 Hans de Goede 2017-11-02 18:53:00 UTC 
I'm unable to reproduce this (despite having tested 10+ different webcams), I've a feeling this is a kernel bug somehow, but it could also be a libv4l2 bug. Can someone who is seeing this do:

LIBV4L2_LOG_FILENAME=/tmp/log cheese

And then attach /tmp/log here afterwards ?
Comment 5 Adam Williamson 2017-11-02 19:15:28 UTC 
Created attachment 1347102 [details]
V4L2 log requested by hans

Here you go, Hans. This is with kernel 4.13.9-300.fc27.x86_64 and the same webcam listed in the initial report.
Comment 6 Hans de Goede 2017-11-02 20:21:14 UTC 
Ok, looks like a your webcam is triggering a somewhat old, but so far unnoticed bug in libv4lconvert.

I've started a scratch-build of v4l-utils with a fix here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22870480

Please give it a go when it is finished and let me know if it fixes things.
Comment 7 Hans de Goede 2017-11-02 20:21:43 UTC 
And the x86_64 build is done already :)
Comment 8 Adam Williamson 2017-11-02 23:41:16 UTC 
Yeah, works now. Seems very sluggish (low frame rate), but works.
Comment 9 Hans de Goede 2017-11-03 07:43:33 UTC 
Hi,

(In reply to Adam Williamson from comment #8)
> Yeah, works now.

Good, I will go and create official updated v4l-utils packages for this then.

> Seems very sluggish (low frame rate), but works.

Yes I noticed that too with a few cams, where as other cams work fine, not sure what is going on here but this seems to be a separate bug. Can you try:

dnf install camorama
camorama -M -d /dev/video0

(/dev/video0 assuming you don't have a tvcard are some such)

camorama is a quite old simple camera app, if that works the sluggishness problem is likely somewhere in gstreamer or cheese.

Another interesting test-app (created and used by v4l developers) is qv4l2.

Anyways it is probably a good idea to file a new bug (against cheese for now) for the sluggishness.

Regards,

Hans
Comment 10 Fedora Update System 2017-11-03 10:53:26 UTC 
v4l-utils-1.12.5-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8477dfde52
Comment 11 Fedora Update System 2017-11-03 10:53:40 UTC 
v4l-utils-1.12.5-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c58475975
Comment 12 Hans de Goede 2017-11-03 10:54:33 UTC 
Is there anything I need to do to make use of the FreezeException (assuming there will be a time-window to do so) ?
Comment 13 Fedora Update System 2017-11-03 14:24:23 UTC 
v4l-utils-1.12.5-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8477dfde52
Comment 14 Adam Williamson 2017-11-03 16:34:49 UTC 
Hans: nothing you need to do, no. There may or may not be a time window, we are making the second go/no-go call this morning. There's some thorny issues to talk over.
Comment 15 Adam Williamson 2017-11-03 16:35:18 UTC 
BTW, seems it's just the camera that's slow, behaves the same with camorama. It's better at low resolutions.
Comment 16 Fedora Update System 2017-11-04 18:03:52 UTC 
v4l-utils-1.12.5-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c58475975
Comment 17 Fedora Update System 2017-11-08 22:11:05 UTC 
v4l-utils-1.12.5-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2017-11-15 20:15:23 UTC 
v4l-utils-1.12.5-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.