From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
Thibault Saunier <thibault.saunier@osg.samsung.com>,
linux-kernel@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Mauro Carvalho Chehab <mchehab@s-opensource.com>,
Andi Shyti <andi.shyti@samsung.com>,
linux-media@vger.kernel.org, Shuah Khan <shuahkh@osg.samsung.com>,
Javier Martinez Canillas <javier@osg.samsung.com>,
linux-samsung-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Inki Dae <inki.dae@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
linux-arm-kernel@lists.infradead.org,
Ulf Hansson <ulf.hansson@linaro.org>,
Jeongtae Park <jtp.park@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Kamil Debski <kamil@wypas.org>
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 10:21:06 -0500 [thread overview]
Message-ID: <1488381666.14858.5.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,
> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!
I think we need some nuance here for this to actually be usable. If the
information is not provided by the driver (yes, hardware is limiting
sometimes), it would make sense to copy over the information that
userspace provided. Setting NONE is just the worst approximation in my
opinion.
About MFC, it will be worth trying to read the DISPLAY_STATUS after the
headers has been processed. It's not clearly stated in the spec if this
will be set or not.
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
Thibault Saunier <thibault.saunier@osg.samsung.com>,
linux-kernel@vger.kernel.org
Cc: Inki Dae <inki.dae@samsung.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-samsung-soc@vger.kernel.org,
Jeongtae Park <jtp.park@samsung.com>,
Shuah Khan <shuahkh@osg.samsung.com>,
Andi Shyti <andi.shyti@samsung.com>,
Kamil Debski <kamil@wypas.org>,
Mauro Carvalho Chehab <mchehab@s-opensource.com>,
Javier Martinez Canillas <javier@osg.samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 10:21:06 -0500 [thread overview]
Message-ID: <1488381666.14858.5.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --]
Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,
> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!
I think we need some nuance here for this to actually be usable. If the
information is not provided by the driver (yes, hardware is limiting
sometimes), it would make sense to copy over the information that
userspace provided. Setting NONE is just the worst approximation in my
opinion.
About MFC, it will be worth trying to read the DISPLAY_STATUS after the
headers has been processed. It's not clearly stated in the spec if this
will be set or not.
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: nicolas.dufresne@collabora.com (Nicolas Dufresne)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt
Date: Wed, 01 Mar 2017 10:21:06 -0500 [thread overview]
Message-ID: <1488381666.14858.5.camel@collabora.com> (raw)
In-Reply-To: <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com>
Le mercredi 01 mars 2017 ? 14:12 +0100, Andrzej Hajda a ?crit?:
> - on output side you have encoded bytestream - you cannot say about
> interlacing in such case, so the only valid value is NONE,
> - on capture side you have decoded frames, and in this case it
> depends
> on the device and driver capabilities, if the driver/device does not
> support (de-)interlacing (I suppose this is MFC case), interlace type
> field should be filled according to decoded bytestream header (on
> output
> side), but no direct copying from output side!!!
I think we need some nuance here for this to actually be usable. If the
information is not provided by the driver (yes, hardware is limiting
sometimes), it would make sense to copy over the information that
userspace provided. Setting NONE is just the worst approximation in my
opinion.
About MFC, it will be worth trying to read the DISPLAY_STATUS after the
headers has been processed. It's not clearly stated in the spec if this
will be set or not.
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170301/cd10c72b/attachment.sig>
next prev parent reply other threads:[~2017-03-01 15:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 11:51 [PATCH v6 0/2] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 11:51 ` [PATCH v6 1/2] [media] exynos-gsc: Use user configured colorspace if provided Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-10 10:31 ` Hans Verkuil
2017-03-10 10:31 ` Hans Verkuil
2017-03-01 11:51 ` [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 11:51 ` Thibault Saunier
2017-03-01 13:12 ` Andrzej Hajda
2017-03-01 13:12 ` Andrzej Hajda
2017-03-01 13:12 ` Andrzej Hajda
2017-03-01 13:20 ` Thibault Saunier
2017-03-01 13:20 ` Thibault Saunier
2017-03-01 13:20 ` Thibault Saunier
2017-03-01 14:35 ` Nicolas Dufresne
2017-03-01 14:35 ` Nicolas Dufresne
2017-03-01 14:35 ` Nicolas Dufresne
2017-03-01 14:41 ` Thibault Saunier
2017-03-01 14:41 ` Thibault Saunier
2017-03-01 14:41 ` Thibault Saunier
2017-03-01 15:21 ` Nicolas Dufresne [this message]
2017-03-01 15:21 ` Nicolas Dufresne
2017-03-01 15:21 ` Nicolas Dufresne
2017-03-02 7:42 ` Andrzej Hajda
2017-03-02 7:42 ` Andrzej Hajda
2017-03-02 7:42 ` Andrzej Hajda
2017-03-10 10:45 ` Hans Verkuil
2017-03-10 10:45 ` 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=1488381666.14858.5.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=a.hajda@samsung.com \
--cc=andi.shyti@samsung.com \
--cc=inki.dae@samsung.com \
--cc=javier@osg.samsung.com \
--cc=jtp.park@samsung.com \
--cc=kamil@wypas.org \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=mchehab@s-opensource.com \
--cc=s.nawrocki@samsung.com \
--cc=shuahkh@osg.samsung.com \
--cc=thibault.saunier@osg.samsung.com \
--cc=ulf.hansson@linaro.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.