From: Hans Verkuil <hverkuil@xs4all.nl>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Kamil Debski <k.debski@samsung.com>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
linux-media@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH 00/10] CODA7 JPEG support
Date: Tue, 30 Sep 2014 16:24:31 +0200 [thread overview]
Message-ID: <542ABD1F.9000701@xs4all.nl> (raw)
In-Reply-To: <1412086849.3692.3.camel@pengutronix.de>
On 09/30/14 16:20, Philipp Zabel wrote:
> Hi Hans,
>
> Am Dienstag, den 30.09.2014, 15:43 +0200 schrieb Hans Verkuil:
>> On 09/30/14 11:57, Philipp Zabel wrote:
>>> Hi,
>>>
>>> These patches add JPEG encoding and decoding support for CODA7541 (i.MX5).
>>> The encoder video device is split into one video device per codec, so that
>>> each video device can register only the relevant controls. The H.264/MPEG4
>>> decoder is kept as one video device, but the JPEG decoder video device is
>>> separate because it supports more uncompressed formats (currently YUV422P,
>>> in the future grayscale or YUV 4:4:4 support could be added).
>>
>> Normally device nodes are linked to DMA engines, so the only reason why you
>> would have e.g. two video nodes is if you can capture from both at the same
>> time. Is that the case here as well? If not, then it really should be a
>> single video node. That not all controls are relevant for the currently
>> chosen codec is not important.
>>
>> Are there other reasons than the controls to split it up into multiple video
>> devices?
>
> I had already split the encoder and decoder parts of this mem2mem device
> into two video devices because of the issue of changing available
> capture formats depending on the selected output format.
> The motivation for splitting the JPEG codecs from the H264/MPEG4 codecs
> is the same: to avoid the appearing and disappearing of the YUV422P
> format on the uncompressed side whenever the compressed format changes
> between JPEG and H264/MPEG4. I could keep the H264 and MPEG4 encoders
> combined without running into this issue.
>
> Furthermore, I want to change the output queue for the currently
> available decoders to use vb2-vmalloc eventually (because the CPU has to
> copy incoming frames into the bitstream buffer), but have to keep using
> vb2-dma-contig for the CODA960 JPEG decoder, which will have the
> hardware read from the incoming buffers directly.
Based on this description I think it makes sense to split off the JPEG
encoder, but I would keep H264/MPEG4 together. Kamil, what's your opinion
on this?
Regards,
Hans
next prev parent reply other threads:[~2014-09-30 14:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 9:57 [PATCH 00/10] CODA7 JPEG support Philipp Zabel
2014-09-30 9:57 ` [PATCH 01/10] [media] coda: add support for planar YCbCr 4:2:2 (YUV422P) format Philipp Zabel
2014-09-30 9:57 ` [PATCH 02/10] [media] coda: identify platform device earlier Philipp Zabel
2014-09-30 9:57 ` [PATCH 03/10] [media] coda: add coda_video_device descriptors Philipp Zabel
2014-09-30 9:57 ` [PATCH 04/10] [media] coda: split out encoder control setup to specify controls per video device Philipp Zabel
2014-09-30 9:57 ` [PATCH 05/10] [media] coda: add JPEG register definitions for CODA7541 Philipp Zabel
2014-09-30 9:57 ` [PATCH 06/10] [media] coda: add CODA7541 JPEG support Philipp Zabel
2014-09-30 9:57 ` [PATCH 07/10] [media] coda: store bitstream buffer position with buffer metadata Philipp Zabel
2014-09-30 9:57 ` [PATCH 08/10] [media] coda: pad input stream for JPEG decoder Philipp Zabel
2014-09-30 9:57 ` [PATCH 09/10] [media] coda: try to only queue a single JPEG into the bitstream Philipp Zabel
2014-09-30 9:57 ` [PATCH 10/10] [media] coda: allow userspace to set compressed buffer size in a certain range Philipp Zabel
2014-09-30 13:43 ` [PATCH 00/10] CODA7 JPEG support Hans Verkuil
2014-09-30 14:20 ` Philipp Zabel
2014-09-30 14:24 ` Hans Verkuil [this message]
2014-09-30 14:34 ` Kamil Debski
2014-10-01 13:33 ` Nicolas Dufresne
2014-10-01 15:40 ` Philipp Zabel
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=542ABD1F.9000701@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=hans.verkuil@cisco.com \
--cc=k.debski@samsung.com \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=p.zabel@pengutronix.de \
/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.