[libav-devel] [RFC] [PATCH] Drop non-refcounted-frame code on the next version bump

2017-10-21 Thread Diego Biurrun
---
 libavcodec/decode.c  | 11 +++
 libavcodec/version.h |  3 +++
 libavfilter/vsrc_movie.c |  5 +
 3 files changed, 19 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b74c163f92..040e1cc08e 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -36,6 +36,7 @@
 #include "decode.h"
 #include "internal.h"
 #include "thread.h"
+#include "version.h"
 
 static int apply_param_change(AVCodecContext *avctx, AVPacket *avpkt)
 {
@@ -576,11 +577,15 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
*frame,
 }
 
 if (frame != avci->compat_decode_frame) {
+#if FF_API_REFCOUNTED_FRAMES
+FF_DISABLE_DEPRECATION_WARNINGS
 if (!avctx->refcounted_frames) {
 ret = unrefcount_frame(avci, frame);
 if (ret < 0)
 goto finish;
 }
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 
 *got_frame = 1;
 frame = avci->compat_decode_frame;
@@ -1277,8 +1282,14 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
 
 ff_decode_bsfs_uninit(avctx);
 
+#if FF_API_REFCOUNTED_FRAMES
+FF_DISABLE_DEPRECATION_WARNINGS
 if (!avctx->refcounted_frames)
 av_frame_unref(avctx->internal->to_free);
+FF_ENABLE_DEPRECATION_WARNINGS
+#else
+av_frame_unref(avctx->internal->to_free);
+#endif
 }
 
 void ff_decode_bsfs_uninit(AVCodecContext *avctx)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index aa6cdcd6bc..f0cba4cc6b 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -95,5 +95,8 @@
 #ifndef FF_API_VAAPI_CONTEXT
 #define FF_API_VAAPI_CONTEXT(LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_REFCOUNTED_FRAMES
+#define FF_API_REFCOUNTED_FRAMES (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
 
 #endif /* AVCODEC_VERSION_H */
diff --git a/libavfilter/vsrc_movie.c b/libavfilter/vsrc_movie.c
index aff6e620ff..0bacb672fd 100644
--- a/libavfilter/vsrc_movie.c
+++ b/libavfilter/vsrc_movie.c
@@ -37,6 +37,7 @@
 #include "libavutil/imgutils.h"
 
 #include "libavcodec/avcodec.h"
+#include "libavcodec/version.h"
 
 #include "libavformat/avformat.h"
 
@@ -157,7 +158,11 @@ static av_cold int movie_init(AVFilterContext *ctx)
 if (ret < 0)
 return ret;
 
+#if FF_API_REFCOUNTED_FRAMES
+FF_DISABLE_DEPRECATION_WARNINGS
 movie->codec_ctx->refcounted_frames = 1;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 
 if ((ret = avcodec_open2(movie->codec_ctx, codec, NULL)) < 0) {
 av_log(ctx, AV_LOG_ERROR, "Failed to open codec\n");
-- 
2.11.0

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [libav-commits] lavc: external hardware frame pool initialization

2017-10-21 Thread Diego Biurrun
On Thu, Oct 19, 2017 at 05:25:17PM +0200, wm4  wrote:
> Module: libav
> Author:wm4 
> Committer: Anton Khirnov 
> Date:  Thu Oct 19 16:38:20 2017 +0200
> 
> lavc: external hardware frame pool initialization
> 
> This adds a new API, which allows the API user to query the required
> AVHWFramesContext parameters. This also reduces code duplication across
> the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
> the new API function. It takes care of initializing the hw_frames_ctx
> if needed, and does additional error handling and API usage checking.
> 
> ---
> 
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3984,6 +3994,109 @@ int avcodec_send_frame(AVCodecContext *avctx, const 
> AVFrame *frame);
> +int avcodec_get_hw_frames_parameters(AVCodecContext *avctx,
> + AVBufferRef *device_ref,
> + enum AVPixelFormat hw_pix_fmt,
> + AVBufferRef **out_frames_ref);
> +
> +
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -669,6 +669,88 @@ static AVHWAccel *find_hwaccel(enum AVCodecID codec_id,
> +int ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> +enum AVHWDeviceType dev_type)
> +{
> +ret = avcodec_get_hw_frames_parameters(avctx,
> +   avctx->hw_device_ctx,
> +   avctx->hwaccel->pix_fmt,
> +   avctx->hw_frames_ctx);

This generates a very suspicious warning:

libavcodec/decode.c: In function ‘ff_decode_get_hw_frames_ctx’:
libavcodec/decode.c:701:44: warning: passing argument 4 of 
avcodec_get_hw_frames_parameters’ from incompatible pointer type 
[-Wincompatible-pointer-types]
avctx->hw_frames_ctx);
^
In file included from libavcodec/decode.c:34:0:
libavcodec/avcodec.h:4094:5: note: expected ‘AVBufferRef ** {aka struct 
AVBufferRef **}’ but argument is of type ‘AVBufferRef * {aka struct AVBufferRef 
*}’
 int avcodec_get_hw_frames_parameters(AVCodecContext *avctx,
 ^~~~

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [GASPP PATCH] Conditionally work around an armasm64 bug in the scale operand to fcvtzs/scvtf

2017-10-21 Thread Martin Storsjö

On Sat, 21 Oct 2017, Diego Biurrun wrote:


On Sat, Oct 21, 2017 at 12:04:48AM +0300, Martin Storsjo wrote:

The operand shouldn't be stored as is, but stored as 64-scale, in
the opcode, but armasm64 currently misses to do this.

This bug will be fixed in a future release, and a fix for the bug
will break the workaround. Therefore, only do the workaround as
long as a environment variable is set.
---
Suggestions on what to name the environment variable are welcome;
it's hard to guess what to name it as I don't know what version
the fix will appear in.


When do you expect this future release to appear? It may be sensible
to just wait for the fix to appear and live with a bit of pain in the
meantime...


I didn't get any estimate on that, but lately they've released fixes every 
couple months, so it could possibly appear before the OS itself becomes 
public.


// Martin

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [GASPP PATCH] Conditionally work around an armasm64 bug in the scale operand to fcvtzs/scvtf

2017-10-21 Thread Diego Biurrun
On Sat, Oct 21, 2017 at 12:04:48AM +0300, Martin Storsjo wrote:
> The operand shouldn't be stored as is, but stored as 64-scale, in
> the opcode, but armasm64 currently misses to do this.
> 
> This bug will be fixed in a future release, and a fix for the bug
> will break the workaround. Therefore, only do the workaround as
> long as a environment variable is set.
> ---
> Suggestions on what to name the environment variable are welcome;
> it's hard to guess what to name it as I don't know what version
> the fix will appear in.

GASPP_ARMASM_SCALE_WORKAROUND

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [GASPP PATCH] Conditionally work around an armasm64 bug in the scale operand to fcvtzs/scvtf

2017-10-21 Thread Diego Biurrun
On Sat, Oct 21, 2017 at 12:04:48AM +0300, Martin Storsjo wrote:
> The operand shouldn't be stored as is, but stored as 64-scale, in
> the opcode, but armasm64 currently misses to do this.
> 
> This bug will be fixed in a future release, and a fix for the bug
> will break the workaround. Therefore, only do the workaround as
> long as a environment variable is set.
> ---
> Suggestions on what to name the environment variable are welcome;
> it's hard to guess what to name it as I don't know what version
> the fix will appear in.

When do you expect this future release to appear? It may be sensible
to just wait for the fix to appear and live with a bit of pain in the
meantime...

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel