Le jeudi 16 novembre 2017 à 12:02 +0100, Maxime Ripard a écrit : > Assuming that the request API is in, we'd need to: > - Finish the MPEG4 support > - Work on more useful codecs (H264 comes to my mind) For which we will have to review the tables and make sure they match the spec (the easy part). But as an example, that branch uses a table that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does not pause problems or split it up. On top of that, ST and Rockchip teams should give some help and sync with these tables on their side. We also need to consider decoder like Tegra 2. In H264, they don't need frame parsing, but just the PPS/SPS data (might just be parsed in the driver, like CODA ?). There is other mode of operation, specially in H264/HEVC low latency, where the decoder will be similar, but will accept and process slices right away, without waiting for the full frame. We also need some doc, to be able to tell the GStreamer and FFMPEG team how to detect and handle these decoder. I doubt the libv4l2 proposed approach will be used for these two projects since they already have their own parser and would like to not parse twice. As an example, we need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the Request API and specific CID. We should probably also ping the Chrome Devs, which probably have couple of pending branches around this. regards, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
