Hi, > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > Sent: Tuesday, September 30, 2014 4:25 PM > To: Philipp Zabel > Cc: Kamil Debski; Mauro Carvalho Chehab; Hans Verkuil; linux- > media@xxxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx > Subject: Re: [PATCH 00/10] CODA7 JPEG support > > 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? I agree with you Hans. MFC has a single encoder node that supports multiple codecs and I think this design works well. JPEG should be separated into separate device. Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
