From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754162AbdCBHyR (ORCPT ); Thu, 2 Mar 2017 02:54:17 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:20006 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132AbdCBHyL (ORCPT ); Thu, 2 Mar 2017 02:54:11 -0500 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfec7f4-f79716d000006f65-22-58b7ccfed787 Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt To: Nicolas Dufresne , Thibault Saunier , linux-kernel@vger.kernel.org Cc: Mauro Carvalho Chehab , Marek Szyprowski , Kukjin Kim , Mauro Carvalho Chehab , Andi Shyti , linux-media@vger.kernel.org, Shuah Khan , Javier Martinez Canillas , linux-samsung-soc@vger.kernel.org, Krzysztof Kozlowski , Inki Dae , Sylwester Nawrocki , linux-arm-kernel@lists.infradead.org, Ulf Hansson , Jeongtae Park , Kyungmin Park , Kamil Debski From: Andrzej Hajda Message-id: <54862f6b-290d-7e87-4297-57ffc35d357a@samsung.com> Date: Thu, 02 Mar 2017 08:42:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-reply-to: <1488381666.14858.5.camel@collabora.com> Content-transfer-encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/fufqjNbtPqzT6MRVJhWmB4soi0gosSaEGKBbXyopJabakZ SBY4nZYOLVKRENr8Iq2u8yNZpjY/wtRCiyS3QsvMlEQXFGo1dw3873nPeX7Pe96Xw5KKUcqL jU+6IqiTVAlK2lXW0Pm7f9ffV41Ru0tP4UbLGIULPupleHLqIYEtNW8JXNydReH80e8k7u9/ zODem5MMFkffUXiguZTGtx7XU7iov4XANRYrg8vFeQJ/NFzGzXYbjV9MOtC79mkZnm0tIHFX TeQhT77JakC8WK2j+eF3ZpqvM1znTflWhhdnrBSfZ6pG/Ky4mR+03GDCXaJdD8QICfEpgtr/ 4FnXOF2Lmbj0w/1q7kAFk4G+uOUgFxa4AGgaHpNJei28tj2ic5Arq+CMCO7Mf2OkYhbBjLbP 4WKdRJ4tUDovR2D/oEWLtJxbDb8Kbc4kktsB4/YCmWQaQ6DLsjtNHtw5qB6ZdqZ6cjkIfjdX IYmopWBcv3VR0w56oW6IllIPglEvOj0ybhvcyBxmFvUaLgqa3t9yely4vZBvKCakHG9oG/zq 7AyckYW+uQlaevYmEFtJac4jIGZPM5L2gIku05LeCAOFuUtsrmPk/G5GKu4g+DNdtETvhxdd byipmzsUNNwjpQZyyNYqJAsPC7V/CUkHQ9vUhBNVcPUENBtBj7xLlm2sZNnGSpbNUIbIauQp JGsSYwVNgJ9GlahJTor1O38xUUSOr9fzp8vehB50BrUjjkXKlfK4FY1RCkqVoklLbEfAkkpP +XqL40geo0q7JqgvnlEnJwiadrSBlSnXyc1lg5EKLlZ1RbggCJcE9f9bgnXxykBhYcf9xjtp 9XZjq21F5khQb/BT/3MUKLWt7qd/Gk8G3T/6uZBSv+92O5kbeNMntK0yLmC9TjBYK9JD7oam m1K2qKDqW7ZYeUTb4ntsKOJTR7Rvmo+8IudJ6ks6POKw+cQqfWb33PN9qSmmhme6dtJOm2/n dXiYQgKTRuomej4rZZo41Z6dpFqj+gdtLxEXdgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42I5/e/4ZV22s9sjDE4eNLPYfuQZq8Wk+xNY LN68XcNkcWTtVSaLmSfaWS36H79mtjh/fgO7xdmmN+wWmx5fY7W4vGsOm0XPhq2sFjPO72Oy WHvkLrvFsk1/mCzuLym02PXlHpvF4TdArVO/fGCx+HxgErPF8bXhDiIeO+4uYfTYtKqTzePO tT1sHpuX1Hts6b/L7rHp011Wj74tqxg9Pm+S87hypJE9gDPKzSYjNTEltUghNS85PyUzL91W KTTETddCSSEvMTfVVilC1zckSEmhLDGnFMgzMkADDs4B7sFK+nYJbhmd+/YwFbznq+i+vJy9 gfEpdxcjB4eEgIlE3z3zLkZOIFNM4sK99WwgtpDAEkaJ499CQWxeAUGJH5PvsYCUMwuoS0yZ ktvFyAVU8oxR4vbEK+wgNcICSRL7rp9iAkmICPQwSsz7eJsFomork8S2jWuZQRxmgQ2sEuvX HGAFaWET0JT4u/kmG8QKO4mlEzYxgtgsAqoSja13wMaKCkRIzH+6ignE5hQwlehfMhPMZhaQ lzh45TnLBEaBWUgunIVw4SwkVQsYmVcxiqSWFuem5xYb6RUn5haX5qXrJefnbmIExv+2Yz+3 7GDsehd8iFGAg1GJh/cA0/YIIdbEsuLK3EOMEhzMSiK8kkeAQrwpiZVVqUX58UWlOanFhxhN gW6dyCwlmpwPTE15JfGGJobmloZGxhYW5kZGSuK8Uz9cCRcSSE8sSc1OTS1ILYLpY+LglGpg NN6tVCq98FPQb/+qae3bTWZ/DmndWSH7pbtdUveku5OFhv/vxS//vinZEKDmaimmob4oam60 9iXR62d2i+Vc2rV15x7FhPWsfwvZ1/jObZnKd8MgQV/j+ox3Bx8m9p0ucX0rdv77GplnIcXO ftW1V+Nbd+S+9dy2ri/+voeI11dLxyW7gkJuK7EUZyQaajEXFScCAHOsoL0VAwAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170302074254eucas1p2094ef729f0cf33e3ff82634e50518686 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?QW5kcnplaiBIYWpkYRtTUlBPTC1LZXJuZWwgKFRQKRvsgrw=?= =?UTF-8?B?7ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?QW5kcnplaiBIYWpkYRtTUlBPTC1LZXJuZWwgKFRQKRtTYW1z?= =?UTF-8?B?dW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170301115141epcas2p37801b1fbe0951cc37a4e01bf2bcae3da X-RootMTR: 20170301115141epcas2p37801b1fbe0951cc37a4e01bf2bcae3da References: <20170301115108.14187-1-thibault.saunier@osg.samsung.com> <20170301115108.14187-3-thibault.saunier@osg.samsung.com> <33dbd3fa-04b2-3d94-5163-0a10589ff1c7@samsung.com> <1488381666.14858.5.camel@collabora.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01.03.2017 16:21, Nicolas Dufresne wrote: > 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. The whole point is that s_fmt on output side is to describe format of the stream passed to the device, and in case of decoder it is just mpeg/h.26x/... stream. It does not contain frames, fields, width, height - it is just raw stream of bytes. We cannot say in such case about field type, there is not such thing as interlaced byte stream. Using s_fmt on output to describe things on capture side look for me unnecessary and abuses V4L2 API IMO. > > 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. > Documentation for MFC6.5 states clearly: > Note: On SEQ_DONE, INTERLACE_PICTURE will return the picture type to > be decoded based on the > sequence header information. In case of MFC5.1 it is unclear, but I hope HW behaves the same way. Anyway I agree it will be good to fix it at least for MFC6.5+, any volunteer? Regards Andrzej