Hmn, this gets even stranger. The debug log from those uvideo printfs seems to show everything operating fine - some messages are unexpected, but legal. There are no complaints about bad header lengths, which I would expect if there was bad data in the buffer. And crucially, uvideo reads 614400 bytes before receiving an end-of-frame, which is the correct size for a frame of the format mplayer has selected. So, the UVC headers on each packet are intact, and there's nothing else uvideo can really do wrong, which leaves ehci and video(4). The attached uvideo_mset.diff should rule out one of them: if you get a plain green mplayer window with the patch applied, the fault is with ehci. If mplayer still produces the output you've been seeing (or something else), then video is knarling things up. Additionally, the trace produced by the attached vid.diff (with VIDEO_DEBUG enabled, UVIDEO_DEBUG disabled) might shed some light on how mplayer is fetching frames, and whether video(4) is actually queuing/dequeuing frames properly. Thanks for bearing with this debug effort so far. -- Thanks, Jeremy
Index: uvideo.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 uvideo.c
--- uvideo.c 3 Nov 2010 22:34:24 -0000 1.32
+++ uvideo.c 23 Dec 2010 08:12:51 -0000
@@ -1776,6 +1776,8 @@ uvideo_stream_recv_process(struct uvideo
payload.frameno = hdr->bmHeaderInfo & UV_FRAME_ID;
payload.end_of_frame = hdr->bmHeaderInfo & UV_END_OF_FRAME;
+ memset(payload.data, 0, payload.size);
+
video_submit_payload(vs->vs_parent->sc_videodev, &payload);
return USBD_NORMAL_COMPLETION;
Index: video.c
===================================================================
RCS file: /cvsroot/src/sys/dev/video.c,v
retrieving revision 1.23
diff -u -p -r1.23 video.c
--- video.c 6 Dec 2009 22:42:48 -0000 1.23
+++ video.c 23 Dec 2010 05:34:50 -0000
@@ -925,6 +925,7 @@ video_queue_buf(struct video_softc *sc,
memcpy(userbuf, driverbuf, sizeof(*driverbuf));
mutex_exit(&vs->vs_lock);
+printf("enqueue %p\n", vb);
break;
default:
return EINVAL;
@@ -1144,6 +1145,7 @@ videoread(dev_t dev, struct uio *uio, in
size_t len;
off_t offset;
+printf("videoread - unexpected\n");
sc = device_private(device_lookup(&video_cd, VIDEOUNIT(dev)));
if (sc == NULL)
return ENXIO;
@@ -1710,6 +1712,7 @@ video_stream_setup_bufs(struct video_str
{
int i, err;
+printf("video alloc %d bufs\n", nbufs);
mutex_enter(&vs->vs_lock);
/* Ensure that all allocated buffers are queued and not under
@@ -1936,6 +1939,9 @@ video_stream_write(struct video_stream *
mutex_enter(&vs->vs_lock);
+if (payload->end_of_frame || (vs->vs_frameno > 0 && vs->vs_frameno !=
payload->frameno))
+ printf("video buf complete; frameno %d EOF %d\n", payload->frameno,
payload->end_of_frame);
+
/* change of frameno implies end of current frame */
if (vs->vs_frameno > 0 && vs->vs_frameno != payload->frameno)
video_stream_sample_done(vs);
@@ -1990,6 +1996,7 @@ video_stream_sample_done(struct video_st
vb->vb_buf->sequence = vs->vs_sequence;
SIMPLEQ_REMOVE_HEAD(&vs->vs_ingress, entries);
+printf("egress %p\n", vb);
SIMPLEQ_INSERT_TAIL(&vs->vs_egress, vb, entries);
cv_signal(&vs->vs_sample_cv);
selnotify(&vs->vs_sel, 0, 0);
Attachment:
signature.asc
Description: This is a digitally signed message part