From: Dmitry Buzdyk <dima.buzdyk@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: john.agosta@canonical.com, kevin.lu@canonical.com,
ethan.hsieh@canonical.com,
'Jesse Sung' <jesse.sung@canonical.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] uvcvideo: Add mapping for HEVC payloads
Date: Wed, 29 Jul 2020 16:26:02 +1000 [thread overview]
Message-ID: <20200729062602.GA258740@dmitry-T520> (raw)
In-Reply-To: <20200728001721.GG15448@pendragon.ideasonboard.com>
Hi Laurent,
On Tue, Jul 28, 2020 at 03:17:21AM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
>
> Sorry for the late reply.
>
> Mauro, there's a question for your below.
>
> On Tue, Jul 28, 2020 at 09:25:46AM +1000, Dmitry Buzdyk wrote:
> > Hi Laurent,
> >
> > Had you a chance to review USB descriptors from the device provided
> > below? Is any additional information needed?
> >
> > On Wed, Jul 15, 2020 at 06:00:10PM +1000, Dmitry Buzdyk wrote:
> > > On Tue, Jun 09, 2020 at 02:57:36PM +1000, Dmitry Buzdyk wrote:
> > > Hi Laurent,
> > >
> > > Please see updated information below
> > >
> > >> On Sun, Jun 07, 2020 at 04:07:19AM +0300, Laurent Pinchart wrote:
> > >>> Hi Dmitry,
> > >>>
> > >>> Thank you for the patch.
> > >>>
> > >>> On Fri, May 29, 2020 at 11:05:47AM +1000, Dmitry Buzdyk wrote:
> > >>>> Add HEVC GUID and assotiate with HEVC pixel format so that frame
> > >>>> based format descriptors recognized by the UVC video driver.
> > >>>
> > >>> The patch itself looks OK to me, but could you share a bit more
> > >>> information about which device(s) implement this ? Are they UVC 1.1
> > >>> devices ? Could you share their full USB descriptors (retrieved with
> > >>> 'lsusb -v', running as root if possible) ?
> > >>
> > >> This is a UVC1.1 camera device based on Ambarella H22 SOC.
>
> That's interesting. It would be nice to have upstream support for the
> Ambarella SoCs in the kernel :-)
>
> > >> Please note that device is still in development and yet to get actual
> > >> VID and PID.
> > >
> > > Device got its VID:PID from USB-IF:
> > >
> > > Bus 001 Device 009: ID 3301:1000
> > > Device Descriptor:
> > > bLength 18
> > > bDescriptorType 1
> > > bcdUSB 2.00
> > > bDeviceClass 239 Miscellaneous Device
> > > bDeviceSubClass 2
> > > bDeviceProtocol 1 Interface Association
> > > bMaxPacketSize0 64
> > > idVendor 0x3301
> > > idProduct 0x1000
> > > bcdDevice 0.10
> > > iManufacturer 1 Rhonda
> > > iProduct 2 Rhonda Cam
> > > iSerial 3 FMABCLE15000007
> > > bNumConfigurations 1
>
> Thank you for the descriptors.
>
> [snip]
>
> > > VideoControl Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 36
> > > bDescriptorSubtype 3 (OUTPUT_TERMINAL)
> > > bTerminalID 16
> > > wTerminalType 0x0101 USB Streaming
> > > bAssocTerminal 0
> > > bSourceID 10
> > > iTerminal 0
> > > VideoControl Interface Descriptor:
> > > bLength 9
> > > bDescriptorType 36
> > > bDescriptorSubtype 3 (OUTPUT_TERMINAL)
> > > bTerminalID 17
> > > wTerminalType 0x0101 USB Streaming
> > > bAssocTerminal 0
> > > bSourceID 10
> > > iTerminal 0
>
> Two output terminals ? Does that mean the device can provide two streams
> from the same source ?
Correct. This device encode and stream two indpendent H264 or HEVC video streams.
Picture for both streams comes from single image sensor, with own ROI applied for each stream.
>
> [snip]
>
>
> > > Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x83 EP 3 IN
> > > bmAttributes 2
> > > Transfer Type Bulk
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0200 1x 512 bytes
> > > bInterval 0
>
> This is interesting too, does it provide enough bandwidth for 3000x4000
> @10fps MJPEG ?
This video mode has relatively high compression ratio thus total bitrate
for this mode does not exceed 100Mbps.
>
> [snip]
>
> > >>> Is there anything else needed to get HEVC capture working, such as
> > >>> extension unit controls, or is this patch enough ? What userspace
> > >>> software do you use to capture and decode HEVC (or capture it to disk) ?
> > >>
> > >> No other changes to Linux nor extra actions needed to start HEVC capture.
> > >> We use patched version of FFmpeg to capture, decode and display HEVC
> > >> stream from camera device. That simple patch also going to be sent to
> > >> FFmpeg upstream.
> > >
> > > Patch for FFmpeg sent to https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1760
> > >
> > >>>> Signed-off-by: Dmitry Buzdyk <dima.buzdyk@gmail.com>
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> and taken in my tree. I'm afraid we're a bit too close to the v5.9 merge
> window for me to send a pull request now, unless Mauro would be fine
> with that. Otherwise I'll include it in the pull request for the next
> release.
>
> > >>>> ---
> > >>>> drivers/media/usb/uvc/uvc_driver.c | 5 +++++
> > >>>> drivers/media/usb/uvc/uvcvideo.h | 4 ++++
> > >>>> 2 files changed, 9 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> > >>>> index 431d86e1c94b..825ee3601661 100644
> > >>>> --- a/drivers/media/usb/uvc/uvc_driver.c
> > >>>> +++ b/drivers/media/usb/uvc/uvc_driver.c
> > >>>> @@ -214,6 +214,11 @@ static struct uvc_format_desc uvc_fmts[] = {
> > >>>> .guid = UVC_GUID_FORMAT_CNF4,
> > >>>> .fcc = V4L2_PIX_FMT_CNF4,
> > >>>> },
> > >>>> + {
> > >>>> + .name = "HEVC",
> > >>>> + .guid = UVC_GUID_FORMAT_HEVC,
> > >>>> + .fcc = V4L2_PIX_FMT_HEVC,
> > >>>> + },
> > >>>> };
> > >>>>
> > >>>> /* ------------------------------------------------------------------------
> > >>>> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> > >>>> index 6ab972c643e3..c7f043121b41 100644
> > >>>> --- a/drivers/media/usb/uvc/uvcvideo.h
> > >>>> +++ b/drivers/media/usb/uvc/uvcvideo.h
> > >>>> @@ -165,6 +165,10 @@
> > >>>> {0x32, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00, \
> > >>>> 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> > >>>>
> > >>>> +#define UVC_GUID_FORMAT_HEVC \
> > >>>> + { 'H', 'E', 'V', 'C', 0x00, 0x00, 0x10, 0x00, \
> > >>>> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> > >>>> +
> > >>>>
> > >>>> /* ------------------------------------------------------------------------
> > >>>> * Driver specific constants.
>
> --
> Regards,
>
> Laurent Pinchart
--
Dmitry Buzdyk
Rhonda Software
prev parent reply other threads:[~2020-07-29 6:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 1:05 [RFC PATCH] uvcvideo: Add mapping for HEVC payloads Dmitry Buzdyk
2020-06-07 1:07 ` Laurent Pinchart
2020-06-09 4:57 ` Dmitry Buzdyk
2020-07-15 8:00 ` Dmitry Buzdyk
2020-07-27 23:25 ` Dmitry Buzdyk
2020-07-28 0:17 ` Laurent Pinchart
2020-07-29 6:26 ` Dmitry Buzdyk [this message]
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=20200729062602.GA258740@dmitry-T520 \
--to=dima.buzdyk@gmail.com \
--cc=ethan.hsieh@canonical.com \
--cc=jesse.sung@canonical.com \
--cc=john.agosta@canonical.com \
--cc=kevin.lu@canonical.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@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.