<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY> Le jeudi 29 mai 2014 à 16:16 +0200, Lee Matthews a écrit : <BLOCKQUOTE TYPE=CITE> <PRE> Hi, </PRE> I'm using the http-launch code compiled by NDK for an Android phone to grab video from an external webcam (attached to the phone) and stream it to a web browser. </BLOCKQUOTE> Sorry,I don't get what you are using. What version of GStreamer is that ? From the log, it seems relatively recent. <BLOCKQUOTE TYPE=CITE> <PRE> </PRE> I'm using the following to setup the pipeline : bin = gst_parse_launch ("webmmux streamable=true name=stream v4l2src device=/dev/video3 ! video/x-raw,format=YUYV,width=320,height=240,framerate=(fraction)10/1 ! videoconvert ! vp8enc deadline=1 threads=16 cpu-used=15 end-usage=cbr target-bitrate=512000 undershoot=95 max-quantizer=56 ! stream.", &err); </BLOCKQUOTE> YUYV is the 4CC from V4L2, in GStreamer we use the YUY2 notation. That caps filter is invalid. <BLOCKQUOTE TYPE=CITE> The app has internet permissions, and the file /dev/video3 is accessible to all users on the phone. When I try executing the code, the first error that I get is : gst_v4l2_buffer_pool_streamon:<v4l2src0:pool:src> error with STREAMON 22 (Invalid argument) The error appears when I try connecting to the http server via a webbrowser. The webcam supports the following formats : <PRE> v4l2-ctl --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Pixel Format: 'YUYV' Name : YUV 4:2:2 (YUYV) Index : 1 Type : Video Capture Pixel Format: 'MJPG' (compressed) Name : MJPEG lma@lma-Precision-T1650:~$ Can anyone explain why I'm getting this error ? </PRE> </BLOCKQUOTE> Just found in your log that the closest caps to your request has been determined as. video/x-raw\,\ format\=$string$YUY2\,\ width\=$int$2304\,\ height\=$int$1536\,\ pixel-aspect-ratio\=$fraction$1/1\,\ interlace-mode\=$string$progressive\,\ framerate\=$fraction$2/1" This normally should have cause negotiation error, I'll check if I can reproduce. Basically you are forcing the device to something it cannot support. Probing says your device can do: YUY2 2304x1535@2fps, 2304x1296@2fps, 1920x1080@5fps, 1600x896@15,5fps, 720p@10,15,5fps, ... the rest has bee stripped in the log, normally it should be followed with MJPEG where you have much higher framerate, though you'd need to decode the jpeg first. Outside of that, it seems like the buffers never get queued, or you haven't enabled enough trace to let me see that. You could pretty much remove everything, and only keep "v4l2*:7". Normally, on capture device, right after call to gst_v4l2_buffer_pool_start() buffer get released, which has the effect of queuing them in the v4l2 capture device queued. Note it's hard to say, because this ioctl shared the same errno for multiple possible error (from real invalid value, to out of memory). All this seems to fall from the initial problem, though I'll try to see if I also get such a fall through, and will se if I can make it faile more cleanly, and with a negotiation error. Nicolas </BODY> </HTML>