Hi Ezequiel, On Wed, 2019-11-13 at 16:42 -0300, Ezequiel Garcia wrote: > Hi Philipp, > > Thanks a lot for working on this. I'm so glad about > both efforts: the CODA JPEG support and the JPEG > helpers. > > On Wed, 2019-11-13 at 16:05 +0100, Philipp Zabel wrote: > > Hi, > > > > as far as I can tell we currently have three JPEG header parsers in the > > media tree (in the rcar_jpu, s5p-jpeg, and mtk-jpeg drivers). I would > > like to add support for the CODA960 JPEG decoder to the coda-vpu driver > > without adding yet another. > > > > To this end, this patch series adds some common JPEG code to v4l2-core. > > For now this just contains header parsing helpers (I have tried to keep > > the terminology close to JPEG ITU-T.81) that should be usable for all of > > the current drivers. In the future we might want to move JPEG header > > generation for encoders and common quantization tables in there as well. > > > > Indeed, moving encoders to use these helpers sounds like the right thing > to do. IIRC, quantization tables are implementation defined, and not imposed > by anything. I believe gspca drivers use some tables that don't follow > any recomendation. Right. I was just thinking of the default tables from Annex K.3. I'll have to recheck what's up with the CODA q tables, but the Huffman tables are identical between hantro_jpeg and coda-jpeg. I suppose we could make the tables userspace controlled for those drivers that support arbitrary ones. > I guess it's fine to leave some drivers unconverted, without using any helpers, > and move others to use a helper-derived quantization table. Agreed. regards Philipp
