Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Quoting Soft Works (2022-02-09 07:19:23) > > Sure. Don't understand my reply as an objection I don't even know what > xvmc is (or was). I rather see the burden and effort that it takes > to retain all those compatibility paths and at the same time how it > is blocking innovation and progress. > Compatibility is important - without question, but doing it in a way > that libs from different versions can be combined, is a somewhat crazy > endeavor. I keep wondering who would be the developer whose dreams > this might fulfil.. > The discussion about that seems to have gotten stuck about whether > to merge libs together or not, or how, but I haven't followed in > detailed, so please excuse the question (which has probably been > covered before): > Why can't ffmpeg simply declare that starting from version X, it > will be a requirement that all libs are from the same version? > (of course after equalizing) That is pretty offtopic in this thread =p That said, in my opinion - the extra flexibility is useful - the actual effort required to allow mismatching versions is overstated - the things this mainly affects are various private interfaces, which IMO are a mispattern and should not exist anyway -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Wednesday, February 9, 2022 6:49 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC > hwaccel code > > Quoting Soft Works (2022-02-08 22:34:42) > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Tuesday, February 8, 2022 10:37 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC > > > hwaccel code > > > > > > Quoting Soft Works (2022-02-07 03:18:54) > > > > I sometimes wonder whether there exists a single API user who > > > > really understands this (very special) kind of logic and > > > > would make decisions based on that understanding. > > > > > > > > When it's not even fully understood internally, how should it > > > > be understood externally? > > > > > > The rule for API users is simple: you are not allowed to assume a > > > specific component (like a decoder, demuxer or hwaccel) will be > > > available at runtime*. You are supposed to check for it using the > APIs > > > provided for this purpose. In this case, AV_PIX_FMT_XVMC will just > > > stop > > > being offered in get_format(). > > > > > > Not to mention that I very much doubt there are any users of xvmc > > > left, > > > besides the original mplayer. > > > > > > * unless you are running with a very specific verified build, in > which > > > case a removal like this should be caught at the build stage > > > > Thanks for the explanation. I misunderstood this a bit - when the > > only effect of the "removal" is an output like when the libs > wouldn't > > have been compiled with that part, then that's maybe nothing to > > be blamed for. > > On the other side: when somebody is using it and updates the libs > > to a point where it's missing, it will be broken for her/him. > > So the outcome might not be _that_ different for any other breaking > > changes being made. > > I agree that in general removing random components would be a bad > thing > to do, even though it's not technically an API break. That's why we > don't do it if there's any chance the component in question is useful. > > The argument _in this specific case_ is that xvmc is not useful to > anyone and has not been for a very long time, so no valid use cases > are > broken by its removal. In fact its only user ever I'm aware of is the > original mplayer (mplayer2, which was later forked into mpv, dropped > it > in 2011). Sure. Don't understand my reply as an objection I don't even know what xvmc is (or was). I rather see the burden and effort that it takes to retain all those compatibility paths and at the same time how it is blocking innovation and progress. Compatibility is important - without question, but doing it in a way that libs from different versions can be combined, is a somewhat crazy endeavor. I keep wondering who would be the developer whose dreams this might fulfil.. The discussion about that seems to have gotten stuck about whether to merge libs together or not, or how, but I haven't followed in detailed, so please excuse the question (which has probably been covered before): Why can't ffmpeg simply declare that starting from version X, it will be a requirement that all libs are from the same version? (of course after equalizing) BR, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Quoting Soft Works (2022-02-08 22:34:42) > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Tuesday, February 8, 2022 10:37 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC > > hwaccel code > > > > Quoting Soft Works (2022-02-07 03:18:54) > > > I sometimes wonder whether there exists a single API user who > > > really understands this (very special) kind of logic and > > > would make decisions based on that understanding. > > > > > > When it's not even fully understood internally, how should it > > > be understood externally? > > > > The rule for API users is simple: you are not allowed to assume a > > specific component (like a decoder, demuxer or hwaccel) will be > > available at runtime*. You are supposed to check for it using the APIs > > provided for this purpose. In this case, AV_PIX_FMT_XVMC will just > > stop > > being offered in get_format(). > > > > Not to mention that I very much doubt there are any users of xvmc > > left, > > besides the original mplayer. > > > > * unless you are running with a very specific verified build, in which > > case a removal like this should be caught at the build stage > > Thanks for the explanation. I misunderstood this a bit - when the > only effect of the "removal" is an output like when the libs wouldn't > have been compiled with that part, then that's maybe nothing to > be blamed for. > On the other side: when somebody is using it and updates the libs > to a point where it's missing, it will be broken for her/him. > So the outcome might not be _that_ different for any other breaking > changes being made. I agree that in general removing random components would be a bad thing to do, even though it's not technically an API break. That's why we don't do it if there's any chance the component in question is useful. The argument _in this specific case_ is that xvmc is not useful to anyone and has not been for a very long time, so no valid use cases are broken by its removal. In fact its only user ever I'm aware of is the original mplayer (mplayer2, which was later forked into mpv, dropped it in 2011). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Tuesday, February 8, 2022 10:37 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC > hwaccel code > > Quoting Soft Works (2022-02-07 03:18:54) > > I sometimes wonder whether there exists a single API user who > > really understands this (very special) kind of logic and > > would make decisions based on that understanding. > > > > When it's not even fully understood internally, how should it > > be understood externally? > > The rule for API users is simple: you are not allowed to assume a > specific component (like a decoder, demuxer or hwaccel) will be > available at runtime*. You are supposed to check for it using the APIs > provided for this purpose. In this case, AV_PIX_FMT_XVMC will just > stop > being offered in get_format(). > > Not to mention that I very much doubt there are any users of xvmc > left, > besides the original mplayer. > > * unless you are running with a very specific verified build, in which > case a removal like this should be caught at the build stage Thanks for the explanation. I misunderstood this a bit - when the only effect of the "removal" is an output like when the libs wouldn't have been compiled with that part, then that's maybe nothing to be blamed for. On the other side: when somebody is using it and updates the libs to a point where it's missing, it will be broken for her/him. So the outcome might not be _that_ different for any other breaking changes being made. And that's what I meant to point out: On one side, we are carefully curating those versioning changes (individually for each lib!) with a complex set of rules and considerations to be made, while in the majority of cases I tend to believe that not many really care that much about it, instead sitting there, happily using it until the moment "Oh it's broken - - need to do something - fix it and go on.." :-) softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Quoting Andreas Rheinhardt (2022-02-07 02:46:08) > I thought that removing components is only possible at a major version > bump. Am I wrong? AFAIK we provide no API guarantees for specific components being available. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Quoting Soft Works (2022-02-07 03:18:54) > I sometimes wonder whether there exists a single API user who > really understands this (very special) kind of logic and > would make decisions based on that understanding. > > When it's not even fully understood internally, how should it > be understood externally? The rule for API users is simple: you are not allowed to assume a specific component (like a decoder, demuxer or hwaccel) will be available at runtime*. You are supposed to check for it using the APIs provided for this purpose. In this case, AV_PIX_FMT_XVMC will just stop being offered in get_format(). Not to mention that I very much doubt there are any users of xvmc left, besides the original mplayer. * unless you are running with a very specific verified build, in which case a removal like this should be caught at the build stage -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Monday, February 7, 2022 2:53 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC > hwaccel code > > On 2/6/2022 10:46 PM, Andreas Rheinhardt wrote: > > Anton Khirnov: > >> XvMC was last relevant over 10 years ago, if ever. There is no > reason to > >> use it today. > >> --- > >> MAINTAINERS| 1 - > >> configure | 9 - > >> libavcodec/Makefile| 2 - > >> libavcodec/avcodec.h | 12 -- > >> libavcodec/error_resilience.c | 9 - > >> libavcodec/hwaccels.h | 2 - > >> libavcodec/hwconfig.h | 2 - > >> libavcodec/mpeg12dec.c | 43 > >> libavcodec/mpegvideo.c | 6 - > >> libavcodec/mpegvideo.h | 2 - > >> libavcodec/mpegvideo_xvmc.c| 376 > - > >> libavcodec/x86/blockdsp_init.c | 4 - > >> libavcodec/xvmc_internal.h | 31 --- > >> 13 files changed, 499 deletions(-) > >> delete mode 100644 libavcodec/mpegvideo_xvmc.c > >> delete mode 100644 libavcodec/xvmc_internal.h > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index c065e94498..f33ccbd1d9 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -266,7 +266,6 @@ Codecs: > >> xan.c Mike Melanson > >> xbm* Paul B Mahol > >> xface Stefano Sabatini > >> - xvmc.cIvan Kalvachev > >> xwd* Paul B Mahol > >> > >> Hardware acceleration: > >> diff --git a/configure b/configure > >> index 5b19a35f59..6dbe108284 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -1900,7 +1900,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" > >> videotoolbox > >> vulkan > >> v4l2_m2m > >> -xvmc > >> " > >> > >> # catchall list of things that require external libs to link > >> @@ -3006,7 +3005,6 @@ vaapi_x11_deps="xlib_x11" > >> videotoolbox_hwaccel_deps="videotoolbox pthreads" > >> videotoolbox_hwaccel_extralibs="-framework QuartzCore" > >> vulkan_deps_any="libdl LoadLibrary" > >> -xvmc_deps="X11_extensions_XvMClib_h" > >> > >> av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1" > >> av1_d3d11va_hwaccel_select="av1_decoder" > >> @@ -3054,16 +3052,12 @@ mjpeg_nvdec_hwaccel_deps="nvdec" > >> mjpeg_nvdec_hwaccel_select="mjpeg_decoder" > >> mjpeg_vaapi_hwaccel_deps="vaapi" > >> mjpeg_vaapi_hwaccel_select="mjpeg_decoder" > >> -mpeg_xvmc_hwaccel_deps="xvmc" > >> -mpeg_xvmc_hwaccel_select="mpeg2video_decoder" > >> mpeg1_nvdec_hwaccel_deps="nvdec" > >> mpeg1_nvdec_hwaccel_select="mpeg1video_decoder" > >> mpeg1_vdpau_hwaccel_deps="vdpau" > >> mpeg1_vdpau_hwaccel_select="mpeg1video_decoder" > >> mpeg1_videotoolbox_hwaccel_deps="videotoolbox" > >> mpeg1_videotoolbox_hwaccel_select="mpeg1video_decoder" > >> -mpeg1_xvmc_hwaccel_deps="xvmc" > >> -mpeg1_xvmc_hwaccel_select="mpeg1video_decoder" > >> mpeg2_d3d11va_hwaccel_deps="d3d11va" > >> mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder" > >> mpeg2_d3d11va2_hwaccel_deps="d3d11va" > >> @@ -3078,8 +3072,6 @@ mpeg2_vdpau_hwaccel_deps="vdpau" > >> mpeg2_vdpau_hwaccel_select="mpeg2video_decoder" > >> mpeg2_videotoolbox_hwaccel_deps="videotoolbox" > >> mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder" > >> -mpeg2_xvmc_hwaccel_deps="xvmc" > >> -mpeg2_xvmc_hwaccel_select="mpeg2video_decoder" > >> mpeg4_nvdec_hwaccel_deps="nvdec" > >> mpeg4_nvdec_hwaccel_select="mpeg4_decoder" > >> mpeg4_vaapi_hwaccel_deps="vaapi" > >> @@ -6320,7 +6312,6 @@ check_headers unistd.h > >> check_headers valgrind/valgrind.h > >> check_func_headers VideoToolbox/VTCompressionSession.h > VTCompressionSes
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
On 2/6/2022 10:46 PM, Andreas Rheinhardt wrote:
Anton Khirnov:
XvMC was last relevant over 10 years ago, if ever. There is no reason to
use it today.
---
MAINTAINERS| 1 -
configure | 9 -
libavcodec/Makefile| 2 -
libavcodec/avcodec.h | 12 --
libavcodec/error_resilience.c | 9 -
libavcodec/hwaccels.h | 2 -
libavcodec/hwconfig.h | 2 -
libavcodec/mpeg12dec.c | 43
libavcodec/mpegvideo.c | 6 -
libavcodec/mpegvideo.h | 2 -
libavcodec/mpegvideo_xvmc.c| 376 -
libavcodec/x86/blockdsp_init.c | 4 -
libavcodec/xvmc_internal.h | 31 ---
13 files changed, 499 deletions(-)
delete mode 100644 libavcodec/mpegvideo_xvmc.c
delete mode 100644 libavcodec/xvmc_internal.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c065e94498..f33ccbd1d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,7 +266,6 @@ Codecs:
xan.c Mike Melanson
xbm* Paul B Mahol
xface Stefano Sabatini
- xvmc.cIvan Kalvachev
xwd* Paul B Mahol
Hardware acceleration:
diff --git a/configure b/configure
index 5b19a35f59..6dbe108284 100755
--- a/configure
+++ b/configure
@@ -1900,7 +1900,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
videotoolbox
vulkan
v4l2_m2m
-xvmc
"
# catchall list of things that require external libs to link
@@ -3006,7 +3005,6 @@ vaapi_x11_deps="xlib_x11"
videotoolbox_hwaccel_deps="videotoolbox pthreads"
videotoolbox_hwaccel_extralibs="-framework QuartzCore"
vulkan_deps_any="libdl LoadLibrary"
-xvmc_deps="X11_extensions_XvMClib_h"
av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1"
av1_d3d11va_hwaccel_select="av1_decoder"
@@ -3054,16 +3052,12 @@ mjpeg_nvdec_hwaccel_deps="nvdec"
mjpeg_nvdec_hwaccel_select="mjpeg_decoder"
mjpeg_vaapi_hwaccel_deps="vaapi"
mjpeg_vaapi_hwaccel_select="mjpeg_decoder"
-mpeg_xvmc_hwaccel_deps="xvmc"
-mpeg_xvmc_hwaccel_select="mpeg2video_decoder"
mpeg1_nvdec_hwaccel_deps="nvdec"
mpeg1_nvdec_hwaccel_select="mpeg1video_decoder"
mpeg1_vdpau_hwaccel_deps="vdpau"
mpeg1_vdpau_hwaccel_select="mpeg1video_decoder"
mpeg1_videotoolbox_hwaccel_deps="videotoolbox"
mpeg1_videotoolbox_hwaccel_select="mpeg1video_decoder"
-mpeg1_xvmc_hwaccel_deps="xvmc"
-mpeg1_xvmc_hwaccel_select="mpeg1video_decoder"
mpeg2_d3d11va_hwaccel_deps="d3d11va"
mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
mpeg2_d3d11va2_hwaccel_deps="d3d11va"
@@ -3078,8 +3072,6 @@ mpeg2_vdpau_hwaccel_deps="vdpau"
mpeg2_vdpau_hwaccel_select="mpeg2video_decoder"
mpeg2_videotoolbox_hwaccel_deps="videotoolbox"
mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder"
-mpeg2_xvmc_hwaccel_deps="xvmc"
-mpeg2_xvmc_hwaccel_select="mpeg2video_decoder"
mpeg4_nvdec_hwaccel_deps="nvdec"
mpeg4_nvdec_hwaccel_select="mpeg4_decoder"
mpeg4_vaapi_hwaccel_deps="vaapi"
@@ -6320,7 +6312,6 @@ check_headers unistd.h
check_headers valgrind/valgrind.h
check_func_headers VideoToolbox/VTCompressionSession.h
VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox
check_headers windows.h
-check_headers X11/extensions/XvMClib.h
check_headers asm/types.h
# it seems there are versions of clang in some distros that try to use the
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cfc70a3eaf..6076b4ad80 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -963,7 +963,6 @@ OBJS-$(CONFIG_MJPEG_VAAPI_HWACCEL)+= vaapi_mjpeg.o
OBJS-$(CONFIG_MPEG1_NVDEC_HWACCEL)+= nvdec_mpeg12.o
OBJS-$(CONFIG_MPEG1_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG1_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
-OBJS-$(CONFIG_MPEG1_XVMC_HWACCEL) += mpegvideo_xvmc.o
OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL) += dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
@@ -971,7 +970,6 @@ OBJS-$(CONFIG_MPEG2_QSV_HWACCEL) += qsvdec.o
OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
-OBJS-$(CONFIG_MPEG2_XVMC_HWACCEL) += mpegvideo_xvmc.o
OBJS-$(CONFIG_MPEG4_NVDEC_HWACCEL)+= nvdec_mpeg4.o
OBJS-$(CONFIG_MPEG4_VAAPI_HWACCEL)+= vaapi_mpeg4.o
OBJS-$(CONFIG_MPEG4_VDPAU_HWACCEL)+= vdpau_mpeg4.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ec1a0566a4..acb7ae0e14 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2119,7 +2119,6 @@ typedef struct AVHWAccel {
*
* Meaningful slice information (codec specific) is guaranteed to
* be parsed at this point. This function is mandatory.
- * The only exception is
Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Anton Khirnov:
> XvMC was last relevant over 10 years ago, if ever. There is no reason to
> use it today.
> ---
> MAINTAINERS| 1 -
> configure | 9 -
> libavcodec/Makefile| 2 -
> libavcodec/avcodec.h | 12 --
> libavcodec/error_resilience.c | 9 -
> libavcodec/hwaccels.h | 2 -
> libavcodec/hwconfig.h | 2 -
> libavcodec/mpeg12dec.c | 43
> libavcodec/mpegvideo.c | 6 -
> libavcodec/mpegvideo.h | 2 -
> libavcodec/mpegvideo_xvmc.c| 376 -
> libavcodec/x86/blockdsp_init.c | 4 -
> libavcodec/xvmc_internal.h | 31 ---
> 13 files changed, 499 deletions(-)
> delete mode 100644 libavcodec/mpegvideo_xvmc.c
> delete mode 100644 libavcodec/xvmc_internal.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c065e94498..f33ccbd1d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -266,7 +266,6 @@ Codecs:
>xan.c Mike Melanson
>xbm* Paul B Mahol
>xface Stefano Sabatini
> - xvmc.cIvan Kalvachev
>xwd* Paul B Mahol
>
> Hardware acceleration:
> diff --git a/configure b/configure
> index 5b19a35f59..6dbe108284 100755
> --- a/configure
> +++ b/configure
> @@ -1900,7 +1900,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
> videotoolbox
> vulkan
> v4l2_m2m
> -xvmc
> "
>
> # catchall list of things that require external libs to link
> @@ -3006,7 +3005,6 @@ vaapi_x11_deps="xlib_x11"
> videotoolbox_hwaccel_deps="videotoolbox pthreads"
> videotoolbox_hwaccel_extralibs="-framework QuartzCore"
> vulkan_deps_any="libdl LoadLibrary"
> -xvmc_deps="X11_extensions_XvMClib_h"
>
> av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1"
> av1_d3d11va_hwaccel_select="av1_decoder"
> @@ -3054,16 +3052,12 @@ mjpeg_nvdec_hwaccel_deps="nvdec"
> mjpeg_nvdec_hwaccel_select="mjpeg_decoder"
> mjpeg_vaapi_hwaccel_deps="vaapi"
> mjpeg_vaapi_hwaccel_select="mjpeg_decoder"
> -mpeg_xvmc_hwaccel_deps="xvmc"
> -mpeg_xvmc_hwaccel_select="mpeg2video_decoder"
> mpeg1_nvdec_hwaccel_deps="nvdec"
> mpeg1_nvdec_hwaccel_select="mpeg1video_decoder"
> mpeg1_vdpau_hwaccel_deps="vdpau"
> mpeg1_vdpau_hwaccel_select="mpeg1video_decoder"
> mpeg1_videotoolbox_hwaccel_deps="videotoolbox"
> mpeg1_videotoolbox_hwaccel_select="mpeg1video_decoder"
> -mpeg1_xvmc_hwaccel_deps="xvmc"
> -mpeg1_xvmc_hwaccel_select="mpeg1video_decoder"
> mpeg2_d3d11va_hwaccel_deps="d3d11va"
> mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
> mpeg2_d3d11va2_hwaccel_deps="d3d11va"
> @@ -3078,8 +3072,6 @@ mpeg2_vdpau_hwaccel_deps="vdpau"
> mpeg2_vdpau_hwaccel_select="mpeg2video_decoder"
> mpeg2_videotoolbox_hwaccel_deps="videotoolbox"
> mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder"
> -mpeg2_xvmc_hwaccel_deps="xvmc"
> -mpeg2_xvmc_hwaccel_select="mpeg2video_decoder"
> mpeg4_nvdec_hwaccel_deps="nvdec"
> mpeg4_nvdec_hwaccel_select="mpeg4_decoder"
> mpeg4_vaapi_hwaccel_deps="vaapi"
> @@ -6320,7 +6312,6 @@ check_headers unistd.h
> check_headers valgrind/valgrind.h
> check_func_headers VideoToolbox/VTCompressionSession.h
> VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox
> check_headers windows.h
> -check_headers X11/extensions/XvMClib.h
> check_headers asm/types.h
>
> # it seems there are versions of clang in some distros that try to use the
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index cfc70a3eaf..6076b4ad80 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -963,7 +963,6 @@ OBJS-$(CONFIG_MJPEG_VAAPI_HWACCEL)+= vaapi_mjpeg.o
> OBJS-$(CONFIG_MPEG1_NVDEC_HWACCEL)+= nvdec_mpeg12.o
> OBJS-$(CONFIG_MPEG1_VDPAU_HWACCEL)+= vdpau_mpeg12.o
> OBJS-$(CONFIG_MPEG1_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
> -OBJS-$(CONFIG_MPEG1_XVMC_HWACCEL) += mpegvideo_xvmc.o
> OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL) += dxva2_mpeg2.o
> OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
> OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
> @@ -971,7 +970,6 @@ OBJS-$(CONFIG_MPEG2_QSV_HWACCEL) += qsvdec.o
> OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
> OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+= vdpau_mpeg12.o
> OBJS-$(CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
> -OBJS-$(CONFIG_MPEG2_XVMC_HWACCEL) += mpegvideo_xvmc.o
> OBJS-$(CONFIG_MPEG4_NVDEC_HWACCEL)+= nvdec_mpeg4.o
> OBJS-$(CONFIG_MPEG4_VAAPI_HWACCEL)+= vaapi_mpeg4.o
> OBJS-$(CONFIG_MPEG4_VDPAU_HWACCEL)+= vdpau_mpeg4.o
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index ec1a0566a4..acb7ae0e14 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2119,7 +2119,6 @@ typedef struct AVHWAccel {
> *
> * Meaningful slice information (codec specific) is
[FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
XvMC was last relevant over 10 years ago, if ever. There is no reason to
use it today.
---
MAINTAINERS| 1 -
configure | 9 -
libavcodec/Makefile| 2 -
libavcodec/avcodec.h | 12 --
libavcodec/error_resilience.c | 9 -
libavcodec/hwaccels.h | 2 -
libavcodec/hwconfig.h | 2 -
libavcodec/mpeg12dec.c | 43
libavcodec/mpegvideo.c | 6 -
libavcodec/mpegvideo.h | 2 -
libavcodec/mpegvideo_xvmc.c| 376 -
libavcodec/x86/blockdsp_init.c | 4 -
libavcodec/xvmc_internal.h | 31 ---
13 files changed, 499 deletions(-)
delete mode 100644 libavcodec/mpegvideo_xvmc.c
delete mode 100644 libavcodec/xvmc_internal.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c065e94498..f33ccbd1d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,7 +266,6 @@ Codecs:
xan.c Mike Melanson
xbm* Paul B Mahol
xface Stefano Sabatini
- xvmc.cIvan Kalvachev
xwd* Paul B Mahol
Hardware acceleration:
diff --git a/configure b/configure
index 5b19a35f59..6dbe108284 100755
--- a/configure
+++ b/configure
@@ -1900,7 +1900,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
videotoolbox
vulkan
v4l2_m2m
-xvmc
"
# catchall list of things that require external libs to link
@@ -3006,7 +3005,6 @@ vaapi_x11_deps="xlib_x11"
videotoolbox_hwaccel_deps="videotoolbox pthreads"
videotoolbox_hwaccel_extralibs="-framework QuartzCore"
vulkan_deps_any="libdl LoadLibrary"
-xvmc_deps="X11_extensions_XvMClib_h"
av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1"
av1_d3d11va_hwaccel_select="av1_decoder"
@@ -3054,16 +3052,12 @@ mjpeg_nvdec_hwaccel_deps="nvdec"
mjpeg_nvdec_hwaccel_select="mjpeg_decoder"
mjpeg_vaapi_hwaccel_deps="vaapi"
mjpeg_vaapi_hwaccel_select="mjpeg_decoder"
-mpeg_xvmc_hwaccel_deps="xvmc"
-mpeg_xvmc_hwaccel_select="mpeg2video_decoder"
mpeg1_nvdec_hwaccel_deps="nvdec"
mpeg1_nvdec_hwaccel_select="mpeg1video_decoder"
mpeg1_vdpau_hwaccel_deps="vdpau"
mpeg1_vdpau_hwaccel_select="mpeg1video_decoder"
mpeg1_videotoolbox_hwaccel_deps="videotoolbox"
mpeg1_videotoolbox_hwaccel_select="mpeg1video_decoder"
-mpeg1_xvmc_hwaccel_deps="xvmc"
-mpeg1_xvmc_hwaccel_select="mpeg1video_decoder"
mpeg2_d3d11va_hwaccel_deps="d3d11va"
mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
mpeg2_d3d11va2_hwaccel_deps="d3d11va"
@@ -3078,8 +3072,6 @@ mpeg2_vdpau_hwaccel_deps="vdpau"
mpeg2_vdpau_hwaccel_select="mpeg2video_decoder"
mpeg2_videotoolbox_hwaccel_deps="videotoolbox"
mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder"
-mpeg2_xvmc_hwaccel_deps="xvmc"
-mpeg2_xvmc_hwaccel_select="mpeg2video_decoder"
mpeg4_nvdec_hwaccel_deps="nvdec"
mpeg4_nvdec_hwaccel_select="mpeg4_decoder"
mpeg4_vaapi_hwaccel_deps="vaapi"
@@ -6320,7 +6312,6 @@ check_headers unistd.h
check_headers valgrind/valgrind.h
check_func_headers VideoToolbox/VTCompressionSession.h
VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox
check_headers windows.h
-check_headers X11/extensions/XvMClib.h
check_headers asm/types.h
# it seems there are versions of clang in some distros that try to use the
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cfc70a3eaf..6076b4ad80 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -963,7 +963,6 @@ OBJS-$(CONFIG_MJPEG_VAAPI_HWACCEL)+= vaapi_mjpeg.o
OBJS-$(CONFIG_MPEG1_NVDEC_HWACCEL)+= nvdec_mpeg12.o
OBJS-$(CONFIG_MPEG1_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG1_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
-OBJS-$(CONFIG_MPEG1_XVMC_HWACCEL) += mpegvideo_xvmc.o
OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL) += dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
@@ -971,7 +970,6 @@ OBJS-$(CONFIG_MPEG2_QSV_HWACCEL) += qsvdec.o
OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
-OBJS-$(CONFIG_MPEG2_XVMC_HWACCEL) += mpegvideo_xvmc.o
OBJS-$(CONFIG_MPEG4_NVDEC_HWACCEL)+= nvdec_mpeg4.o
OBJS-$(CONFIG_MPEG4_VAAPI_HWACCEL)+= vaapi_mpeg4.o
OBJS-$(CONFIG_MPEG4_VDPAU_HWACCEL)+= vdpau_mpeg4.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ec1a0566a4..acb7ae0e14 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2119,7 +2119,6 @@ typedef struct AVHWAccel {
*
* Meaningful slice information (codec specific) is guaranteed to
* be parsed at this point. This function is mandatory.
- * The only exception is XvMC, that works on MB level.
*
* @param avctx the codec context
* @param buf the slice data buffer base
@@ -2148,17 +2147,6
