| Message ID | 20190903010230.96236-26-ffmpeg@tmm1.net |
|---|---|
| State | New |
| Headers | show |
On 03/09/2019 02:02, Aman Gupta wrote: > From: Jonas Karlman <jonas@kwiboo.se> > > This allows the cli to create a dummy drm hwcontext > that can be shared between the v4l2 decoder/scaler/encoder. > > This is especially useful on older RPI3 where /dev/dri devices > are not available in the default configuration. > > Signed-off-by: Jonas Karlman <jonas@kwiboo.se> > Signed-off-by: Aman Gupta <aman@tmm1.net> > --- > libavutil/hwcontext_drm.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/libavutil/hwcontext_drm.c b/libavutil/hwcontext_drm.c > index 32cbde82eb..aa4794c5e6 100644 > --- a/libavutil/hwcontext_drm.c > +++ b/libavutil/hwcontext_drm.c > @@ -43,6 +43,11 @@ static int drm_device_create(AVHWDeviceContext *hwdev, const char *device, > AVDRMDeviceContext *hwctx = hwdev->hwctx; > drmVersionPtr version; > > + if (device == NULL) { > + hwctx->fd = -1; > + return 0; > + } > + > hwctx->fd = open(device, O_RDWR); > if (hwctx->fd < 0) > return AVERROR(errno); > This smells like a hack for making something work in the ffmpeg command-line utility. Can you explain the use-case? If necessary, modifying the behaviour of ffmpeg would probably be better than putting this sort of thing into the library. - Mark
On Thu, Sep 12, 2019 at 5:05 PM Mark Thompson <sw@jkqxz.net> wrote: > On 03/09/2019 02:02, Aman Gupta wrote: > > From: Jonas Karlman <jonas@kwiboo.se> > > > > This allows the cli to create a dummy drm hwcontext > > that can be shared between the v4l2 decoder/scaler/encoder. > > > > This is especially useful on older RPI3 where /dev/dri devices > > are not available in the default configuration. > > > > Signed-off-by: Jonas Karlman <jonas@kwiboo.se> > > Signed-off-by: Aman Gupta <aman@tmm1.net> > > --- > > libavutil/hwcontext_drm.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavutil/hwcontext_drm.c b/libavutil/hwcontext_drm.c > > index 32cbde82eb..aa4794c5e6 100644 > > --- a/libavutil/hwcontext_drm.c > > +++ b/libavutil/hwcontext_drm.c > > @@ -43,6 +43,11 @@ static int drm_device_create(AVHWDeviceContext > *hwdev, const char *device, > > AVDRMDeviceContext *hwctx = hwdev->hwctx; > > drmVersionPtr version; > > > > + if (device == NULL) { > > + hwctx->fd = -1; > > + return 0; > > + } > > + > > hwctx->fd = open(device, O_RDWR); > > if (hwctx->fd < 0) > > return AVERROR(errno); > > > > This smells like a hack for making something work in the ffmpeg > command-line utility. Can you explain the use-case? If necessary, > modifying the behaviour of ffmpeg would probably be better than putting > this sort of thing into the library. > Since this v4l2 decoder can output either software frames or DRM frames, this allows using the CLI to switch between the two modes. i.e.: ffmpeg -c:v h264_v4l2m2m -i sample.mpg vs ./ffmpeg -hwaccel drm -hwaccel_output_format drm_prime -c:v h264_v4l2m2m -i sample.mpg This is also why I made the decoder define itself as AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX, so it was possible to use the CLI to trigger the DRM prime decoding mode. It sounds like it might be better to define a new v4l2 hwaccel/hwdevice, and maybe just return EINVAL from it's map/transfer methods since those are not applicable? Aman > > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/libavutil/hwcontext_drm.c b/libavutil/hwcontext_drm.c index 32cbde82eb..aa4794c5e6 100644 --- a/libavutil/hwcontext_drm.c +++ b/libavutil/hwcontext_drm.c @@ -43,6 +43,11 @@ static int drm_device_create(AVHWDeviceContext *hwdev, const char *device, AVDRMDeviceContext *hwctx = hwdev->hwctx; drmVersionPtr version; + if (device == NULL) { + hwctx->fd = -1; + return 0; + } + hwctx->fd = open(device, O_RDWR); if (hwctx->fd < 0) return AVERROR(errno);