Hi Philipp, Ezequiel, On 11/13/19 8:42 PM, 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. > > I guess it's fine to leave some drivers unconverted, without using any helpers, > and move others to use a helper-derived quantization table. I fully agree here. I don't have longer access to Exynos4x12 and 3250 based boards to test the patches and the volume of changes allows to assume that not everything will go smoothly. That can lead to unpleasant hangups during decoding, caused by not arrived IRQ when e.g. unsupported JPEG->raw format subsampling transition is requested. >> I have tested this on hardware only with coda-vpu, the other drivers are >> just compile-tested. >> >> Feedback very welcome, especially whether this actually works for the >> other drivers, and if this could be structured any better. I'm a bit >> unhappy with the (current) need for separate frame/scan header and >> quantization/hfufman table parsing functions, but those are required >> by s5p-jpeg, which splits localization and parsing of the marker >> segments. Also, could this be used for i.MX8 JPEGDEC as is? >> > [..] > > Regards, > Ezequiel > > -- Best regards, Jacek Anaszewski
