Le vendredi 04 novembre 2016 ? 14:55 +0100, Hugues FRUCHET a ?crit?:
> >>
> >> I can help on H264 on a code review basis based on the functional H264
> >> setup I have in-house and codec knowledge, but I cannot provide
> >> implementation in a reasonable timeframe, same for VP8.
> >>
> >>
> >>
> >> Apart of very details of each codec, we have also to state about generic
> >> concerns such as:
> >>
> >> -????????? new pixel format introduction (VP8 => VP8F, H264 => S264,
> >> MPG2 => MG2F, MPG4 => MG4F)
> > I don't think it is necessary.
>
> But currently it is done that way in all patches proposals I have seen?
> so far, including rockchip:
> rockchip_decoder_v4l2.c:{VAProfileH264Baseline,V4L2_PIX_FMT_H264_SLICE},
>
> We have to state about it all together. Seems natural to me to do this?
> way instead of device caps.
> Doing so user knows that the driver is based on "Frame API" -so?
> additional headers are required to decode input stream- and not
> on "Stream API" -H264 stream can be decoded directly-.
We should probably use something else then "STREAMING" in the
capabilities instead of duplicating all the encoding formats (exception
to H264 byte-stream and H264 AVC, that also applies to streaming
drivers and there is not easy way to introduce stream-format in the API
atm). Other then that, this solution works, so it could just be
considered the right way, I just find it less elegant personally.
my two cents,
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20161104/ebc30765/attachment.sig>
