git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> index 60dbe81c8..a066bc40f 100644
> --- a/libavcodec/hwaccel.h
> +++ b/libavcodec/hwaccel.h
> @@ -19,6 +19,24 @@
> #ifndef AVCODEC_HWACCEL_H
> #define AVCODEC_HWACCEL_H
>
> +#include "avcodec.h"
> +
> +
> #define HWACCEL
for. If you have packet loss, you're not required to do anything special
with the decoder, you just do not give the packets you don't have.
Similarly, I don't see any reason why sending a NULL packet at the
beginning should ever accomplish anything useful.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-10-02 00:01:06)
> The message callbacks are library-safe in libva2, so we can now use
> them.
> ---
> libavutil/hwcontext_vaapi.c | 21 +
> 1 file changed, 21 insertions(+)
>
Looks very good to me
.c | 4 ++--
> libavcodec/vaapi_encode.c | 4 ++--
> libavfilter/vf_deinterlace_vaapi.c | 2 +-
> libavfilter/vf_scale_vaapi.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
Ok
--
Anton Khirnov
___
libav-devel mailing
ff_cbs_fragment_uninit(&priv->cbc, au);
>
> -*type = VAEncPackedHeaderH264_SEI;
> +*type = VAEncPackedHeaderRawData;
This makes no difference for old libva?
--
Anton Khirnov
___
libav-devel mailing list
libav-deve
code.c | 1 -
> libavcodec/vaapi_encode_h264.c | 7 ---
> 2 files changed, 4 insertions(+), 4 deletions(-)
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
texturedsp
> texturedspenc
> tpeldsp
> +vaapi_1
Isn't SYSTEM_FEATURES the more correct places for this?
Otherwise looks ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-10-02 00:01:01)
> ---
> libavcodec/vaapi_decode.h | 3 +++
> 1 file changed, 3 insertions(+)
>
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
akes care of initializing the hw_frames_ctx
> if needed, and does additional error handling and API usage checking.
>
> Support for VDA and Cuvid missing.
> ---
> With updated doxygen.
> ---
Thanks, pushed.
--
Anton Khirnov
___
libav-
can potentially contain user-allocated content which
is then freed in the user-set free() callback. The semantics of that
memory management is then unclear.
Is there any reason the av_hwframe_ctx_alloc() call must be done by the
user? Doing it inside this function (and so changing the last parameter
to AVBu
Quoting wm4 (2017-08-18 15:35:49)
> On Fri, 18 Aug 2017 15:22:28 +0200
> Anton Khirnov wrote:
>
> > Quoting wm4 (2017-08-18 14:44:45)
> > > On Fri, 18 Aug 2017 15:40:32 +0300 (EEST)
> > > Martin Storsjö wrote:
> > >
> &
Quoting wm4 (2017-08-18 14:44:45)
> On Fri, 18 Aug 2017 15:40:32 +0300 (EEST)
> Martin Storsjö wrote:
>
> > On Fri, 18 Aug 2017, Anton Khirnov wrote:
> >
> > > Quoting wm4 (2017-08-17 15:01:44)
> > >> Main use-case is proxying avio through a foreign
ich may be influenced by other
> + * user settings (such as avctx->extra_hw_frames).
> + *
> + * avctx->hw_frames_ctx must be set before calling this function.
> + * Inside avctx->hw_frames_ctx, the fields format, sw_format, width and
> + * height must be set. If dynamicall
tual diffs are all trivial, e.g. for fate-lavf-mxf:
Ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
->cbc, out, frag);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
> +goto fail;
> +}
> +
> +err = av_packet_copy_props(out, in);
> +if (err < 0)
> +goto fail;
This leaks the contents of out I think.
Not sure if we should make the generic code unref it on failure.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
.c | 1 +
> 9 files changed, 975 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/cbs_mpeg2.c
> create mode 100644 libavcodec/cbs_mpeg2.h
> create mode 100644 libavcodec/cbs_mpeg2_syntax_template.c
>
LGTM
--
Anton Khirnov
__
all. This always tries to read at least 1 byte.
> + * Useful to reduce latency in certain cases.
> + * @return number of bytes read or AVERROR
> + */
> +int avio_read_partial(AVIOContext *s, unsigned char *buf, int size);
Maybe this would be a good opportunity to make this size_t
--
pic_num can be at most 17-bit, so uint8_t is not sufficient.
Found-By: Bradley Sepos
CC: libav-sta...@libav.org
---
libavcodec/h264dec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index ddfe224..cce5e19 100644
--- a/libavcodec/
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-ref-pic-mod-overflow | 21 +
2 files changed, 23 insertions(+)
create mode 100644 tests/ref/fate/h264-ref-pic-mod-overflow
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index bdc390d..7676fb8 1
// video_format:
> 5 is unspecified
> put_bits(&s->pb, 1, 1); //
> colour_description
> put_bits(&s->pb, 8, s->avctx->color_primaries); //
> colour_primaries
> put_bits(&s->pb, 8, s->avctx->
Quoting Mark Thompson (2017-08-11 01:37:09)
> Replaced with more complete implementation via coded bitstream infrastructure.
> ---
> Unchanged.
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.or
ence decoder barfs if it isn't).
> ---
> Build system change only.
Looks ok. I'll try to test it on Windows later. Poke me if I forget.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-08-11 01:37:07)
> Matching the H.264 encoder.
> ---
Looks ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Is this related to the rest of the patch? Does not seem so.
Otherwise looks ok as far as I can tell.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-08-11 01:37:05)
> Included by default with non-IDR intra frames.
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
unnecessary. And in any case it should use a proper logging
context and have a lower verbosity level.
>+ }
>+
>+av_expr_free(w_expr);
>+av_expr_free(h_expr);
>+av_expr_free(cw_expr);
>+av_expr_free(ch_expr);
>+av_expr_free(cx_expr);
>+av_expr_fre
ame(QSVVPPContext *s, AVFilterLink *inlink, AVFrame
> > *picref)
> > +{
> > +in_frame = submit_frame(s, inlink, picref);
> > +if (!in_frame) {
> > +av_log(ctx, AV_LOG_ERROR, "Fail to submit frame on input[%d]\n",
> > +FF_INLINK_IDX(inlink));
>
> "Failed", indentation is off.
>
> > +return AVERROR(EINVAL);
>
> Is this an error due to user-supplied data or user-supplied configuration?
> Because that's what EINVAL is for.
Should be ENOMEM
>
> Don't you leak vpp->comp_conf.InputStream here?
>
No, uninit is always called even if init fails.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
tret = 0;
>+AVExpr *ox_expr, *oy_expr, *ow_expr, *oh_expr;
Those need to be initialized to NULL, otherwise you have invalid frees
in the failure path.
Otherwise looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.
Quoting Mark Thompson (2017-07-29 23:16:36)
> Adds a new private option to enable them (off by default).
> ---
> libavcodec/vaapi_encode_h264.c | 33 +
> 1 file changed, 33 insertions(+)
Looks ok
--
A
CODER)+= qsvdec_h2645.o
> OBJS-$(CONFIG_H264_QSV_ENCODER)+= qsvenc_h264.o
> -OBJS-$(CONFIG_H264_VAAPI_ENCODER) += vaapi_encode_h264.o
> vaapi_encode_h26x.o
> +OBJS-$(CONFIG_H264_VAAPI_ENCODER) += vaapi_encode_h264.o
I'd expect a dependency on cbs here (or in configu
+@item crop_left
> +@item crop_right
> +@item crop_top
> +@item crop_bottom
> +Set the conformance window cropping offsets in the SPS. These values
> +will replace the current ones if the stream is already cropped.
> +
> +The unit of these values is chroma pixels after subsampli
int8_t intra_quantiser_matrix[64];
> +uint8_t load_non_intra_quantiser_matrix;
> +uint8_t non_intra_quantiser_matrix[64];
> +uint8_t load_chroma_intra_quantiser_matrix;
> +uint8_t chroma_intra_quantiser_matrix[64];
> +uint8_t load_chroma_non_intra_quantiser_matrix;
> +uint8_t chroma_non_intra_quantiser_matrix[64];
> +} MPEG2RawQuantMatrixExtension;
> +
> +typedef struct MPEG2RawExtensionData {
> +uint8_t extension_start_code;
> +uint8_t extension_start_code_identifier;
> +
> +union {
> +MPEG2RawSequenceExtension sequence;
> +MPEG2RawSequenceDisplayExtension sequence_display;
> +MPEG2RawQuantMatrixExtension quant_matrix;
> +MPEG2RawPictureCodingExtension picture_coding;
> +} data;
> +} MPEG2RawExtensionData;
> +
> +typedef struct MPEG2RawSliceHeader {
> +uint8_t slice_vertical_position;
> +
> +uint8_t slice_vertical_position_extension;
> +uint8_t priority_breakpoint;
> +
> +uint8_t quantiser_scale_code;
> +
> +uint8_t slice_extension_flag;
> +uint8_t intra_slice;
> +uint8_t slice_picture_id_enable;
> +uint8_t slice_picture_id;
> +
> +uint8_t extra_bit_slice;
> +
> +size_t extra_information_length;
> +uint8_t *extra_information;
Does this get freed? Same for user_data.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ted, and all of the redundant PPSs
> within the stream are removed.
> ---
Seems no changes here, so still ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
t(&ctx->cbc, au,
> + sei_pos, H264_NAL_SEI, sei);
> + if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to insert SEI.\n");
> +goto fail;
> +}
> +}
> +
> +payload = &sei->payload[sei->payload_count];
> +
> +payload->payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED;
> +udu = &payload->payload.user_data_unregistered;
> +
> +for (i = j = 0; j < 32 && ctx->sei_user_data[i]; i++) {
> +int c, v;
> +c = ctx->sei_user_data[i];
> +if (c == '-') {
> +continue;
> +} else if (av_isxdigit(c)) {
> + c = av_tolower(c);
> + v = (c <= '9' ? c - '0' : c - 'a' + 10);
> +} else {
> + goto invalid_user_data;
weird indentation
Otherwise ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
v_strlcat(tmp, ", corrupt", sizeof(tmp));
> +
> +if (in->pts != AV_NOPTS_VALUE)
> +av_strlcatf(tmp, sizeof(tmp), ", pts %"PRId64, in->pts);
since you're going all out here, might as well print 'nopts' for
AV_NOPTS_VALUE
Otherwise looks ok.
--
bs_h265.h
> create mode 100644 libavcodec/cbs_h265_syntax.c
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
5.h
> create mode 100644 libavcodec/cbs_h264_syntax.c
ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
; create mode 100644 libavcodec/cbs.c
> create mode 100644 libavcodec/cbs.h
> create mode 100644 libavcodec/cbs_internal.h
>
This one looks unchanged, so still ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://li
ret = blend_frame(ctx, s->main, s->over_prev);
>+} else {
>+av_frame_free(&s->main);
>+ret = AVERROR(EAGAIN);
>+}
>+
>+s->main = NULL;
>+
>+return ret ;
>+}
This duplication of nontrivial code with vf_overlay is suboptimal. Would it be
hard to share?
>+
>+static int filter_frame_main(AVFilterLink *inlink, AVFrame *frame)
>+{
>+QSVOverlayContext *s = inlink->dst->priv;
>+
>+av_assert0(!s->main);
>+s->main = frame;
>+
>+return 0;
>+}
>+
>+static int filter_frame_overlay(AVFilterLink *inlink, AVFrame *frame)
>+{
>+QSVOverlayContext *s = inlink->dst->priv;
>+
>+av_assert0(!s->over_next);
>+s->over_next = frame;
>+
>+return 0;
>+}
>+
>+static int overlay_qsv_init(AVFilterContext *ctx)
>+{
>+QSVOverlayContext *vpp = ctx->priv;
>+
>+/* fill composite config */
>+vpp->comp_conf.Header.BufferId = MFX_EXTBUFF_VPP_COMPOSITE;
>+vpp->comp_conf.Header.BufferSz = sizeof(vpp->comp_conf);
>+vpp->comp_conf.NumInputStream = ctx->nb_inputs;
>+vpp->comp_conf.InputStream =
>+av_mallocz(sizeof(*vpp->comp_conf.InputStream) * ctx->nb_inputs);
nit: av_mallocz_array()
>+if (!vpp->comp_conf.InputStream)
>+return AVERROR(ENOMEM);
>+
>+/* initialize QSVVPP params */
>+vpp->qsv_param.filter_frame = NULL;
>+vpp->qsv_param.ext_buf = av_mallocz(sizeof(*vpp->qsv_param.ext_buf));
>+if (!vpp->qsv_param.ext_buf)
>+return AVERROR(ENOMEM);
>+
>+vpp->qsv_param.ext_buf[0]= (mfxExtBuffer *)&vpp->comp_conf;
>+vpp->qsv_param.num_ext_buf = 1;
>+vpp->qsv_param.out_sw_format = AV_PIX_FMT_NV12;
>+vpp->qsv_param.num_crop = 0;
>+
>+return 0;
>+}
>+
>+static void overlay_qsv_uninit(AVFilterContext *ctx)
>+{
>+QSVOverlayContext *vpp = ctx->priv;
>+
>+av_frame_free(&vpp->main);
>+av_frame_free(&vpp->over_prev);
>+av_frame_free(&vpp->over_next);
>+ff_qsvvpp_free(&vpp->qsv);
>+av_freep(&vpp->comp_conf.InputStream);
>+av_freep(&vpp->qsv_param.ext_buf);
>+}
>+
>+static int overlay_qsv_query_formats(AVFilterContext *ctx)
>+{
>+int i;
>+
>+static const enum AVPixelFormat main_in_fmts[] = {
>+AV_PIX_FMT_YUV420P,
>+AV_PIX_FMT_NV12,
>+AV_PIX_FMT_YUYV422,
>+AV_PIX_FMT_RGB32,
>+AV_PIX_FMT_QSV,
>+AV_PIX_FMT_NONE
>+};
>+static const enum AVPixelFormat out_pix_fmts[] = {
>+AV_PIX_FMT_NV12,
>+AV_PIX_FMT_QSV,
>+AV_PIX_FMT_NONE
>+};
>+
>+for(i = 0; i < ctx->nb_inputs; i++)
missing space
>+AVFilter ff_vf_overlay_qsv = {
>+.name = "overlay_qsv",
>+.description = NULL_IF_CONFIG_SMALL("Quick Sync Video overlay."),
>+.priv_size = sizeof(QSVOverlayContext),
>+.query_formats = overlay_qsv_query_formats,
>+.init = overlay_qsv_init,
>+.uninit= overlay_qsv_uninit,
>+.inputs= overlay_qsv_inputs,
>+.outputs = overlay_qsv_outputs,
>+.priv_class= &overlay_qsv_class,
>+ .flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
broken indentation
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Luca Barbato (2017-07-21 00:53:18)
> The hardware encoders currently do pick the first compatible device
> available by themselves.
I don't think this is true for all encoders. Perhaps what we should do
instead is auto-create the device like we do for decoding.
--
An
---
libavcodec/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ac13166..eba651f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -797,6 +797,7 @@ SKIPHEADERS+= %_tablegen.h
\
Both pushed, thanks.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Sean McGovern (2017-07-27 07:42:29)
> Hi Anton,
>
> On Mon, Jul 24, 2017 at 12:50 PM, Anton Khirnov wrote:
> > Quoting Luca Barbato (2017-07-24 18:21:20)
> >> On 24/07/2017 15:15, Anton Khirnov wrote:
> >> > Some parts of the code are based on
From: Anton Mitrofanov
CC: libav-sta...@libav.org
Signed-off-by: Anton Khirnov
---
libavcodec/h264_cabac.c | 16
libavcodec/h264_cavlc.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/h264_cabac.c b/libavcodec/h264_cabac.c
From: Anton Mitrofanov
Use the correct ctxIdxInc calculation for coded_block_flag.
Keep old behavior for old versions of x264 for backward compatibility.
CC: libav-sta...@libav.org
Signed-off-by: Anton Khirnov
---
libavcodec/h264_cabac.c | 47
Do not use the one in the SEI directly as that is reset at certain
points.
Inspired by patches from Michael Niedermayer and
Anton Mitrofanov .
CC: libav-sta...@libav.org
---
libavcodec/h264_direct.c | 4 ++--
libavcodec/h264_slice.c | 6 +-
libavcodec/h264dec.c | 1 +
libavcodec
From: Yogender Kumar Gupta
CC: libav-sta...@libav.org
Signed-off-by: Anton Khirnov
---
libavcodec/h264_mb.c | 7 +++-
libavcodec/h264pred.c | 2 ++
libavcodec/h264pred.h | 3 ++
libavcodec/h264pred_template.c | 73 ++
4
> libavcodec/cbs_internal.h|1 +
> 5 files changed, 2435 insertions(+), 3 deletions(-)
> create mode 100644 libavcodec/cbs_h265.h
> create mode 100644 libavcodec/cbs_h265_syntax.c
>
Looks okish from a quick look
--
Anton Khirnov
__
Quoting Luca Barbato (2017-07-24 18:21:20)
> On 24/07/2017 15:15, Anton Khirnov wrote:
> > Some parts of the code are based on a patch by
> > Timo Rothenpieler
> > ---
> > Now with high bit depth support
> > ---
>
> I recently updated the nvidia-video-c
t map_avcodec_id(enum AVCodecID id)
{
switch (id) {
case AV_CODEC_ID_H264: return cudaVideoCodec_H264;
+case AV_CODEC_ID_HEVC: return cudaVideoCodec_HEVC;
}
return -1;
}
diff --git a/libavcodec/cuvid_hevc.c b/libavcodec/cuvid_hevc.c
new file mode 100644
index
@ -68,6 +68,7 @@ void avcodec_register_all(void)
/* hardware accelerators */
REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
+REGISTER_HWACCEL(H264_CUVID,h264_cuvid);
REGISTER_HWACCEL(H264_D3D11VA, h264_d3d11va);
REGISTER_HWACCEL(H264_D3D11VA2, h264_d3d11va2)
Quoting Hendrik Leppkes (2017-07-24 12:09:52)
> On Mon, Jul 24, 2017 at 11:46 AM, Anton Khirnov wrote:
> > This allows running those tests with hwaccel.
> > ---
> > tests/fate/hevc.mak | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -
This way the SPS is available to the hwaccel init code.
---
libavcodec/hevcdec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index f6bbb70..664e4ac 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -490,13 +
This allows running those tests with hwaccel.
---
tests/fate/hevc.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 5446969..fe3ef26 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -144,7 +144,7 @@ HEVC_SAMPLES_10B
)
{
switch (id) {
case AV_CODEC_ID_H264: return cudaVideoCodec_H264;
+case AV_CODEC_ID_HEVC: return cudaVideoCodec_HEVC;
}
return -1;
}
diff --git a/libavcodec/cuvid_hevc.c b/libavcodec/cuvid_hevc.c
new file mode 100644
index 000..5de9bca
--- /dev/null
+++ b/libavcodec/cuvid_hevc
; create mode 100644 libavcodec/cbs.c
> create mode 100644 libavcodec/cbs.h
> create mode 100644 libavcodec/cbs_internal.h
>
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
5.h
> create mode 100644 libavcodec/cbs_h264_syntax.c
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+
> 4 files changed, 188 insertions(+)
> create mode 100644 libavcodec/h264_redundant_pps_bsf.c
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+
> libavcodec/bitstream_filters.c | 1 +
> libavcodec/h264_metadata_bsf.c | 462
> +
> 4 files changed, 512 insertions(+)
> create mode 100644 libavcodec/h264_metadata_bsf.c
>
Looks ok
--
Anton Khirnov
___
e
> +av_log(bsf, AV_LOG_INFO, "Packet (%spts %"PRId64")\n",
> + in->flags & AV_PKT_FLAG_KEY ? "key frame, " : "", in->pts);
Why not log the dts as well?
Otherwise looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-06-24 01:39:09)
> This would overflow if the stream contained a value greater than the
> maximum allowed by the standard (32).
> ---
> libavcodec/hevc_ps.c | 6 ++
> 1 file changed, 6 insertions(+)
>
Looks ok and should go into stable.
> 4 files changed, 52 insertions(+), 19 deletions(-)
>
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
n't see it as a problem.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ter. That helps ensuring that the compat
layers are correct.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
me*
> return AVERROR(ENOMEM);
>
> if (!s->time_base.num)
> s->time_base = (AVRational){1, s->sample_rate};
>
> +chlstr = av_channel_layout_describe(&s->ch_layout);
> av_log(ctx, AV_LOG_VERBOSE, "tb:%d/%d samplefmt:%s samplerate: %d "
> "ch layout:%s\n", s->time_base.num, s->time_base.den,
> s->sample_fmt_str,
> - s->sample_rate, s->channel_layout_str);
> + s->sample_rate, chlstr);
> +av_free(chlstr);
>
> return ret;
> }
> @@ -344,7 +347,7 @@ static int query_formats(AVFilterContext *ctx)
> ff_add_format(&samplerates, c->sample_rate);
> ff_set_common_samplerates(ctx, samplerates);
>
> -ff_add_channel_layout(&channel_layouts, c->channel_layout);
> +ff_add_channel_layout(&channel_layouts, c->ch_layout.u.mask);
> ff_set_common_channel_layouts(ctx, channel_layouts);
> break;
> default:
> @@ -357,6 +360,7 @@ static int query_formats(AVFilterContext *ctx)
> static int config_props(AVFilterLink *link)
> {
> BufferSourceContext *c = link->src->priv;
> +int ret;
>
> switch (link->type) {
> case AVMEDIA_TYPE_VIDEO:
> @@ -371,7 +375,16 @@ static int config_props(AVFilterLink *link)
> }
> break;
> case AVMEDIA_TYPE_AUDIO:
> -link->channel_layout = c->channel_layout;
> +ret = av_channel_layout_copy(&link->ch_layout, &c->ch_layout);
> +if (ret < 0)
> +return ret;
> +#if FF_API_OLD_CHANNEL_LAYOUT
> +FF_DISABLE_DEPRECATION_WARNINGS
> +if (c->ch_layout.order == AV_CHANNEL_ORDER_NATIVE ||
> +c->ch_layout.order == AV_CHANNEL_ORDER_UNSPEC)
> +link->channel_layout = c->ch_layout.u.mask;
Same as above.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
"Unspecified channel layout order is supported only for up
> "
> + "to 63 channels (got %d).\n",
> avr->out_ch_layout.nb_channels);
> + return AVERROR(ENOSYS);
> +}
> +av_channel_layout_default(&avr->out_ch_layout,
> avr->out_ch_layout.nb_channels);
> +}
Why are those needed? Seems they are redundant given the other checks
right below.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
t
needs to be done here, then your compatibility layer is broken.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Vittorio Giovara (2017-06-29 00:10:48)
> From: Anton Khirnov
>
> Signed-off-by: Vittorio Giovara
> ---
> libavcodec/decode.c | 67
> libavcodec/encode.c | 9 ++
> lib
Quoting Vittorio Giovara (2017-06-29 00:10:48)
> From: Anton Khirnov
>
> Signed-off-by: Vittorio Giovara
> ---
> libavcodec/decode.c | 67
> libavcodec/encode.c | 9 ++
Why are there lavc changes in this patch. Should they n
Quoting wm4 (2017-07-05 20:53:54)
> On Fri, 30 Jun 2017 12:51:16 -0400
> Vittorio Giovara wrote:
>
> > On Fri, Jun 30, 2017 at 4:38 AM, wm4 wrote:
> > > On Thu, 29 Jun 2017 17:28:51 -0400
> > > Vittorio Giovara wrote:
> > >
> > >>
ented by:
> + * - the formal channel layout name (returned by
> av_channel_layout_describe())
> + * - single or multiple channel names (returned by av_channel_name()
> + *or concatenated with "|")
Shouldn't this be
- single or multiple channel names (returned by av_channel_name(
Quoting Luca Barbato (2017-07-21 19:28:29)
> On 21/07/2017 15:19, Anton Khirnov wrote:
> > Some parts of the code are based on a patch by
> > Timo Rothenpieler
> > ---
>
> Seems fine, once I manage to boot the desktop I can test it.
>
> lu
>
> PS: Do
t_desc_get(pix_fmt);
> +int nb_planes = av_pix_fmt_count_planes(pix_fmt);
> +// A pixel on each plane, with a value that represents black.
> +// Consider e.g. AV_PIX_FMT_UYVY422 for non-trivial cases.
> + uint8_t pixel[4][MAX_PIXEL_SIZE] = {0}; // clear padding with 0
> +
Quoting wm4 (2017-07-21 22:56:43)
> On Fri, 21 Jul 2017 22:32:43 +0200
> Anton Khirnov wrote:
>
> > Quoting wm4 (2017-07-12 17:02:49)
> > > +int av_frame_apply_cropping(AVFrame *frame, int flags)
> > > +{
> > > +const AVPixFmtDescriptor *desc;
>
icitly specify
otherwise) expect the frame data to be aligned, so when this flag is
used, the resulting frame must not be fed back to Libav.'
Otherwise looks ok, modulo apichanges/bump
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+AVIOContext *pb;
> +
> +if (!ps || !*ps)
This is overly lax IMO. *ps being NULL should be allowed, in analogy
with free(NULL) beeing a no-op. But ps being NULL makes no sense at all
ever and just means that the caller is broken, so that should crash.
--
Anton Khirnov
__
CC: libav-sta...@libav.org
---
libavformat/caf.c| 1 +
libavformat/cafdec.c | 8
2 files changed, 9 insertions(+)
diff --git a/libavformat/caf.c b/libavformat/caf.c
index cf128d5..c299cad 100644
--- a/libavformat/caf.c
+++ b/libavformat/caf.c
@@ -49,6 +49,7 @@ const AVCodecTag ff_cod
Quoting James Almer (2017-07-21 17:49:33)
> On 7/21/2017 9:19 AM, Anton Khirnov wrote:
> > Quoting Anton Khirnov (2017-07-21 13:59:41)
> >> CC: libav-sta...@libav.org
> >> ---
> >> libavformat/caf.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >
Use the AVFrame.opaque_ref field. The original user's opaque_ref is
wrapped in the lavc struct and then unwrapped before the frame is
returned to the caller.
This new struct will be useful in the following commits.
---
libavcodec/decode.c | 57 +
This will be useful in the CUVID hwaccel. It should also eventually
replace current decoder-specific mechanisms used by various other
hwaccels.
---
libavcodec/decode.c | 3 +++
libavcodec/decode.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
This will be useful in the CUVID hwaccel.
---
libavcodec/decode.c | 11 +++
libavcodec/decode.h | 15 +++
2 files changed, 26 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 9cd3081..01e4dd2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
If the get_buffer() call fails, the frame might have some side data
already set. Make sure it gets freed.
---
libavcodec/decode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 175a6fa..89a6d34 100644
--- a/libavcodec/decode.c
+++ b/libavcode
register_all(void)
/* hardware accelerators */
REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
+REGISTER_HWACCEL(H264_CUVID,h264_cuvid);
REGISTER_HWACCEL(H264_D3D11VA, h264_d3d11va);
REGISTER_HWACCEL(H264_D3D11VA2, h264_d3d11va2);
REGISTER_HWACCEL(H2
Quoting Anton Khirnov (2017-07-21 13:59:41)
> CC: libav-sta...@libav.org
> ---
> libavformat/caf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/caf.c b/libavformat/caf.c
> index cf128d5..c299cad 100644
> --- a/libavformat/caf.c
> +++ b/libavfo
CC: libav-sta...@libav.org
---
libavformat/caf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/caf.c b/libavformat/caf.c
index cf128d5..c299cad 100644
--- a/libavformat/caf.c
+++ b/libavformat/caf.c
@@ -49,6 +49,7 @@ const AVCodecTag ff_codec_caf_tags[] = {
{ AV_CODEC_ID_QCE
do it. H264SEI should
store the content of the last parsed SEI, other code should not mess
with it.
The right thing to do is maintain a copy of x264_build in H264Context.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
t output buffer */
> frame->nb_samples = unp_size / (avctx->channels * (bits + 1));
> +if (unp_size % (avctx->channels * (bits + 1))) {
> +av_log(avctx, AV_LOG_ERROR, "unp_size %d is odd\n", unp_size);
> +return AVERROR(EINVAL);
> + }
The
p; !(pkt->flags & AV_PKT_FLAG_KEY)) &&
> >> !ost->copy_initial_nonkeyframes)
> >> return;
> >
> > This doesn't initialize all AVPacket fields.
>
> I can throw in a { 0 } if you like it better :)
Stab. It's not a question of "liking", there are correct things to do
and incorrect things to do. So do the correct thing.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting wm4 (2017-05-26 20:03:07)
> On Fri, 26 May 2017 19:30:40 +0200
> Anton Khirnov wrote:
>
> > Quoting Luca Barbato (2017-05-23 22:08:49)
> > > On 5/17/17 7:46 PM, Vittorio Giovara wrote:
> > > > +av_channel_layout_uninit(dst);
> >
Quoting Vittorio Giovara (2017-05-22 22:05:55)
> On Sat, May 20, 2017 at 7:57 AM, Anton Khirnov wrote:
> > The default logging callback in lavu currently contains several
> > "advanced" features, such as
> > - suppressing repeated messages
> > - automatica
Quoting Mark Thompson (2017-05-26 01:37:21)
> On 21/05/17 09:46, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-05-14 23:24:11)
> >> +
> >> +start = end = 6;
> >> +for (i = 0; i < count; i++) {
> >> +size = AV_RB16(d
Quoting Mark Thompson (2017-05-26 00:46:09)
> On 20/05/17 07:35, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-05-14 23:24:10)
> >> +int ff_cbs_insert_unit(CodedBitstreamContext *ctx,
> >> + CodedBitstreamFragment *frag,
> >> +
The commit message could use more detail, it's not entirely obvious why
this is the correct thing to do.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
leak memory if you forget.
I am against this. Freeing memory should be explicit.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+ CodedBitstreamUnit *unit)
> +{
> +BitstreamContext bc;
> +int err;
> +
> +err = bitstream_init(&bc, unit->data, 8 * unit->data_size);
> +if (err < 0)
> +return err;
> +
> +switch (unit->type) {
> +case H264_NAL_SPS:
> +{
> +H264RawSPS *sps;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +return AVERROR(ENOMEM);
> +err = cbs_h264_read_sps(ctx, &bc, sps);
> +if (err < 0) {
> +av_free(sps);
> +return err;
> +}
> +
> +cbs_h264_replace_sps(ctx, sps);
Should probably check the return value. Same below.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Hendrik Leppkes (2017-05-20 21:20:58)
> On Sat, May 20, 2017 at 9:15 PM, Anton Khirnov wrote:
> > Quoting Martin Storsjö (2017-05-20 20:28:35)
> >> On Sat, 20 May 2017, Anton Khirnov wrote:
> >>
> >> > The default logging callback in lavu curr
Quoting Martin Storsjö (2017-05-20 20:28:35)
> On Sat, 20 May 2017, Anton Khirnov wrote:
>
> > The default logging callback in lavu currently contains several
> > "advanced" features, such as
> > - suppressing repeated messages
> > - automatically h
It is not a public header and has not been used since
10173c0e58e557582dbd659f42c6aa164a8682db
---
avtools/cmdutils.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/avtools/cmdutils.c b/avtools/cmdutils.c
index b0445eb..a19df30 100644
--- a/avtools/cmdutils.c
+++ b/avtools/cmdutils.c
@@ -47
The default logging callback in lavu currently contains several
"advanced" features, such as
- suppressing repeated messages
- automatically hiding the log prefix
- color support
They add significant complexity to the logging callback and - more
importantly - global state, making logging not thread
---
libavutil/log.h | 9 +++--
libavutil/version.h | 3 +++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavutil/log.h b/libavutil/log.h
index ce00bcc..0fc8b9c 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -249,15 +249,12 @@ void av_log_default_callback(void *av
1 - 100 of 8923 matches
Mail list logo
