RE: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Friday, August 03, 2012 1:45 PM > To: Bhupesh SHARMA > Cc: linux-...@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 > > 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. > Yes, you are right. It should be bytesused field instead of the length field. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Laurent, Thanks for clearing this doubt.. > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Wednesday, August 01, 2012 6:46 PM > To: Bhupesh SHARMA > Cc: linux-...@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 > > Hi Bhupesh, > > 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. I will try with these changes in the user-space daemon. Thanks for your help, Regards, Bhupesh > > Can you please let me know your opinions and how you tested the UVC > gadget's > > MJPEG frame format. > > > > [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Bhupesh, 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). > Can you please let me know your opinions and how you tested the UVC gadget's > MJPEG frame format. > > [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
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]). Can you please let me know your opinions and how you tested the UVC gadget's MJPEG frame format. [1] http://lxr.linux.no/linux+v3.5/drivers/usb/gadget/webcam.c#L232 Thanks, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
