All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Cc: kernel@pengutronix.de
Subject: Re: [PATCH 08/10] media: coda: allow encoder to set colorimetry on the output queue
Date: Wed, 10 Apr 2019 16:23:02 +0200	[thread overview]
Message-ID: <1554906182.3765.10.camel@pengutronix.de> (raw)
In-Reply-To: <1c5e978c-eecb-8847-8746-51e83e48ae85@xs4all.nl>

On Wed, 2019-04-10 at 15:48 +0200, Hans Verkuil wrote:
[...]
> Isn't the colorimetry information encoded in the stream's metadata?

That depends on the codec. Colorimetry information can be stored in
optional headers (for example Sequence Display Extension for MPEG-2,
Video Usability Information for H.264) but I don't know that the CODA
firmware can parse or generate any of them.

> So should it be set i an encoder register so it ends up in the right
> place in the bitstream?

I could produce the necessary headers manually and inject them into the
bitstream in the driver.

But for example for JPEG it is not clear to me if there even is a
correct way to do that. Can V4L2 colorimetry settings be translated into
ICC profiles?

> And for decoders it should then be read back from a register.

Same as above, I'd have to parse the headers in the driver.

> Just curious how this would work for this codec and if it is even possible.
> 
> For now this patch is OK, but I think more work is needed.

Agreed.

regards
Philipp

  reply	other threads:[~2019-04-10 14:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 12:32 [PATCH 01/10] media: coda: set codec earlier Philipp Zabel
2019-04-08 12:32 ` [PATCH 02/10] media: coda: remove mask from decoder h.264 level control Philipp Zabel
2019-04-08 12:32 ` [PATCH 03/10] media: coda: clear error return value before picture run Philipp Zabel
2019-04-08 12:32 ` [PATCH 04/10] media: coda: add min number of buffers controls Philipp Zabel
2019-04-08 12:32 ` [PATCH 05/10] media: coda: disable encoder command on decoder and vice versa Philipp Zabel
2019-04-08 12:32 ` [PATCH 06/10] media: coda: implement encoder frame size enumeration Philipp Zabel
2019-04-08 12:32 ` [PATCH 07/10] media: coda: limit frame interval enumeration to supported frame sizes Philipp Zabel
2019-04-10 13:43   ` Hans Verkuil
2019-04-10 14:22     ` Philipp Zabel
2019-04-10 16:11       ` Nicolas Dufresne
2019-04-10 16:24         ` Hans Verkuil
2019-04-11  8:22           ` Philipp Zabel
2019-04-11 10:18             ` Hans Verkuil
2019-04-11 11:52               ` Ian Arkver
2019-04-11 12:00               ` Philipp Zabel
2019-04-11 15:53                 ` Nicolas Dufresne
2019-04-15  5:32                   ` Tomasz Figa
2019-04-08 12:32 ` [PATCH 08/10] media: coda: allow encoder to set colorimetry on the output queue Philipp Zabel
2019-04-10 13:48   ` Hans Verkuil
2019-04-10 14:23     ` Philipp Zabel [this message]
2019-04-08 12:32 ` [PATCH 09/10] media: coda: throw error on create_bufs with too small size Philipp Zabel
2019-04-08 12:32 ` [PATCH 10/10] media: coda: require all decoder command flags to be cleared Philipp Zabel
2019-04-09 16:57   ` Philipp Zabel
2019-04-10 13:53     ` Hans Verkuil

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=1554906182.3765.10.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@pengutronix.de \
    --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.