On Thu, 6 Jul 2017 00:02:08 +0100
Mark Thompson <s...@jkqxz.net> wrote:
> ---
> Updated following discussion:
> * Back to using nested arrays.
> * Documentation improved.
> * Configure option now called libdrm.
> * Other minor fixups.
>
>
> configure | 3 +
> libavutil/Makefile | 2 +
> libavutil/hwcontext.c | 4 +
> libavutil/hwcontext.h | 1 +
> libavutil/hwcontext_drm.c | 294
> +++++++++++++++++++++++++++++++++++++++++
> libavutil/hwcontext_drm.h | 166 +++++++++++++++++++++++
> libavutil/hwcontext_internal.h | 1 +
> libavutil/pixdesc.c | 4 +
> libavutil/pixfmt.h | 4 +
> 9 files changed, 479 insertions(+)
> create mode 100644 libavutil/hwcontext_drm.c
> create mode 100644 libavutil/hwcontext_drm.h
Generally LGTM, though I don't know when LongChair can try it.
> +#include <fcntl.h>
> +#include <sys/mman.h>
> +#if HAVE_UNISTD_H
> +# include <unistd.h>
> +#endif
Is there really going to be a system that has fcntl.h and sys/mman.h,
but not unistd.h? This code is going to work on POSIX only anyway,
which requires this header.
> +typedef struct AVDRMObjectDescriptor {
> + /**
> + * DRM PRIME fd for the object.
> + */
> + int fd;
> + /**
> + * Total size of the object.
> + *
> + * (This includes any parts not which do not contain image data.)
> + */
> + size_t size;
> + /**
> + * Format modifier applied to the object (DRM_FORMAT_MOD_*).
> + */
> + uint64_t format_modifier;
> +} AVDRMObjectDescriptor;
So I guess this thing really is worth the trouble, but I still don't
entirely understand it. Why is the size needed, and what do the
format_modifiers do?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
