[libav-devel] [PATCH 4/4] vaapi_encode: Add VP9 support

2017-01-09 Thread Mark Thompson
---
Uses global_quality without accounting for any multiplier rather than adding a 
private option.

B-frames are not enabled by default (without running it through the vp9_reorder 
filter the output will not show the right frames).


 configure |   3 +
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/vaapi_encode_vp9.c | 311 ++
 4 files changed, 316 insertions(+)
 create mode 100644 libavcodec/vaapi_encode_vp9.c

diff --git a/configure b/configure
index 9cd4fe6b4..722c18c99 100755
--- a/configure
+++ b/configure
@@ -2240,6 +2240,8 @@ vc1_qsv_decoder_deps="libmfx"
 vc1_qsv_decoder_select="qsvdec vc1_qsv_hwaccel vc1_parser"
 vp8_qsv_decoder_deps="libmfx"
 vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
+vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
+vp9_vaapi_encoder_select="vaapi_encode"
 
 nvenc_h264_encoder_select="h264_nvenc_encoder"
 nvenc_hevc_encoder_select="hevc_nvenc_encoder"
@@ -4581,6 +4583,7 @@ check_type "va/va.h va/va_vpp.h" 
"VAProcPipelineParameterBuffer"
 check_type "va/va.h va/va_enc_h264.h" "VAEncPictureParameterBufferH264"
 check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
 check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
+check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
 
 check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6e3a5ab66..fbb40852c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -483,6 +483,7 @@ OBJS-$(CONFIG_VP8_DECODER) += vp8.o vp56rac.o
 OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec_other.o
 OBJS-$(CONFIG_VP9_DECODER) += vp9.o vp9data.o vp9dsp.o \
   vp9block.o vp9prob.o vp9mvs.o 
vp56rac.o
+OBJS-$(CONFIG_VP9_VAAPI_ENCODER)   += vaapi_encode_vp9.o
 OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
 OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
 OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 74cbc8ff0..e92444efe 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -510,6 +510,7 @@ void avcodec_register_all(void)
 REGISTER_ENCODER(NVENC_H264,nvenc_h264);
 REGISTER_ENCODER(NVENC_HEVC,nvenc_hevc);
 #endif
+REGISTER_ENCODER(VP9_VAAPI, vp9_vaapi);
 
 /* parsers */
 REGISTER_PARSER(AAC,aac);
diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
new file mode 100644
index 0..5d3eec177
--- /dev/null
+++ b/libavcodec/vaapi_encode_vp9.c
@@ -0,0 +1,311 @@
+/*
+ * 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
+ */
+
+#include 
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixfmt.h"
+
+#include "avcodec.h"
+#include "internal.h"
+#include "vaapi_encode.h"
+
+
+typedef struct VAAPIEncodeVP9Context {
+int q_idx_idr;
+int q_idx_p;
+int q_idx_b;
+
+// Reference direction for B-like frames:
+// 0 - most recent P/IDR frame is last.
+// 1 - most recent P frame is golden.
+int last_ref_dir;
+} VAAPIEncodeVP9Context;
+
+typedef struct VAAPIEncodeVP9Options {
+int loop_filter_level;
+int loop_filter_sharpness;
+} VAAPIEncodeVP9Options;
+
+
+#define vseq_var(name) vseq->name, name
+#define vseq_field(name)   vseq->seq_fields.bits.name, name
+#define vpic_var(name) vpic->name, name
+#define vpic_field(name)   vpic->pic_fields.bits.name, name
+
+
+static int vaapi_encode_vp9_init_sequence_params(AVCodecContext *avctx)
+{
+VAAPIEncodeContext   *ctx = avctx->priv_data;
+VAEncSequenceParameterBufferVP9 *vseq = ctx->codec_sequence_params;
+VAEncPictureParameterBufferVP9  *vpic = ctx->codec_picture_params;
+
+vseq->max_frame_width  = avctx->width;
+vseq->max_frame_height = avctx->height;
+
+vseq->kf_auto = 0;
+
+if (!(ctx->va_rc_mode & VA_RC_CQP)) {
+vseq->bits_per_second = avctx->bit_rate;
+vseq->intra_period= avctx->gop_size;
+}
+
+vpic->frame_width_src  = avctx->width;

[libav-devel] [PATCH 3/4] vp9: Add bsf to fix reordering in raw streams

2017-01-09 Thread Mark Thompson
Takes a raw input stream containing frames with correct timestamps but
possibly out of order and inserts additional show-existing-frame
packets to correct the ordering.
---
More specifically, it fixes up the output of VAAPI VP9 with B-frames enabled to 
show the frames in the right order.  It may be desirable to follow it with 
vp9_superframe immediately to make a complete 1 packet -> 1 frame stream.


 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/vp9_reorder_bsf.c   | 412 +
 3 files changed, 414 insertions(+)
 create mode 100644 libavcodec/vp9_reorder_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7be9c2880..6e3a5ab66 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -769,6 +769,7 @@ OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_VP9_REORDER_BSF)+= vp9_reorder_bsf.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
 
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index d46fdad81..5e3a39f4d 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -38,6 +38,7 @@ extern const AVBitStreamFilter ff_null_bsf;
 extern const AVBitStreamFilter ff_text2movsub_bsf;
 extern const AVBitStreamFilter ff_noise_bsf;
 extern const AVBitStreamFilter ff_remove_extradata_bsf;
+extern const AVBitStreamFilter ff_vp9_reorder_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
 
diff --git a/libavcodec/vp9_reorder_bsf.c b/libavcodec/vp9_reorder_bsf.c
new file mode 100644
index 0..c6d54472f
--- /dev/null
+++ b/libavcodec/vp9_reorder_bsf.c
@@ -0,0 +1,412 @@
+/*
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/intmath.h"
+#include "libavutil/log.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+
+#include "bitstream.h"
+#include "bsf.h"
+#include "put_bits.h"
+
+#define FRAME_SLOTS 8
+
+typedef struct VP9ReorderFrame {
+AVPacket*packet;
+int  needs_output;
+int  needs_display;
+
+int64_t  pts;
+int64_t  sequence;
+unsigned int slots;
+
+unsigned int profile;
+
+unsigned int show_existing_frame;
+unsigned int frame_to_show;
+
+unsigned int frame_type;
+unsigned int show_frame;
+unsigned int refresh_frame_flags;
+} VP9ReorderFrame;
+
+typedef struct VP9ReorderContext {
+int64_t sequence;
+VP9ReorderFrame *slot[FRAME_SLOTS];
+VP9ReorderFrame *next_frame;
+} VP9ReorderContext;
+
+static void vp9_reorder_frame_free(VP9ReorderFrame **frame)
+{
+if (*frame)
+av_packet_free(&(*frame)->packet);
+av_freep(frame);
+}
+
+static void vp9_reorder_clear_slot(VP9ReorderContext *ctx, int s)
+{
+if (ctx->slot[s]) {
+ctx->slot[s]->slots &= ~(1 << s);
+if (ctx->slot[s]->slots == 0)
+vp9_reorder_frame_free(>slot[s]);
+else
+ctx->slot[s] = NULL;
+}
+}
+
+static int vp9_reorder_frame_parse(AVBSFContext *bsf, VP9ReorderFrame *frame)
+{
+BitstreamContext bc;
+int err;
+
+unsigned int frame_marker;
+unsigned int profile_low_bit, profile_high_bit, reserved_zero;
+unsigned int error_resilient_mode;
+unsigned int frame_sync_code;
+
+err = bitstream_init8(, frame->packet->data, frame->packet->size);
+if (err)
+return err;
+
+frame_marker = bitstream_read(, 2);
+if (frame_marker != 2) {
+av_log(bsf, AV_LOG_ERROR, "Invalid frame marker: %u.\n",
+   frame_marker);
+return AVERROR_INVALIDDATA;
+}
+
+profile_low_bit  = bitstream_read_bit();
+profile_high_bit = bitstream_read_bit();
+frame->profile = (profile_high_bit << 1) | profile_low_bit;
+if (frame->profile == 3) {
+reserved_zero = bitstream_read_bit();
+if (reserved_zero != 0) {
+av_log(bsf, AV_LOG_ERROR, 

[libav-devel] [PATCH 2/4] vp9: Add bsf to merge superframes

2017-01-09 Thread Mark Thompson
From: "Ronald S. Bultje" 

From ffmpeg commit 2e6636aa87303d37b112e79f093ca39500f92364.
---
Exactly as in the other tine (except licence header).  It might be nicer to 
call it vp9_superframe_merge, but maintaining identical behaviour probably 
trumps that?


 libavcodec/Makefile |   1 +
 libavcodec/bitstream_filters.c  |   1 +
 libavcodec/vp9_superframe_bsf.c | 205 
 3 files changed, 207 insertions(+)
 create mode 100644 libavcodec/vp9_superframe_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b3cee1d0c..7be9c2880 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -769,6 +769,7 @@ OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
 
 # thread libraries
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1cea6d77a..d46fdad81 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -38,6 +38,7 @@ extern const AVBitStreamFilter ff_null_bsf;
 extern const AVBitStreamFilter ff_text2movsub_bsf;
 extern const AVBitStreamFilter ff_noise_bsf;
 extern const AVBitStreamFilter ff_remove_extradata_bsf;
+extern const AVBitStreamFilter ff_vp9_superframe_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
 
 #include "libavcodec/bsf_list.c"
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
new file mode 100644
index 0..27445176b
--- /dev/null
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -0,0 +1,205 @@
+/*
+ * Vp9 invisible (alt-ref) frame to superframe merge bitstream filter
+ * Copyright (c) 2016 Ronald S. Bultje 
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "avcodec.h"
+#include "bsf.h"
+#include "get_bits.h"
+
+#define MAX_CACHE 8
+typedef struct VP9BSFContext {
+int n_cache;
+struct CachedBuf {
+uint8_t *data;
+int size;
+} cache[MAX_CACHE];
+} VP9BSFContext;
+
+static void stats(const struct CachedBuf *in, int n_in,
+  unsigned *_max, unsigned *_sum)
+{
+int n;
+unsigned max = 0, sum = 0;
+
+for (n = 0; n < n_in; n++) {
+unsigned sz = in[n].size;
+
+if (sz > max)
+max = sz;
+sum += sz;
+}
+
+*_max = max;
+*_sum = sum;
+}
+
+static int merge_superframe(const struct CachedBuf *in, int n_in, AVPacket 
*out)
+{
+unsigned max, sum, mag, marker, n, sz;
+uint8_t *ptr;
+int res;
+
+stats(in, n_in, , );
+mag = av_log2(max) >> 3;
+marker = 0xC0 + (mag << 3) + (n_in - 1);
+sz = sum + 2 + (mag + 1) * n_in;
+res = av_new_packet(out, sz);
+if (res < 0)
+return res;
+ptr = out->data;
+for (n = 0; n < n_in; n++) {
+memcpy(ptr, in[n].data, in[n].size);
+ptr += in[n].size;
+}
+
+#define wloop(mag, wr) \
+for (n = 0; n < n_in; n++) { \
+wr; \
+ptr += mag + 1; \
+}
+
+// write superframe with marker 110[mag:2][nframes:3]
+*ptr++ = marker;
+switch (mag) {
+case 0:
+wloop(mag, *ptr = in[n].size);
+break;
+case 1:
+wloop(mag, AV_WL16(ptr, in[n].size));
+break;
+case 2:
+wloop(mag, AV_WL24(ptr, in[n].size));
+break;
+case 3:
+wloop(mag, AV_WL32(ptr, in[n].size));
+break;
+}
+*ptr++ = marker;
+av_assert0(ptr == >data[out->size]);
+
+return 0;
+}
+
+static int vp9_superframe_filter(AVBSFContext *ctx, AVPacket *out)
+{
+GetBitContext gb;
+VP9BSFContext *s = ctx->priv_data;
+AVPacket *in;
+int res, invisible, profile, marker, uses_superframe_syntax = 0, n;
+
+res = ff_bsf_get_packet(ctx, );
+if (res < 0)
+return res;
+
+marker = in->data[in->size - 1];
+if ((marker & 0xe0) == 0xc0) {
+int nbytes = 1 + ((marker >> 3) & 0x3);
+int n_frames = 1 + (marker & 0x7), idx_sz = 2 + 

[libav-devel] [PATCH 1/4] vaapi_encode: Pass framerate parameters to driver

2017-01-09 Thread Mark Thompson
---
The i965 driver has been updated so that this works consistently.

 libavcodec/vaapi_encode.c | 14 ++
 libavcodec/vaapi_encode.h |  4 
 2 files changed, 18 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 246b76abc..953a6bae0 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1090,6 +1090,7 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 VAAPIEncodeContext *ctx = avctx->priv_data;
 int hrd_buffer_size;
 int hrd_initial_buffer_fullness;
+int num, den;
 
 if (avctx->rc_buffer_size)
 hrd_buffer_size = avctx->rc_buffer_size;
@@ -1124,6 +1125,19 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 ctx->global_params_size[ctx->nb_global_params++] =
 sizeof(ctx->hrd_params);
 
+if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
+av_reduce(, , avctx->framerate.num, avctx->framerate.den, 
65535);
+else
+av_reduce(, , avctx->time_base.den, avctx->time_base.num, 
65535);
+
+ctx->fr_params.misc.type = VAEncMiscParameterTypeFrameRate;
+ctx->fr_params.fr.framerate = (unsigned int)den << 16 | num;
+
+ctx->global_params[ctx->nb_global_params] =
+>fr_params.misc;
+ctx->global_params_size[ctx->nb_global_params++] =
+sizeof(ctx->fr_params);
+
 return 0;
 }
 
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 2a72510b8..e7f36eaf5 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -154,6 +154,10 @@ typedef struct VAAPIEncodeContext {
 VAEncMiscParameterBuffer misc;
 VAEncMiscParameterHRD hrd;
 } hrd_params;
+struct {
+VAEncMiscParameterBuffer misc;
+VAEncMiscParameterFrameRate fr;
+} fr_params;
 
 // Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
 void   *codec_sequence_params;
-- 
2.11.0

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

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Luca Barbato
On 09/01/2017 15:38, Diego Biurrun wrote:
> IMNSHO this is just a pointless complication for a handful of devs
> that run the av* tools from the build dir instead of installing them
> or using an installed version.

It is not not an handful devs and it is not a complication, please make
it so the overall behavior isn't that surprising since it is a minimal
change.

lu

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

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Vittorio Giovara
On Mon, Jan 9, 2017 at 4:06 PM, Diego Biurrun  wrote:
> On Mon, Jan 09, 2017 at 03:53:44PM +0100, Vittorio Giovara wrote:
>> Finally, there are equally-annoying files present in the top level
>> directory, such as COPYING.* LICENSE and several others, which hardly
>> anybody reads or edits, which could be probably be moved to a separate
>> directory too.
>
> Go right ahead and move them instead of making up arguments then.

Please, don't claim I'm making up arguments, no need to get
aggressive. I was just suggesting other equally important less
invasive and controversial bits related to this clean up work you are
carrying out.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Diego Biurrun
On Mon, Jan 09, 2017 at 03:53:44PM +0100, Vittorio Giovara wrote:
> Finally, there are equally-annoying files present in the top level
> directory, such as COPYING.* LICENSE and several others, which hardly
> anybody reads or edits, which could be probably be moved to a separate
> directory too.

Go right ahead and move them instead of making up arguments then.

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

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Vittorio Giovara
On Mon, Jan 9, 2017 at 3:38 PM, Diego Biurrun  wrote:
> On Mon, Jan 09, 2017 at 01:41:13PM +0100, Luca Barbato wrote:
>> On 09/01/2017 12:11, Vittorio Giovara wrote:
>> >
>> > I don't mind the idea, but imo the main files (avconv.c avprobe.c
>> > avserver.c) should be kept in the top level directory. Similarly
>> > executables should be in the top level directory, rather than under
>> > avtool. I believe that after configuring and compiling, finding the
>> > necessary tools immediately in the build directory is more
>> > user-friendly than looking for them in any other arbitrary location.
>>
>> you mean having avconv, avprobe and avplay in the root dir. Maybe isn't
>> a bad idea.
>
> IMNSHO this is just a pointless complication for a handful of devs that
> run the av* tools from the build dir instead of installing them or using
> an installed version.

Besides the fact that installing the tools is not always available
everywhere, depending on the configuration variant installing the
tools might not be the best practice. For example when configuring
shared libs, you have a hard time figuring out whether the installed
libs are going to be linked before the just built ones.

Additionally the handful of devs are the ones working on such tools,
so I don't see why we should add pointless complications for them in
editing sources and running the executables.

Finally, there are equally-annoying files present in the top level
directory, such as COPYING.* LICENSE and several others, which hardly
anybody reads or edits, which could be probably be moved to a separate
directory too.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Diego Biurrun
On Mon, Jan 09, 2017 at 01:41:13PM +0100, Luca Barbato wrote:
> On 09/01/2017 12:11, Vittorio Giovara wrote:
> > On Fri, Jan 6, 2017 at 2:45 PM, Diego Biurrun  wrote:
> >> This unclutters the top-level directory and groups related files together.
> >> ---
> >>  .gitignore   |  3 --
> >>  Makefile | 47 
> >> 
> >>  configure|  2 +-
> >>  tools/.gitignore |  3 ++
> >>  tools/Makefile   | 43 
> >> +
> >>  avconv.c => tools/avconv.c   |  0
> >>  avconv.h => tools/avconv.h   |  0
> >>  avconv_dxva2.c => tools/avconv_dxva2.c   |  0
> >>  avconv_filter.c => tools/avconv_filter.c |  0
> >>  avconv_opt.c => tools/avconv_opt.c   |  0
> >>  avconv_qsv.c => tools/avconv_qsv.c   |  0
> >>  avconv_vaapi.c => tools/avconv_vaapi.c   |  0
> >>  avconv_vda.c => tools/avconv_vda.c   |  0
> >>  avconv_vdpau.c => tools/avconv_vdpau.c   |  0
> >>  avplay.c => tools/avplay.c   |  0
> >>  avprobe.c => tools/avprobe.c |  0
> >>  cmdutils.c => tools/cmdutils.c   |  0
> >>  cmdutils.h => tools/cmdutils.h   |  0
> >>  18 files changed, 52 insertions(+), 46 deletions(-)
> >>  create mode 100644 tools/.gitignore
> >>  create mode 100644 tools/Makefile
> >>  rename avconv.c => tools/avconv.c (100%)
> >>  rename avconv.h => tools/avconv.h (100%)
> >>  rename avconv_dxva2.c => tools/avconv_dxva2.c (100%)
> >>  rename avconv_filter.c => tools/avconv_filter.c (100%)
> >>  rename avconv_opt.c => tools/avconv_opt.c (100%)
> >>  rename avconv_qsv.c => tools/avconv_qsv.c (100%)
> >>  rename avconv_vaapi.c => tools/avconv_vaapi.c (100%)
> >>  rename avconv_vda.c => tools/avconv_vda.c (100%)
> >>  rename avconv_vdpau.c => tools/avconv_vdpau.c (100%)
> >>  rename avplay.c => tools/avplay.c (100%)
> >>  rename avprobe.c => tools/avprobe.c (100%)
> >>  rename cmdutils.c => tools/cmdutils.c (100%)
> >>  rename cmdutils.h => tools/cmdutils.h (100%)
> > 
> > I don't mind the idea, but imo the main files (avconv.c avprobe.c
> > avserver.c) should be kept in the top level directory. Similarly
> > executables should be in the top level directory, rather than under
> > avtool. I believe that after configuring and compiling, finding the
> > necessary tools immediately in the build directory is more
> > user-friendly than looking for them in any other arbitrary location.
> 
> you mean having avconv, avprobe and avplay in the root dir. Maybe isn't
> a bad idea.

IMNSHO this is just a pointless complication for a handful of devs that
run the av* tools from the build dir instead of installing them or using
an installed version.

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

Re: [libav-devel] [PATCH] avconv: Do not pass NULL to avio_tell

2017-01-09 Thread Luca Barbato
On 09/01/2017 12:38, Anton Khirnov wrote:
> Quoting Luca Barbato (2017-01-09 11:36:47)
>> On 09/01/2017 10:47, Anton Khirnov wrote:
>>> The patch is fine with me, but more generally I'd say that as long
>>> as the muxer is open, the AVIOContext belongs to it and the caller
>>> touching it in any way is invalid.
>>
>> Shall we add an avformat_report_progress() or similar?
> 
> Perhaps a field in AVFormatContext which stores the number of bytes
> written so far?
> 

Should be quite easy to implement, basically at the end of every
avformat write call we'd have to take the value from avio and store it
to avformat.

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

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Luca Barbato
On 09/01/2017 12:11, Vittorio Giovara wrote:
> On Fri, Jan 6, 2017 at 2:45 PM, Diego Biurrun  wrote:
>> This unclutters the top-level directory and groups related files together.
>> ---
>>  .gitignore   |  3 --
>>  Makefile | 47 
>> 
>>  configure|  2 +-
>>  tools/.gitignore |  3 ++
>>  tools/Makefile   | 43 +
>>  avconv.c => tools/avconv.c   |  0
>>  avconv.h => tools/avconv.h   |  0
>>  avconv_dxva2.c => tools/avconv_dxva2.c   |  0
>>  avconv_filter.c => tools/avconv_filter.c |  0
>>  avconv_opt.c => tools/avconv_opt.c   |  0
>>  avconv_qsv.c => tools/avconv_qsv.c   |  0
>>  avconv_vaapi.c => tools/avconv_vaapi.c   |  0
>>  avconv_vda.c => tools/avconv_vda.c   |  0
>>  avconv_vdpau.c => tools/avconv_vdpau.c   |  0
>>  avplay.c => tools/avplay.c   |  0
>>  avprobe.c => tools/avprobe.c |  0
>>  cmdutils.c => tools/cmdutils.c   |  0
>>  cmdutils.h => tools/cmdutils.h   |  0
>>  18 files changed, 52 insertions(+), 46 deletions(-)
>>  create mode 100644 tools/.gitignore
>>  create mode 100644 tools/Makefile
>>  rename avconv.c => tools/avconv.c (100%)
>>  rename avconv.h => tools/avconv.h (100%)
>>  rename avconv_dxva2.c => tools/avconv_dxva2.c (100%)
>>  rename avconv_filter.c => tools/avconv_filter.c (100%)
>>  rename avconv_opt.c => tools/avconv_opt.c (100%)
>>  rename avconv_qsv.c => tools/avconv_qsv.c (100%)
>>  rename avconv_vaapi.c => tools/avconv_vaapi.c (100%)
>>  rename avconv_vda.c => tools/avconv_vda.c (100%)
>>  rename avconv_vdpau.c => tools/avconv_vdpau.c (100%)
>>  rename avplay.c => tools/avplay.c (100%)
>>  rename avprobe.c => tools/avprobe.c (100%)
>>  rename cmdutils.c => tools/cmdutils.c (100%)
>>  rename cmdutils.h => tools/cmdutils.h (100%)
>>
> 
> I don't mind the idea, but imo the main files (avconv.c avprobe.c
> avserver.c) should be kept in the top level directory. Similarly
> executables should be in the top level directory, rather than under
> avtool. I believe that after configuring and compiling, finding the
> necessary tools immediately in the build directory is more
> user-friendly than looking for them in any other arbitrary location.
> 

you mean having avconv, avprobe and avplay in the root dir. Maybe isn't
a bad idea.

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

Re: [libav-devel] [PATCH 2/8] lavc: add an option for exporting cropping information to the caller

2017-01-09 Thread Anton Khirnov
Quoting Vittorio Giovara (2017-01-09 13:24:21)
> On Mon, Jan 9, 2017 at 1:18 PM, Anton Khirnov  wrote:
> > Quoting Vittorio Giovara (2017-01-03 11:43:22)
> >> > @@ -450,6 +451,106 @@ int attribute_align_arg 
> >> > avcodec_send_packet(AVCodecContext *avctx, const AVPacke
> >> >  return 0;
> >> >  }
> >> >
> >> > +static int calc_cropping_offsets(size_t offsets[4], const AVFrame 
> >> > *frame,
> >> > + const AVPixFmtDescriptor *desc)
> >>
> >> IMO passing desc here is not ideal, deriving it from frame seems more
> >> usual to me
> >
> > How is it better? What's the advantage?
> 
> It's not a big deal, it just feels strange to pass `desc` in a
> function argument, while any other use of AVPixFmtDescriptor is within
> the function itself.

It feels even more strange to call this external API three times when
just once is enough.

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

Re: [libav-devel] [PATCH 2/8] lavc: add an option for exporting cropping information to the caller

2017-01-09 Thread Vittorio Giovara
On Mon, Jan 9, 2017 at 1:18 PM, Anton Khirnov  wrote:
> Quoting Vittorio Giovara (2017-01-03 11:43:22)
>> > @@ -450,6 +451,106 @@ int attribute_align_arg 
>> > avcodec_send_packet(AVCodecContext *avctx, const AVPacke
>> >  return 0;
>> >  }
>> >
>> > +static int calc_cropping_offsets(size_t offsets[4], const AVFrame *frame,
>> > + const AVPixFmtDescriptor *desc)
>>
>> IMO passing desc here is not ideal, deriving it from frame seems more
>> usual to me
>
> How is it better? What's the advantage?

It's not a big deal, it just feels strange to pass `desc` in a
function argument, while any other use of AVPixFmtDescriptor is within
the function itself.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/8] lavc: add an option for exporting cropping information to the caller

2017-01-09 Thread Anton Khirnov
Quoting Vittorio Giovara (2017-01-03 11:43:22)
> On Tue, Dec 27, 2016 at 7:31 PM, Anton Khirnov  wrote:
> > Also, add generic code for handling cropping, so the decoders can export
> > just the cropping size and not bother with the rest.
> > ---
> >  doc/APIchanges |   4 ++
> >  libavcodec/avcodec.h   |  22 +
> >  libavcodec/decode.c| 112 
> > -
> >  libavcodec/internal.h  |   6 +++
> >  libavcodec/options_table.h |   1 +
> >  libavcodec/version.h   |   4 +-
> >  6 files changed, 146 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 10a2da4..a0ef198 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -13,6 +13,10 @@ libavutil: 2015-08-28
> >
> >  API changes, most recent first:
> >
> > +2016-xx-xx - xxx - lavc 57.31.0 - avcodec.h
> > +  Add AVCodecContext.apply_cropping to control whether cropping
> > +  is handled by libavcodec or the caller.
> > +
> >  2016-xx-xx - xxx - lavu 55.30.0 - frame.h
> >Add AVFrame.crop_left/right/top/bottom fields for attaching cropping
> >information to video frames.
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 95da50b..524e06a 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3112,6 +3112,28 @@ typedef struct AVCodecContext {
> >   * This field should be set before avcodec_open2() is 
> > called.
> >   */
> >  AVBufferRef *hw_frames_ctx;
> > +
> > +/**
> > + * Video decoding only. Certain video codecs support cropping, meaning 
> > that
> > + * only a sub-rectangle of the decoded frame is intended for display.  
> > This
> > + * option controls how cropping is handled by libavcodec.
> > + *
> > + * When set to 1 (the default), libavcodec will apply cropping 
> > internally.
> > + * I.e. it will modify the output frame width/height fields and offset 
> > the
> > + * data pointers (only by as much as possible while preserving 
> > alignment, or
> > + * by the full amount if the AV_CODEC_FLAG_UNALIGNED flag is set) so 
> > that
> > + * the frames output by the decoder refer only to the cropped area. The
> > + * crop_* fields of the output frames will be zero.
> > + *
> > + * When set to 0, the width/height fields of the output frames will be 
> > set
> > + * to the coded dimensions and the crop_* fields will describe the 
> > cropping
> > + * rectangle. Applying the cropping is left to the caller.
> > + *
> > + * When hardware acceleration with opaque output frames is used, the 
> > actual
> > + * value of this option is disregarded and libavcodec behaves as if it 
> > was
> > + * set to 0.
> > + */
> > +int apply_cropping;
> 
> Why is this a new field? As long as it is used to convey a boolean
> state isn't a codec flag more efficient?

I'm not a big fan of the flags field, as it mushes together a bunch of
completely unrelated functionality, a lot of it encoding options.

> 
> >  } AVCodecContext;
> >
> >  /**
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0fd41ab..65ee8b0 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -29,6 +29,7 @@
> >  #include "libavutil/frame.h"
> >  #include "libavutil/hwcontext.h"
> >  #include "libavutil/imgutils.h"
> > +#include "libavutil/intmath.h"
> >
> >  #include "avcodec.h"
> >  #include "bytestream.h"
> > @@ -450,6 +451,106 @@ int attribute_align_arg 
> > avcodec_send_packet(AVCodecContext *avctx, const AVPacke
> >  return 0;
> >  }
> >
> > +static int calc_cropping_offsets(size_t offsets[4], const AVFrame *frame,
> > + const AVPixFmtDescriptor *desc)
> 
> IMO passing desc here is not ideal, deriving it from frame seems more
> usual to me

How is it better? What's the advantage?

> 
> > +{
> > +int i, j;
> > +
> > +for (i = 0; frame->data[i]; i++) {
> > +const AVComponentDescriptor *comp = NULL;
> > +int shift_x = (i == 1 || i == 2) ? desc->log2_chroma_w : 0;
> > +int shift_y = (i == 1 || i == 2) ? desc->log2_chroma_h : 0;
> > +
> > +if (desc->flags & (AV_PIX_FMT_FLAG_PAL | 
> > AV_PIX_FMT_FLAG_PSEUDOPAL) && i == 1) {
> > +offsets[i] = 0;
> > +break;
> > +}
> > +
> > +/* find any component descriptor for this plane */
> > +for (j = 0; j < desc->nb_components; j++) {
> > +if (desc->comp[j].plane == i) {
> > +comp = >comp[j];
> > +break;
> > +}
> > +}
> > +if (!comp)
> > +return AVERROR_BUG;
> > +
> > +offsets[i] = (frame->crop_top  >> shift_y) * frame->linesize[i] +
> > + (frame->crop_left >> shift_x) * comp->step;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static int apply_cropping(AVCodecContext *avctx, AVFrame *frame)

Re: [libav-devel] [PATCH 2/8] lavc: add an option for exporting cropping information to the caller

2017-01-09 Thread Anton Khirnov
Quoting wm4 (2016-12-30 10:41:58)
> On Tue, 27 Dec 2016 19:31:15 +0100
> Anton Khirnov  wrote:
> 
> > Also, add generic code for handling cropping, so the decoders can export
> > just the cropping size and not bother with the rest.
> > ---
> >  doc/APIchanges |   4 ++
> >  libavcodec/avcodec.h   |  22 +
> >  libavcodec/decode.c| 112 
> > -
> >  libavcodec/internal.h  |   6 +++
> >  libavcodec/options_table.h |   1 +
> >  libavcodec/version.h   |   4 +-
> >  6 files changed, 146 insertions(+), 3 deletions(-)
> > 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 10a2da4..a0ef198 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -13,6 +13,10 @@ libavutil: 2015-08-28
> >  
> >  API changes, most recent first:
> >  
> > +2016-xx-xx - xxx - lavc 57.31.0 - avcodec.h
> > +  Add AVCodecContext.apply_cropping to control whether cropping
> > +  is handled by libavcodec or the caller.
> > +
> >  2016-xx-xx - xxx - lavu 55.30.0 - frame.h
> >Add AVFrame.crop_left/right/top/bottom fields for attaching cropping
> >information to video frames.
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 95da50b..524e06a 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3112,6 +3112,28 @@ typedef struct AVCodecContext {
> >   * This field should be set before avcodec_open2() is 
> > called.
> >   */
> >  AVBufferRef *hw_frames_ctx;
> > +
> > +/**
> > + * Video decoding only. Certain video codecs support cropping, meaning 
> > that
> > + * only a sub-rectangle of the decoded frame is intended for display.  
> > This
> > + * option controls how cropping is handled by libavcodec.
> > + *
> > + * When set to 1 (the default), libavcodec will apply cropping 
> > internally.
> > + * I.e. it will modify the output frame width/height fields and offset 
> > the
> > + * data pointers (only by as much as possible while preserving 
> > alignment, or
> > + * by the full amount if the AV_CODEC_FLAG_UNALIGNED flag is set) so 
> > that
> > + * the frames output by the decoder refer only to the cropped area. The
> > + * crop_* fields of the output frames will be zero.
> > + *
> > + * When set to 0, the width/height fields of the output frames will be 
> > set
> > + * to the coded dimensions and the crop_* fields will describe the 
> > cropping
> > + * rectangle. Applying the cropping is left to the caller.
> 
> Maybe could explain why AVCodecContext or AVCodecPar width/height will
> mismatch with the width/height of the AVFrame if it's set to 0. From
> what I understand, containers will normally use a cropped dimension (?).

AFAIK most containers just store "dimensions" without further
explanation, usually interpreted as visible (since coded is not really
meaningful outside of the decoding process).

> 
> > + *
> > + * When hardware acceleration with opaque output frames is used, the 
> > actual
> > + * value of this option is disregarded and libavcodec behaves as if it 
> > was
> > + * set to 0.
> > + */
> 
> Isn't that last part an implicit API change? This would probably annoy
> a lot of people.

Right, didn't think this through. Will fix.

> 
> > +int apply_cropping;
> >  } AVCodecContext;
> >  
> >  /**
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0fd41ab..65ee8b0 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -29,6 +29,7 @@
> >  #include "libavutil/frame.h"
> >  #include "libavutil/hwcontext.h"
> >  #include "libavutil/imgutils.h"
> > +#include "libavutil/intmath.h"
> >  
> >  #include "avcodec.h"
> >  #include "bytestream.h"
> > @@ -450,6 +451,106 @@ int attribute_align_arg 
> > avcodec_send_packet(AVCodecContext *avctx, const AVPacke
> >  return 0;
> >  }
> >  
> > +static int calc_cropping_offsets(size_t offsets[4], const AVFrame *frame,
> > + const AVPixFmtDescriptor *desc)
> > +{
> > +int i, j;
> > +
> > +for (i = 0; frame->data[i]; i++) {
> > +const AVComponentDescriptor *comp = NULL;
> > +int shift_x = (i == 1 || i == 2) ? desc->log2_chroma_w : 0;
> > +int shift_y = (i == 1 || i == 2) ? desc->log2_chroma_h : 0;
> > +
> > +if (desc->flags & (AV_PIX_FMT_FLAG_PAL | 
> > AV_PIX_FMT_FLAG_PSEUDOPAL) && i == 1) {
> > +offsets[i] = 0;
> > +break;
> > +}
> > +
> > +/* find any component descriptor for this plane */
> > +for (j = 0; j < desc->nb_components; j++) {
> > +if (desc->comp[j].plane == i) {
> > +comp = >comp[j];
> > +break;
> > +}
> > +}
> > +if (!comp)
> > +return AVERROR_BUG;
> > +
> > +offsets[i] = (frame->crop_top  >> shift_y) * frame->linesize[i] +
> > + 

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Vittorio Giovara
On Mon, Jan 9, 2017 at 12:59 PM, Diego Biurrun  wrote:
> On Mon, Jan 09, 2017 at 12:11:58PM +0100, Vittorio Giovara wrote:
>> On Fri, Jan 6, 2017 at 2:45 PM, Diego Biurrun  wrote:
>> > This unclutters the top-level directory and groups related files together.
>> > ---
>> >  .gitignore   |  3 --
>> >  Makefile | 47 
>> > 
>> >  configure|  2 +-
>> >  tools/.gitignore |  3 ++
>> >  tools/Makefile   | 43 
>> > +
>> >  avconv.c => tools/avconv.c   |  0
>> >  avconv.h => tools/avconv.h   |  0
>> >  avconv_dxva2.c => tools/avconv_dxva2.c   |  0
>> >  avconv_filter.c => tools/avconv_filter.c |  0
>> >  avconv_opt.c => tools/avconv_opt.c   |  0
>> >  avconv_qsv.c => tools/avconv_qsv.c   |  0
>> >  avconv_vaapi.c => tools/avconv_vaapi.c   |  0
>> >  avconv_vda.c => tools/avconv_vda.c   |  0
>> >  avconv_vdpau.c => tools/avconv_vdpau.c   |  0
>> >  avplay.c => tools/avplay.c   |  0
>> >  avprobe.c => tools/avprobe.c |  0
>> >  cmdutils.c => tools/cmdutils.c   |  0
>> >  cmdutils.h => tools/cmdutils.h   |  0
>> >  18 files changed, 52 insertions(+), 46 deletions(-)
>> >  create mode 100644 tools/.gitignore
>> >  create mode 100644 tools/Makefile
>> >  rename avconv.c => tools/avconv.c (100%)
>> >  rename avconv.h => tools/avconv.h (100%)
>> >  rename avconv_dxva2.c => tools/avconv_dxva2.c (100%)
>> >  rename avconv_filter.c => tools/avconv_filter.c (100%)
>> >  rename avconv_opt.c => tools/avconv_opt.c (100%)
>> >  rename avconv_qsv.c => tools/avconv_qsv.c (100%)
>> >  rename avconv_vaapi.c => tools/avconv_vaapi.c (100%)
>> >  rename avconv_vda.c => tools/avconv_vda.c (100%)
>> >  rename avconv_vdpau.c => tools/avconv_vdpau.c (100%)
>> >  rename avplay.c => tools/avplay.c (100%)
>> >  rename avprobe.c => tools/avprobe.c (100%)
>> >  rename cmdutils.c => tools/cmdutils.c (100%)
>> >  rename cmdutils.h => tools/cmdutils.h (100%)
>> >
>>
>> I don't mind the idea, but imo the main files (avconv.c avprobe.c
>> avserver.c) should be kept in the top level directory. Similarly
>> executables should be in the top level directory, rather than under
>> avtool. I believe that after configuring and compiling, finding the
>> necessary tools immediately in the build directory is more
>> user-friendly than looking for them in any other arbitrary location.
>
> How so? The libs are also in subdirs.

usually you don't need to use libraries right away as you use command line tools
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Diego Biurrun
On Mon, Jan 09, 2017 at 12:11:58PM +0100, Vittorio Giovara wrote:
> On Fri, Jan 6, 2017 at 2:45 PM, Diego Biurrun  wrote:
> > This unclutters the top-level directory and groups related files together.
> > ---
> >  .gitignore   |  3 --
> >  Makefile | 47 
> > 
> >  configure|  2 +-
> >  tools/.gitignore |  3 ++
> >  tools/Makefile   | 43 +
> >  avconv.c => tools/avconv.c   |  0
> >  avconv.h => tools/avconv.h   |  0
> >  avconv_dxva2.c => tools/avconv_dxva2.c   |  0
> >  avconv_filter.c => tools/avconv_filter.c |  0
> >  avconv_opt.c => tools/avconv_opt.c   |  0
> >  avconv_qsv.c => tools/avconv_qsv.c   |  0
> >  avconv_vaapi.c => tools/avconv_vaapi.c   |  0
> >  avconv_vda.c => tools/avconv_vda.c   |  0
> >  avconv_vdpau.c => tools/avconv_vdpau.c   |  0
> >  avplay.c => tools/avplay.c   |  0
> >  avprobe.c => tools/avprobe.c |  0
> >  cmdutils.c => tools/cmdutils.c   |  0
> >  cmdutils.h => tools/cmdutils.h   |  0
> >  18 files changed, 52 insertions(+), 46 deletions(-)
> >  create mode 100644 tools/.gitignore
> >  create mode 100644 tools/Makefile
> >  rename avconv.c => tools/avconv.c (100%)
> >  rename avconv.h => tools/avconv.h (100%)
> >  rename avconv_dxva2.c => tools/avconv_dxva2.c (100%)
> >  rename avconv_filter.c => tools/avconv_filter.c (100%)
> >  rename avconv_opt.c => tools/avconv_opt.c (100%)
> >  rename avconv_qsv.c => tools/avconv_qsv.c (100%)
> >  rename avconv_vaapi.c => tools/avconv_vaapi.c (100%)
> >  rename avconv_vda.c => tools/avconv_vda.c (100%)
> >  rename avconv_vdpau.c => tools/avconv_vdpau.c (100%)
> >  rename avplay.c => tools/avplay.c (100%)
> >  rename avprobe.c => tools/avprobe.c (100%)
> >  rename cmdutils.c => tools/cmdutils.c (100%)
> >  rename cmdutils.h => tools/cmdutils.h (100%)
> >
> 
> I don't mind the idea, but imo the main files (avconv.c avprobe.c
> avserver.c) should be kept in the top level directory. Similarly
> executables should be in the top level directory, rather than under
> avtool. I believe that after configuring and compiling, finding the
> necessary tools immediately in the build directory is more
> user-friendly than looking for them in any other arbitrary location.

How so? The libs are also in subdirs.

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

Re: [libav-devel] [PATCH] qsvdec: do not sync PIX_FMT_QSV surfaces

2017-01-09 Thread Diego Biurrun
On Mon, Jan 09, 2017 at 10:48:32AM +0100, Anton Khirnov wrote:
> This is also consistent with that VAAPI hwaccel does.

with _W_hat

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

Re: [libav-devel] [PATCH] Changelog: mention the new avbuild/ directory

2017-01-09 Thread Diego Biurrun
On Mon, Jan 09, 2017 at 11:10:24AM +0100, Anton Khirnov wrote:
> Especially config.log is often read by users trying to compile Libav, so
> its move should be documented.
> ---
>  Changelog | 1 +
>  1 file changed, 1 insertion(+)

OK

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

Re: [libav-devel] [PATCH 08/12] motionpixels: Convert to the new bitstream reader

2017-01-09 Thread Diego Biurrun
On Sun, Nov 27, 2016 at 05:32:39PM +0100, Diego Biurrun wrote:
> From: Alexandra Hájková 
> 
> ---
>  libavcodec/motionpixels.c | 77 
> ---
>  1 file changed, 40 insertions(+), 37 deletions(-)

OKed by Luca on IRC.

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

Re: [libav-devel] [PATCH] avconv: Do not pass NULL to avio_tell

2017-01-09 Thread Anton Khirnov
Quoting Luca Barbato (2017-01-09 11:36:47)
> On 09/01/2017 10:47, Anton Khirnov wrote:
> > The patch is fine with me, but more generally I'd say that as long
> > as the muxer is open, the AVIOContext belongs to it and the caller
> > touching it in any way is invalid.
> 
> Shall we add an avformat_report_progress() or similar?

Perhaps a field in AVFormatContext which stores the number of bytes
written so far?

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

Re: [libav-devel] [PATCH 4/4] build: Move cli tools to a separate subdirectory

2017-01-09 Thread Vittorio Giovara
On Fri, Jan 6, 2017 at 2:45 PM, Diego Biurrun  wrote:
> This unclutters the top-level directory and groups related files together.
> ---
>  .gitignore   |  3 --
>  Makefile | 47 
> 
>  configure|  2 +-
>  tools/.gitignore |  3 ++
>  tools/Makefile   | 43 +
>  avconv.c => tools/avconv.c   |  0
>  avconv.h => tools/avconv.h   |  0
>  avconv_dxva2.c => tools/avconv_dxva2.c   |  0
>  avconv_filter.c => tools/avconv_filter.c |  0
>  avconv_opt.c => tools/avconv_opt.c   |  0
>  avconv_qsv.c => tools/avconv_qsv.c   |  0
>  avconv_vaapi.c => tools/avconv_vaapi.c   |  0
>  avconv_vda.c => tools/avconv_vda.c   |  0
>  avconv_vdpau.c => tools/avconv_vdpau.c   |  0
>  avplay.c => tools/avplay.c   |  0
>  avprobe.c => tools/avprobe.c |  0
>  cmdutils.c => tools/cmdutils.c   |  0
>  cmdutils.h => tools/cmdutils.h   |  0
>  18 files changed, 52 insertions(+), 46 deletions(-)
>  create mode 100644 tools/.gitignore
>  create mode 100644 tools/Makefile
>  rename avconv.c => tools/avconv.c (100%)
>  rename avconv.h => tools/avconv.h (100%)
>  rename avconv_dxva2.c => tools/avconv_dxva2.c (100%)
>  rename avconv_filter.c => tools/avconv_filter.c (100%)
>  rename avconv_opt.c => tools/avconv_opt.c (100%)
>  rename avconv_qsv.c => tools/avconv_qsv.c (100%)
>  rename avconv_vaapi.c => tools/avconv_vaapi.c (100%)
>  rename avconv_vda.c => tools/avconv_vda.c (100%)
>  rename avconv_vdpau.c => tools/avconv_vdpau.c (100%)
>  rename avplay.c => tools/avplay.c (100%)
>  rename avprobe.c => tools/avprobe.c (100%)
>  rename cmdutils.c => tools/cmdutils.c (100%)
>  rename cmdutils.h => tools/cmdutils.h (100%)
>

I don't mind the idea, but imo the main files (avconv.c avprobe.c
avserver.c) should be kept in the top level directory. Similarly
executables should be in the top level directory, rather than under
avtool. I believe that after configuring and compiling, finding the
necessary tools immediately in the build directory is more
user-friendly than looking for them in any other arbitrary location.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/6] avconv: add avconv_d3d11va

2017-01-09 Thread wm4
On Tue,  3 Jan 2017 17:35:03 +0100
Steve Lhomme  wrote:

> From: Steve Lhomme 
> 
> The code is similar to avconv_dxva2. The decoded output needs to be copied 
> into
> a staging texture that can be accessed by the CPU as the decoder texture can't
> be accessed by the CPU.
> 
> edit: move the actual GUID definitions in a shared C file
> ---
>  Changelog|   1 +
>  Makefile |   1 +
>  avconv.h |   2 +
>  avconv_d3d11va.c | 213 
> +++
>  avconv_dxva.c|  28 
>  avconv_opt.c |   3 +
>  configure|   6 ++
>  7 files changed, 254 insertions(+)
>  create mode 100644 avconv_d3d11va.c
>  create mode 100644 avconv_dxva.c
> 
> diff --git a/Changelog b/Changelog
> index e17ef20..6aa3f03 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,6 +6,7 @@ version :
>  - Intel QSV-accelerated VP8 and VC-1 decoding
>  - VAAPI-accelerated VP8 and HEVC decoding
>  - VAAPI-accelerated deinterlacing
> +- support for decoding through D3D11VA in avconv
>  
>  
>  version 12:
> diff --git a/Makefile b/Makefile
> index 26c296f..6040131 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -85,6 +85,7 @@ OBJS-avconv   += avconv_opt.o 
> avconv_filter.o
>  OBJS-avconv-$(CONFIG_LIBMFX)  += avconv_qsv.o
>  OBJS-avconv-$(CONFIG_VAAPI)   += avconv_vaapi.o
>  OBJS-avconv-$(CONFIG_VDA) += avconv_vda.o
> +OBJS-avconv-$(HAVE_D3D11VA_LIB) += avconv_d3d11va.o avconv_guid.o
>  OBJS-avconv-$(HAVE_DXVA2_LIB) += avconv_dxva2.o avconv_guid.o
>  OBJS-avconv-$(HAVE_VDPAU_X11) += avconv_vdpau.o
>  
> diff --git a/avconv.h b/avconv.h
> index 6360f76..1919c66 100644
> --- a/avconv.h
> +++ b/avconv.h
> @@ -56,6 +56,7 @@ enum HWAccelID {
>  HWACCEL_VDA,
>  HWACCEL_QSV,
>  HWACCEL_VAAPI,
> +HWACCEL_D3D11VA,
>  };
>  
>  typedef struct HWAccel {
> @@ -498,6 +499,7 @@ int ifilter_parameters_from_frame(InputFilter *ifilter, 
> const AVFrame *frame);
>  int avconv_parse_options(int argc, char **argv);
>  
>  int vdpau_init(AVCodecContext *s);
> +int d3d11va_init(AVCodecContext *s);
>  int dxva2_init(AVCodecContext *s);
>  int vda_init(AVCodecContext *s);
>  int qsv_init(AVCodecContext *s);
> diff --git a/avconv_d3d11va.c b/avconv_d3d11va.c
> new file mode 100644
> index 000..d7ec558
> --- /dev/null
> +++ b/avconv_d3d11va.c
> @@ -0,0 +1,213 @@
> +/*
> + * 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
> + */
> +
> +#include 
> +
> +#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
> +#undef _WIN32_WINNT
> +#define _WIN32_WINNT 0x0600
> +#endif
> +#define COBJMACROS
> +
> +#include 
> +
> +#include 
> +
> +#include "avconv.h"
> +
> +#include "libavcodec/d3d11va.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/buffer.h"
> +#include "libavutil/frame.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/pixfmt.h"
> +
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/hwcontext_d3d11va.h"
> +
> +typedef struct D3D11VAContext {
> +D3D11_VIDEO_DECODER_CONFIG   decoder_config;
> +
> +AVFrame *tmp_frame;
> +
> +AVBufferRef *hw_device_ctx;
> +AVBufferRef *hw_frames_ctx;
> +} D3D11VAContext;
> +
> +typedef D3D11_VIDEO_DECODER_CONFIG DXVA_DECODER_CONFIG;
> +typedef DXGI_FORMATDXVA_SURFACE_FORMAT;
> +typedef D3D11VAContext DXVA_CONTEXT;
> +typedef AVD3D11VAContext   DXVA_AV_CONTEXT;
> +typedef ID3D11VideoDevice  *DXVA_DECODER_SERVICE;
> +#include "avconv_dxva_template.c"
> +
> +static int d3d11va_get_decoder_configuration(AVCodecContext *s,
> + const D3D11_VIDEO_DECODER_DESC 
> *desc,
> + DXVA_DECODER_CONFIG *config)
> +{
> +InputStream  *ist = s->opaque;
> +int loglevel = (ist->hwaccel_id == HWACCEL_AUTO) ? AV_LOG_VERBOSE : 
> AV_LOG_ERROR;
> +unsigned cfg_count = 0;
> +DXVA_DECODER_CONFIG *cfg_list = NULL;
> +HRESULT hr;
> +int i, ret;
> +
> +DXVA_CONTEXT *ctx= ist->hwaccel_ctx;
> +AVHWDeviceContext*device_ctx = 
> (AVHWDeviceContext*)ctx->hw_device_ctx->data;
> +AVD3D11VADeviceContext 

Re: [libav-devel] [PATCH 2/6] avconv: dxva2: factorize some code that can be common with d3d11va

2017-01-09 Thread wm4
On Tue,  3 Jan 2017 17:35:00 +0100
Steve Lhomme  wrote:

> From: Steve Lhomme 
> 
> avconv_dxva.h has to be included and misc. typedefs have to be set to use the
> proper DXVA2 structures.
> 
> initguid.h is included in avconv_dxva.h so any includes after that will also
> define GUIDs locally.
> ---
>  avconv_dxva2.c | 277 ---
>  avconv_dxva_template.c | 289 
> +
>  2 files changed, 335 insertions(+), 231 deletions(-)
>  create mode 100644 avconv_dxva_template.c
> 
> diff --git a/avconv_dxva2.c b/avconv_dxva2.c
> index 7578c3f..442a0bd 100644
> --- a/avconv_dxva2.c
> +++ b/avconv_dxva2.c
> @@ -43,52 +43,6 @@
>  #include "libavutil/hwcontext.h"
>  #include "libavutil/hwcontext_dxva2.h"
>  
> -/* define all the GUIDs used directly here,
> -   to avoid problems with inconsistent dxva2api.h versions in mingw-w64 and 
> different MSVC version */
> -#include 
> -DEFINE_GUID(IID_IDirectXVideoDecoderService, 
> 0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
> -
> -DEFINE_GUID(DXVA2_ModeMPEG2_VLD,  0xee27417f, 
> 0x5e28,0x4e65,0xbe,0xea,0x1d,0x26,0xb5,0x08,0xad,0xc9);
> -DEFINE_GUID(DXVA2_ModeMPEG2and1_VLD,  0x86695f12, 
> 0x340e,0x4f04,0x9f,0xd3,0x92,0x53,0xdd,0x32,0x74,0x60);
> -DEFINE_GUID(DXVA2_ModeH264_E, 0x1b81be68, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
> -DEFINE_GUID(DXVA2_ModeH264_F, 0x1b81be69, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
> -DEFINE_GUID(DXVADDI_Intel_ModeH264_E, 0x604F8E68, 
> 0x4951,0x4C54,0x88,0xFE,0xAB,0xD2,0x5C,0x15,0xB3,0xD6);
> -DEFINE_GUID(DXVA2_ModeVC1_D,  0x1b81beA3, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
> -DEFINE_GUID(DXVA2_ModeVC1_D2010,  0x1b81beA4, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
> -DEFINE_GUID(DXVA2_ModeHEVC_VLD_Main,  0x5b11d51b, 
> 0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
> -DEFINE_GUID(DXVA2_ModeHEVC_VLD_Main10,0x107af0e0, 
> 0xef1a,0x4d19,0xab,0xa8,0x67,0xa1,0x63,0x07,0x3d,0x13);
> -DEFINE_GUID(DXVA2_NoEncrypt,  0x1b81beD0, 
> 0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
> -DEFINE_GUID(GUID_NULL,0x, 
> 0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
> -
> -typedef struct dxva2_mode {
> -  const GUID *guid;
> -  enum AVCodecID codec;
> -} dxva2_mode;
> -
> -static const dxva2_mode dxva2_modes[] = {
> -/* MPEG-2 */
> -{ _ModeMPEG2_VLD,  AV_CODEC_ID_MPEG2VIDEO },
> -{ _ModeMPEG2and1_VLD,  AV_CODEC_ID_MPEG2VIDEO },
> -
> -/* H.264 */
> -{ _ModeH264_F, AV_CODEC_ID_H264 },
> -{ _ModeH264_E, AV_CODEC_ID_H264 },
> -/* Intel specific H.264 mode */
> -{ _Intel_ModeH264_E, AV_CODEC_ID_H264 },
> -
> -/* VC-1 / WMV3 */
> -{ _ModeVC1_D2010,  AV_CODEC_ID_VC1  },
> -{ _ModeVC1_D2010,  AV_CODEC_ID_WMV3 },
> -{ _ModeVC1_D,  AV_CODEC_ID_VC1  },
> -{ _ModeVC1_D,  AV_CODEC_ID_WMV3 },
> -
> -/* HEVC/H.265 */
> -{ _ModeHEVC_VLD_Main,  AV_CODEC_ID_HEVC },
> -{ _ModeHEVC_VLD_Main10, AV_CODEC_ID_HEVC },
> -
> -{ NULL,  0 },
> -};
> -
>  typedef struct DXVA2Context {
>  IDirectXVideoDecoder*decoder;
>  
> @@ -102,55 +56,24 @@ typedef struct DXVA2Context {
>  AVBufferRef *hw_frames_ctx;
>  } DXVA2Context;
>  
> +typedef DXVA2_ConfigPictureDecode   DXVA_DECODER_CONFIG;
> +typedef D3DFORMAT   DXVA_SURFACE_FORMAT;
> +typedef DXVA2ContextDXVA_CONTEXT;
> +typedef struct dxva_context DXVA_AV_CONTEXT;
> +typedef IDirectXVideoDecoderService *DXVA_DECODER_SERVICE;
> +#include "avconv_dxva_template.c"
> +
> +DEFINE_GUID(IID_IDirectXVideoDecoderService, 
> 0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
> +
>  static void dxva2_uninit(AVCodecContext *s)
>  {
>  InputStream  *ist = s->opaque;
>  DXVA2Context *ctx = ist->hwaccel_ctx;
>  
> -ist->hwaccel_uninit= NULL;
> -ist->hwaccel_get_buffer= NULL;
> -ist->hwaccel_retrieve_data = NULL;
> -
>  if (ctx->decoder_service)
>  IDirectXVideoDecoderService_Release(ctx->decoder_service);
>  
> -av_buffer_unref(>hw_frames_ctx);
> -av_buffer_unref(>hw_device_ctx);
> -
> -av_frame_free(>tmp_frame);
> -
> -av_freep(>hwaccel_ctx);
> -av_freep(>hwaccel_context);
> -}
> -
> -static int dxva2_get_buffer(AVCodecContext *s, AVFrame *frame, int flags)
> -{
> -InputStream  *ist = s->opaque;
> -DXVA2Context *ctx = ist->hwaccel_ctx;
> -
> -return av_hwframe_get_buffer(ctx->hw_frames_ctx, frame, 0);
> -}
> -
> -static int dxva2_retrieve_data(AVCodecContext *s, AVFrame *frame)
> -{
> -InputStream*ist = s->opaque;
> -DXVA2Context   *ctx = ist->hwaccel_ctx;
> -intret;
> -
> -ret = 

Re: [libav-devel] [PATCH 1/6] libavutil: add support for AV_HWDEVICE_TYPE_D3D11VA

2017-01-09 Thread wm4
On Tue,  3 Jan 2017 17:34:59 +0100
Steve Lhomme  wrote:

> From: Steve Lhomme 
> 
> ---
>  doc/APIchanges |   3 +
>  libavutil/Makefile |   3 +
>  libavutil/hwcontext.c  |   3 +
>  libavutil/hwcontext.h  |   1 +
>  libavutil/hwcontext_d3d11va.c  | 460 
> +
>  libavutil/hwcontext_d3d11va.h  |  70 +++
>  libavutil/hwcontext_internal.h |   1 +
>  libavutil/version.h|   2 +-
>  8 files changed, 542 insertions(+), 1 deletion(-)
>  create mode 100644 libavutil/hwcontext_d3d11va.c
>  create mode 100644 libavutil/hwcontext_d3d11va.h
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 7633c99..29d5113 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2017-xx-xx - xxx - lavu 55.30.0 - hwcontext.h
> +  Add AV_HWDEVICE_TYPE_D3D11VA to decode using Direct3D11.
> +
>  2016-xx-xx - xxx - lavc 57.29.0 - avcodec.h
>Add AV_PKT_DATA_SPHERICAL packet side data to export AVSphericalMapping
>information from containers.
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 60e180c..6fb24db 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -27,6 +27,7 @@ HEADERS = adler32.h 
> \
>hmac.h\
>hwcontext.h   \
>hwcontext_cuda.h  \
> +  hwcontext_d3d11va.h   \
>hwcontext_dxva2.h \
>hwcontext_qsv.h   \
>hwcontext_vaapi.h \
> @@ -112,6 +113,7 @@ OBJS = adler32.o  
>   \
> xtea.o   \
>  
>  OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
> +OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
>  OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
>  OBJS-$(CONFIG_LIBMFX)   += hwcontext_qsv.o
>  OBJS-$(CONFIG_LZO)  += lzo.o
> @@ -121,6 +123,7 @@ OBJS-$(CONFIG_VDPAU)+= 
> hwcontext_vdpau.o
>  OBJS += $(COMPAT_OBJS:%=../compat/%)
>  
>  SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
> +SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
>  SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
>  SKIPHEADERS-$(CONFIG_LIBMFX)   += hwcontext_qsv.h
>  SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 83f733e..ae27c51 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -32,6 +32,9 @@ static const HWContextType *hw_table[] = {
>  #if CONFIG_CUDA
>  _hwcontext_type_cuda,
>  #endif
> +#if CONFIG_D3D11VA
> +_hwcontext_type_d3d11va,
> +#endif
>  #if CONFIG_DXVA2
>  _hwcontext_type_dxva2,
>  #endif
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index 037ca64..d64b2da 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -30,6 +30,7 @@ enum AVHWDeviceType {
>  AV_HWDEVICE_TYPE_VAAPI,
>  AV_HWDEVICE_TYPE_DXVA2,
>  AV_HWDEVICE_TYPE_QSV,
> +AV_HWDEVICE_TYPE_D3D11VA,
>  };
>  
>  typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> new file mode 100644
> index 000..a23a475
> --- /dev/null
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -0,0 +1,460 @@
> +/*
> + * 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
> + */
> +
> +#include 
> +
> +#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
> +#undef _WIN32_WINNT
> +#define _WIN32_WINNT 0x0600
> +#endif
> +#define COBJMACROS
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "avassert.h"
> +#include "common.h"
> +#include "hwcontext.h"
> +#include "hwcontext_d3d11va.h"
> 

Re: [libav-devel] [PATCH] avconv: Do not pass NULL to avio_tell

2017-01-09 Thread Luca Barbato
On 09/01/2017 10:47, Anton Khirnov wrote:
> The patch is fine with me, but more generally I'd say that as long
> as the muxer is open, the AVIOContext belongs to it and the caller
> touching it in any way is invalid.

Shall we add an avformat_report_progress() or similar?

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

Re: [libav-devel] [PATCH] qsvdec: do not sync PIX_FMT_QSV surfaces

2017-01-09 Thread Luca Barbato
On 09/01/2017 10:48, Anton Khirnov wrote:
> Introducing enforced sync points in arbitrary places is bad for
> performance. Since the vast majority of receiving code (QSV VPP or
> encoders, retrieving frames through hwcontext) will do the syncing, this
> change should not be visible to most callers. But bumping micro just in
> case.
> 
> This is also consistent with that VAAPI hwaccel does.

Fine for me.

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

Re: [libav-devel] [PATCH] Changelog: mention the new avbuild/ directory

2017-01-09 Thread Luca Barbato
On 09/01/2017 11:10, Anton Khirnov wrote:
> Especially config.log is often read by users trying to compile Libav, so
> its move should be documented.
> ---
>  Changelog | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Changelog b/Changelog
> index e17ef20..70d6a4a 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,6 +6,7 @@ version :
>  - Intel QSV-accelerated VP8 and VC-1 decoding
>  - VAAPI-accelerated VP8 and HEVC decoding
>  - VAAPI-accelerated deinterlacing
> +- config.log and other configuration files moved into avbuild/ directory
>  
>  
>  version 12:
> 

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

[libav-devel] [PATCH] Changelog: mention the new avbuild/ directory

2017-01-09 Thread Anton Khirnov
Especially config.log is often read by users trying to compile Libav, so
its move should be documented.
---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index e17ef20..70d6a4a 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - Intel QSV-accelerated VP8 and VC-1 decoding
 - VAAPI-accelerated VP8 and HEVC decoding
 - VAAPI-accelerated deinterlacing
+- config.log and other configuration files moved into avbuild/ directory
 
 
 version 12:
-- 
2.0.0

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

Re: [libav-devel] [PATCH] hevcdec: add P010 support for D3D11VA

2017-01-09 Thread Anton Khirnov
Quoting Steve Lhomme (2017-01-04 09:39:31)
> Given it's the same API than DVXA2 I don't know why the same output was not
> enabled for both.
> ---
>  libavcodec/hevcdec.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 8326690..700b5f0 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -388,6 +388,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, 
> const HEVCSPS *sps)
>  
>  if (sps->pix_fmt == AV_PIX_FMT_YUV420P || sps->pix_fmt == 
> AV_PIX_FMT_YUVJ420P ||
>  sps->pix_fmt == AV_PIX_FMT_YUV420P10) {
> +#if CONFIG_HEVC_D3D11VA_HWACCEL
> +*fmt++ = AV_PIX_FMT_D3D11VA_VLD;
> +#endif
>  #if CONFIG_HEVC_DXVA2_HWACCEL
>  *fmt++ = AV_PIX_FMT_DXVA2_VLD;
>  #endif
> @@ -396,9 +399,6 @@ static enum AVPixelFormat get_format(HEVCContext *s, 
> const HEVCSPS *sps)
>  #endif
>  }
>  if (sps->pix_fmt == AV_PIX_FMT_YUV420P || sps->pix_fmt == 
> AV_PIX_FMT_YUVJ420P) {
> -#if CONFIG_HEVC_D3D11VA_HWACCEL
> -*fmt++ = AV_PIX_FMT_D3D11VA_VLD;
> -#endif
>  #if CONFIG_HEVC_VDPAU_HWACCEL
>  *fmt++ = AV_PIX_FMT_VDPAU;
>  #endif
> -- 
> 2.10.2

Looks good, queueing.

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

[libav-devel] [PATCH] qsvdec: do not sync PIX_FMT_QSV surfaces

2017-01-09 Thread Anton Khirnov
Introducing enforced sync points in arbitrary places is bad for
performance. Since the vast majority of receiving code (QSV VPP or
encoders, retrieving frames through hwcontext) will do the syncing, this
change should not be visible to most callers. But bumping micro just in
case.

This is also consistent with that VAAPI hwaccel does.
---
 libavcodec/qsvdec.c  | 8 +---
 libavcodec/version.h | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index b83b0fc..0cbe509 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -363,9 +363,11 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 av_fifo_generic_read(q->async_fifo, ,  sizeof(sync),  
NULL);
 out_frame->queued = 0;
 
-do {
-ret = MFXVideoCORE_SyncOperation(q->session, *sync, 1000);
-} while (ret == MFX_WRN_IN_EXECUTION);
+if (avctx->pix_fmt != AV_PIX_FMT_QSV) {
+do {
+ret = MFXVideoCORE_SyncOperation(q->session, *sync, 1000);
+} while (ret == MFX_WRN_IN_EXECUTION);
+}
 
 av_freep();
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 5b6fb6c..7348a0c 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR 57
 #define LIBAVCODEC_VERSION_MINOR 30
-#define LIBAVCODEC_VERSION_MICRO  2
+#define LIBAVCODEC_VERSION_MICRO  3
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.0.0

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

Re: [libav-devel] [PATCH] avconv: Do not pass NULL to avio_tell

2017-01-09 Thread Anton Khirnov
Quoting Luca Barbato (2016-12-15 19:01:03)
> The null demuxer does not have a backing AVIOContext.
> ---
>  avconv.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/avconv.c b/avconv.c
> index 5c31332..fe60625 100644
> --- a/avconv.c
> +++ b/avconv.c
> @@ -909,7 +909,7 @@ static void print_report(int is_last_report, int64_t 
> timer_start)
>  char buf[1024];
>  OutputStream *ost;
>  AVFormatContext *oc;
> -int64_t total_size;
> +int64_t total_size = 0;
>  AVCodecContext *enc;
>  int frame_number, vid, i;
>  double bitrate, ti1, pts;
> @@ -934,16 +934,17 @@ static void print_report(int is_last_report, int64_t 
> timer_start)
>  
>  
>  oc = output_files[0]->ctx;
> -
> -total_size = avio_size(oc->pb);
> -if (total_size <= 0) // FIXME improve avio_size() so it works with non 
> seekable output too
> -total_size = avio_tell(oc->pb);
> -if (total_size < 0) {
> -char errbuf[128];
> -av_strerror(total_size, errbuf, sizeof(errbuf));
> -av_log(NULL, AV_LOG_VERBOSE, "Bitrate not available, "
> -   "avio_tell() failed: %s\n", errbuf);
> -total_size = 0;
> +if (oc->pb) {
> +total_size = avio_size(oc->pb);
> +if (total_size <= 0) // FIXME improve avio_size() so it works with 
> non seekable output too
> +total_size = avio_tell(oc->pb);
> +if (total_size < 0) {
> +char errbuf[128];
> +av_strerror(total_size, errbuf, sizeof(errbuf));
> +av_log(NULL, AV_LOG_VERBOSE, "Bitrate not available, "
> +   "avio_tell() failed: %s\n", errbuf);
> +total_size = 0;
> +}
>  }
>  
>  buf[0] = '\0';
> -- 
> 2.9.2

The patch is fine with me, but more generally I'd say that as long as
the muxer is open, the AVIOContext belongs to it and the caller touching
it in any way is invalid.

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

Re: [libav-devel] [PATCH] hmac: Explicitly convert types at function pointer assignment

2017-01-09 Thread Anton Khirnov
Quoting Diego Biurrun (2016-12-15 13:27:02)
> Fixes a number of warnings of the type
> libavutil/hmac.c:61:21: warning: assignment from incompatible pointer type
> ---
> 
> Ifdeffed the function pointer signature for hmac_update to match API,
> according to Martin's review.
> 
>  libavutil/hmac.c | 35 +++
>  1 file changed, 23 insertions(+), 12 deletions(-)
> 

Ok I guess

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

Re: [libav-devel] [PATCH] crypto: consistently use size_t as type for length parameters

2017-01-09 Thread Anton Khirnov
Quoting Diego Biurrun (2017-01-03 12:08:10)
> size_t is the correct type to use for sizes.
> ---
> 
> Dropped the kind of pointless version bump.
> 
>  doc/APIchanges  | 4 
>  libavutil/md5.c | 8 
>  libavutil/md5.h | 8 +++-
>  libavutil/sha.c | 6 +-
>  libavutil/sha.h | 9 +++--
>  libavutil/version.h | 3 +++
>  6 files changed, 34 insertions(+), 4 deletions(-)
> 

LGTM

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

Re: [libav-devel] [PATCH 3/3] vaapi_h264: Scale log2_max_pic_order_cnt_lsb with max_b_frames

2017-01-09 Thread Anton Khirnov
Quoting Mark Thompson (2017-01-05 01:10:09)
> Before this change, it was possible to overflow pic_order_cnt_lsb and
> generate a stream with invalid POC numbering.  This makes sure that
> the field is large enough that a single IDR B* P sequence uses fewer
> than half the available POC lsb values.
> ---
>  libavcodec/vaapi_encode_h264.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index deb99a7d2..74e7cb1c1 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -800,6 +800,8 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  vseq->seq_fields.bits.direct_8x8_inference_flag = 1;
>  vseq->seq_fields.bits.log2_max_frame_num_minus4 = 4;
>  vseq->seq_fields.bits.pic_order_cnt_type = 0;
> +vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4 =
> +av_clip(av_log2(avctx->max_b_frames + 1) - 2, 0, 12);
>  
>  if (avctx->width  != ctx->surface_width ||
>  avctx->height != ctx->surface_height) {
> -- 
> 2.11.0

LGTM

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