All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Pawel Osciak <posciak@chromium.org>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Kamil Debski <k.debski@samsung.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v1 16/19] v4l: Add encoding camera controls.
Date: Thu, 12 Sep 2013 06:20:23 +0200	[thread overview]
Message-ID: <52314107.60903@xs4all.nl> (raw)
In-Reply-To: <CACHYQ-rTaU5mgQ=p1ARx+PDk8wPR5yVxhJob5hHGxLg8zjne8g@mail.gmail.com>

Hi Pawel,

On 09/12/2013 03:10 AM, Pawel Osciak wrote:
> On Tue, Sep 10, 2013 at 6:17 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On Mon 9 September 2013 11:09:57 Sylwester Nawrocki wrote:
>>> On 09/09/2013 11:00 AM, Kamil Debski wrote:
>>> [...]
>>>>>>> We have QP controls separately for H264, H263 and MPEG4. Why is that?
>>>>>>> Which one should I use for VP8? Shouldn't we unify them instead?
>>>>>>
>>>>>> I can't quite remember the details, so I've CCed Kamil since he added
>>>>> those controls.
>>>>>> At least the H264 QP controls are different from the others as they
>>>>>> have a different range. What's the range for VP8?
>>>>>
>>>>> Yes, it differs, 0-127.
>>>>> But I feel this is pretty unfortunate, is it a good idea to multiply
>>>>> controls to have one per format when they have different ranges
>>>>> depending on the selected format in general? Perhaps a custom handler
>>>>> would be better?
>>>>>
>>>>>> I'm not sure why the H263/MPEG4 controls weren't unified: it might be
>>>>>> that since the
>>>>>> H264 range was different we decided to split it up per codec. But I
>>>>>> seem to remember that there was another reason as well.
>>>>
>>>> We had a discussion about this on linux-media mailing list. It can be found
>>>> here:
>>>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/32606
>>>> In short, it is a mix of two reasons: one - the valid range is different for
>>>> different formats and second - implementing controls which have different
>>>> min/max values depending on format was not easy.
>>>
>>> Hmm, these seem pretty vague reasons. And since some time we have support
>>> for dynamic control range update [1].
>>
>> I don't think we should change this. We chose to go with separate controls,
>> and we should stick with that. We might do it differently today, but it's
>> not a big deal.
> 
> I guess I can't reuse MPEG controls as you suggested then.

Sure you can. Just call it V4L2_CID_MPEG_VIDEO_VPX_MIN_QP etc. The name 'MPEG'
was an unfortunate choice, it should have been 'CODEC'. And in fact in the spec
it's now known as the Codec Control Class. The QP settings are most definitely
codec controls, not camera or vpx controls.

> But I could
> either create a new VPX class, or keep these ones in camera class and
> create separate VPX class later for codecs. It's technically possible
> for UVC to have different constraints on some controls though, even if
> the codec is the same, potentially creating more confusion...

That's nothing new for uvc and there isn't anything you can do about it.
I don't think this will cause problems in practice.

Regards,

	Hans

> 
> 
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>>> On the one hand I am thinking that now, when we have more codecs, it would
>>>> be better
>>>> to have a single control, on the other hand what about backward
>>>> compatibility?
>>>> Is there a graceful way to merge H263 and H264 QP controls?
>>>
>>> [1] https://patchwork.linuxtv.org/patch/16436/
>>>
>>> --
>>> Regards,
>>> Sylwester
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>

  reply	other threads:[~2013-09-12  4:20 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30  2:16 [PATCH v1 00/19] UVC 1.5 VP8 support for uvcvideo Pawel Osciak
2013-08-30  2:17 ` [PATCH v1 01/19] uvcvideo: Add UVC query tracing Pawel Osciak
2013-09-03 20:17   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 02/19] uvcvideo: Return 0 when setting probe control succeeds Pawel Osciak
2013-09-03 20:21   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 03/19] uvcvideo: Add support for multiple chains with common roots Pawel Osciak
2013-11-10 20:37   ` Laurent Pinchart
2013-11-11 13:55     ` Paulo Assis
2013-08-30  2:17 ` [PATCH v1 04/19] uvcvideo: Create separate debugfs entries for each streaming interface Pawel Osciak
2013-09-03 20:28   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 05/19] uvcvideo: Add support for UVC1.5 P&C control Pawel Osciak
2013-09-03 20:42   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 06/19] uvcvideo: Recognize UVC 1.5 encoding units Pawel Osciak
2013-11-10 21:46   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 07/19] uvcvideo: Unify error reporting during format descriptor parsing Pawel Osciak
2013-09-03 20:55   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 08/19] uvcvideo: Add UVC1.5 VP8 format support Pawel Osciak
2013-11-10 22:30   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 09/19] uvcvideo: Reorganize uvc_{get,set}_le_value Pawel Osciak
2013-11-10 22:34   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 10/19] uvcvideo: Support UVC 1.5 runtime control property Pawel Osciak
2013-08-30  6:36   ` Hans Verkuil
2013-11-10 22:51   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 11/19] uvcvideo: Support V4L2_CTRL_TYPE_BITMASK controls Pawel Osciak
2013-11-10 22:57   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 12/19] uvcvideo: Reorganize next buffer handling Pawel Osciak
2013-11-10 23:43   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 13/19] uvcvideo: Unify UVC payload header parsing Pawel Osciak
2013-11-11  1:27   ` Laurent Pinchart
2013-11-11  1:46   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 14/19] v4l: Add v4l2_buffer flags for VP8-specific special frames Pawel Osciak
2013-08-30  6:42   ` Hans Verkuil
     [not found]     ` <CACHYQ-pUhmPhMrbE8QWM+r6OWbBnOx7g6vjQvOxBSoodnPk4+Q@mail.gmail.com>
2013-08-30  8:12       ` Hans Verkuil
2013-08-31 17:42         ` Sakari Ailus
2013-08-31 17:44   ` Sakari Ailus
2013-11-11  1:27   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 15/19] uvcvideo: Add support for VP8 special frame flags Pawel Osciak
2013-11-11  1:49   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 16/19] v4l: Add encoding camera controls Pawel Osciak
2013-08-30  6:48   ` Hans Verkuil
2013-09-09  3:48     ` Pawel Osciak
2013-09-09  7:52       ` Hans Verkuil
2013-09-09  7:59         ` Pawel Osciak
2013-09-09  9:00           ` Kamil Debski
2013-09-09  9:09             ` Sylwester Nawrocki
2013-09-10  9:17               ` Hans Verkuil
2013-09-12  1:10                 ` Pawel Osciak
2013-09-12  4:20                   ` Hans Verkuil [this message]
2013-11-11  1:53   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 17/19] uvcvideo: Add UVC 1.5 Encoding Unit controls Pawel Osciak
2013-11-11  2:33   ` Laurent Pinchart
2013-08-30  2:17 ` [PATCH v1 18/19] v4l: Add V4L2_PIX_FMT_VP8_SIMULCAST format Pawel Osciak
2013-08-31 17:52   ` Sakari Ailus
2013-08-30  2:17 ` [PATCH v1 19/19] uvcvideo: Add support for UVC 1.5 VP8 simulcast Pawel Osciak
2013-10-10 10:27 ` [PATCH v1 00/19] UVC 1.5 VP8 support for uvcvideo Paulo Assis
2013-11-11  2:05   ` Laurent Pinchart
2013-11-11 10:00     ` Paulo Assis

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=52314107.60903@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=k.debski@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=posciak@chromium.org \
    --cc=s.nawrocki@samsung.com \
    /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.