On 04/10/17 09:54, wm4 wrote: > On Wed, 4 Oct 2017 09:07:11 +0100 > Mark Thompson <s...@jkqxz.net> wrote: > >> --- >> libavcodec/h263dec.c | 10 ++++++++++ >> libavcodec/h264dec.c | 19 +++++++++++++++++++ >> libavcodec/hevcdec.c | 19 +++++++++++++++++++ >> libavcodec/hwaccel.h | 27 +++++++++++++++++++++++++++ >> libavcodec/mmaldec.c | 7 +++++++ >> libavcodec/mpeg12dec.c | 24 +++++++++++++++++++++++- >> libavcodec/mpeg4videodec.c | 10 ++++++++++ >> libavcodec/qsvdec.c | 11 +++++++++++ >> libavcodec/qsvdec.h | 2 ++ >> libavcodec/qsvdec_h2645.c | 2 ++ >> libavcodec/qsvdec_other.c | 3 +++ >> libavcodec/vc1dec.c | 19 +++++++++++++++++++ >> libavcodec/vp8.c | 7 +++++++ >> 13 files changed, 159 insertions(+), 1 deletion(-) > > LGTM. The macros seem a bit messy on the first look, but I like that > the line noise/duplication is kept to a minimum. > > I _think_ with this we could easily remove the get_format mess in the > decoders. See for example hevcdec.c/get_format(): we go through lots of > effort and ifdeffery to build the pix_fmts[] array, which seems dumb. > Just mentioning that in case someone complains that this patch adds > more ifdeffery.
Not sure. You have annoying cases with only subsets of formats (e.g. 8-bit only or only YUV 4:2:0) being supported by the hardware APIs, which would need to be expressed anyway. > Though I also wonder if we could merge the AVHWAccel entrypoints into > AVCodec and AVCodecHWConfig, which would require different definitions > again. I have kindof done this part - in the next version, the only reference to an AVHWAccel structure is in the corresponding CodecHWConfig. - Mark _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
