Re: [libav-devel] [PATCH] lavf: remove the concat protocol
Hello, On Thursday 21 January 2016 23:03:25 Andreas Cadhalpun wrote: > Why not fix the issue properly instead of removing useful functionality? By its very essence, the concat protocol allows for injection attacks with untrusted URLs (the same super-class of vulnerabilities as XSS and SQL injection). Either you remove that functionality, or you ensure that all URls ever passed to libavformat trusted. Best of luck with the latter option. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: remove the concat protocol
On Wednesday 20 January 2016 13:42:43 Anton Khirnov wrote: > It is of very limited usefulness and is a source of important security > problems. I suggested it so obviously fine with me. If someone really has a use for it, I´d suggest configuring it via out-of-band options. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hls: Add a blacklist option
On Wednesday 13 January 2016 18:14:16 Luca Barbato wrote: > concat can be abused to leak local file contents as url parameter. I now managed to reproduce the problem, and indeed confirms that there is a real problem. However, this patch does not fix it because the issue is not specific to HLS. I would suggest either: 1) removing concat completely, or 2) ignoring the concat locator string, and passing the list of concatenated URIs through AV options (similarly to what VLC does). -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hls: Add a blacklist option
On Wednesday 13 January 2016 19:29:40 Luca Barbato wrote: > On 13/01/16 18:46, Rémi Denis-Courmont wrote: > > How and to whom? I fail to see a bug. > > In a moderately convoluted way one can upload a m3u8 that references to > the concatenation of a playlist and the file you want to leak That "leaks" the file to the local user that has read access to it. In other words, it does not leak anything. Or if you want to call that a leak, then a playlist can also "leak" any local file using a file URI, so long as avformat recognizes the file format. Or an Intranet resource using http/https/ftp/ftpes/ftps URI. Etc. So you need to blacklist all protocols (or almost). -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hls: Add a blacklist option
On Wednesday 13 January 2016 18:14:16 Luca Barbato wrote: > concat can be abused to leak local file contents as url parameter. How and to whom? I fail to see a bug. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/5] lavc/vdpau: add support for allocating surfaces internally
creating a surface\n"); > +return vdpau_error(err); > +} > + > +frame->buf[0] = av_buffer_create((uint8_t*)(uintptr_t)surf, sizeof(surf), > + vdpau_release_buffer, vdctx->surf_destroy, > + AV_BUFFER_FLAG_READONLY); Shouldn't this return/alloc the frame from a surface pool? (Though I'm going to be happy if you tell me that vdpau surface allocation is always maximally efficient and doesn't need a pool.) Rémi tells me the pools are not need for performance reasons. But some old hardware requires preallocating surfaces for some other weird reasons. And of course many other APIs can only work with the full pool preallocated beforehand, so some support for that will be needed. Uh? No. VDPAU has no requirements to preallocate surfaces. The problem is, preallocating is the only way to ensure that the GPU will have enough memory to meet the run-time buffers requirements. Otherwise, you might end up, e.g. with 4 video surfaces on a bitstream that requires 16 reference frames. And fail. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/5] lavu: add a framework for handling hwaccel frames
Le 2015-12-20 21:59, Anton Khirnov a écrit :
diff --git a/libavutil/hwframe.h b/libavutil/hwframe.h
new file mode 100644
index 000..3e33aa5
--- /dev/null
+++ b/libavutil/hwframe.h
@@ -0,0 +1,97 @@
+/*
+ * This file is part of Libav.
+ *
+ * Libav is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later
version.
+ *
+ * Libav is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with Libav; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+#ifndef AVUTIL_HWFRAME_H
+#define AVUTIL_HWFRAME_H
+
+#include "buffer.h"
+#include "frame.h"
+#include "log.h"
+#include "pixfmt.h"
+
+typedef struct AVHWFramesInternal AVHWFramesInternal;
+
+/**
+ * This struct aggregates any state necessary for handling
"hardware" frames
+ * (i.e. those with data not located in normal system memory).
+ *
+ * This struct is reference-counted with the AVBuffer mechanism. The
+ * av_hwframe_ctx_alloc() constructor yields a reference, whose data
field
+ * points to the actual AVHWFramesContext struct.
+ */
+typedef struct AVHWFramesContext {
+/**
+ * A class for logging.
+ */
+const AVClass *av_class;
+
+/**
+ * The pixel format identifying the underlying HW surface type.
+ *
+ * Must be a hwaccel format, i.e. the corresponding descriptor
must have the
+ * AV_PIX_FMT_FLAG_HWACCEL flag set.
+ *
+ * This field is set when this struct is allocated and never
changed
+ * afterwards.
+ */
+enum AVPixelFormat format;
+
+/**
+ * The format-specific data, allocated and freed automatically
along with
+ * this context.
+ *
+ * Should be cast by the user to the format-specific context
defined in the
+ * corresponding header (hwframe_*.h) and filled as described in
the
+ * documentation before creating any frames using this context.
+ *
+ * After any frames using this context are created, the contents
of this
+ * struct should not be modified by the caller.
+ */
+void *hwctx;
+
+/**
+ * Private data used internally by libavutil. Must not be
accessed in any
+ * way by the caller.
+ */
+AVHWFramesInternal *internal;
+
+/**
+ * This field may be set by the caller immediately after
allocating this
+ * context.
+ *
+ * If non-NULL, this callback will be called when the last
reference to
+ * this context is unreferences, immediately before it is freed.
Nit: unreferenced.
+ */
+void (*free)(struct AVHWFramesContext *ctx);
+
+/**
+ * Arbitrary user data, to be used e.g. by the free() callback.
+ */
+void *user_opaque;
+} AVHWFramesContext;
+
+AVBufferRef *av_hwframe_ctx_alloc(enum AVPixelFormat format);
+
+int av_hwframe_ctx_init(AVBufferRef *ref);
+
+int av_hwframe_get_target_formats(const AVFrame *frame,
+ enum AVPixelFormat **formats);
+
+int av_hwframe_retrieve_data(AVFrame *dst, const AVFrame *src);
+
+#endif /* AVUTIL_HWFRAME_H */
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/5] hwframe: add a VDPAU implementation
get_transfer_caps);
+GET_CALLBACK(VDP_FUNC_ID_VIDEO_SURFACE_GET_BITS_Y_CB_CR,
get_data);
+
+ret = vdpau_init_pixmfts(ctx);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Error querying the supported
pixel formats\n");
+return ret;
+}
+
+return 0;
+}
+
+static void vdpau_uninit(AVHWFramesContext *ctx)
+{
+VDPAUFramesContext *priv = ctx->internal->priv;
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(priv->pix_fmts); i++)
+av_freep(>pix_fmts[i]);
+}
+
+static int vdpau_get_target_formats(AVHWFramesContext *ctx, const
AVFrame *frame,
+enum AVPixelFormat **formats)
+{
+VDPAUFramesContext *priv = ctx->internal->priv;
+
+VdpChromaType chroma_type;
+VdpStatus err;
+uint32_t width, height;
+
+enum AVPixelFormat *fmts;
+int i, idx = -1;
+
+err =
priv->get_surf_parameters((VdpVideoSurface)(uintptr_t)frame->data[3],
_type,
+, );
+if (err != VDP_STATUS_OK) {
+av_log(ctx, AV_LOG_ERROR, "Error querying the surface
parameters\n");
+return AVERROR_UNKNOWN;
+}
+
+for (i = 0; i < FF_ARRAY_ELEMS(vdpau_pix_fmts); i++) {
+if (vdpau_pix_fmts[i].chroma_type == chroma_type) {
+idx = i;
+break;
+}
+}
+if (idx < 0) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported chroma type: %d\n",
chroma_type);
+return AVERROR(ENOSYS);
+}
+if (priv->nb_pix_fmts[idx] == 1) {
+av_log(ctx, AV_LOG_ERROR,
+ "No target formats are supported for chroma type
%d\n", chroma_type);
+return AVERROR(ENOSYS);
+}
+
+fmts = av_malloc_array(priv->nb_pix_fmts[idx], sizeof(*fmts));
+if (!fmts)
+return AVERROR(ENOMEM);
+
+memcpy(fmts, priv->pix_fmts[idx], sizeof(*fmts) *
(priv->nb_pix_fmts[idx]));
+*formats = fmts;
+
+return 0;
+}
+
+static int vdpau_retrieve_data(AVHWFramesContext *ctx, AVFrame *dst,
+ const AVFrame *src)
+{
+VDPAUFramesContext *priv = ctx->internal->priv;
+VdpVideoSurface surf =
(VdpVideoSurface)(uintptr_t)src->data[3];
+
+const VDPAUPixFmtMap *map;
+VdpChromaType chroma_type;
+VdpYCbCrFormat vdpau_format;
+VdpStatus err;
+uint32_t width, height;
+int i, idx;
+
+err = priv->get_surf_parameters(surf, _type, ,
);
+if (err != VDP_STATUS_OK) {
+av_log(ctx, AV_LOG_ERROR, "Error querying the surface
parameters\n");
+return AVERROR_UNKNOWN;
+}
+for (i = 0; i < FF_ARRAY_ELEMS(vdpau_pix_fmts); i++) {
+if (vdpau_pix_fmts[i].chroma_type == chroma_type) {
+idx = i;
+break;
+}
+}
+if (idx < 0) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported chroma type: %d\n",
chroma_type);
+return AVERROR(ENOSYS);
+}
+map = vdpau_pix_fmts[idx].map;
+
+for (i = 0; map[i].pix_fmt != AV_PIX_FMT_NONE; i++) {
+if (map[i].pix_fmt == dst->format) {
+vdpau_format = map[i].vdpau_fmt;
+break;
+}
+}
+if (map[i].pix_fmt == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported target pixel format: %s\n",
+ av_get_pix_fmt_name(dst->format));
+return AVERROR(EINVAL);
+}
+
+err = priv->get_data(surf, vdpau_format, (void * const
*)dst->data,
Suspicious cast.
+ dst->linesize);
I am not sure but that might be a bit naive w.r.t. potential alignment
requirements.
+if (err != VDP_STATUS_OK) {
+av_log(ctx, AV_LOG_ERROR, "Error retrieving the data from a
VDPAU surface\n");
+return AVERROR_UNKNOWN;
+}
+
+return 0;
+}
+
+const HWFrameType ff_hwframe_type_vdpau = {
+.format = AV_PIX_FMT_VDPAU,
+.name = "VDPAU",
+.hwctx_size = sizeof(AVVDPAUFramesContext),
+.priv_size = sizeof(VDPAUFramesContext),
+.init = vdpau_init,
+.uninit = vdpau_uninit,
+.get_target_formats = vdpau_get_target_formats,
+.retrieve_data = vdpau_retrieve_data,
+};
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vdpau: Remove a spurious CONFIG_H263_VDPAU_HWACCEL
Le 2015-11-05 14:04, Vittorio Giovara a écrit : From: Michael Niedermayer <mich...@niedermayer.cc> Fixes libavcodec/vdpau.c:282:5: warning: "CONFIG_H263_VDPAU_HWACCEL" is not defined [-Wundef] Removed in d35d0c723e3c8fc8cde76bf677f67928f5e179a8. This patch is correct. I would probably have noticed the problem in the first place if libavcodec did not print (at least) one deprecation warning per source module :-( -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ff_getnameinfo: fix struct servent dependancy
Le 2015-10-28 15:54, Martin Storsjö a écrit : From: Clément Gregoire <lec...@gmail.com> On systems lacking getservbyport, struct servent might not be defined, causing a compilation error when trying to access its member s_name (ent->s_name). There is no point in keeping the if(ent) branch when getservbyport is not available. On ancient OSes, I'd remove all use of servent and replace with strtoul/s*printf or whatever. It would be thread safe and not have those issues. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] vdpau: remoe dysfunctional H.263 support
The VDPAU API never explicitly supported H.263 in the first place.
---
configure| 2 --
libavcodec/Makefile | 1 -
libavcodec/allcodecs.c | 1 -
libavcodec/vdpau_mpeg4.c | 24
4 files changed, 28 deletions(-)
diff --git a/configure b/configure
index 8d44768..c79c203 100755
--- a/configure
+++ b/configure
@@ -2061,8 +2061,6 @@ vdpau_deps="vdpau_vdpau_h vdpau_vdpau_x11_h"
h263_vaapi_hwaccel_deps="vaapi"
h263_vaapi_hwaccel_select="h263_decoder"
-h263_vdpau_hwaccel_deps="vdpau"
-h263_vdpau_hwaccel_select="h263_decoder"
h264_d3d11va_hwaccel_deps="d3d11va"
h264_d3d11va_hwaccel_select="h264_decoder"
h264_dxva2_hwaccel_deps="dxva2"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9dc8009..0cca9ce 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -592,7 +592,6 @@ OBJS-$(CONFIG_VDA)+= vda.o
OBJS-$(CONFIG_VDPAU) += vdpau.o
OBJS-$(CONFIG_H263_VAAPI_HWACCEL) += vaapi_mpeg4.o
-OBJS-$(CONFIG_H263_VDPAU_HWACCEL) += vdpau_mpeg4.o
OBJS-$(CONFIG_H264_D3D11VA_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_DXVA2_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_VAAPI_HWACCEL) += vaapi_h264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 731b757..0ad102c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -75,7 +75,6 @@ void avcodec_register_all(void)
/* hardware accelerators */
REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
-REGISTER_HWACCEL(H263_VDPAU,h263_vdpau);
REGISTER_HWACCEL(H264_D3D11VA, h264_d3d11va);
REGISTER_HWACCEL(H264_DXVA2,h264_dxva2);
REGISTER_HWACCEL(H264_MMAL, h264_mmal);
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/vdpau_mpeg4.c
index 978456a..fcad42f 100644
--- a/libavcodec/vdpau_mpeg4.c
+++ b/libavcodec/vdpau_mpeg4.c
@@ -88,29 +88,6 @@ static int vdpau_mpeg4_decode_slice(av_unused AVCodecContext
*avctx,
return 0;
}
-#if CONFIG_H263_VDPAU_HWACCEL
-static int vdpau_h263_init(AVCodecContext *avctx)
-{
-return ff_vdpau_common_init(avctx, VDP_DECODER_PROFILE_MPEG4_PART2_ASP,
-VDP_DECODER_LEVEL_MPEG4_PART2_ASP_L5);
-}
-
-AVHWAccel ff_h263_vdpau_hwaccel = {
-.name = "h263_vdpau",
-.type = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H263,
-.pix_fmt= AV_PIX_FMT_VDPAU,
-.start_frame= vdpau_mpeg4_start_frame,
-.end_frame = ff_vdpau_mpeg_end_frame,
-.decode_slice = vdpau_mpeg4_decode_slice,
-.frame_priv_data_size = sizeof(struct vdpau_picture_context),
-.init = vdpau_h263_init,
-.uninit = ff_vdpau_common_uninit,
-.priv_data_size = sizeof(VDPAUContext),
-};
-#endif
-
-#if CONFIG_MPEG4_VDPAU_HWACCEL
static int vdpau_mpeg4_init(AVCodecContext *avctx)
{
VdpDecoderProfile profile;
@@ -142,4 +119,3 @@ AVHWAccel ff_mpeg4_vdpau_hwaccel = {
.uninit = ff_vdpau_common_uninit,
.priv_data_size = sizeof(VDPAUContext),
};
-#endif
--
2.6.2
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vdpau: remoe dysfunctional H.263 support
On Wednesday 28 October 2015 20:59:01 Luca Barbato wrote: > On 28/10/15 20:21, Rémi Denis-Courmont wrote: > > The VDPAU API never explicitly supported H.263 in the first place. > > --- > > > > configure| 2 -- > > libavcodec/Makefile | 1 - > > libavcodec/allcodecs.c | 1 - > > libavcodec/vdpau_mpeg4.c | 24 > > 4 files changed, 28 deletions(-) > > Hum? this part below maybe is a stray? Patch ok I think. No, and wm4 explained why already. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] httpauth: Add quotes around the algorithm string
Le 2015-10-13 12:44, Martin Storsjö a écrit : From: Carl Eugen Hoyos <ceho...@ag.or.at> Some overly strict implementations require this, even though it technically is incorrect according to the spec. That's not overly strict, that's just plain broken. Overly (or not so overly) strict implementations require that there be no quotes here. It might be a good idea to accept invalid extraneous quotes for IOP. Sending invalid messages ones on purpose is insane. The problem is known and the conclusion from RFC7616 was to verry explicitly FORBID quotes. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] httpauth: Add quotes around the algorithm string
Le 2015-10-13 20:47, Luca Barbato a écrit : On 13/10/15 18:21, Rémi Denis-Courmont wrote: Le 2015-10-13 12:44, Martin Storsjö a écrit : From: Carl Eugen Hoyos <ceho...@ag.or.at> Some overly strict implementations require this, even though it technically is incorrect according to the spec. That's not overly strict, that's just plain broken. Overly (or not so overly) strict implementations require that there be no quotes here. It might be a good idea to accept invalid extraneous quotes for IOP. Sending invalid messages ones on purpose is insane. The problem is known and the conclusion from RFC7616 was to verry explicitly FORBID quotes. You suggest to drop the patch or to update the commit message (I already amended it with s/overly strict/faulty/ locally.) I suggest dropping the patch. Postel's principle is to be strict in what you send, relaxed in what you accept. Though there has been recent push for being strict both ways due to, notably, security concerns. There never was a reasonable proposal to be relaxed in what you send, for a good reason. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
Le 2015-10-07 19:33, Derek Buitenhuis a écrit :
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/h264.c | 9 -
libavcodec/h264.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 4c1e135..0a0db9a 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -606,6 +606,8 @@ static int h264_init_context(AVCodecContext
*avctx, H264Context *h)
return 0;
}
+static pthread_once_t ff_h264_vlc_init = PTHREAD_ONCE_INIT;
+
av_cold int ff_h264_decode_init(AVCodecContext *avctx)
{
H264Context *h = avctx->priv_data;
@@ -619,7 +621,11 @@ av_cold int ff_h264_decode_init(AVCodecContext
*avctx)
if (!avctx->has_b_frames)
h->low_delay = 1;
-ff_h264_decode_init_vlc();
+ret = pthread_once(_h264_vlc_init, _h264_decode_init_vlc);
+if (ret != 0) {
I would assert and abort here. The most likely problems here are
deadlocks (i.e. recursive initialization) and memory corruption (once
ff_h264_vlc_init is garbage)...
+av_log(avctx, AV_LOG_ERROR, "pthread_once has failed.");
+return AVERROR_UNKNOWN;
+}
if (avctx->codec_id == AV_CODEC_ID_H264) {
if (avctx->ticks_per_frame == 1)
@@ -1801,6 +1807,7 @@ AVCodec ff_h264_decoder = {
.capabilities = /*AV_CODEC_CAP_DRAW_HORIZ_BAND |*/
AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_FRAME_THREADS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
.flush = flush_dpb,
.init_thread_copy =
ONLY_IF_THREADS_ENABLED(decode_init_thread_copy),
.update_thread_context =
ONLY_IF_THREADS_ENABLED(ff_h264_update_thread_context),
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index bf8b07e..e9fd9cc 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -29,6 +29,7 @@
#define AVCODEC_H264_H
#include "libavutil/intreadwrite.h"
+#include "libavutil/thread.h"
#include "cabac.h"
#include "error_resilience.h"
#include "get_bits.h"
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] thread: Provide no-op macros for pthread_once
Le 2015-10-07 23:48, Luca Barbato a écrit :
---
libavutil/thread.h | 10 ++
1 file changed, 10 insertions(+)
It isn't exactly beautiful with `!control` used to return 0 and
suppress the unused warning, but seems to work as intended and it
is fully portable, I'd use `({ routine(); !control; })` if we assume
the construct is always supported, but I'm afraid it is not.
diff --git a/libavutil/thread.h b/libavutil/thread.h
index 3556544..d2fb847 100644
--- a/libavutil/thread.h
+++ b/libavutil/thread.h
@@ -39,6 +39,11 @@
#define ff_mutex_unlock pthread_mutex_unlock
#define ff_mutex_destroy pthread_mutex_destroy
+#define AVOnce pthread_once_t
+#define AV_ONCE_INIT PTHREAD_ONCE_INIT
+
+#define ff_thread_once(control, routine) pthread_once(control,
routine)
+
#else
#define AVMutex char
@@ -48,6 +53,11 @@
#define ff_mutex_unlock(mutex) (0)
#define ff_mutex_destroy(mutex) (0)
+#define AVOnce char
+#define AV_ONCE_INIT 0
+
+#define ff_thread_once(control, routine) !control; routine();
Why don't you use a static inline? I don't think you can make a
semantically correct and expansion-safe pure C macro here.
This should be semantically correct, but is obviously not safe w.r.t.
to evaluation of "control":
#define ff_thread_once(control, routine) \
(*(control) == 0 ? ((routine)(), *(control) = 1, 0) \
: ((*(control) != 1) * EINVAL))
I'm not convinced this is very useful. The overhead of pthread_once()
should be negligible when single threaded.
(And pthread-stubs is a much better solution to this "problem", as it
can (de)select multithreading at run time rather than build time.)
+
#endif
#endif /* AVUTIL_THREAD_H */
--
2.5.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
Le 2015-10-08 17:21, Hendrik Leppkes a écrit : pthread is a bit of a exception. All its functions can return errors, but the only time they would is if you pass in an invalid argument. No-one checks return values of pthread_mutex_lock, for example. That is not true. Plenty of projects check for errors there for debugging. Only functions worthy of checking are the related init functions. I have to disagree pretty much totally here. POSIX thread errors on use (lock, unlock, signal, wait, etc) and destroy functions should be checked via assertions. I found quite a few bugs in other projects thanks to that. In debug builds, error detection can be further improved with the error-checking mutex type instead of the default. On the other hand, checking init functions is useless. Any sane POSIX thread implementation will just initialize memory and always return 0 (glibc does that, probably musl too). Errors are only specified to allow naive POSIX implementations to allocate resources; reasonable implementations allocate all needed resources when creating processes and threads. Except for the ETIMEDOUT error, the only really possible failure case is pthread_create(). -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] thread: Provide no-op macros for pthread_once
Le 2015-10-08 18:01, wm4 a écrit : It's extremely related. We could use pthread function names directly, instead of going through our stupid ff_ aliases. And you wouldn't have to make two separate builds of libav*. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
Le 2015-10-08 17:47, Hendrik Leppkes a écrit : The real point of course is that pthread_once just cannot fail. The spec doesn't define any error codes, A reasonable implementation cannot fail. The specification certainly allows for it to fail. The only forbidden error code is EINTR, meaning a signal will not interrupt the call. It would definitely make sense for a libc to return EINVAL if it detects that the once is not in either of the valid two states. A lame implementation could return ENOMEM. I don't really care about pthread_once(). But I think libav should check mutex and CV operations. Namely, abort if init fails, and assert for all other functions for self debugging. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] w32pthreads: add pthread_once emulation
Le 2015-10-06 20:43, wm4 a écrit : On Tue, 6 Oct 2015 12:41:13 +0200 Hendrik Leppkes <h.lepp...@gmail.com> wrote: The emulation uses native InitOnce* APIs on Windows Vista+, and a lock-free/allocation-free approach using atomics and spinning for Windows XP. --- This is in preparation to use pthread_once for global static init functions, and eventually removing the global lock in avcodec_open2 compat/w32pthreads.h | 68 1 file changed, 68 insertions(+) Somewhat related to this patch, we were discussing ways to deal with w32thread_init(). Personally, I think we should not have to litter the code with w32thread_init() calls. Nor should the user somehow have to make sure that this function is somehow called implicitly, when calling API functions which use threads. There are a few ways to handle this: 1. Don't handle it, but put it e.g. in avcodec_register_all(), and hope the user calls it before calling other APIs which might require it. 2. Call it from DllMain() only. This breaks static linking, or requires special care if an application uses a statically linked libav. 3. Make w32thread_init() thread-safe, and call it from all entrypoints that need it, like pthread_cond_init() and pthread_once(). 4. Remove the *run-time* Windows Vista+ support. People get to choose the better Vista+ or the crappy NT5 CV implementation at build time. 5. Drop support for Windows 2003 and older completely. Even MSDN started dropping documentation for it. Either way, the function is no longer necessary at all. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] closing down ABI breaking time
Le 2015-10-06 15:27, wm4 a écrit : On Tue, 6 Oct 2015 12:39:12 +0200 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: Hi all, it's been about two months since the big major bump, and ABI hunt season has been quite intense. Is there anything left that people would like to address before we close down changing ABI and move to release/12? I'm wondering if we should remove sizeof(AVPacket) from the ABI. I don't think you can have a defined type without a size in C. Decreeing that the size is no longer fixed without enforcing it at build time will be a disaster with existing code bases. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] vdpau: deprecate av_vdpau_get_profile()
This function can intrinsically not deal with codec profile fallback (for H.264 Constrained Baseline especially), and was made redundant by av_vdpau_bind_context(). --- libavcodec/vdpau.h | 5 + libavcodec/version.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h index 4e5c351..d25ee1c 100644 --- a/libavcodec/vdpau.h +++ b/libavcodec/vdpau.h @@ -177,10 +177,13 @@ int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type, */ AVVDPAUContext *av_vdpau_alloc_context(void); +#if FF_API_VDPAU_PROFILE /** * Get a decoder profile that should be used for initializing a VDPAU decoder. * Should be called from the AVCodecContext.get_format() callback. * + * @deprecated Use av_vdpau_bind_context() instead. + * * @param avctx the codec context being used for decoding the stream * @param profile a pointer into which the result will be written on success. *The contents of profile are undefined if this function returns @@ -188,7 +191,9 @@ AVVDPAUContext *av_vdpau_alloc_context(void); * * @return 0 on success (non-negative), a negative AVERROR on failure. */ +attribute_deprecated int av_vdpau_get_profile(AVCodecContext *avctx, VdpDecoderProfile *profile); +#endif #if FF_API_CAP_VDPAU /** @brief The videoSurface is used for rendering. */ diff --git a/libavcodec/version.h b/libavcodec/version.h index ecd6e1d..c704d44 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -165,5 +165,8 @@ #ifndef FF_API_SIDEDATA_ONLY_PKT #define FF_API_SIDEDATA_ONLY_PKT (LIBAVCODEC_VERSION_MAJOR < 59) #endif +#ifndef FF_API_VDPAU_PROFILE +#define FF_API_VDPAU_PROFILE (LIBAVCODEC_VERSION_MAJOR < 59) +#endif #endif /* AVCODEC_VERSION_H */ -- 2.1.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vdpau: fix constrained baseline fallback
Le 2015-09-26 16:17, wm4 a écrit :
It appears vdpau drivers can return constrained baseline as
unsupported,
even if libvdpau knows about the symbol, and the main profile is
supported.
---
Reenables hw decoding of CBP video with some drivers.
---
libavcodec/vdpau.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 8606624..77b649b 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -173,8 +173,7 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
status = decoder_query_caps(vdctx->device, profile, ,
_level,
_mb, _width, _height);
#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
-if (status != VDP_STATUS_OK && profile ==
VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE) {
-/* Run-time backward compatibility for libvdpau 0.8 and
earlier */
+if ((status != VDP_STATUS_OK || supported != VDP_TRUE) &&
profile == VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE) {
profile = VDP_DECODER_PROFILE_H264_MAIN;
status = decoder_query_caps(vdctx->device, profile,
,
_level, _mb,
Seems fine.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ABI compatiblity with ffmpeg
Hello, Le 2015-09-06 23:56, Ganesh Ajjanagadde a écrit : (...) change in policy of ffmpeg; with most devs in ffmpeg not caring about ABI compatibility with libav anymore. I don't know that any application developer ever cared about binary compatibility between libav and FFmpeg. A number of developers try to keep source compatibility with both sides, but what would be the point of binary compatiblity? It seems rather unlikely that someone would want to run-time switch. Besides, libav regularly breaks binary compatibility with its own self, making the issue largely moot. I think this is really a matter for FFmpeg developers to decide. But if I were them, I would definitely not waste my time^W^W^Wcare for binary compatiblity. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Dropping Windows XP and Windows 2003 support
Le 2015-07-01 15:35, wm4 a écrit : We were discussing some necessary library-safety cleanups on #libav-devel. One of them is the removal of the lock manager, which we all agreed that it must die. This would be pretty simple with pthreads and modern win32 APIs. But some of the win32 APIs which would make this easy are not available on XP, such as the InitOnce* group of functions. In the case of libav, it would also greatly simplify the threading code thanks to native support for condition variables, in particular. Windows XP is ancient, and despite its popularity is not even supported by Microsoft anymore. Windows 2003, which is on a similar level as XP in supported APIs, is also being killed of by Microsoft. (Extended support apparently ends in 13 days.) So the question is: would it be ok to finally drop XP support for the sake of cleaner and simpler code? I would rather have phrased the question more explicitly as: Is it acceptable to drop 2003/older support in future versions?. Nobody breaks support for already running software on existing computers running XP in any case. In my opinion, imposing known bugs on users of supported Windows version for the sake of users of unsupported versions is immoral. On the development side, the fact of the matter is that Microsoft silently removes compatibility informations from MSDN for unsupported OS versions. Indeed, Windows XP is arleady partly removed. So expecting support in patches/reviews is impractical. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] network: prevent SIGPIPE on OSX
Le jeudi 28 mai 2015, 18:23:27 wm4 a écrit : OSX does not know MSG_NOSIGNAL, and provides its own non-standard mechanism instead. I guess Apple hates standards. Actually, SO_NOSIGPIPE is a BSD thing. It just happens to be so old that Darwin inherited it. (And it was made redundant by MSG_NOSIGNAL on modern BSD, of course.) -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] nvenc: Initial implementation
Le 2015-05-19 13:26, Luca Barbato a écrit :
+static int nvenc_setup_h264_config(AVCodecContext *avctx)
+{
+NVENCContext *ctx = avctx-priv_data;
+NV_ENC_CONFIG *cc = ctx-config;
+NV_ENC_CONFIG_H264 *h264 =
cc-encodeCodecConfig.h264Config;
+NV_ENC_CONFIG_H264_VUI_PARAMETERS *vui =
h264-h264VUIParameters;
+
+vui-colourDescriptionPresentFlag = 1;
+vui-videoSignalTypePresentFlag = 1;
+
+vui-colourMatrix= avctx-colorspace;
+vui-colourPrimaries = avctx-color_primaries;
+vui-transferCharacteristics = avctx-color_trc;
+
+vui-videoFullRangeFlag = avctx-color_range ==
AVCOL_RANGE_JPEG;
+
+h264-disableSPSPPS = (avctx-flags CODEC_FLAG_GLOBAL_HEADER)
? 1 : 0;
+h264-repeatSPSPPS = (avctx-flags CODEC_FLAG_GLOBAL_HEADER)
? 0 : 1;
+
+h264-maxNumRefFrames = avctx-refs;
+h264-idrPeriod = cc-gopLength;
+
+if (ctx-profile)
+avctx-profile = ctx-profile;
+
+if (avctx-pix_fmt == AV_PIX_FMT_YUV444P)
+h264-chromaFormatIDC = 3;
+else
+h264-chromaFormatIDC = 1;
+
+switch (avctx-profile) {
+case FF_PROFILE_H264_BASELINE:
+cc-profileGUID = NV_ENC_H264_PROFILE_BASELINE_GUID;
+break;
What about CBP?
+case FF_PROFILE_H264_MAIN:
+cc-profileGUID = NV_ENC_H264_PROFILE_MAIN_GUID;
+break;
+case FF_PROFILE_H264_HIGH:
+cc-profileGUID = NV_ENC_H264_PROFILE_HIGH_GUID;
+break;
+case FF_PROFILE_UNKNOWN:
+default:
+av_log(avctx, AV_LOG_WARNING,
+ Unsupported profile %d requested, falling back to
high\n,
+ ctx-profile);
+cc-profileGUID = NV_ENC_H264_PROFILE_HIGH_GUID;
+avctx-profile = FF_PROFILE_H264_HIGH;
+break;
+}
+
+if (ctx-level) {
+h264-level = ctx-level;
+} else {
+h264-level = NV_ENC_LEVEL_AUTOSELECT;
+}
+
+return 0;
+}
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] nvenc: Initial implementation
Le 2015-05-25 13:54, Luca Barbato a écrit :
On 25/05/15 12:46, Rémi Denis-Courmont wrote:
+switch (avctx-profile) {
+case FF_PROFILE_H264_BASELINE:
+cc-profileGUID = NV_ENC_H264_PROFILE_BASELINE_GUID;
+break;
What about CBP?
I see a NV_ENC_H264_PROFILE_CONSTRAINED_HIGH_GUID but not a
NV_ENC_H264_PROFILE_CONSTRAINED_BASELINE_GUID
How does that justify falling back to High when CBP is requested? And
ditto for CHP since you brought it up.
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] nvenc: Initial implementation
Le 2015-05-25 14:44, Luca Barbato a écrit : On 25/05/15 13:37, Rémi Denis-Courmont wrote: How does that justify falling back to High when CBP is requested? And ditto for CHP since you brought it up. Issuing an error and going out instead of a warning sounds better? IMHO, an encoder output: - MUST obey the requested constraints, - SHOULD leverage as many codec feature as the requested constraints permit. So you cannot upgrade CBP or CHP to HP. I presume that NVENC's BP is actually H264's CBP. It's very unlikely that the non-constrained features of BP would be used: the resulting output would not conform to MP/HP. -- Rémi Denis-Courmont Remlab T:mi http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] nvenc: Initial implementation
Le lundi 25 mai 2015, 20:42:58 Luca Barbato a écrit : On 25/05/15 13:51, Rémi Denis-Courmont wrote: Le 2015-05-25 14:44, Luca Barbato a écrit : On 25/05/15 13:37, Rémi Denis-Courmont wrote: How does that justify falling back to High when CBP is requested? And ditto for CHP since you brought it up. Issuing an error and going out instead of a warning sounds better? IMHO, an encoder output: - MUST obey the requested constraints, - SHOULD leverage as many codec feature as the requested constraints permit. So you cannot upgrade CBP or CHP to HP. I presume that NVENC's BP is actually H264's CBP. It's very unlikely that the non-constrained features of BP would be used: the resulting output would not conform to MP/HP. Btw right now it just accepts main, high and baseline as input and rejects anything else. That is not how I read the patch... It seems to me it´s falling back to High for all except Baseline and Main. I'd keep it like this for the first iteration and add more profiles as the need arises later. IMO, that is terrible: You require selecting BP to get CBP. That punishes with failure those with a clue who correctly select CBP when they want CBP. -- Rémi Denis-Courmont Remlab T:mi http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] udp: Use a larger default for the system buffer
Le vendredi 15 mai 2015, 22:06:02 Luca Barbato a écrit : On 15/05/15 20:39, Rémi Denis-Courmont wrote: Le 2015-05-15 17:18, Luca Barbato a écrit : Make it as large as 5 times the expected maximum udp packet. Increasing the buffer size may be a good idea on Windows. But setting a buffer size is usually a bad idea on Linux in my experience (the kernel knows better). You need that if you are receiving a full hd video over udp+mpegts and that's getting the standard use case. No. You need that if your software has performance problems and fails to read incoming datagrams for too long. But then again, that being the case, your application will sooner or later exceed the kernel-imposed security limits. Of course, the kernel buffers need to be large enough to cope with packet bursts, but that is not directly related to the bit rate. If you do not have enough CPU to process incoming packets, you are screwed. If you do, but the application is making poor use of it, then you should fix the application, not the kernel settings. FWIW, VLC reads UDP from a dedicated thread, maintaining potentially large buffer in *user* space. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] udp: Use a larger default for the system buffer
Le lundi 18 mai 2015, 16:48:26 John Högberg a écrit : I think you either misunderstood what the patch is intended to fix (as I understand it) or underestimate how small the forced default 64K is. In case you missed it, libav forces the receive buffer size to 64K (or buffer_size) overriding whatever size the OS wanted. My point is that leaving the OS default is the best choice on Linux, and that the patch is hardly an improvement in this respect. I of course agree that shrinking the OS default is bad idea. -- Rémi Denis-Courmont Remlab T:mi http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] udp: Use a larger default for the system buffer
Le 2015-05-15 17:18, Luca Barbato a écrit :
Make it as large as 5 times the expected maximum udp packet.
Increasing the buffer size may be a good idea on Windows. But setting a
buffer size is usually a bad idea on Linux in my experience (the kernel
knows better).
In any case, PACKET size over 65535 bytes makes absolutely no sense. It
is not possible at the protocol level (unless jumbo grams maybe but
nobody uses that for multimedia if at all).
---
libavformat/udp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index dfc3b5a..d7b5eb10 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -58,8 +58,8 @@ typedef struct UDPContext {
char *block;
} UDPContext;
-#define UDP_TX_BUF_SIZE 32768
-#define UDP_MAX_PKT_SIZE 65536
+#define UDP_TX_BUF_SIZE 32768 * 5
+#define UDP_MAX_PKT_SIZE 65536 * 5
#define OFFSET(x) offsetof(UDPContext, x)
#define D AV_OPT_FLAG_DECODING_PARAM
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] tls: fix SIGPIPE with GnuTLS
Le dimanche 10 mai 2015, 19:15:24 wm4 a écrit : GnuTLS uses writev() to write to the socket without giving MSG_NOSIGNAL. Should that not be fixed upstream? Do they specifically want to support non- socket file descriptors? -- Rémi Denis-Courmont Remlab T:mi http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] tls: fix SIGPIPE with OpenSSL
Le dimanche 10 mai 2015, 19:15:25 wm4 a écrit :
A low-effort fix for fixing SIGPIPE being raised in some situations
because OpenSSL uses a naive write() to send data to the socket without
using MSG_NOSIGNAL.
The idea and code for blocking and unqueuing SIGPIPE is taken from:
http://stackoverflow.com/questions/24920748/how-to-handle-a-sigpipe-error-in
side-the-object-that-generated-it/24921005#24921005
A proper fix would probably either fix OpenSSL itself, or use a callback
based BIO wrapper.
---
I'm very sorry for even sending this shitty patch.
My hope is that someone else implements a proper fix, because I'm too
lazy to write a proper fix. (Matching OpenSSL's and avio's IO doesn't
sound like fun.)
---
libavformat/tls.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/libavformat/tls.c b/libavformat/tls.c
index 4a52e84..892fa6f 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -57,6 +57,25 @@
#include poll.h
#endif
+#if CONFIG_OPENSSL HAVE_POLL_H HAVE_PTHREADS
+#include pthread.h
+#include signal.h
+#include errno.h
+#define BLOCK_SIGPIPE \
Why an ugly macro rather than two function calls?
+sigset_t oldset, newset; \
+siginfo_t si; \
+struct timespec ts = {0}; \
0,0 to avoid a warning?
+sigemptyset(newset); \
+sigaddset(newset, SIGPIPE); \
+pthread_sigmask(SIG_BLOCK, newset, oldset);
+#define UNBLOCK_SIGPIPE \
+while (sigtimedwait(newset, si, ts) = 0 || errno != EAGAIN) {}; \
+pthread_sigmask(SIG_SETMASK, oldset, 0);
+#else
+#define BLOCK_SIGPIPE
+#define UNBLOCK_SIGPIPE
+#endif
+
typedef struct TLSContext {
const AVClass *class;
URLContext *tcp;
@@ -155,6 +174,7 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op struct addrinfo hints = { 0 }, *ai = NULL;
const char *proxy_path;
int use_proxy;
+BLOCK_SIGPIPE
ff_tls_init();
@@ -317,12 +337,14 @@ static int tls_open(URLContext *h, const char *uri,
int flags, AVDictionary **op goto fail;
}
#endif
+UNBLOCK_SIGPIPE
return 0;
fail:
TLS_free(c);
if (c-tcp)
ffurl_close(c-tcp);
ff_tls_deinit();
+UNBLOCK_SIGPIPE
return ret;
}
@@ -344,25 +366,32 @@ static int tls_read(URLContext *h, uint8_t *buf, int
size) static int tls_write(URLContext *h, const uint8_t *buf, int size) {
TLSContext *c = h-priv_data;
+int ret;
+BLOCK_SIGPIPE
while (1) {
-int ret = TLS_write(c, buf, size);
+ret = TLS_write(c, buf, size);
if (ret 0)
-return ret;
-if (ret == 0)
-return AVERROR_EOF;
+break;
+if (ret == 0) {
+ret = AVERROR_EOF;
+break;
+}
if ((ret = do_tls_poll(h, ret)) 0)
-return ret;
+break;
}
-return 0;
+UNBLOCK_SIGPIPE
+return ret;
}
static int tls_close(URLContext *h)
{
TLSContext *c = h-priv_data;
+BLOCK_SIGPIPE
TLS_shutdown(c);
TLS_free(c);
ffurl_close(c-tcp);
ff_tls_deinit();
+UNBLOCK_SIGPIPE
return 0;
}
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] dxva2: split the code so it can be reused by a D3D11 decoder
Le 2015-05-06 14:42, Steve Lhomme a écrit : most calls to DXVA are now done via macros and the core C code is included I am not an authority here, but I'd use callbacks over macros, if only to avoid duplicate byte code. -- Rémi Denis-Courmont Remlab T:mi http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH] avconv: Add an option for automatically rotating video according to display matrix
Le 2015-04-30 15:58, Anton Khirnov a écrit : Another thing we should keep in mind for the future is that the rotation side data can also be present on the codec level or the packet level (...) the latter is only theoretical for now http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-10 ? -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH] avconv: Add an option for automatically rotating video according to display matrix
Le 2015-04-30 16:13, Anton Khirnov a écrit : I meant that we don't currently support it. Is this feature actually used in the wild? I would not call Video over LTE wild just yet... (if ever.) -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/4] lavc: Improve thread locking error message
Le 2015-03-10 04:28, Vittorio Giovara a écrit :
---
libavcodec/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d568cbb..f8a8908 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,7 +1050,10 @@ int attribute_align_arg
avcodec_open2(AVCodecContext *avctx, const AVCodec *code
entangled_thread_counter++;
if (entangled_thread_counter != 1) {
-av_log(avctx, AV_LOG_ERROR, insufficient thread locking
around avcodec_open/close()\n);
+av_log(avctx, AV_LOG_ERROR,
+ Insufficient thread locking around avcodec_open2().
+ At least %d threads are running at the same time
right now.\n,
+ entangled_thread_counter);
Why don't you use standard __func__ and %s ?
ret = -1;
goto end;
}
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] why there is no pulse audio output in libavdevice?
Le 2015-03-05 12:39, Aihua Zhao a écrit : I noticed that there is pulse audio input in libavdevice, but not for pulse audio output. PulseAudio sink inputs (i.e. playback streams) offer a lot of features that could not be exposed through the libavdevice abstraction. For most applications, you are better off outputting to libpulse directly or through a more specific and feature-rich audio output abstraction. And then there is the major issue of timing. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mem: fix pointer pointer aliasing violations
This uses explicit memory copying to read and write pointer to pointers
of arbitrary object types. This works provided that the architecture
uses the same representation for all pointer types (the previous code
made that assumption already anyway).
---
libavutil/mem.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index b7bb65c..47bf847 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -139,21 +139,22 @@ void *av_realloc(void *ptr, size_t size)
int av_reallocp(void *ptr, size_t size)
{
-void **ptrptr = ptr;
-void *ret;
+void *val;
if (!size) {
av_freep(ptr);
return 0;
}
-ret = av_realloc(*ptrptr, size);
-if (!ret) {
+memcpy(val, ptr, sizeof (val));
+val = av_realloc(val, size);
+
+if (!val) {
av_freep(ptr);
return AVERROR(ENOMEM);
}
-*ptrptr = ret;
+memcpy(ptr, val, sizeof (val));
return 0;
}
@@ -166,20 +167,23 @@ void *av_realloc_array(void *ptr, size_t nmemb, size_t
size)
int av_reallocp_array(void *ptr, size_t nmemb, size_t size)
{
-void **ptrptr = ptr;
-void *ret;
+void *val;
+
if (!size || nmemb = INT_MAX / size)
return AVERROR(ENOMEM);
if (!nmemb) {
av_freep(ptr);
return 0;
}
-ret = av_realloc(*ptrptr, nmemb * size);
-if (!ret) {
+
+memcpy(val, ptr, sizeof (val));
+val = av_realloc(val, nmemb * size);
+if (!val) {
av_freep(ptr);
return AVERROR(ENOMEM);
}
-*ptrptr = ret;
+
+memcpy(ptr, val, sizeof (val));
return 0;
}
@@ -197,9 +201,11 @@ void av_free(void *ptr)
void av_freep(void *arg)
{
-void **ptr = (void **)arg;
-av_free(*ptr);
-*ptr = NULL;
+void *val;
+
+memcpy(val, arg, sizeof (val));
+memcpy(arg, (void *){ NULL }, sizeof (val));
+av_free(val);
}
void *av_mallocz(size_t size)
--
2.1.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 6/7] Add DXVA2 HEVC HWAccel
Le 2015-01-25 10:53, Hendrik Leppkes a écrit :
On Sun, Jan 25, 2015 at 8:06 AM, Diego Biurrun di...@biurrun.de
wrote:
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -401,6 +401,12 @@ static int set_sps(HEVCContext *s, const
HEVCSPS
*sps)
s-avctx-height = sps-output_height;
s-avctx-has_b_frames=
sps-temporal_layer[sps-max_sub_layers - 1].num_reorder_pics;
+if (sps-pix_fmt == AV_PIX_FMT_YUV420P || sps-pix_fmt ==
AV_PIX_FMT_YUVJ420P) {
+#if CONFIG_HEVC_DXVA2_HWACCEL
The more common style is to fold the condition into the if and rely
on the compiler performing DCE.
Its done this way in the expectation that more implementations will
appear
eventually, where having it inside the if condition makes no sense
anymore.
I'd use a switch statement though.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/7] hevc: reindent after previous commit
1-5 LGTM. 6-7 I don't have much clue. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vaapi: check the libva availability during the execution.
Le 2015-01-16 10:59, 김건수 a écrit : Let me explain our user scenario. Libavcodec will be distributed with our application. When the application starts to play a video, it will check the availability of libva. If libva is possible to use, the application uses hardware acceleration feature. That would fail miserably if libva is present but has no functioning driver backend. Besides, it makes no sense: it is not libavcodec that devices to use libva or not, it is the calling application. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vaapi: check the libva availability during the execution.
Le 2015-01-15 18:06, Luca Barbato a écrit : Personally I'm not against that assuming we can make it not completely brittle. The calling application and libavcodec must agree on the instance and SO version of libva in use. How do you make that not brittle? -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vaapi: check the libva availability during the execution.
Le 2015-01-14 12:45, Luca Barbato a écrit : We recently got some patches that would use dlopen so probably we can consolidate the dlopen support (and convince those the dislike it that isn't bad to provide an option for it). It is not bad to libraries that are large or somehow sensitive. It makes no sense for a library that is itself a plugin loader. libva is neither large nor sensitive; if anything, the individual VA drivers are large and/or sensitive. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vaapi: check the libva availability during the execution.
Le mercredi 14 janvier 2015, 16:09:47 Kim Gunsoo a écrit : - If you are deploying libav, build and runtime environments are different. Using --enable-vaapi can might cause to fail on the execution. - This is an optional feature to check the execution environment in the runtime. It can prevent to fail. I utterly fail to see any point in doing this. libva is just a glorified convenience wrapper around dlfcn.h. It consumes little memory and disk space of its own. The vendor-specific drivers do take a lot of disk space. But libva does not depend on them - that is the whole point... -- Rémi ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FOSDEM 2015 airport transfer
Hello all, Those of you going to/from FOSDEM via Brussels National / Zaventem airport, I strongly recommend that you buy train tickets to the city center online: http://www.sncb.be/ If you make the return trip between Friday 19:00 and Sunday 24:00, you can pay for the WEEKEND INTERNET fare type. Otherwise, you have to pay the normal price, but you avoid queues at the ticket counter. Looking forward to seeing many of you in Brussels, -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] Allow loading the OpenH264 library dynamically
Le 2014-12-31 20:34, Derek Buitenhuis a écrit : On 12/31/2014 5:25 PM, Luca Barbato wrote: I had those in my wishlist since a while (actually something a little more gory) since sometimes I feel the need of it =p I am liekly never going to accept to a patch to libx265.c to dynamically load arbitrary libs, and *especially* not to load both at once (oh my the symbol nightmares etc). On the one hand, symbol nightmares only occur because of RTLD_GLOBAL. Yet I am not aware of any good reason to use RTLD_GLOBAL within libavcodec. On the other hand, binary compatibility is peremptory. That pretty much excludes x264 and x265, and according to the comments in the previous patch, Cisco's OpenH264 as well. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCHv2 0/10] VDPAU H.264 High 4:4:4 support
Le 2014-12-19 08:51, Anton Khirnov a écrit : Why would you have to call avcodec_default_get_format()? You could just look at the last offered pixel format (the only non-hwaccel one). Sure but that is effectively the same thing. The problem remain that each and every application would have to code the mapping from AV_PIX_FMT_* to VDP_CHROMA_TYPE_* and to VDPAU-specific dimension constraints. Speaking of which, why is avcodec_default_get_format even public right now? I don't know but at least VLC uses it. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/7] avcodec: add AVCodecContext.sw_pix_fmt
This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 7 +++
libavcodec/utils.c | 15 +++
libavcodec/version.h | 2 +-
4 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3d1b72f..49e43f4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.8.0 - avcodec.h
+ Add AVCodecContext.sw_pix_fmt.
+
2014-11-xx - xxx - lavf 56.06.3 - avformat.h
Add AVFormatContext.avoid_negative_ts.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7df64ae..c998ee4 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2800,6 +2800,13 @@ typedef struct AVCodecContext {
* - encoding: unused
*/
AVRational framerate;
+
+/**
+ * Nominal unaccelerated pixel format, see AV_PIX_FMT_xxx.
+ * - encoding: unused.
+ * - decoding: Set by libavcodec before calling get_format()
+ */
+enum AVPixelFormat sw_pix_fmt;
} AVCodecContext;
/**
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 8cbd47b..fcc7dde 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -665,10 +665,13 @@ int ff_get_buffer(AVCodecContext *avctx, AVFrame *frame,
int flags)
if (ret 0)
return ret;
-if (hwaccel hwaccel-alloc_frame) {
-ret = hwaccel-alloc_frame(avctx, frame);
-goto end;
-}
+if (hwaccel) {
+if (hwaccel-alloc_frame) {
+ret = hwaccel-alloc_frame(avctx, frame);
+goto end;
+}
+} else
+avctx-sw_pix_fmt = avctx-pix_fmt;
#if FF_API_GET_BUFFER
FF_DISABLE_DEPRECATION_WARNINGS
@@ -933,6 +936,10 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
while (fmt[n] != AV_PIX_FMT_NONE)
++n;
+av_assert0(n = 1);
+avctx-sw_pix_fmt = fmt[n - 1];
+av_assert2(!is_hwaccel_pix_fmt(avctx-sw_pix_fmt));
+
choices = av_malloc_array(n + 1, sizeof(*choices));
if (!choices)
return AV_PIX_FMT_NONE;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f51c9d7..5d8f9a1 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 7
+#define LIBAVCODEC_VERSION_MINOR 8
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 4/7] libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 49e43f4..705501e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.9.0 - avcodec.h
+ Add AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH flag to av_vdpau_bind_context().
+
201x-xx-xx - xxx - lavc 56.8.0 - avcodec.h
Add AVCodecContext.sw_pix_fmt.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c998ee4..8a008c9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3052,6 +3052,12 @@ typedef struct AVHWAccel {
#define AV_HWACCEL_FLAG_IGNORE_LEVEL (1 0)
/**
+ * Hardware acceleration can output YUV pixel formats with a different chroma
+ * sampling than 4:2:0 and/or other than 8 bits per component.
+ */
+#define AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH (1 1)
+
+/**
* @}
*/
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 5d8f9a1..b5d3ce0 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 8
+#define LIBAVCODEC_VERSION_MINOR 9
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/7] h264: factor hwaccel pixel formats list
This is to avoid proliferation of similar tables in following changes.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 9169ff4..c2826e6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -143,42 +143,6 @@ static const uint8_t dequant8_coeff_init[6][6] = {
{ 36, 32, 58, 34, 46, 43 },
};
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-};
-
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_jpeg_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
-
static void release_unused_pictures(H264Context *h, int remove_current)
{
@@ -975,54 +939,69 @@ static int clone_slice(H264Context *dst, H264Context *src)
static enum AVPixelFormat get_pixel_format(H264Context *h)
{
-enum AVPixelFormat pix_fmts[2];
+#define HWACCEL_MAX (CONFIG_H264_DXVA2_HWACCEL + \
+ CONFIG_H264_VAAPI_HWACCEL + \
+ (CONFIG_H264_VDA_HWACCEL * 2) + \
+ CONFIG_H264_VDPAU_HWACCEL)
+enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
const enum AVPixelFormat *choices = pix_fmts;
-pix_fmts[1] = AV_PIX_FMT_NONE;
-
switch (h-sps.bit_depth_luma) {
case 9:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP9;
+*fmt++ = AV_PIX_FMT_GBRP9;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P9;
+*fmt++ = AV_PIX_FMT_YUV444P9;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P9;
+*fmt++ = AV_PIX_FMT_YUV422P9;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P9;
+*fmt++ = AV_PIX_FMT_YUV420P9;
break;
case 10:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP10;
+*fmt++ = AV_PIX_FMT_GBRP10;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P10;
+*fmt++ = AV_PIX_FMT_YUV444P10;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P10;
+*fmt++ = AV_PIX_FMT_YUV422P10;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P10;
+*fmt++ = AV_PIX_FMT_YUV420P10;
break;
case 8:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
-pix_fmts[0] = AV_PIX_FMT_GBRP;
+*fmt++ = AV_PIX_FMT_GBRP;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ444P;
+*fmt++ = AV_PIX_FMT_YUVJ444P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV444P;
+*fmt++ = AV_PIX_FMT_YUV444P;
} else if (CHROMA422(h)) {
if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ422P;
+*fmt++ = AV_PIX_FMT_YUVJ422P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV422P;
+*fmt++ = AV_PIX_FMT_YUV422P;
} else {
+#if CONFIG_H264_DXVA2_HWACCEL
+*fmt++ = AV_PIX_FMT_DXVA2_VLD;
+#endif
+#if CONFIG_H264_VAAPI_HWACCEL
+*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+#endif
+#if CONFIG_H264_VDA_HWACCEL
+*fmt++ = AV_PIX_FMT_VDA_VLD;
+*fmt++ = AV_PIX_FMT_VDA;
+#endif
+#if CONFIG_H264_VDPAU_HWACCEL
+*fmt++ = AV_PIX_FMT_VDPAU;
+#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-choices = h264_hwaccel_pixfmt_list_jpeg_420;
+*fmt++ = AV_PIX_FMT_YUVJ420P;
else
-choices = h264_hwaccel_pixfmt_list_420;
+*fmt++ = AV_PIX_FMT_YUV420P;
}
break;
default:
@@ -1031,6 +1010,8 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
return AVERROR_INVALIDDATA;
}
+*fmt = AV_PIX_FMT_NONE;
+
return ff_get_format(h-avctx, choices);
}
--
1.9.1
___
libav-devel mailing list
libav-devel
[libav-devel] [PATCH 1/7] vdpau: add support for the H.264 High 4:4:4 Predictive profile
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 11 +--
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 5ed1fff..742b648 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -123,6 +123,9 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
H264Picture *pic = h-cur_pic_ptr;
struct vdpau_picture_context *pic_ctx = pic-hwaccel_picture_private;
VdpPictureInfoH264 *info = pic_ctx-info.h264;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive *info2 = pic_ctx-info.h264_predictive;
+#endif
/* init VdpPictureInfoH264 */
info-slice_count= 0;
@@ -149,6 +152,10 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
info-log2_max_pic_order_cnt_lsb_minus4 = h-sps.poc_type ? 0 :
h-sps.log2_max_poc_lsb - 4;
info-delta_pic_order_always_zero_flag =
h-sps.delta_pic_order_always_zero_flag;
info-direct_8x8_inference_flag =
h-sps.direct_8x8_inference_flag;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+info2-qpprime_y_zero_transform_bypass_flag = h-sps.transform_bypass;
+info2-separate_colour_plane_flag=
h-sps.residual_color_transform_flag;
+#endif
info-entropy_coding_mode_flag = h-pps.cabac;
info-pic_order_present_flag = h-pps.pic_order_present;
info-deblocking_filter_control_present_flag =
h-pps.deblocking_filter_parameters_present;
@@ -228,6 +235,18 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_EXTENDED;
break;
#endif
+case FF_PROFILE_H264_HIGH_10:
+/* XXX: High 10 can be treated as High so long as only 8-bits per
+ * formats are supported. */
+profile = VDP_DECODER_PROFILE_H264_HIGH;
+break;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+case FF_PROFILE_H264_HIGH_422:
+case FF_PROFILE_H264_HIGH_444_PREDICTIVE:
+case FF_PROFILE_H264_CAVLC_444:
+profile = VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 16493b0..9cc9538 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -37,16 +37,15 @@ static inline uintptr_t ff_vdpau_get_surface_id(AVFrame
*pic)
return (uintptr_t)pic-data[3];
}
-#if !FF_API_BUFS_VDPAU
-union AVVDPAUPictureInfo {
+union VDPAUPictureInfo {
VdpPictureInfoH264h264;
VdpPictureInfoMPEG1Or2mpeg;
VdpPictureInfoVC1 vc1;
VdpPictureInfoMPEG4Part2 mpeg4;
-};
-#else
-#include vdpau.h
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive h264_predictive;
#endif
+};
typedef struct VDPAUHWContext {
AVVDPAUContext context;
@@ -85,7 +84,7 @@ struct vdpau_picture_context {
/**
* VDPAU picture information.
*/
-union AVVDPAUPictureInfo info;
+union VDPAUPictureInfo info;
/**
* Allocated size of the bitstream_buffers table.
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 5/7] vdpau: add helper for surface chroma type and size
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
doc/APIchanges | 3 +++
libavcodec/vdpau.c | 51 +++
libavcodec/vdpau.h | 20
libavcodec/version.h | 2 +-
4 files changed, 71 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 705501e..fce42e3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.10.0 - vdpau.h
+ Add av_vdpau_get_surface_parameters().
+
201x-xx-xx - xxx - lavc 56.9.0 - avcodec.h
Add AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH flag to av_vdpau_bind_context().
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index ccb3352..ea67314 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -64,6 +64,46 @@ static int vdpau_error(VdpStatus status)
}
}
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx,
+VdpChromaType *type,
+uint32_t *width, uint32_t *height)
+{
+VdpChromaType t;
+uint32_t w = avctx-coded_width;
+uint32_t h = avctx-coded_height;
+
+/* See vdpau/vdpau.h for per-type alignment constraints. */
+switch (avctx-sw_pix_fmt) {
+case AV_PIX_FMT_YUV420P:
+case AV_PIX_FMT_YUVJ420P:
+t = VDP_CHROMA_TYPE_420;
+w = (w + 1) ~1;
+h = (h + 3) ~3;
+break;
+case AV_PIX_FMT_YUV422P:
+case AV_PIX_FMT_YUVJ422P:
+t = VDP_CHROMA_TYPE_422;
+w = (w + 1) ~1;
+h = (h + 1) ~1;
+break;
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUVJ444P:
+t = VDP_CHROMA_TYPE_444;
+h = (h + 1) ~1;
+break;
+default:
+return AVERROR(ENOSYS);
+}
+
+if (type)
+*type = t;
+if (width)
+*width = w;
+if (height)
+*height = h;
+return 0;
+}
+
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
int level)
{
@@ -76,9 +116,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
VdpStatus status;
VdpBool supported;
uint32_t max_level, max_mb, max_width, max_height;
-/* See vdpau/vdpau.h for alignment constraints. */
-uint32_t width = (avctx-coded_width + 1) ~1;
-uint32_t height = (avctx-coded_height + 3) ~3;
+VdpChromaType type;
+uint32_t width;
+uint32_t height;
vdctx-width= UINT32_MAX;
vdctx-height = UINT32_MAX;
@@ -99,6 +139,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else if (level 0)
return AVERROR(ENOTSUP);
+if (av_vdpau_get_surface_parameters(avctx, type, width, height))
+return AVERROR(ENOSYS);
+
status = vdctx-get_proc_address(vdctx-device,
VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
func);
@@ -107,7 +150,7 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else
surface_query_caps = func;
-status = surface_query_caps(vdctx-device, VDP_CHROMA_TYPE_420, supported,
+status = surface_query_caps(vdctx-device, type, supported,
max_width, max_height);
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 24c3b02..4e5c351 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -151,6 +151,26 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
VdpGetProcAddress *get_proc_address, unsigned flags);
/**
+ * Gets the parameters to create an adequate VDPAU video surface for the codec
+ * context using VDPAU hardware decoding acceleration.
+ *
+ * @note Behavior is undefined if the context was not successfully bound to a
+ * VDPAU device using av_vdpau_bind_context().
+ *
+ * @param avctx the codec context being used for decoding the stream
+ * @param type storage space for the VDPAU video surface chroma type
+ * (or NULL to ignore
[libav-devel] [PATCH 6/7] vdpau: add support for 4:2:2 and 4:4:4 chroma sampling
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau.c | 6 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index c2826e6..edce30f 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -970,6 +970,9 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*fmt++ = AV_PIX_FMT_YUV420P10;
break;
case 8:
+#if CONFIG_H264_VDPAU_HWACCEL
+*fmt++ = AV_PIX_FMT_VDPAU;
+#endif
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
*fmt++ = AV_PIX_FMT_GBRP;
@@ -993,9 +996,6 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*fmt++ = AV_PIX_FMT_VDA_VLD;
*fmt++ = AV_PIX_FMT_VDA;
#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-*fmt++ = AV_PIX_FMT_VDPAU;
-#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index ea67314..8606624 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -142,6 +142,10 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
if (av_vdpau_get_surface_parameters(avctx, type, width, height))
return AVERROR(ENOSYS);
+if (!(hwctx-flags AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH)
+type != VDP_CHROMA_TYPE_420)
+return AVERROR(ENOSYS);
+
status = vdctx-get_proc_address(vdctx-device,
VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
func);
@@ -371,7 +375,7 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
{
VDPAUHWContext *hwctx;
-if (flags ~AV_HWACCEL_FLAG_IGNORE_LEVEL)
+if (flags
~(AV_HWACCEL_FLAG_IGNORE_LEVEL|AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH))
return AVERROR(EINVAL);
if (av_reallocp(avctx-hwaccel_context, sizeof(*hwctx)))
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 7/7] avconv_vdpau: allocate video surface of VDPAU-specified size
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..1bd1f48 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
VDPAUContext*ctx = ist-hwaccel_ctx;
VdpVideoSurface *surface;
VdpStatus err;
+VdpChromaType chroma;
+uint32_t width, height;
av_assert0(frame-format == AV_PIX_FMT_VDPAU);
+if (av_vdpau_get_surface_parameters(s, chroma, width, height))
+return AVERROR(ENOSYS);
+
surface = av_malloc(sizeof(*surface));
if (!surface)
return AVERROR(ENOMEM);
@@ -108,8 +113,8 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
// properly we should keep a pool of surfaces instead of creating
// them anew for each frame, but since we don't care about speed
// much in this code, we don't bother
-err = ctx-video_surface_create(ctx-device, VDP_CHROMA_TYPE_420,
-frame-width, frame-height, surface);
+err = ctx-video_surface_create(ctx-device, chroma, width, height,
+surface);
if (err != VDP_STATUS_OK) {
av_log(NULL, AV_LOG_ERROR, Error allocating a VDPAU video surface:
%s\n,
ctx-get_error_string(err));
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCHv2 0/10] VDPAU H.264 High 4:4:4 support
Le jeudi 18 décembre 2014, 22:55:06 Anton Khirnov a écrit : Overall I'm not entirely happy with the API creep, but as I cannot suggest any better way, I'm mostly fine with this set. There are three other ways I can suggest. The first one is to use different pixel formats, and I only mention it for the sake of completeness because nobody likes that idea except me. Another option is for the application to call avcodec_default_get_format(), match the unaccelerated pixel format to a hardware surface chroma type and to the size requirements. That is a little bit uglier in my opinion, and means more per-application copycat code. The last option is to store the needed bits directly in the context. That would be awful though. I think adding the new function from patch 4 is yet the cleanest and least invasive solution. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] avcodec/svq1dec: Fix multiple bugs from svq1: do not modify the input packet
From: Michael Niedermayer michae...@gmx.at Add padding, clear size, use the correct pointer. Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Rémi Denis-Courmont r...@remlab.net --- libavcodec/svq1dec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/svq1dec.c b/libavcodec/svq1dec.c index 14ff41c..4ea7ed2 100644 --- a/libavcodec/svq1dec.c +++ b/libavcodec/svq1dec.c @@ -637,7 +637,7 @@ static int svq1_decode_frame(AVCodecContext *avctx, void *data, return AVERROR_INVALIDDATA; } -av_fast_malloc(s-pkt_swapped, s-pkt_swapped_allocated, +av_fast_padded_malloc(s-pkt_swapped, s-pkt_swapped_allocated, buf_size); if (!s-pkt_swapped) return AVERROR(ENOMEM); @@ -818,6 +818,7 @@ static av_cold int svq1_decode_end(AVCodecContext *avctx) av_frame_free(s-prev); av_freep(s-pkt_swapped); +s-pkt_swapped_allocated = 0; return 0; } -- 2.1.3 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] vaapi: wrap codec specific functions in appropiate #ifs
From: Thiago Santos thiago.sousa.san...@collabora.com
Fixes linking when only a subset of vaapi decoders is enabled.
To reproduce, disable all features except h264 decoder and vaapi/vdpau
for h264
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/vaapi.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index b2dc41d..fcc6243 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -194,6 +194,9 @@ void ff_vaapi_common_end_frame(AVCodecContext *avctx)
vactx-slice_params_alloc = 0;
}
+#if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG1_VAAPI_HWACCEL || \
+CONFIG_MPEG2_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL || \
+CONFIG_VC1_VAAPI_HWACCEL || CONFIG_WMV3_VAAPI_HWACCEL
int ff_vaapi_mpeg_end_frame(AVCodecContext *avctx)
{
struct vaapi_context * const vactx = avctx-hwaccel_context;
@@ -215,5 +218,6 @@ finish:
ff_vaapi_common_end_frame(avctx);
return ret;
}
+#endif
/* @} */
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] avcodec/svq1dec: Fix multiple bugs from svq1: do not modify the input packet
Le dimanche 14 décembre 2014, 22:59:26 Rémi Denis-Courmont a écrit : From: Michael Niedermayer michae...@gmx.at Fixes bug #766. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] vaapi: wrap codec specific functions in appropiate #ifs
Le dimanche 14 décembre 2014, 22:59:27 Rémi Denis-Courmont a écrit : From: Thiago Santos thiago.sousa.san...@collabora.com Fixes bug #760. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCHv2 0/10] VDPAU H.264 High 4:4:4 support
The following changes since commit e737a4aaafcb1d761b7f96043c2f83ce742c64ae: dashenc: Change the duration fields to 64 bit (2014-12-10 22:51:51 +0200) are waiting for review up to. vdpau: add support for the H.264 High 4:4:4 Predictive profile (2014-12-13 18:39:01 +0200) Updates since last changes: - resync with libvdpau git tree, - address comments from Luca and Vittorio, - misc minor fixes. Rémi Denis-Courmont (10): vdpau: revector macro to reduce line span vdpau: add mapping for H.264 Extended profile vdpau: add mapping for H.264 Constrained Baseline profile and fallback vdpau: add helper for surface chroma type and size avconv_vdpau: allocate video surface of VDPAU-specified size libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag vdpau: add common support for other surface chroma types h264: factor hwaccel pixel formats list vdpau: add support for 4:2:2 and 4:4:4 chroma sampling in H.264 vdpau: add support for the H.264 High 4:4:4 Predictive profile avconv_vdpau.c | 9 +++- doc/APIchanges | 6 +++ libavcodec/avcodec.h| 6 +++ libavcodec/h264_slice.c | 89 +++- libavcodec/vdpau.c | 107 +++- libavcodec/vdpau.h | 20 + libavcodec/vdpau_h264.c | 57 ++- libavcodec/vdpau_internal.h | 17 --- libavcodec/vdpau_mpeg12.c | 6 ++- libavcodec/vdpau_mpeg4.c| 6 ++- libavcodec/vdpau_vc1.c | 3 +- libavcodec/version.h| 2 +- 12 files changed, 236 insertions(+), 92 deletions(-) -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 03/10] vdpau: add mapping for H.264 Constrained Baseline profile and fallback
Old VDPAU drivers do not support this newly defined profile, so falling
back to Main profile is necessary for backward binary compatibility.
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1e891ed..ccb3352 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -125,6 +125,15 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
status = decoder_query_caps(vdctx-device, profile, supported, max_level,
max_mb, max_width, max_height);
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+if (status != VDP_STATUS_OK profile ==
VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE) {
+/* Run-time backward compatibility for libvdpau 0.8 and earlier */
+profile = VDP_DECODER_PROFILE_H264_MAIN;
+status = decoder_query_caps(vdctx-device, profile, supported,
+max_level, max_mb,
+max_width, max_height);
+}
+#endif
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index d18a970..5ed1fff 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -213,6 +213,10 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_BASELINE;
break;
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+profile = VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE;
+break;
+#endif
case FF_PROFILE_H264_MAIN:
profile = VDP_DECODER_PROFILE_H264_MAIN;
break;
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 07/10] vdpau: add common support for other surface chroma types
---
libavcodec/vdpau.c | 38 ++
libavcodec/vdpau_h264.c | 2 +-
libavcodec/vdpau_internal.h | 3 ++-
libavcodec/vdpau_mpeg12.c | 6 --
libavcodec/vdpau_mpeg4.c| 6 --
libavcodec/vdpau_vc1.c | 3 ++-
6 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 8d9a649..463e600 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -67,20 +67,38 @@ static int vdpau_error(VdpStatus status)
int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
uint32_t *width, uint32_t *height)
{
-/* XXX: only 8-bits YCbCr 4:2:0 is supported yet */
-if (type)
-*type = VDP_CHROMA_TYPE_420;
+VdpChromaType t = VDP_CHROMA_TYPE_420;
+uint32_t w = avctx-coded_width;
+uint32_t h = avctx-coded_height;
+
/* See vdpau/vdpau.h for per-type alignment constraints. */
+switch (t)
+{
+case VDP_CHROMA_TYPE_420:
+w = (w + 1) ~1;
+h = (h + 3) ~3;
+break;
+case VDP_CHROMA_TYPE_422:
+w = (w + 1) ~1;
+h = (h + 1) ~1;
+break;
+case VDP_CHROMA_TYPE_444:
+h = (h + 1) ~1;
+break;
+}
+
+if (type)
+*type = t;
if (width)
-*width = (avctx-coded_width + 1) ~1;
+*width = w;
if (height)
-*height = (avctx-coded_height + 3) ~3;
+*height = h;
return 0;
}
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
- int level)
+ int level, VdpChromaType type)
{
VDPAUHWContext *hwctx = avctx-hwaccel_context;
VDPAUContext *vdctx = avctx-internal-hwaccel_priv_data;
@@ -91,10 +109,10 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
VdpStatus status;
VdpBool supported;
uint32_t max_level, max_mb, max_width, max_height;
-VdpChromaType type;
uint32_t width;
uint32_t height;
+vdctx-chroma_type = type;
vdctx-width= UINT32_MAX;
vdctx-height = UINT32_MAX;
hwctx-reset= 0;
@@ -114,6 +132,10 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else if (level 0)
return AVERROR(ENOTSUP);
+if (!(hwctx-flags AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH)
+type != VDP_CHROMA_TYPE_420)
+return AVERROR(ENOSYS);
+
status = vdctx-get_proc_address(vdctx-device,
VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
func);
@@ -122,7 +144,7 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else
surface_query_caps = func;
-av_vdpau_get_surface_parameters(avctx, type, width, height);
+av_vdpau_get_surface_parameters(avctx, NULL, width, height);
status = surface_query_caps(vdctx-device, type, supported,
max_width, max_height);
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 5ed1fff..6774882 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -235,7 +235,7 @@ static int vdpau_h264_init(AVCodecContext *avctx)
if ((avctx-profile FF_PROFILE_H264_INTRA) avctx-level == 11)
level = VDP_DECODER_LEVEL_H264_1b;
-return ff_vdpau_common_init(avctx, profile, level);
+return ff_vdpau_common_init(avctx, profile, level, VDP_CHROMA_TYPE_420);
}
AVHWAccel ff_h264_vdpau_hwaccel = {
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 16493b0..bcdeb90 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -77,6 +77,7 @@ typedef struct VDPAUContext {
*/
VdpDecoderRender *render;
+VdpChromaType chroma_type;
uint32_t width;
uint32_t height;
} VDPAUContext;
@@ -104,7 +105,7 @@ struct vdpau_picture_context {
};
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
- int level);
+ int level, VdpChromaType type);
int ff_vdpau_common_uninit(AVCodecContext *avctx);
int ff_vdpau_common_start_frame(struct vdpau_picture_context *pic,
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
index 421abe9..bafe83c 100644
--- a/libavcodec/vdpau_mpeg12.c
+++ b/libavcodec/vdpau_mpeg12.c
@@ -98,7 +98,8 @@ static int vdpau_mpeg_decode_slice(AVCodecContext *avctx,
static int vdpau_mpeg1_init(AVCodecContext *avctx)
{
return ff_vdpau_common_init(avctx, VDP_DECODER_PROFILE_MPEG1,
-VDP_DECODER_LEVEL_MPEG1_NA);
+VDP_DECODER_LEVEL_MPEG1_NA,
+VDP_CHROMA_TYPE_420);
}
AVHWAccel ff_mpeg1_vdpau_hwaccel = {
@@ -132,7 +133,8 @@ static int vdpau_mpeg2_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-
[libav-devel] [PATCH 10/10] vdpau: add support for the H.264 High 4:4:4 Predictive profile
---
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 11 +--
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 578b711..b7f79bf 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -123,6 +123,9 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
H264Picture *pic = h-cur_pic_ptr;
struct vdpau_picture_context *pic_ctx = pic-hwaccel_picture_private;
VdpPictureInfoH264 *info = pic_ctx-info.h264;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive *info2 = pic_ctx-info.h264_predictive;
+#endif
/* init VdpPictureInfoH264 */
info-slice_count= 0;
@@ -149,6 +152,10 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
info-log2_max_pic_order_cnt_lsb_minus4 = h-sps.poc_type ? 0 :
h-sps.log2_max_poc_lsb - 4;
info-delta_pic_order_always_zero_flag =
h-sps.delta_pic_order_always_zero_flag;
info-direct_8x8_inference_flag =
h-sps.direct_8x8_inference_flag;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+info2-qpprime_y_zero_transform_bypass_flag = h-sps.transform_bypass;
+info2-separate_colour_plane_flag=
h-sps.residual_color_transform_flag;
+#endif
info-entropy_coding_mode_flag = h-pps.cabac;
info-pic_order_present_flag = h-pps.pic_order_present;
info-deblocking_filter_control_present_flag =
h-pps.deblocking_filter_parameters_present;
@@ -255,6 +262,18 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_EXTENDED;
break;
#endif
+case FF_PROFILE_H264_HIGH_10:
+/* XXX: High 10 can be treated as High so long as only 8-bits per
+ * formats are supported. */
+profile = VDP_DECODER_PROFILE_H264_HIGH;
+break;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+case FF_PROFILE_H264_HIGH_422:
+case FF_PROFILE_H264_HIGH_444_PREDICTIVE:
+case FF_PROFILE_H264_CAVLC_444:
+profile = VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 05b3361..39b 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -37,16 +37,15 @@ static inline uintptr_t ff_vdpau_get_surface_id(AVFrame
*pic)
return (uintptr_t)pic-data[3];
}
-#if !FF_API_BUFS_VDPAU
-union AVVDPAUPictureInfo {
+union VDPAUPictureInfo {
VdpPictureInfoH264h264;
VdpPictureInfoMPEG1Or2mpeg;
VdpPictureInfoVC1 vc1;
VdpPictureInfoMPEG4Part2 mpeg4;
-};
-#else
-#include vdpau.h
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive h264_predictive;
#endif
+};
typedef struct VDPAUHWContext {
AVVDPAUContext context;
@@ -86,7 +85,7 @@ struct vdpau_picture_context {
/**
* VDPAU picture information.
*/
-union AVVDPAUPictureInfo info;
+union VDPAUPictureInfo info;
/**
* Allocated size of the bitstream_buffers table.
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 09/10] vdpau: add support for 4:2:2 and 4:4:4 chroma sampling in H.264
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau.c | 11 +++
libavcodec/vdpau_h264.c | 29 -
libavcodec/vdpau_internal.h | 3 +++
4 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index fe9c0e9..6379d29 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -970,6 +970,9 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*fmt++ = AV_PIX_FMT_YUV420P10;
break;
case 8:
+#if CONFIG_H264_VDPAU_HWACCEL
+*fmt++ = AV_PIX_FMT_VDPAU;
+#endif
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
*fmt++ = AV_PIX_FMT_GBRP;
@@ -993,9 +996,6 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*fmt++ = AV_PIX_FMT_VDA_VLD;
*fmt++ = AV_PIX_FMT_VDA;
#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-*fmt++ = AV_PIX_FMT_VDPAU;
-#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 463e600..e22ab1e 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -70,6 +70,17 @@ int av_vdpau_get_surface_parameters(AVCodecContext *avctx,
VdpChromaType *type,
VdpChromaType t = VDP_CHROMA_TYPE_420;
uint32_t w = avctx-coded_width;
uint32_t h = avctx-coded_height;
+int val = 0;
+
+switch (avctx-codec_id)
+{
+case AV_CODEC_ID_H264:
+val = ff_vdpau_h264_get_chroma_type(avctx, t);
+break;
+}
+
+if (val 0)
+return val;
/* See vdpau/vdpau.h for per-type alignment constraints. */
switch (t)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 6774882..578b711 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -203,10 +203,37 @@ static int vdpau_h264_end_frame(AVCodecContext *avctx)
return 0;
}
+int ff_vdpau_h264_get_chroma_type(const AVCodecContext *avctx,
+ VdpChromaType *type)
+{
+const H264Context *h = avctx-priv_data;
+
+switch (h-sps.chroma_format_idc) {
+case 1:
+*type = VDP_CHROMA_TYPE_420;
+break;
+case 2:
+*type = VDP_CHROMA_TYPE_422;
+break;
+case 3:
+*type = VDP_CHROMA_TYPE_444;
+break;
+default:
+return AVERROR(ENOSYS);
+}
+return 0;
+}
+
static int vdpau_h264_init(AVCodecContext *avctx)
{
VdpDecoderProfile profile;
uint32_t level = avctx-level;
+VdpChromaType type;
+int val;
+
+val = ff_vdpau_h264_get_chroma_type(avctx, type);
+if (val 0)
+return val;
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
case FF_PROFILE_H264_BASELINE:
@@ -235,7 +262,7 @@ static int vdpau_h264_init(AVCodecContext *avctx)
if ((avctx-profile FF_PROFILE_H264_INTRA) avctx-level == 11)
level = VDP_DECODER_LEVEL_H264_1b;
-return ff_vdpau_common_init(avctx, profile, level, VDP_CHROMA_TYPE_420);
+return ff_vdpau_common_init(avctx, profile, level, type);
}
AVHWAccel ff_h264_vdpau_hwaccel = {
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index bcdeb90..05b3361 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -116,4 +116,7 @@ int ff_vdpau_mpeg_end_frame(AVCodecContext *avctx);
int ff_vdpau_add_buffer(struct vdpau_picture_context *pic, const uint8_t *buf,
uint32_t buf_size);
+int ff_vdpau_h264_get_chroma_type(const AVCodecContext *avctx,
+ VdpChromaType *type);
+
#endif /* AVCODEC_VDPAU_INTERNAL_H */
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 02/10] vdpau: add mapping for H.264 Extended profile
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do { \
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_MAIN: PROFILE(H264_MAIN);
case FF_PROFILE_H264_HIGH: PROFILE(H264_HIGH);
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED: PROFILE(H264_EXTENDED);
+#endif
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_WMV3:
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 4103328..d18a970 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -219,6 +219,11 @@ static int vdpau_h264_init(AVCodecContext *avctx)
case FF_PROFILE_H264_HIGH:
profile = VDP_DECODER_PROFILE_H264_HIGH;
break;
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED:
+profile = VDP_DECODER_PROFILE_H264_EXTENDED;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 04/10] vdpau: add helper for surface chroma type and size
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
---
doc/APIchanges | 3 +++
libavcodec/vdpau.c | 25 +
libavcodec/vdpau.h | 20
libavcodec/version.h | 2 +-
4 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3d1b72f..066779a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.7.0 - vdpau.h
+ Add av_vdpau_get_surface_parameters().
+
2014-11-xx - xxx - lavf 56.06.3 - avformat.h
Add AVFormatContext.avoid_negative_ts.
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index ccb3352..edf09f1 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -64,6 +64,21 @@ static int vdpau_error(VdpStatus status)
}
}
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
+uint32_t *width, uint32_t *height)
+{
+/* XXX: only 8-bits YCbCr 4:2:0 is supported yet */
+if (type)
+*type = VDP_CHROMA_TYPE_420;
+/* See vdpau/vdpau.h for per-type alignment constraints. */
+if (width)
+*width = (avctx-coded_width + 1) ~1;
+if (height)
+*height = (avctx-coded_height + 3) ~3;
+
+return 0;
+}
+
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
int level)
{
@@ -76,9 +91,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
VdpStatus status;
VdpBool supported;
uint32_t max_level, max_mb, max_width, max_height;
-/* See vdpau/vdpau.h for alignment constraints. */
-uint32_t width = (avctx-coded_width + 1) ~1;
-uint32_t height = (avctx-coded_height + 3) ~3;
+VdpChromaType type;
+uint32_t width;
+uint32_t height;
vdctx-width= UINT32_MAX;
vdctx-height = UINT32_MAX;
@@ -107,7 +122,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else
surface_query_caps = func;
-status = surface_query_caps(vdctx-device, VDP_CHROMA_TYPE_420, supported,
+av_vdpau_get_surface_parameters(avctx, type, width, height);
+
+status = surface_query_caps(vdctx-device, type, supported,
max_width, max_height);
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 24c3b02..4e5c351 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -151,6 +151,26 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
VdpGetProcAddress *get_proc_address, unsigned flags);
/**
+ * Gets the parameters to create an adequate VDPAU video surface for the codec
+ * context using VDPAU hardware decoding acceleration.
+ *
+ * @note Behavior is undefined if the context was not successfully bound to a
+ * VDPAU device using av_vdpau_bind_context().
+ *
+ * @param avctx the codec context being used for decoding the stream
+ * @param type storage space for the VDPAU video surface chroma type
+ * (or NULL to ignore)
+ * @param width storage space for the VDPAU video surface pixel width
+ * (or NULL to ignore)
+ * @param height storage space for the VDPAU video surface pixel height
+ * (or NULL to ignore)
+ *
+ * @return 0 on success, a negative AVERROR code on failure.
+ */
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
+uint32_t *width, uint32_t *height);
+
+/**
* Allocate an AVVDPAUContext.
*
* @return Newly-allocated AVVDPAUContext or NULL on failure.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index fd774a7..f51c9d7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 6
+#define LIBAVCODEC_VERSION_MINOR 7
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.1.3
___
libav-devel mailing
[libav-devel] [PATCH 08/10] h264: factor hwaccel pixel formats list
This is to avoid proliferation of similar tables in following changes.
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 42d0c95..fe9c0e9 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -143,42 +143,6 @@ static const uint8_t dequant8_coeff_init[6][6] = {
{ 36, 32, 58, 34, 46, 43 },
};
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-};
-
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_jpeg_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
-
static void release_unused_pictures(H264Context *h, int remove_current)
{
@@ -975,54 +939,69 @@ static int clone_slice(H264Context *dst, H264Context *src)
static enum AVPixelFormat get_pixel_format(H264Context *h)
{
-enum AVPixelFormat pix_fmts[2];
+#define HWACCEL_MAX (CONFIG_H264_DXVA2_HWACCEL + \
+ CONFIG_H264_VAAPI_HWACCEL + \
+ (CONFIG_H264_VDA_HWACCEL * 2) + \
+ CONFIG_H264_VDPAU_HWACCEL)
+enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
const enum AVPixelFormat *choices = pix_fmts;
-pix_fmts[1] = AV_PIX_FMT_NONE;
-
switch (h-sps.bit_depth_luma) {
case 9:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP9;
+*fmt++ = AV_PIX_FMT_GBRP9;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P9;
+*fmt++ = AV_PIX_FMT_YUV444P9;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P9;
+*fmt++ = AV_PIX_FMT_YUV422P9;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P9;
+*fmt++ = AV_PIX_FMT_YUV420P9;
break;
case 10:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP10;
+*fmt++ = AV_PIX_FMT_GBRP10;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P10;
+*fmt++ = AV_PIX_FMT_YUV444P10;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P10;
+*fmt++ = AV_PIX_FMT_YUV422P10;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P10;
+*fmt++ = AV_PIX_FMT_YUV420P10;
break;
case 8:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
-pix_fmts[0] = AV_PIX_FMT_GBRP;
+*fmt++ = AV_PIX_FMT_GBRP;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ444P;
+*fmt++ = AV_PIX_FMT_YUVJ444P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV444P;
+*fmt++ = AV_PIX_FMT_YUV444P;
} else if (CHROMA422(h)) {
if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ422P;
+*fmt++ = AV_PIX_FMT_YUVJ422P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV422P;
+*fmt++ = AV_PIX_FMT_YUV422P;
} else {
+#if CONFIG_H264_DXVA2_HWACCEL
+*fmt++ = AV_PIX_FMT_DXVA2_VLD;
+#endif
+#if CONFIG_H264_VAAPI_HWACCEL
+*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+#endif
+#if CONFIG_H264_VDA_HWACCEL
+*fmt++ = AV_PIX_FMT_VDA_VLD;
+*fmt++ = AV_PIX_FMT_VDA;
+#endif
+#if CONFIG_H264_VDPAU_HWACCEL
+*fmt++ = AV_PIX_FMT_VDPAU;
+#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-choices = h264_hwaccel_pixfmt_list_jpeg_420;
+*fmt++ = AV_PIX_FMT_YUVJ420P;
else
-choices = h264_hwaccel_pixfmt_list_420;
+*fmt++ = AV_PIX_FMT_YUV420P;
}
break;
default:
@@ -1031,6 +1010,8 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
return AVERROR_INVALIDDATA;
}
+*fmt = AV_PIX_FMT_NONE;
+
return ff_get_format(h-avctx, choices);
}
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
[libav-devel] [PATCH 06/10] libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/vdpau.c | 2 +-
libavcodec/version.h | 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 066779a..db9d3cc 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.8.0 - vdpau.h
+ Add AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH flag to av_vdpau_bind_context().
+
201x-xx-xx - xxx - lavc 56.7.0 - vdpau.h
Add av_vdpau_get_surface_parameters().
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7df64ae..7666d4f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3045,6 +3045,12 @@ typedef struct AVHWAccel {
#define AV_HWACCEL_FLAG_IGNORE_LEVEL (1 0)
/**
+ * Hardware acceleration can output YUV pixel formats with a different chroma
+ * sampling than 4:2:0 and/or other than 8 bits per component.
+ */
+#define AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH (1 1)
+
+/**
* @}
*/
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index edf09f1..8d9a649 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -345,7 +345,7 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
{
VDPAUHWContext *hwctx;
-if (flags ~AV_HWACCEL_FLAG_IGNORE_LEVEL)
+if (flags
~(AV_HWACCEL_FLAG_IGNORE_LEVEL|AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH))
return AVERROR(EINVAL);
if (av_reallocp(avctx-hwaccel_context, sizeof(*hwctx)))
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f51c9d7..5d8f9a1 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 7
+#define LIBAVCODEC_VERSION_MINOR 8
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 05/10] avconv_vdpau: allocate video surface of VDPAU-specified size
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..1bd1f48 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
VDPAUContext*ctx = ist-hwaccel_ctx;
VdpVideoSurface *surface;
VdpStatus err;
+VdpChromaType chroma;
+uint32_t width, height;
av_assert0(frame-format == AV_PIX_FMT_VDPAU);
+if (av_vdpau_get_surface_parameters(s, chroma, width, height))
+return AVERROR(ENOSYS);
+
surface = av_malloc(sizeof(*surface));
if (!surface)
return AVERROR(ENOMEM);
@@ -108,8 +113,8 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
// properly we should keep a pool of surfaces instead of creating
// them anew for each frame, but since we don't care about speed
// much in this code, we don't bother
-err = ctx-video_surface_create(ctx-device, VDP_CHROMA_TYPE_420,
-frame-width, frame-height, surface);
+err = ctx-video_surface_create(ctx-device, chroma, width, height,
+surface);
if (err != VDP_STATUS_OK) {
av_log(NULL, AV_LOG_ERROR, Error allocating a VDPAU video surface:
%s\n,
ctx-get_error_string(err));
--
2.1.3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 04/10] vdpau: add helper for surface chroma type and size
Le 2014-12-11 04:28, Vittorio Giovara a écrit :
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index ccb3352..edf09f1 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -64,6 +64,21 @@ static int vdpau_error(VdpStatus status)
}
}
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx,
VdpChromaType *type,
+uint32_t *width, uint32_t
*height)
+{
+/* XXX: only 8-bits YCbCr 4:2:0 is supported yet */
+if (type)
+*type = VDP_CHROMA_TYPE_420;
+/* See vdpau/vdpau.h for per-type alignment constraints. */
+if (width)
+*width = (avctx-coded_width + 1) ~1;
+if (height)
+*height = (avctx-coded_height + 3) ~3;
+
+return 0;
+}
this function seems to never fail, maybe it's fine to make it void?
I would rather not. We could (later) redefine the function to return an
error in cases where it currently is undefined for instance.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RESEND] [PATCH 02/10] vdpau/h264: add mapping for Extended Profile
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do { \
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_MAIN: PROFILE(H264_MAIN);
case FF_PROFILE_H264_HIGH: PROFILE(H264_HIGH);
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED: PROFILE(H264_EXTENDED);
+#endif
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_WMV3:
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 4103328..d18a970 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -219,6 +219,11 @@ static int vdpau_h264_init(AVCodecContext *avctx)
case FF_PROFILE_H264_HIGH:
profile = VDP_DECODER_PROFILE_H264_HIGH;
break;
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED:
+profile = VDP_DECODER_PROFILE_H264_EXTENDED;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 08/10] h264: factor hwaccel pixel formats list
This is to avoid proliferation of similar tables in following changes.
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 42d0c95..f20e017 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -143,42 +143,6 @@ static const uint8_t dequant8_coeff_init[6][6] = {
{ 36, 32, 58, 34, 46, 43 },
};
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-};
-
-static const enum AVPixelFormat h264_hwaccel_pixfmt_list_jpeg_420[] = {
-#if CONFIG_H264_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_H264_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
-#endif
-#if CONFIG_H264_VDA_HWACCEL
-AV_PIX_FMT_VDA_VLD,
-AV_PIX_FMT_VDA,
-#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
-
static void release_unused_pictures(H264Context *h, int remove_current)
{
@@ -975,54 +939,69 @@ static int clone_slice(H264Context *dst, H264Context *src)
static enum AVPixelFormat get_pixel_format(H264Context *h)
{
-enum AVPixelFormat pix_fmts[2];
+#define HWACCEL_MAX (CONFIG_H264_DXVA2_HWACCEL + \
+ CONFIG_H264_VAAPI_HWACCEL + \
+ (CONFIG_H264_VDA_HWACCEL * 2) + \
+ CONFIG_H264_VDPAU_HWACCEL)
+enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
const enum AVPixelFormat *choices = pix_fmts;
-pix_fmts[1] = AV_PIX_FMT_NONE;
-
switch (h-sps.bit_depth_luma) {
case 9:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP9;
+*(fmt++) = AV_PIX_FMT_GBRP9;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P9;
+*(fmt++) = AV_PIX_FMT_YUV444P9;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P9;
+*(fmt++) = AV_PIX_FMT_YUV422P9;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P9;
+*(fmt++) = AV_PIX_FMT_YUV420P9;
break;
case 10:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB) {
-pix_fmts[0] = AV_PIX_FMT_GBRP10;
+*(fmt++) = AV_PIX_FMT_GBRP10;
} else
-pix_fmts[0] = AV_PIX_FMT_YUV444P10;
+*(fmt++) = AV_PIX_FMT_YUV444P10;
} else if (CHROMA422(h))
-pix_fmts[0] = AV_PIX_FMT_YUV422P10;
+*(fmt++) = AV_PIX_FMT_YUV422P10;
else
-pix_fmts[0] = AV_PIX_FMT_YUV420P10;
+*(fmt++) = AV_PIX_FMT_YUV420P10;
break;
case 8:
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
-pix_fmts[0] = AV_PIX_FMT_GBRP;
+*(fmt++) = AV_PIX_FMT_GBRP;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ444P;
+*(fmt++) = AV_PIX_FMT_YUVJ444P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV444P;
+*(fmt++) = AV_PIX_FMT_YUV444P;
} else if (CHROMA422(h)) {
if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-pix_fmts[0] = AV_PIX_FMT_YUVJ422P;
+*(fmt++) = AV_PIX_FMT_YUVJ422P;
else
-pix_fmts[0] = AV_PIX_FMT_YUV422P;
+*(fmt++) = AV_PIX_FMT_YUV422P;
} else {
+#if CONFIG_H264_DXVA2_HWACCEL
+*(fmt++) = AV_PIX_FMT_DXVA2_VLD;
+#endif
+#if CONFIG_H264_VAAPI_HWACCEL
+*(fmt++) = AV_PIX_FMT_VAAPI_VLD;
+#endif
+#if CONFIG_H264_VDA_HWACCEL
+*(fmt++) = AV_PIX_FMT_VDA_VLD;
+*(fmt++) = AV_PIX_FMT_VDA;
+#endif
+#if CONFIG_H264_VDPAU_HWACCEL
+*(fmt++) = AV_PIX_FMT_VDPAU;
+#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
-choices = h264_hwaccel_pixfmt_list_jpeg_420;
+*(fmt++) = AV_PIX_FMT_YUVJ420P;
else
-choices = h264_hwaccel_pixfmt_list_420;
+*(fmt++) = AV_PIX_FMT_YUV420P;
}
break;
default:
@@ -1031,6 +1010,8 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
return AVERROR_INVALIDDATA;
}
+*fmt = AV_PIX_FMT_NONE;
+
return ff_get_format(h-avctx, choices);
}
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
[libav-devel] [PATCH 10/10] vdpau/h264: add support for the High 4:4:4 Predictive profile
/!\ DO NOT MERGE YET ! /!\ This depends on a pending libvdpau patch.
---
libavcodec/vdpau.h | 3 +++
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 3 +++
3 files changed, 25 insertions(+)
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 4244d15..d0194b0 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -63,6 +63,9 @@ union AVVDPAUPictureInfo {
VdpPictureInfoMPEG1Or2mpeg;
VdpPictureInfoVC1 vc1;
VdpPictureInfoMPEG4Part2 mpeg4;
+# ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive h264_predictive;
+# endif
};
#endif
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 2e41910..8416c0a 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -123,6 +123,9 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
H264Picture *pic = h-cur_pic_ptr;
struct vdpau_picture_context *pic_ctx = pic-hwaccel_picture_private;
VdpPictureInfoH264 *info = pic_ctx-info.h264;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264 *info_predictive = pic_ctx-info.h264_predictive;
+#endif
/* init VdpPictureInfoH264 */
info-slice_count= 0;
@@ -149,6 +152,10 @@ static int vdpau_h264_start_frame(AVCodecContext *avctx,
info-log2_max_pic_order_cnt_lsb_minus4 = h-sps.poc_type ? 0 :
h-sps.log2_max_poc_lsb - 4;
info-delta_pic_order_always_zero_flag =
h-sps.delta_pic_order_always_zero_flag;
info-direct_8x8_inference_flag =
h-sps.direct_8x8_inference_flag;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+info_predictive-transform_bypass= h-sps.transform_bypass;
+info_predictive-separate_colour_plane_flag =
h-sps.residual_color_transform_flag;
+#endif
info-entropy_coding_mode_flag = h-pps.cabac;
info-pic_order_present_flag = h-pps.pic_order_present;
info-deblocking_filter_control_present_flag =
h-pps.deblocking_filter_parameters_present;
@@ -244,6 +251,18 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_EXTENDED;
break;
#endif
+case FF_PROFILE_H264_HIGH_10:
+/* XXX: High 10 can be treated as High so long as only 8-bits per
+ * formats are supported. */
+profile = VDP_DECODER_PROFILE_H264_HIGH;
+break;
+#ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+case FF_PROFILE_H264_HIGH_422:
+case FF_PROFILE_H264_HIGH_444_PREDICTIVE:
+case FF_PROFILE_H264_CAVLC_444:
+profile = VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index bcdeb90..c18a6ff 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -43,6 +43,9 @@ union AVVDPAUPictureInfo {
VdpPictureInfoMPEG1Or2mpeg;
VdpPictureInfoVC1 vc1;
VdpPictureInfoMPEG4Part2 mpeg4;
+# ifdef VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE
+VdpPictureInfoH264Predictive h264_predictive;
+# endif
};
#else
#include vdpau.h
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RESEND] [PATCH 03/10] vdpau/h264: add mapping for Constrained Baseline Profile and fallback
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1e891ed..ccb3352 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -125,6 +125,15 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
status = decoder_query_caps(vdctx-device, profile, supported, max_level,
max_mb, max_width, max_height);
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+if (status != VDP_STATUS_OK profile ==
VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE) {
+/* Run-time backward compatibility for libvdpau 0.8 and earlier */
+profile = VDP_DECODER_PROFILE_H264_MAIN;
+status = decoder_query_caps(vdctx-device, profile, supported,
+max_level, max_mb,
+max_width, max_height);
+}
+#endif
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index d18a970..5ed1fff 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -213,6 +213,10 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_BASELINE;
break;
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+profile = VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE;
+break;
+#endif
case FF_PROFILE_H264_MAIN:
profile = VDP_DECODER_PROFILE_H264_MAIN;
break;
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RESEND] [PATCH 01/10] vdpau: revector macro to reduce line span
---
libavcodec/vdpau.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 93b53dd..fd3ae62 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -264,45 +264,46 @@ int ff_vdpau_add_buffer(struct vdpau_picture_context
*pic_ctx,
int av_vdpau_get_profile(AVCodecContext *avctx, VdpDecoderProfile *profile)
{
-#define PROFILE(prof) \
-do {\
-*profile = prof;\
-return 0; \
+#define PROFILE(prof) \
+do { \
+*profile = VDP_DECODER_PROFILE_##prof; \
+return 0; \
} while (0)
switch (avctx-codec_id) {
-case AV_CODEC_ID_MPEG1VIDEO:
PROFILE(VDP_DECODER_PROFILE_MPEG1);
+case AV_CODEC_ID_MPEG1VIDEO: PROFILE(MPEG1);
case AV_CODEC_ID_MPEG2VIDEO:
switch (avctx-profile) {
-case FF_PROFILE_MPEG2_MAIN:
PROFILE(VDP_DECODER_PROFILE_MPEG2_MAIN);
-case FF_PROFILE_MPEG2_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG2_SIMPLE);
+case FF_PROFILE_MPEG2_MAIN:PROFILE(MPEG2_MAIN);
+case FF_PROFILE_MPEG2_SIMPLE: PROFILE(MPEG2_SIMPLE);
default: return AVERROR(EINVAL);
}
-case AV_CODEC_ID_H263:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_ASP);
+case AV_CODEC_ID_H263: PROFILE(MPEG4_PART2_ASP);
case AV_CODEC_ID_MPEG4:
switch (avctx-profile) {
-case FF_PROFILE_MPEG4_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_SP);
-case FF_PROFILE_MPEG4_ADVANCED_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_ASP);
+case FF_PROFILE_MPEG4_SIMPLE: PROFILE(MPEG4_PART2_SP);
+case FF_PROFILE_MPEG4_ADVANCED_SIMPLE: PROFILE(MPEG4_PART2_ASP);
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_H264:
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
-case FF_PROFILE_H264_BASELINE:
PROFILE(VDP_DECODER_PROFILE_H264_BASELINE);
+case FF_PROFILE_H264_BASELINE: PROFILE(H264_BASELINE);
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
-case FF_PROFILE_H264_MAIN:
PROFILE(VDP_DECODER_PROFILE_H264_MAIN);
-case FF_PROFILE_H264_HIGH:
PROFILE(VDP_DECODER_PROFILE_H264_HIGH);
+case FF_PROFILE_H264_MAIN: PROFILE(H264_MAIN);
+case FF_PROFILE_H264_HIGH: PROFILE(H264_HIGH);
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_WMV3:
case AV_CODEC_ID_VC1:
switch (avctx-profile) {
-case FF_PROFILE_VC1_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_VC1_SIMPLE);
-case FF_PROFILE_VC1_MAIN:
PROFILE(VDP_DECODER_PROFILE_VC1_MAIN);
-case FF_PROFILE_VC1_ADVANCED:
PROFILE(VDP_DECODER_PROFILE_VC1_ADVANCED);
+case FF_PROFILE_VC1_SIMPLE:PROFILE(VC1_SIMPLE);
+case FF_PROFILE_VC1_MAIN: PROFILE(VC1_MAIN);
+case FF_PROFILE_VC1_ADVANCED: PROFILE(VC1_ADVANCED);
default: return AVERROR(EINVAL);
}
}
return AVERROR(EINVAL);
+#undef PROFILE
}
AVVDPAUContext *av_vdpau_alloc_context(void)
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 05/10] avconv_vdpau: allocate video surface of VDPAU-specified size
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..5d7ef36 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
VDPAUContext*ctx = ist-hwaccel_ctx;
VdpVideoSurface *surface;
VdpStatus err;
+VdpChromaType chroma;
+uint32_t width, height;
av_assert0(frame-format == AV_PIX_FMT_VDPAU);
+if (av_vdpau_get_surface_parameters(s, chroma, width, height))
+return AVERROR(ENOTSUP);
+
surface = av_malloc(sizeof(*surface));
if (!surface)
return AVERROR(ENOMEM);
@@ -108,8 +113,8 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
// properly we should keep a pool of surfaces instead of creating
// them anew for each frame, but since we don't care about speed
// much in this code, we don't bother
-err = ctx-video_surface_create(ctx-device, VDP_CHROMA_TYPE_420,
-frame-width, frame-height, surface);
+err = ctx-video_surface_create(ctx-device, chroma, width, height,
+surface);
if (err != VDP_STATUS_OK) {
av_log(NULL, AV_LOG_ERROR, Error allocating a VDPAU video surface:
%s\n,
ctx-get_error_string(err));
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 06/10] libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 066779a..db9d3cc 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.8.0 - vdpau.h
+ Add AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH flag to av_vdpau_bind_context().
+
201x-xx-xx - xxx - lavc 56.7.0 - vdpau.h
Add av_vdpau_get_surface_parameters().
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7df64ae..7666d4f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3045,6 +3045,12 @@ typedef struct AVHWAccel {
#define AV_HWACCEL_FLAG_IGNORE_LEVEL (1 0)
/**
+ * Hardware acceleration can output YUV pixel formats with a different chroma
+ * sampling than 4:2:0 and/or other than 8 bits per component.
+ */
+#define AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH (1 1)
+
+/**
* @}
*/
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f51c9d7..5d8f9a1 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 7
+#define LIBAVCODEC_VERSION_MINOR 8
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 07/10] vdpau: add common support for other surface chroma types
---
libavcodec/vdpau.c | 39 +++
libavcodec/vdpau_internal.h | 3 ++-
libavcodec/vdpau_mpeg12.c | 6 --
libavcodec/vdpau_mpeg4.c| 6 --
libavcodec/vdpau_vc1.c | 3 ++-
5 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index edf09f1..ae1a0cc 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -67,20 +67,39 @@ static int vdpau_error(VdpStatus status)
int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
uint32_t *width, uint32_t *height)
{
-/* XXX: only 8-bits YCbCr 4:2:0 is supported yet */
-if (type)
-*type = VDP_CHROMA_TYPE_420;
+VDPAUContext *vdctx = avctx-internal-hwaccel_priv_data;
+VdpChromaType t = vdctx-chroma_type;
+uint32_t w = avctx-coded_width;
+uint32_t h = avctx-coded_width;
+
/* See vdpau/vdpau.h for per-type alignment constraints. */
+switch (t)
+{
+case VDP_CHROMA_TYPE_420:
+w = (w + 1) ~1;
+h = (h + 3) ~3;
+break;
+case VDP_CHROMA_TYPE_422:
+w = (w + 1) ~1;
+h = (h + 1) ~1;
+break;
+case VDP_CHROMA_TYPE_444:
+h = (h + 1) ~1;
+break;
+}
+
+if (type)
+*type = t;
if (width)
-*width = (avctx-coded_width + 1) ~1;
+*width = w;
if (height)
-*height = (avctx-coded_height + 3) ~3;
+*height = h;
return 0;
}
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
- int level)
+ int level, VdpChromaType type)
{
VDPAUHWContext *hwctx = avctx-hwaccel_context;
VDPAUContext *vdctx = avctx-internal-hwaccel_priv_data;
@@ -91,10 +110,10 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
VdpStatus status;
VdpBool supported;
uint32_t max_level, max_mb, max_width, max_height;
-VdpChromaType type;
uint32_t width;
uint32_t height;
+vdctx-chroma_type = type;
vdctx-width= UINT32_MAX;
vdctx-height = UINT32_MAX;
hwctx-reset= 0;
@@ -114,6 +133,10 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else if (level 0)
return AVERROR(ENOTSUP);
+if (!(hwctx-flags AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH)
+type != VDP_CHROMA_TYPE_420)
+return AVERROR(ENOTSUP);
+
status = vdctx-get_proc_address(vdctx-device,
VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
func);
@@ -122,7 +145,7 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else
surface_query_caps = func;
-av_vdpau_get_surface_parameters(avctx, type, width, height);
+av_vdpau_get_surface_parameters(avctx, NULL, width, height);
status = surface_query_caps(vdctx-device, type, supported,
max_width, max_height);
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 16493b0..bcdeb90 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -77,6 +77,7 @@ typedef struct VDPAUContext {
*/
VdpDecoderRender *render;
+VdpChromaType chroma_type;
uint32_t width;
uint32_t height;
} VDPAUContext;
@@ -104,7 +105,7 @@ struct vdpau_picture_context {
};
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
- int level);
+ int level, VdpChromaType type);
int ff_vdpau_common_uninit(AVCodecContext *avctx);
int ff_vdpau_common_start_frame(struct vdpau_picture_context *pic,
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
index 421abe9..bafe83c 100644
--- a/libavcodec/vdpau_mpeg12.c
+++ b/libavcodec/vdpau_mpeg12.c
@@ -98,7 +98,8 @@ static int vdpau_mpeg_decode_slice(AVCodecContext *avctx,
static int vdpau_mpeg1_init(AVCodecContext *avctx)
{
return ff_vdpau_common_init(avctx, VDP_DECODER_PROFILE_MPEG1,
-VDP_DECODER_LEVEL_MPEG1_NA);
+VDP_DECODER_LEVEL_MPEG1_NA,
+VDP_CHROMA_TYPE_420);
}
AVHWAccel ff_mpeg1_vdpau_hwaccel = {
@@ -132,7 +133,8 @@ static int vdpau_mpeg2_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-return ff_vdpau_common_init(avctx, profile, VDP_DECODER_LEVEL_MPEG2_HL);
+return ff_vdpau_common_init(avctx, profile, VDP_DECODER_LEVEL_MPEG2_HL,
+VDP_CHROMA_TYPE_420);
}
AVHWAccel ff_mpeg2_vdpau_hwaccel = {
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/vdpau_mpeg4.c
index 978456a..b5cbc9b 100644
--- a/libavcodec/vdpau_mpeg4.c
+++ b/libavcodec/vdpau_mpeg4.c
@@ -92,7 +92,8 @@ static int
[libav-devel] [PATCH 09/10] vdpau/h264: add support for 4:2:2 and 4:4:4 8-bits YUV
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau_h264.c | 18 +-
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index f20e017..d9e296a 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -970,6 +970,9 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*(fmt++) = AV_PIX_FMT_YUV420P10;
break;
case 8:
+#if CONFIG_H264_VDPAU_HWACCEL
+*(fmt++) = AV_PIX_FMT_VDPAU;
+#endif
if (CHROMA444(h)) {
if (h-avctx-colorspace == AVCOL_SPC_RGB)
*(fmt++) = AV_PIX_FMT_GBRP;
@@ -993,9 +996,6 @@ static enum AVPixelFormat get_pixel_format(H264Context *h)
*(fmt++) = AV_PIX_FMT_VDA_VLD;
*(fmt++) = AV_PIX_FMT_VDA;
#endif
-#if CONFIG_H264_VDPAU_HWACCEL
-*(fmt++) = AV_PIX_FMT_VDPAU;
-#endif
if (h-avctx-codec-pix_fmts)
choices = h-avctx-codec-pix_fmts;
else if (h-avctx-color_range == AVCOL_RANGE_JPEG)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 5ed1fff..2e41910 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -205,8 +205,24 @@ static int vdpau_h264_end_frame(AVCodecContext *avctx)
static int vdpau_h264_init(AVCodecContext *avctx)
{
+const H264Context *h = avctx-priv_data;
VdpDecoderProfile profile;
uint32_t level = avctx-level;
+VdpChromaType type;
+
+switch (h-sps.chroma_format_idc) {
+case 1:
+type = VDP_CHROMA_TYPE_420;
+break;
+case 2:
+type = VDP_CHROMA_TYPE_422;
+break;
+case 3:
+type = VDP_CHROMA_TYPE_444;
+break;
+default:
+return AVERROR(ENOTSUP);
+}
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
case FF_PROFILE_H264_BASELINE:
@@ -235,7 +251,7 @@ static int vdpau_h264_init(AVCodecContext *avctx)
if ((avctx-profile FF_PROFILE_H264_INTRA) avctx-level == 11)
level = VDP_DECODER_LEVEL_H264_1b;
-return ff_vdpau_common_init(avctx, profile, level);
+return ff_vdpau_common_init(avctx, profile, level, type);
}
AVHWAccel ff_h264_vdpau_hwaccel = {
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 04/10] vdpau: add helper for surface chroma type and size
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would loess AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
---
doc/APIchanges | 3 +++
libavcodec/vdpau.c | 25 +
libavcodec/vdpau.h | 20
libavcodec/version.h | 2 +-
4 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3d1b72f..066779a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+201x-xx-xx - xxx - lavc 56.7.0 - vdpau.h
+ Add av_vdpau_get_surface_parameters().
+
2014-11-xx - xxx - lavf 56.06.3 - avformat.h
Add AVFormatContext.avoid_negative_ts.
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index ccb3352..edf09f1 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -64,6 +64,21 @@ static int vdpau_error(VdpStatus status)
}
}
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
+uint32_t *width, uint32_t *height)
+{
+/* XXX: only 8-bits YCbCr 4:2:0 is supported yet */
+if (type)
+*type = VDP_CHROMA_TYPE_420;
+/* See vdpau/vdpau.h for per-type alignment constraints. */
+if (width)
+*width = (avctx-coded_width + 1) ~1;
+if (height)
+*height = (avctx-coded_height + 3) ~3;
+
+return 0;
+}
+
int ff_vdpau_common_init(AVCodecContext *avctx, VdpDecoderProfile profile,
int level)
{
@@ -76,9 +91,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
VdpStatus status;
VdpBool supported;
uint32_t max_level, max_mb, max_width, max_height;
-/* See vdpau/vdpau.h for alignment constraints. */
-uint32_t width = (avctx-coded_width + 1) ~1;
-uint32_t height = (avctx-coded_height + 3) ~3;
+VdpChromaType type;
+uint32_t width;
+uint32_t height;
vdctx-width= UINT32_MAX;
vdctx-height = UINT32_MAX;
@@ -107,7 +122,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
else
surface_query_caps = func;
-status = surface_query_caps(vdctx-device, VDP_CHROMA_TYPE_420, supported,
+av_vdpau_get_surface_parameters(avctx, type, width, height);
+
+status = surface_query_caps(vdctx-device, type, supported,
max_width, max_height);
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 24c3b02..4244d15 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -151,6 +151,26 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
VdpGetProcAddress *get_proc_address, unsigned flags);
/**
+ * Gets the parameters to create an adequate VDPAU video surface for the codec
+ * context using VDPAU hardware decoding acceleration.
+ *
+ * @note Behavior is undefined if the context was not succesfully bound to a
+ * VDPAU device using av_vdpau_bind_context().
+ *
+ * @param avctx the codec context being used for decoding the stream
+ * @param type storage space for the VDPAU video surface chroma type
+ * (or NULL to ignore)
+ * @param width storage space for the VDPAU video surface pixel width
+ * (or NULL to ignore)
+ * @param height storage space for the VDPAU video surface pixel height
+ * (or NULL to ignore)
+ *
+ * @return 0 on success, a negative AVERROR code on failure.
+ */
+int av_vdpau_get_surface_parameters(AVCodecContext *avctx, VdpChromaType *type,
+uint32_t *width, uint32_t *height);
+
+/**
* Allocate an AVVDPAUContext.
*
* @return Newly-allocated AVVDPAUContext or NULL on failure.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index fd774a7..f51c9d7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 6
+#define LIBAVCODEC_VERSION_MINOR 7
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
1.9.1
___
libav-devel mailing list
Re: [libav-devel] [RESEND] [PATCH 01/10] vdpau: revector macro to reduce line span
Le 2014-12-10 17:57, Luca Barbato a écrit : On 10/12/14 15:20, Rémi Denis-Courmont wrote: --- libavcodec/vdpau.c | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) I think I gave it an Ok already. So you did, but to my knowledge, I cannot push those patches myself. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 10/10] vdpau/h264: add support for the High 4:4:4 Predictive profile
Le 2014-12-10 18:11, Luca Barbato a écrit : On 10/12/14 15:20, Rémi Denis-Courmont wrote: /!\ DO NOT MERGE YET ! /!\ This depends on a pending libvdpau patch. --- libavcodec/vdpau.h | 3 +++ libavcodec/vdpau_h264.c | 19 +++ libavcodec/vdpau_internal.h | 3 +++ 3 files changed, 25 insertions(+) The change seems straightforward, is it bound to change in libvdpau? Based on FreeDesktop VDPAU list discussions, it should be finalized during this calendar month - presumably before Xmas. Of course, it will also needs new VDPAU drivers and capable hardware to actually make use of. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/3] vdpau/h264: add mapping for Constrained Baseline Profile and fallback
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1e891ed..ccb3352 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -125,6 +125,15 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
status = decoder_query_caps(vdctx-device, profile, supported, max_level,
max_mb, max_width, max_height);
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+if (status != VDP_STATUS_OK profile ==
VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE) {
+/* Run-time backward compatibility for libvdpau 0.8 and earlier */
+profile = VDP_DECODER_PROFILE_H264_MAIN;
+status = decoder_query_caps(vdctx-device, profile, supported,
+max_level, max_mb,
+max_width, max_height);
+}
+#endif
if (status != VDP_STATUS_OK)
return vdpau_error(status);
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index d18a970..5ed1fff 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -213,6 +213,10 @@ static int vdpau_h264_init(AVCodecContext *avctx)
profile = VDP_DECODER_PROFILE_H264_BASELINE;
break;
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+#ifdef VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
+profile = VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE;
+break;
+#endif
case FF_PROFILE_H264_MAIN:
profile = VDP_DECODER_PROFILE_H264_MAIN;
break;
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/3] vdpau: revector macro to reduce line span
---
libavcodec/vdpau.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 93b53dd..fd3ae62 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -264,45 +264,46 @@ int ff_vdpau_add_buffer(struct vdpau_picture_context
*pic_ctx,
int av_vdpau_get_profile(AVCodecContext *avctx, VdpDecoderProfile *profile)
{
-#define PROFILE(prof) \
-do {\
-*profile = prof;\
-return 0; \
+#define PROFILE(prof) \
+do { \
+*profile = VDP_DECODER_PROFILE_##prof; \
+return 0; \
} while (0)
switch (avctx-codec_id) {
-case AV_CODEC_ID_MPEG1VIDEO:
PROFILE(VDP_DECODER_PROFILE_MPEG1);
+case AV_CODEC_ID_MPEG1VIDEO: PROFILE(MPEG1);
case AV_CODEC_ID_MPEG2VIDEO:
switch (avctx-profile) {
-case FF_PROFILE_MPEG2_MAIN:
PROFILE(VDP_DECODER_PROFILE_MPEG2_MAIN);
-case FF_PROFILE_MPEG2_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG2_SIMPLE);
+case FF_PROFILE_MPEG2_MAIN:PROFILE(MPEG2_MAIN);
+case FF_PROFILE_MPEG2_SIMPLE: PROFILE(MPEG2_SIMPLE);
default: return AVERROR(EINVAL);
}
-case AV_CODEC_ID_H263:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_ASP);
+case AV_CODEC_ID_H263: PROFILE(MPEG4_PART2_ASP);
case AV_CODEC_ID_MPEG4:
switch (avctx-profile) {
-case FF_PROFILE_MPEG4_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_SP);
-case FF_PROFILE_MPEG4_ADVANCED_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_MPEG4_PART2_ASP);
+case FF_PROFILE_MPEG4_SIMPLE: PROFILE(MPEG4_PART2_SP);
+case FF_PROFILE_MPEG4_ADVANCED_SIMPLE: PROFILE(MPEG4_PART2_ASP);
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_H264:
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
-case FF_PROFILE_H264_BASELINE:
PROFILE(VDP_DECODER_PROFILE_H264_BASELINE);
+case FF_PROFILE_H264_BASELINE: PROFILE(H264_BASELINE);
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
-case FF_PROFILE_H264_MAIN:
PROFILE(VDP_DECODER_PROFILE_H264_MAIN);
-case FF_PROFILE_H264_HIGH:
PROFILE(VDP_DECODER_PROFILE_H264_HIGH);
+case FF_PROFILE_H264_MAIN: PROFILE(H264_MAIN);
+case FF_PROFILE_H264_HIGH: PROFILE(H264_HIGH);
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_WMV3:
case AV_CODEC_ID_VC1:
switch (avctx-profile) {
-case FF_PROFILE_VC1_SIMPLE:
PROFILE(VDP_DECODER_PROFILE_VC1_SIMPLE);
-case FF_PROFILE_VC1_MAIN:
PROFILE(VDP_DECODER_PROFILE_VC1_MAIN);
-case FF_PROFILE_VC1_ADVANCED:
PROFILE(VDP_DECODER_PROFILE_VC1_ADVANCED);
+case FF_PROFILE_VC1_SIMPLE:PROFILE(VC1_SIMPLE);
+case FF_PROFILE_VC1_MAIN: PROFILE(VC1_MAIN);
+case FF_PROFILE_VC1_ADVANCED: PROFILE(VC1_ADVANCED);
default: return AVERROR(EINVAL);
}
}
return AVERROR(EINVAL);
+#undef PROFILE
}
AVVDPAUContext *av_vdpau_alloc_context(void)
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/3] vdpau/h264: add mapping for Extended Profile
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do { \
case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_MAIN: PROFILE(H264_MAIN);
case FF_PROFILE_H264_HIGH: PROFILE(H264_HIGH);
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED: PROFILE(H264_EXTENDED);
+#endif
default: return AVERROR(EINVAL);
}
case AV_CODEC_ID_WMV3:
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 4103328..d18a970 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -219,6 +219,11 @@ static int vdpau_h264_init(AVCodecContext *avctx)
case FF_PROFILE_H264_HIGH:
profile = VDP_DECODER_PROFILE_H264_HIGH;
break;
+#ifdef VDP_DECODER_PROFILE_H264_EXTENDED
+case FF_PROFILE_H264_EXTENDED:
+profile = VDP_DECODER_PROFILE_H264_EXTENDED;
+break;
+#endif
default:
return AVERROR(ENOTSUP);
}
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] ff_get_format: deinitialization hardware acceleration early enough
The application will destroy the underlying hardware handles when
get_format() gets called again. Also this ensures the deinitialization
takes place if the get_format callback returns an error.
Regression from 1c80c9d7ef809180042257200c7b5f6b81d0b0e2.
---
libavcodec/utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 95d2193..61893da 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -948,6 +948,11 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
memcpy(choices, fmt, (n + 1) * sizeof(*choices));
for (;;) {
+if (avctx-hwaccel avctx-hwaccel-uninit)
+avctx-hwaccel-uninit(avctx);
+av_freep(avctx-internal-hwaccel_priv_data);
+avctx-hwaccel = NULL;
+
ret = avctx-get_format(avctx, choices);
desc = av_pix_fmt_desc_get(ret);
@@ -956,11 +961,6 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
break;
}
-if (avctx-hwaccel avctx-hwaccel-uninit)
-avctx-hwaccel-uninit(avctx);
-av_freep(avctx-internal-hwaccel_priv_data);
-avctx-hwaccel = NULL;
-
if (!(desc-flags AV_PIX_FMT_FLAG_HWACCEL))
break;
--
2.1.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ff_get_format: deinitialization hardware acceleration early enough
Le mercredi 29 octobre 2014, 18:13:42 Luca Barbato a écrit : Probably fine, anybody willing to test it with other hwaccels? The only other one (with an uninit callback) is VDA, and that really reverts it back to how it was before I/we messed up ff_get_format(). I can´t test it though. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] vdpau/h264: request MAIN rather than BASELINE VDPAU profile for CBP
The H.264 Constrained Baseline Profile (CBP) is a subset of both the
Main Profile and the Baseline Profile. In principles, a hardware
decoder that supports either of those can decode CBP content. As it
happens, Main is supported by all VDPAU drivers, and Baseline is not.
So favor map CBP to MP for now. Hopefully in the future libvdpau will
offer an explicit choice for CBP.
This fixes bug 757.
---
libavcodec/vdpau_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index b759335..4103328 100644
--- a/libavcodec/vdpau_h264.c
+++ b/libavcodec/vdpau_h264.c
@@ -209,10 +209,10 @@ static int vdpau_h264_init(AVCodecContext *avctx)
uint32_t level = avctx-level;
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
-case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_BASELINE:
profile = VDP_DECODER_PROFILE_H264_BASELINE;
break;
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_MAIN:
profile = VDP_DECODER_PROFILE_H264_MAIN;
break;
--
2.1.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] vdpau: return MAIN instead of BASELINE for H.264 CBP
This is the same as the previous change, but for applications using the
old API (such as VLC 2.2).
---
libavcodec/vdpau.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1d68e70..93b53dd 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -287,8 +287,8 @@ do {\
}
case AV_CODEC_ID_H264:
switch (avctx-profile ~FF_PROFILE_H264_INTRA) {
-case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_BASELINE:
PROFILE(VDP_DECODER_PROFILE_H264_BASELINE);
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
case FF_PROFILE_H264_MAIN:
PROFILE(VDP_DECODER_PROFILE_H264_MAIN);
case FF_PROFILE_H264_HIGH:
PROFILE(VDP_DECODER_PROFILE_H264_HIGH);
default: return AVERROR(EINVAL);
--
2.1.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 01/10] hdsenc: Check rename() return value
Le 2014-10-18 18:58, Vittorio Giovara a écrit :
From: Michael Niedermayer michae...@gmx.at
CC: libav-sta...@libav.org
Bug-Id: CID 1135748
---
libavformat/hdsenc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavformat/hdsenc.c b/libavformat/hdsenc.c
index 53fef33..f41381d 100644
--- a/libavformat/hdsenc.c
+++ b/libavformat/hdsenc.c
@@ -204,7 +204,10 @@ static int write_manifest(AVFormatContext *s,
int final)
avio_printf(out, /manifest\n);
avio_flush(out);
avio_close(out);
-rename(temp_filename, filename);
+if (rename(temp_filename, filename) == -1) {
+av_log(s, AV_LOG_ERROR, failed to rename file %s to %s\n,
temp_filename, filename);
Shouldn't the error message be printed too?
+return AVERROR(errno);
+}
return 0;
}
@@ -286,7 +289,10 @@ static int write_abst(AVFormatContext *s,
OutputStream *os, int final)
update_size(out, afrt_pos);
update_size(out, 0);
avio_close(out);
-rename(temp_filename, filename);
+if (rename(temp_filename, filename) == -1) {
+av_log(s, AV_LOG_ERROR, failed to rename file %s to %s\n,
temp_filename, filename);
+return AVERROR(errno);
+}
return 0;
}
@@ -481,7 +487,10 @@ static int hds_flush(AVFormatContext *s,
OutputStream *os, int final,
snprintf(target_filename, sizeof(target_filename),
%s/stream%dSeg1-Frag%d, s-filename, index,
os-fragment_index);
-rename(os-temp_filename, target_filename);
+if (rename(os-temp_filename, target_filename) == -1) {
+av_log(s, AV_LOG_ERROR, failed to rename file %s to %s\n,
os-temp_filename, target_filename);
+return AVERROR(errno);
+}
add_fragment(os, target_filename, os-frag_start_ts, end_ts -
os-frag_start_ts);
if (!final) {
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 02/10] rtpproto: Free the addrinfo pointer on failure
Le 2014-10-18 18:58, Vittorio Giovara a écrit :
From: Luca Barbato lu_z...@gentoo.org
CC: libav-sta...@libav.org
Bug-Id: CID 1238797
---
libavformat/rtpproto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index 0f31539..d5ecfc8 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -231,8 +231,10 @@ static void rtp_parse_addr_list(URLContext *h,
char *buf,
ai = rtp_resolve_host(p, 0, SOCK_DGRAM, AF_UNSPEC, 0);
if (ai) {
source_addr = av_mallocz(sizeof(struct
sockaddr_storage));
-if (!source_addr)
+if (!source_addr) {
+freeaddrinfo(ai);
break;
+}
memcpy(source_addr, ai-ai_addr, ai-ai_addrlen);
freeaddrinfo(ai);
LGTM
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/3] vdpau: have av_vdpau_bind_context() fail on unsupported flag
Currently, no flags are supported.
---
libavcodec/vdpau.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 44eef20..9805a8d 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -313,6 +313,9 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
{
VDPAUHWContext *hwctx;
+if (flags != 0)
+return AVERROR(EINVAL);
+
if (av_reallocp(avctx-hwaccel_context, sizeof(*hwctx)))
return AVERROR(ENOMEM);
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/3] vdpau: add AV_HWACCEL_FLAG_IGNORE_LEVEL to skip the codec level check
Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.
Applications should obviously not set this flag by default, but only if
the user explicitly requested this behavior (and presumably knows how
to turn it back off if it fails).
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h| 14 +-
libavcodec/vdpau.c | 7 +--
libavcodec/vdpau.h | 2 +-
libavcodec/vdpau_internal.h | 1 +
libavcodec/version.h| 2 +-
6 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index a8c8e2e..59d2d03 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+2014-10-xx - xxx - lavc 56.4.0 - avcodec.h
+ Add AV_HWACCEL_FLAG_IGNORE_LEVEL flag to av_vdpau_bind_context().
+
2014-10-13 - xxx - lavc 56.03.0 - avcodec.h
Add AVCodecContext.initial_padding. Deprecate the use of AVCodecContext.delay
for audio encoding.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index a24ce40..8e6c019 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2900,7 +2900,8 @@ typedef struct AVCodec {
} AVCodec;
/**
- * AVHWAccel.
+ * @defgroup lavc_hwaccel AVHWAccel
+ * @{
*/
typedef struct AVHWAccel {
/**
@@ -3025,6 +3026,17 @@ typedef struct AVHWAccel {
} AVHWAccel;
/**
+ * Hardware acceleration should be used for decoding even if the codec level
+ * used is unknown or higher than the maximum supported level reported by the
+ * hardware driver.
+ */
+#define AV_HWACCEL_FLAG_IGNORE_LEVEL (1 0)
+
+/**
+ * @}
+ */
+
+/**
* @defgroup lavc_picture AVPicture
*
* Functions for working with AVPicture
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 9805a8d..1d68e70 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -94,7 +94,9 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
VdpDecoderProfile profile,
vdctx-device = hwctx-device;
vdctx-get_proc_address = hwctx-get_proc_address;
-if (level 0)
+if (hwctx-flags AV_HWACCEL_FLAG_IGNORE_LEVEL)
+level = 0;
+else if (level 0)
return AVERROR(ENOTSUP);
status = vdctx-get_proc_address(vdctx-device,
@@ -313,7 +315,7 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
{
VDPAUHWContext *hwctx;
-if (flags != 0)
+if (flags ~AV_HWACCEL_FLAG_IGNORE_LEVEL)
return AVERROR(EINVAL);
if (av_reallocp(avctx-hwaccel_context, sizeof(*hwctx)))
@@ -325,6 +327,7 @@ int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice
device,
hwctx-context.decoder = VDP_INVALID_HANDLE;
hwctx-device = device;
hwctx-get_proc_address = get_proc;
+hwctx-flags= flags;
hwctx-reset= 1;
return 0;
}
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 1714b1e..24c3b02 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -143,7 +143,7 @@ typedef struct AVVDPAUContext {
* @param avctx decoding context whose get_format() callback is invoked
* @param device VDPAU device handle to use for hardware acceleration
* @param get_proc_address VDPAU device driver
- * @param flags for future use, must be zero
+ * @param flags zero of more OR'd AV_HWACCEL_FLAG_* flags
*
* @return 0 on success, an AVERROR code on failure.
*/
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 69cd455..16493b0 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -53,6 +53,7 @@ typedef struct VDPAUHWContext {
VdpDevice device;
VdpGetProcAddress *get_proc_address;
char reset;
+unsigned char flags;
} VDPAUHWContext;
typedef struct VDPAUContext {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index c44686d..097dee3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include libavutil/version.h
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 3
+#define LIBAVCODEC_VERSION_MINOR 4
#define LIBAVCODEC_VERSION_MICRO 0
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/3] doc: fix typing mistake
--- doc/APIchanges | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 48b0ac8..a8c8e2e 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -13,7 +13,7 @@ libavutil: 2014-08-09 API changes, most recent first: -2014-10-13 - xxx - lavc 55.03.0 - avcodec.h +2014-10-13 - xxx - lavc 56.03.0 - avcodec.h Add AVCodecContext.initial_padding. Deprecate the use of AVCodecContext.delay for audio encoding. -- 1.9.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/5] hwaccel: Bitstream-based support (HWAccel 1.3)
Hello, Le 2014-10-13 14:16, Luca Barbato a écrit : Based on the VDPAU series review, I have to believe that adding new visible but internal members to AVHWAccel is not allowed. I consider AVHWAccel the same as AVCodec, from outside should be always accessed by reference. That's also true of AVVDPAUContext. Are the codec profile and resolution known at that point? I would not think so. A bitstream hwaccel does that internally. Unless the back-end supports everything and falls back to software internally, that will be unusable in generic media players or transcoding pipelines with untrusted/unknown inptus, where the user cannot be expected to toggle hardware acceleration on a per-input basis. If not, that will never going to work smoothly, unless the back-end supported all profiles and all resolutions. In particular, that will prevent software fallback. I'd rather rework the software fallback on a second time and I'd rather add an option to make it an explicit error instead of always automagic. Rewinding is not generally an option. It carries implications for the upstream bytestream and demuxer that are not generally true. Even when true, that hardly fits the typical architecture of a video decoding pipeline where there are no provisions for the decoder to rewind of its own. If it is not generic *and* libavcodec is not doing anything with the data (not even parsing slices), then what's the point in abstracting it inside libavcodec and cluttering the hwaccel abstraction with it? -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/4] rtsp: Support tls-encapsulated RTSP
Le 2014-10-09 23:17, Luca Barbato a écrit :
---
libavformat/rtsp.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 646712e..cadf025 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1589,7 +1589,9 @@ void ff_rtsp_close_connections(AVFormatContext
*s)
int ff_rtsp_connect(AVFormatContext *s)
{
RTSPState *rt = s-priv_data;
-char host[1024], path[1024], tcpname[1024], cmd[2048],
auth[128];
+char proto[128], host[1024], path[1024];
+char tcpname[1024], cmd[2048], auth[128];
+const char *lower_rtsp_proto = tcp;
int port, err, tcp_fd;
RTSPMessageHeader reply1 = {0}, *reply = reply1;
int lower_transport_mask = 0;
@@ -1621,8 +1623,12 @@ int ff_rtsp_connect(AVFormatContext *s)
redirect:
lower_transport_mask = rt-lower_transport_mask;
/* extract hostname and port */
-av_url_split(NULL, 0, auth, sizeof(auth),
+av_url_split(proto, sizeof(proto), auth, sizeof(auth),
host, sizeof(host), port, path, sizeof(path),
s-filename);
+
+if (!strcmp(proto, rtsps))
+lower_rtsp_proto = tls;
That seems much too simplistic to be rtsps. For a start, where is the
default RTSP/TLS port number (332)?
More importantly, the user should expect that the media content proper
will be hashed and encrypted when using rtsps. This seems to merely
encrypt the control connection, which will fail that expectation. And of
course, it makes TLS arguably totally useless. So for the time being, I
think interleaved RTP should be forced (over TLS) and no other RTP
transport should be negotiated by the client.
+
if (*auth) {
av_strlcpy(rt-auth, auth, sizeof(rt-auth));
}
@@ -1647,7 +1653,7 @@ redirect:
/* Construct the URI used in request; this is similar to
s-filename,
* but with authentication credentials removed and RTSP specific
options
* stripped out. */
-ff_url_join(rt-control_uri, sizeof(rt-control_uri), rtsp,
NULL,
+ff_url_join(rt-control_uri, sizeof(rt-control_uri), proto,
NULL,
host, port, %s, path);
if (rt-control_transport == RTSP_MODE_TUNNEL) {
@@ -1726,7 +1732,8 @@ redirect:
}
} else {
/* open the tcp connection */
-ff_url_join(tcpname, sizeof(tcpname), tcp, NULL, host,
port, NULL);
+ff_url_join(tcpname, sizeof(tcpname), lower_rtsp_proto,
NULL,
+host, port, NULL);
if (ffurl_open(rt-rtsp_hd, tcpname, AVIO_FLAG_READ_WRITE,
s-interrupt_callback, NULL) 0) {
err = AVERROR(EIO);
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] rtsp: Support tls when in listen mode
Le 2014-10-09 23:17, Luca Barbato a écrit :
---
libavformat/rtspdec.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 5442b7d..e7a1c4b 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -609,10 +609,11 @@ int ff_rtsp_setup_input_streams(AVFormatContext
*s, RTSPMessageHeader *reply)
static int rtsp_listen(AVFormatContext *s)
{
RTSPState *rt = s-priv_data;
-char host[128], path[512], auth[128];
+char proto[128], host[128], path[512], auth[128];
char uri[500];
int port;
char tcpname[500];
+const char *lower_proto = tcp;
unsigned char rbuf[4096];
unsigned char method[10];
int rbuflen = 0;
@@ -620,18 +621,21 @@ static int rtsp_listen(AVFormatContext *s)
enum RTSPMethod methodcode;
/* extract hostname and port */
-av_url_split(NULL, 0, auth, sizeof(auth), host, sizeof(host),
port,
- path, sizeof(path), s-filename);
+av_url_split(proto, sizeof(proto), auth, sizeof(auth), host,
sizeof(host),
+ port, path, sizeof(path), s-filename);
/* ff_url_join. No authorization by now (NULL) */
-ff_url_join(rt-control_uri, sizeof(rt-control_uri), rtsp,
NULL, host,
+ff_url_join(rt-control_uri, sizeof(rt-control_uri), proto,
NULL, host,
port, %s, path);
if (port 0)
port = RTSP_DEFAULT_PORT;
No. That's 322 for RTSPS (and not 332 as I typo-ed earlier).
+if (!strcmp(proto, rtsps))
+lower_proto = tls;
+
/* Create TCP connection */
-ff_url_join(tcpname, sizeof(tcpname), tcp, NULL, host, port,
+ff_url_join(tcpname, sizeof(tcpname), lower_proto, NULL, host,
port,
?listenlisten_timeout=%d, rt-initial_timeout *
1000);
if (ret = ffurl_open(rt-rtsp_hd, tcpname,
AVIO_FLAG_READ_WRITE,
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
