From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Bhupesh SHARMA <bhupesh.sharma@st.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Date: Fri, 03 Aug 2012 10:15:02 +0200 [thread overview]
Message-ID: <1479304.PR7OAbvLrR@avalon> (raw)
In-Reply-To: <D5ECB3C7A6F99444980976A8C6D896384FABF0D865@EAPEX1MAIL1.st.com>
Hi Bhupesh,
On Wednesday 01 August 2012 21:29:30 Bhupesh SHARMA wrote:
> On Wednesday, August 01, 2012 6:46 PM Laurent Pinchart wrote:
> > On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote:
> > > Hi Laurent,
> > >
> > > I have a query for you regarding the support and testing of MJPEG
> > > frame type in the UVC webcam gadget.
> > >
> > > I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats
> > > are supported. I was trying the same out and got confused because the
> > > data arriving from a real video capture video supporting JPEG will have
> > > no fixed size. We will have the JPEG defined Start-of-Frame and End-of-
> > > Frame markers defining the boundary of the JPEG frame.
> > >
> > > But for almost all JPEG video capture devices even if we have kept a
> > > frame size of VGA initially, the final frame size will be a compressed
> > > version (with the compression depending on the nature of the scene, so a
> > > flat scene will have high compression and hence less frame size) of VGA
> > > and will not be equal to 640 * 480.
> > >
> > > So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept
> > > as 614400 in webcam.c (see [1]).
> >
> > The dwMaxVideoFrameBufferSize value must be larger than or equal to the
> > largest MJPEG frame size. As I have no idea what that value is, I've
> > kept the same size as for uncompressed frames, which should be big enough
> > (and most probably too big).
>
> .. Yes, so that means that the user-space application should set the length
> of the buffer being queued at the UVC side equal to the length of the buffer
> dequeued from the V4L2 side, to ensure that varying length JPEG frames are
> correctly handled.
You should copy the bytesused field from the captured v4l2_buffer to the
output v4l2_buffer. The length field stores the total buffer size, not the
number of bytes used.
> I will try with these changes in the user-space daemon.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2012-08-03 8:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 6:26 Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget Bhupesh SHARMA
2012-08-01 13:15 ` Laurent Pinchart
2012-08-01 13:29 ` Bhupesh SHARMA
2012-08-03 8:15 ` Laurent Pinchart [this message]
2012-08-03 16:25 ` Bhupesh SHARMA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1479304.PR7OAbvLrR@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=bhupesh.sharma@st.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.