---
doc/APIchanges | 3 +++
libavutil/cpu.c | 13 +
libavutil/cpu.h | 13 +
libavutil/version.h | 2 +-
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index c161618..acd1536 100644
--- a/doc/APIchanges
+++ b/doc
Nothing guarantees that the line is large enough for two blocks, so
current code may result in invalid memory access. This change makes the
function ~5% slower, but since this is a highly obscure filter that
nobody should use, its performance is not very important.
---
libavfilter/x86/vf_interlace
Quoting wm4 (2017-02-08 12:08:18)
> On Wed, 8 Feb 2017 11:50:58 +0100
> Anton Khirnov wrote:
>
> > This will avoid every caller from hardcoding some specific alignment,
> > which may break in the future with new instruction sets.
> > ---
>
> > * @param f
tx->device = (AVHWDeviceContext*)avctx->hw_device_ctx->data;
> +ctx->hwctx = ctx->device->hwctx;
> +
> +if (ctx->device->type != AV_HWDEVICE_TYPE_VAAPI) {
> +av_log(avctx, AV_LOG_ERROR, "Device supplied for VAAPI "
>
allback because
> AVCodecContext.hw_frames_ctx is no longer user-accessible.
>
>
> avconv_vaapi.c | 145
> +++--
> 1 file changed, 6 insertions(+), 139 deletions(-)
So much code eliminated, nice.
Pat
Quoting Vittorio Giovara (2017-02-08 14:40:45)
> On Wed, Feb 8, 2017 at 5:50 AM, Anton Khirnov wrote:
> > This will avoid every caller from hardcoding some specific alignment,
> > which may break in the future with new instruction sets.
> > ---
> > doc/APIchanges
gt; return av_dict_set(dict, key, hex, 0);
> --
> 2.9.2
Looks very unsafe. Just pass the buffer size as a function parameter.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
27;d merge it tomorrow, not into figuring out what makes that
> combination of compiler and vm upset with that specific filter.
I don't see any specific system mentioned in what you're changing. Are
you just disabling that test completely? That looks just wrong.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
&& avctx->codec->priv_class)
> av_opt_free(avctx->priv_data);
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 2ade539..a6eda6a 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -28,7
> return AVERROR(EINVAL);
> }
>
> -if ((ret = dict_set_bin(&hls->enc_opts, "iv", hls->iv)) < 0)
> +if ((ret = dict_set_bin(&hls->enc_opts, "iv", hls->iv, hls->iv_len))
> < 0)
> return ret;
> }
>
> --
> 2.9.2
Looks ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
UNT; i++)
> ff_h264_unref_picture(h, &h->DPB[i]);
> --
> 2.9.3
Looks good to me, but I'd appreciate Janne's opinion as well.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Anton Khirnov (2017-02-08 11:51:00)
> Nothing guarantees that the line is large enough for two blocks, so
> current code may result in invalid memory access. This change makes the
> function ~5% slower, but since this is a highly obscure filter that
> nobody should use, its pe
Currently it incorrectly compares bits with bytes.
Also, move the check right before where it's relevant, so that the
correct number of remaining bits is used.
CC: libav-sta...@libav.org
---
libavcodec/svq3.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec
280, 0xe316fec3
> +0, -9600, -9600,0, 185280, 0x6344ec88
> +0, -8800, -8800,0, 185280, 0xe0aa6de4
> +0, -8000, -8000,0, 185280, 0x6cfc8687
> +0, -7200, -7200,0, 185280, 0x
@@ static void write_packet(OutputFile *of, AVPacket *pkt,
> OutputStream *ost)
> ost->packets_written++;
>
> pkt->stream_index = ost->index;
> -av_packet_rescale_ts(pkt, ost->mux_timebase, ost->st->time_base);
>
> ret = av_interl
_rb32(pb);
> -if (size > atom.size)
> +if (size <= 12 || size > atom.size)
> return AVERROR_INVALIDDATA;
>
> tag = avio_rl32(pb);
> --
> 2.10.0
The first hunk looks ok, but the second one is strange? Why specifically
that check. I see a bunch of s
+projection = AV_SPHERICAL_CUBEMAP;
> +break;
> +default:
> +return 0;
> +}
> +
> +spherical = av_spherical_alloc(&spherical_size);
> +if (!spherical)
> +return AVERROR(ENOMEM);
&
ile->width + left_bound + right_bound;
> + * original_height = tile->height + top_bound + bottom_bound;
> + * @endcode
> + *
> + * @note These values are valid only for the tiled equirectangular
> + * projection type (@ref AV_SPHERICAL_EQUIRECT
if (val)
> +sc->spherical->left_bound = strtol(val, NULL, 10);
> +val = av_stristr(buffer, "");
> +if (val)
> +sc->spherical->top_bound = strtol(val, NULL, 10);
> +val = av_stristr(buffer, "");
> +
le changed, 6 insertions(+), 1 deletion(-)
Both patches queued, thanks.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
penh264dec.c | 144
>
> 1 file changed, 25 insertions(+), 119 deletions(-)
>
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+ FFMIN((jobnr + 1) * slice_h,
> frame->height);
> int i, j, plane;
>
> for (plane = 1; plane < 3; plane++) {
> --
> 2.10.1 (Apple Git-78)
Looks good, thanks for the fix.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
This error is treated specially by the API.
CC: libav-sta...@libav.org
---
libavcodec/aacdec.c | 6 +++---
libavcodec/nvenc.c | 8 +---
libavcodec/qsv.c| 8 +---
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 22ebcdc..7
Quoting wm4 (2017-02-17 07:33:14)
> On Thu, 16 Feb 2017 17:34:30 +0100
> Anton Khirnov wrote:
>
> > This error is treated specially by the API.
> >
> > CC: libav-sta...@libav.org
> > ---
> > libavcodec/aacdec.c | 6 +++---
> > libavcodec/nvenc
Quoting Vittorio Giovara (2017-02-15 17:34:52)
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> This should hopefully be a better fix for the undetected interlaced
> samples I reported a couple of days ago.
> Vittorio
LG
Quoting John Stebbins (2017-02-18 14:25:53)
> On 02/10/2017 02:33 AM, Anton Khirnov wrote:
> > Quoting John Stebbins (2017-02-08 22:52:28)
> >> ---
> >> libavcodec/h264dec.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> &
ecs.c
index 46c42c5..ae829f4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -68,6 +68,7 @@ void avcodec_register_all(void)
/* hardware accelerators */
REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
+REGISTER_HWACCEL(H264_CUVID,h264_cuvid);
reference to the newly created AVHWDeviceContext on success or
> NULL
> --
> 2.11.0
Would you mind adding a function for enumerating available device types
while you're at it? I can imagine that being quite useful to some
callers.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
av_add_index_entry(st, asf->first_packet_offset +
> asf->packet_size *
> --
> 2.9.3
LGTM.
Should be backported to stable as well.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
return AVERROR_INVALIDDATA;
> --
> 2.10.1
It's very much non-obvious what exactly does this fix and how, and why
this specific fix is the right way to do it.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting wm4 (2017-02-19 14:48:36)
> On Sun, 19 Feb 2017 11:09:49 +0100
> Anton Khirnov wrote:
>
> > Some parts of the code are based on a patch by
> > Timo Rothenpieler
> > ---
> > Compared to the ffmpeg patch which implements cuvid as a separate decoder
>
OPENCL_FRAME_* flags.
> + */
> +intflags;
> +/**
> + * If AV_OPENCL_FRAME_IMAGE2D_FROM_BUFFER is set in flags, this contains
> + * the OpenCL buffer object from which all of the plane images were
> + * created.
> + */
> +cl_mem source_buffer;
> +} AVOpenCLFrameDescriptor;
> +
> +/**
> + * OpenCL device details.
> + *
> + * Allocated as AVHWDeviceContext.hwctx
> + */
> +typedef struct AVOpenCLDeviceContext {
> +/**
> + * The platform ID of the device.
> + */
> +cl_platform_id platform_id;
Can't you query this from the device?
More comments later.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
enum AVPixelFormat **formats)
> +{
> +enum AVPixelFormat *fmts;
> +
> +fmts = av_malloc_array(2, sizeof(*fmts));
> +if (!fmts)
> +return AVERROR(ENOMEM);
> +
> + fmts[0] = hwfc->sw_format;
> +fmts[1] = AV_PIX_FMT_NONE;
Quoting Mark Thompson (2017-03-07 23:02:26)
> On 07/03/17 20:42, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-03-05 00:57:47)
> >> ---
> >> configure |5 +-
> >> doc/APIchanges |4 +
> >> libavutil/
device_get_type_name(enum AVHWDeviceType type);
> +
> +/**
> + * Iterate over supported device types.
> + *
> + * @param type AV_HWDEVICE_TYPE_NONE initially, then the previous type
> + * returned by this function in subsequent iterations.
> + * @return The next usable device type from enum AVHWDeviceType.
> + */
Better mention explicitly that TYPE_NONE is returned at the end.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
xt.h | 26 +
> libavutil/hwcontext_internal.h | 8 ++
> 3 files changed, 99 insertions(+)
>
LGTM.
Assuming apichanges+bump will be added before pushing.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
http
= av_frame_alloc();
> +if (!output)
> +return AVERROR(ENOMEM);
> +
> +output->format = output_format;
> +
> +err = av_hwframe_transfer_data(output, input, 0);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to transfer data to "
> +
(@ref AV_SPHERICAL_CUBEMAP), and should be ignored in all other
> * cases.
> */
> -size_t padding;
> +uint32_t padding;
> } AVSphericalMapping;
>
> /**
> --
> 2.12.0
I'm not against this change, but as this is an ABI break, it sho
Quoting Luca Barbato (2017-03-15 13:40:03)
> JACK is not commonly installed and should not be picked up as a
> dependency unless specifically requested.
As this is a user-visible behaviour change, I'd say it should be
mentioned in the changelog.
--
An
ons(+), 163 deletions(-)
> delete mode 100644 avtools/avconv_vdpau.c
No further comments on patches 04-07
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
The function currently accepts a PutBitContext and a GetBitContext,
which hardcodes their sizes into the lavc ABI. Since the function is
quite small and only called in a few places, the simplest solution is
making it inline, thus avoiding a runtime dependency completely.
---
To be applied on major
Quoting Diego Biurrun (2017-03-16 17:42:42)
> On Thu, Mar 16, 2017 at 05:34:12PM +0100, Anton Khirnov wrote:
> > The function currently accepts a PutBitContext and a GetBitContext,
> > which hardcodes their sizes into the lavc ABI. Since the function is
> > quite small and
a2} or @samp{vaapi}) and then
> deriving a
> +QSV device from that.)
> +
> +@end table
> +
> +@item -init_hw_device @var{type}[=@var{name}]@@@var{source}
> +Initialise a new hardware device of type @var{type} called @var{name},
> +deriving it from the existing device
> 14:06 #libav-devel: <@elenril> woudln't it be more natural to propagate EOFs
> from one filter to the next as the happen, instead of flushing each one
> separately?
>
> Different approach doing that. Preferable?
Yes, this looks better to me.
--
Anton Khirnov
No further comments from me on this set, feel free to push.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Make the current semi-public avpriv_ac3_parse_header() private to lavc.
---
libavcodec/Makefile| 6 ++--
libavcodec/ac3_parser.c| 35 --
libavcodec/ac3_parser.h| 13 +++-
libavcodec/{ac
AMPLE_FMT_NONE (which currently is -1).
I do not think this is a good idea. The number of places using literal
-1 is quite large and that's just inside libav. There's no telling how
many callers do this, and the change would silently break them, while
the benefits from it are IMO not
Quoting wm4 (2017-03-30 17:08:26)
> On Thu, 30 Mar 2017 16:56:28 +0200
>
> Why have this when we have a wonderful parser API?
This is a probe function, we don't want to allocate a whole parser in
it.
--
Anton Khirnov
___
libav-deve
hanged, 46 insertions(+), 24 deletions(-)
>
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-03-05 00:57:37)
> ---
> libavcodec/qsvenc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
Looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/li
Quoting Mark Thompson (2017-03-05 00:57:36)
> ---
> libavcodec/qsvdec.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.or
x, int flags);
> +int (*map_frames_from)(AVHWFramesContext *dst_ctx,
> +AVHWFramesContext *src_ctx, int
> flags);
Wouldn't derive_frames_foo be more appropriate?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
* @param flags Some combination of AV_HWFRAME_MAP_* flags, defining the
> + * mapping parameters to apply to frames which are allocated
> + * in the derived device.
> * @return Zero on success, negative AVERROR code on failure.
This is strictly speaking an API change, so perhaps an APIchanges entry
and a micro bump are appropriate.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
if (inlink->hw_frames_ctx) {
> hwfc = (AVHWFramesContext*)inlink->hw_frames_ctx->data;
>
> +if (ctx->derive_device_type) {
> +enum AVHWDeviceType type;
> +
> +type = av_hwdevice_find_type_by_name(ctx->derive_device_type);
>
Quoting wm4 (2017-03-30 17:25:50)
> On Thu, 30 Mar 2017 17:06:00 +0200
> Anton Khirnov wrote:
>
> > Quoting wm4 (2017-03-28 12:43:04)
> > > I propose that AV_PIX_FMT_NONE is changed from -1 to 0. The reason is
> > > that default-initializing an AVPix
= src->sw_pix_fmt;
>
> dst->coded_width = src->coded_width;
> dst->coded_height = src->coded_height;
> --
> 2.11.0
LGTM as well
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
} else {
> + h = m;
> +s->yb++;
> +}
> +}
> +
> +s->nb_blocks = s->xb * s->yb;
At this point nothing guarantees that nb_blocks is non-zero (if
avctx->width/height are unset or too small), so that needs to be
checked.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ssion, &s->impl);
> +if (err == MFX_ERR_NONE)
> +err = MFXQueryVersion(hwctx->session, &s->ver);
> +if (err != MFX_ERR_NONE) {
> +av_log(ctx, AV_LOG_ERROR, "Error querying the session attributes: "
> + "%d\n", err);
> +ret = AVERROR_UNKNOWN;
> +goto fail;
> +}
> +
> +
This is duplicated with init, perhaps it should be shared somehow?
nit: extra empty line
Otherwise looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
, flags);
> +if (ret == AVERROR(ENOSYS))
> +ret = 0;
So if I'm reading this correctly, av_hwframe_ctx_init() is now never
called, even for cases where it used to be. What's the deal with that?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-04-02 20:43:54)
> On 02/04/17 11:13, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-03-05 00:57:39)
> >> Some frames contexts are not usable without additional format-specific
> >> state in hwctx. This adds new functions map_frames_fro
Quoting Mark Thompson (2017-04-02 20:37:13)
> On 31/03/17 20:14, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-03-05 00:57:40)
> >> Use the flags argument of av_hwframe_ctx_create_derived() to pass the
> >> mapping flags which will be used on allocation. Al
ef struct HEVCContext {
> int bs_height;
>
> int is_decoded;
> +int no_rasl_output_flag;
>
> HEVCPredContext hpc;
> HEVCDSPContext hevcdsp;
> --
> 2.11.1
Eh? This seems to be write-only.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
> >> to replicate this behaviour in libav, in my opinion.
> >
> > We could add a function that returns size for this and every other
> > similar struct, even if they already have an alloc function that
> > also returns the struct size like Spherical
i_time_scale= avctx->time_base.den;
> }
>
> -vseq->intra_period = ctx->p_per_i * (ctx->b_per_p + 1);
> -vseq->intra_idr_period = vseq->intra_period;
> +vseq->intra_period = avctx->gop_size;
> +
Inlining public functions hardcodes their implementation into the ABI,
so it should be avoided unless there is a very good reason for it. No
such reason exists in this case.
---
libavutil/mem.c | 14 ++
libavutil/mem.h | 14 ++
2 files changed, 16 insertions(+), 12 deletion
ream code will break. API breaks are
> > not the same as ABI breaks.
>
> I know the difference between ABI and API. What I meant is that I consider
> us still in API breaking season.
There never is an API breaking season. During a major bump we
1) break the
Avoids unnecessary allocs+copies and makes the code slightly simpler.
---
libavcodec/vp9_superframe_bsf.c | 49 -
1 file changed, 19 insertions(+), 30 deletions(-)
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index 869d7d4.
---
libavcodec/vp9_raw_reorder_bsf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vp9_raw_reorder_bsf.c b/libavcodec/vp9_raw_reorder_bsf.c
index 7f00f5f..fca1264 100644
--- a/libavcodec/vp9_raw_reorder_bsf.c
+++ b/libavcodec/vp9_raw_reorder_bsf.c
@@ -205,6 +205,7 @@ static int
---
libavcodec/vp9_superframe_bsf.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index be83ba3..869d7d4 100644
--- a/libavcodec/vp9_superframe_bsf.c
+++ b/libavcodec/vp9_superframe_bsf
his parameter when they require a hardware device. Note that
> this
> +is typically only required when the input is not already in hardware frames -
> +when it is, filters will derive the device they require from the context of
> the
> +frames they receive as input.
> +
> +This is a global setting, so all filters will receive the same device.
> +
Maybe mention that this is a (hopefully) temporary thing and people
shouldn't rely on this option in scripts and such.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Mark Thompson (2017-03-05 00:57:43)
> ---
> libavutil/hwcontext_qsv.c | 122
> +++---
> 1 file changed, 93 insertions(+), 29 deletions(-)
>
LGTM
--
Anton Khirnov
___
libav-devel mai
Quoting Anton Khirnov (2017-04-28 11:06:42)
> Quoting Mark Thompson (2017-03-05 00:57:43)
> > ---
> > libavutil/hwcontext_qsv.c | 122
> > +++---
> > 1 file changed, 93 insertions(+), 29 deletions(-)
> >
>
> LG
t which will require it to be set.
> ---
> map_frames_to/from renamed to frames_derive_to/from.
>
>
> libavutil/hwcontext.c | 9 -
> libavutil/hwcontext_internal.h | 5 +
> 2 files changed, 13 insertions(+), 1 deletion(-
Quoting Mark Thompson (2017-04-23 21:21:05)
> Factorises out existing surface initialisation code to reuse.
> ---
> No change.
>
>
> libavutil/hwcontext_qsv.c | 174
> +-
> 1 file changed, 142 insertions(+), 32 deletions(
ld be done more consistently, but actually
> every use is slightly different so the crazy casts are staying for now.
>
>
> libavutil/hwcontext_qsv.c | 88
> +--
> 1 file changed, 86 insertions(+), 2 deletions
d to do this themselves.
> ---
> Added APIchanges + version bump.
>
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
utput_format vaapi
> -i in.mp4 -an -vf
> 'deinterlace_vaapi,scale_vaapi=1280:720,hwmap=derive_device=qsv,format=qsv'
> -c:v h264_qsv -b 5M -maxrate 5M out.mp4
>
>
> libavfilter/vf_hwmap.c | 67
> --
> 1 file changed
bjections, other than "i wish it was possible to do this in a
more sane way".
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
GetBitContext *gb,
> > + int bits)
> > +
> > +static av_always_inline int ff_copy_pce_data(PutBitContext *pb,
> > GetBitContext *gb)
>
> Anton, is there a specific reason to have this as av_always_inline instead
&
Quoting Mark Thompson (2017-04-28 15:06:33)
> On 28/04/17 10:00, Anton Khirnov wrote:
> >
> > Maybe mention that this is a (hopefully) temporary thing and people
> > shouldn't rely on this option in scripts and such.
>
> Not really sure how to express that sentime
Quoting Mark Thompson (2017-04-26 22:49:01)
> This was left over from an earlier version which created the new
> packet inside the current frame structure. Now it just leaks an
> unused packet, so remove the allocation entirely.
> ---
> On 26/04/17 10:41, Anto
Quoting Diego Biurrun (2017-04-26 12:33:53)
> On Wed, Apr 26, 2017 at 11:41:49AM +0200, Anton Khirnov wrote:
> > ---
> > libavcodec/vp9_superframe_bsf.c | 22 --
> > 1 file changed, 12 insertions(+), 10 deletions(-)
>
> I have this locally alrea
HEVCSEIPictureHash should store only the information extracted from the
bitstream and exported to the higher layer (the decoder or the parser).
The MD5 context is allocated, used and freed by this higher layer, so it
makes more sense for it to also be stored there.
---
libavcodec/hevc_sei.h | 3 -
depending on
> > + * the channel order.
> > + *
> > + * - For AV_CHANNEL_ORDER_CUSTOM: each element signals the
> > presence of
> > + * the AVChannel with the corresponding value: eg. when map[i] is
> > + * equa
es Almer
> > ---
> > configure | 10 +-
> > libavcodec/Makefile | 8
> > 2 files changed, 9 insertions(+), 9 deletions(-)
>
> Not against. Anton?
Sure, fine with me
--
Anton Khirnov
__
thing else on part of it), the @option{hwmap} filter can be used again
> +in the next mode to retrieve them.
retrieve _it_, or alternatively 'original hardware frames_s_' above
Otherwise LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ompression_level > attr.value) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid compression level: "
> + "valid range is 0-%d.\n", attr.value);
> +err = AVERROR(EINVAL);
It looks a bit strange to me that this branch fails, while the case
where vaapi doesn't support this option continues.
Otherwise looks fine.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+for (i = 0; i < sctx->nb_d3d11_views; i++) {
> +if (sctx->d3d11_views[i])
> +ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
> +}
> +av_free(sctx->d3d11_views);
nit: av_freep() looks safer he
Quoting wm4 (2017-05-13 12:44:01)
> On Sat, 13 May 2017 12:09:45 +0200
> Anton Khirnov wrote:
>
> > Generally looks good, though I'm not very familiar with this hwaccel.
> > Are you planning to deprecate the old-style hwaccels?
>
> I would, but that's not
Quoting Mark Thompson (2017-05-14 23:24:07)
> Same as f64d1100a54d12c78ce436181bb64229c56da6b3, for stream copy
> rather than encode.
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/li
Currently it does not work at all.
Bug-Id: 1058
---
Sorry, I have no idea what I was thinking when I originally wrote this.
---
libavcodec/decode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 8aa2709..bb58dfc 100644
--
Also drop the notion of active PPS/SPS from H264ParamSets.
This way, encountering new parameter sets that overwrite the old ones,
won't make the active parameters sets suddenly disappear while the
decoder is not done using them.
---
libavcodec/dxva2_h264.c | 10 +++---
libavcodec/h264_cabac
Those SEIs refer to the currently active SPS. However, since the SEI
NALUs precede the coded picture data in the bitstream, the active SPS is
in general not known when we are decoding the SEI.
Therefore, store the content of the picture timing SEIs and actually
parse it when the active SPS is know
It represents the relationship between them more naturally and will be
useful in the following commits.
---
libavcodec/h264_ps.c| 29 +
libavcodec/h264_ps.h| 2 ++
libavcodec/h264_slice.c | 4 ++--
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git
This tells the parsing functions the payload size and prevents them from
overreading.
---
libavcodec/h264_sei.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 17f89ce..2e52227 100644
--- a/libavcodec
t
you can use it as a generic stream analyzer, which this API is very much
not suited for. So just don't.
2) libavcodec is not a place that should do IO directly. The users don't
expect it, so it might even be a security issue in some cases. I know
some other code does it, but those are IM
eof(*frag->units));
If I'm reading right, units themselves need to be uninited, so reallocp
is not what you want here.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
if (au->units[i].type == H264_NAL_SEI ||
> +au->units[i].type == H264_NAL_SLICE ||
> +au->units[i].type == H264_NAL_IDR_SLICE)
> +break;
> + }
> +sei_pos = i;
> +
> +if (sei_pos < au->nb_units &&
> +
RawSPS {
> +uint8_t forbidden_zero_bit;
> +uint8_t nal_ref_idc;
> +uint8_t nal_unit_type;
Wouldn't it be better to aggegate those into a struct?
In case we want to add support for various crap like MVC later.
--
Anton Khirnov
; return
> av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
> -sizeof(*hwctx->surfaces), NULL, 0, 0);
> + sizeof(*hwctx->surfaces),
> dxva2_pool_release_dummy, 0, 0);
> }
>
> return NUL
201 - 300 of 8906 matches
Mail list logo
