---
doc/bitstream_filters.texi | 3 +++
libavcodec/Makefile| 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/null_bsf.c | 44 ++
4 files changed, 49 insertions(+)
create mode 100644 libavcodec/null_bsf.c
diff --git a/doc/b
---
libavcodec/Makefile | 1 +
libavcodec/decode.c | 924
libavcodec/utils.c | 889 --
3 files changed, 925 insertions(+), 889 deletions(-)
create mode 100644 libavcodec/decode.c
diff --git a/
The current code stores a pointer to the packet passed to the decoder,
which is then used during get_buffer() for timestamps and side data
passthrough. However, since this is a pointer to user data which we do
not own, storing it is potentially dangerous. It is also ill defined for
the new decoding
Drop the internal manual conversion from the MP4 format to Annex B.
---
libavcodec/qsvdec_h2645.c | 74 +++
1 file changed, 11 insertions(+), 63 deletions(-)
diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index a26f150..8ac403b 10064
---
doc/examples/decode_audio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/examples/decode_audio.c b/doc/examples/decode_audio.c
index e7b27d3..d952b49 100644
--- a/doc/examples/decode_audio.c
+++ b/doc/examples/decode_audio.c
@@ -179,6 +179,11 @@ int main(int argc, char **argv)
_header(AVFormatContext * s)
> {
> --
> 2.1.4
This is incredibly silly IMO. Unused function parameters are very common
and are NOT a problem (which is why they are not enabled by default).
Shuffling perfectly valid code around just to appease some specific
compiler with some specifi
Quoting Diego Biurrun (2016-11-22 15:32:03)
> On Tue, Nov 22, 2016 at 02:36:37PM +0100, Anton Khirnov wrote:
> > Drop the internal manual conversion from the MP4 format to Annex B.
> > ---
> > libavcodec/qsvdec_h2645.c | 74
> > +++-
Quoting Vittorio Giovara (2016-11-22 17:03:43)
> On Tue, Nov 22, 2016 at 8:36 AM, Anton Khirnov wrote:
> > +
> > +int ff_alloc_packet(AVPacket *avpkt, int size)
> > +{
> > +if (size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
> > +return AVERROR(EIN
Quoting Diego Biurrun (2016-11-22 15:17:22)
> On Tue, Nov 22, 2016 at 02:36:31PM +0100, Anton Khirnov wrote:
> > ---
> > doc/bitstream_filters.texi | 3 +++
> > libavcodec/Makefile| 1 +
> > libavcodec/bitstream_filters.c | 1 +
> > li
UBEMAP)
> +probe_str("projection", "cubemap");
> +else
> +probe_str("projection", "unknown");
> +
> +probe_object_header("orientation");
> +
as reported by James.
> Vittorio
>
> Changelog | 1 +
> libavformat/isom.h | 6 ++
> libavformat/mov.c | 304
> +
> 3 files changed, 311 insertions(+)
LGTM
--
Anton Khirnov
2_t roll; ///< Counter-clockwise rotation around the forward vector
> [-180, 180].
> +/**
> + * @}
> + */
> +
> + /**
> + * @name Bounding rectangle
> + * @{
> + * These fields are the amount of pixels to crop from the edge
> + * of
Quoting Diego Biurrun (2016-11-23 09:23:10)
> On Wed, Nov 23, 2016 at 09:15:06AM +0100, Anton Khirnov wrote:
> > Quoting Diego Biurrun (2016-11-22 15:17:22)
> > > On Tue, Nov 22, 2016 at 02:36:31PM +0100, Anton Khirnov wrote:
> > > > ---
> > >
Quoting Diego Biurrun (2016-11-14 16:01:43)
> On Mon, Nov 14, 2016 at 12:11:47PM +0100, Anton Khirnov wrote:
> > Quoting Diego Biurrun (2016-11-14 11:58:34)
> > > On Mon, Nov 14, 2016 at 11:40:22AM +0100, Anton Khirnov wrote:
> > > > Quoting Diego Biurrun (2016-11
---
libavcodec/tta.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/libavcodec/tta.c b/libavcodec/tta.c
index 2b57406..2ac8255 100644
--- a/libavcodec/tta.c
+++ b/libavcodec/tta.c
@@ -35,6 +35,7 @@
#include "avcodec.h"
#include "get_bits.h"
#include "internal
---
libavcodec/tta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/tta.c b/libavcodec/tta.c
index 2ac8255..5532580 100644
--- a/libavcodec/tta.c
+++ b/libavcodec/tta.c
@@ -360,7 +360,7 @@ static int tta_decode_frame(AVCodecContext *avctx, void
*data,
}
> ---
> Should be backported to release/12.
Pushed, thanks
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Only allow the decoding thread to run while the user is inside a lavc
decode call (avcodec_send_packet/receive_frame).
Hardware decoding APIs are often not thread-safe, so having the user
access decoded hardware surfaces while the decoder is running in another
thread can cause failures (this is mai
Quoting Janne Grunau (2016-11-25 00:17:17)
> On 2016-11-24 19:19:59 +0100, Anton Khirnov wrote:
> > Only allow the decoding thread to run while the user is inside a lavc
> > decode call (avcodec_send_packet/receive_frame).
> > Hardware decoding APIs are often not thread-saf
Quoting Anton Khirnov (2016-11-24 19:19:59)
> Only allow the decoding thread to run while the user is inside a lavc
> decode call (avcodec_send_packet/receive_frame).
> Hardware decoding APIs are often not thread-safe, so having the user
> access decoded hardware surfaces while th
Quoting James Almer (2016-11-25 03:02:30)
> On 3/19/2016 1:02 PM, Anton Khirnov wrote:
> > Quoting Luca Barbato (2016-03-07 09:10:14)
> >> On 07/03/16 08:59, Luca Barbato wrote:
> >>> On 04/03/16 09:15, Anton Khirnov wrote:
> >>>> --
essing: "
> + "%d (%s).\n", vas, vaErrorStr(vas));
> +err = AVERROR(EIO);
> +goto fail_after_render;
> +}
> +
> +if (ctx->hwctx->driver_quirks &
> +AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS) {
> +vas = vaDestroyBuffer(ctx->hwctx->display, params_id);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to free parameter buffer: "
> + "%d (%s).\n", vas, vaErrorStr(vas));
> +// And ignore.
> +}
> +}
> +
> +av_frame_copy_props(output_frame, input_frame);
This needs an error check.
> +
> +av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
> + av_get_pix_fmt_name(output_frame->format),
> + output_frame->width, output_frame->height, output_frame->pts);
> +
> +return ff_filter_frame(outlink, output_frame);
> +
> +fail_after_begin:
> +vaRenderPicture(ctx->hwctx->display, ctx->va_context, ¶ms_id, 1);
> +fail_after_render:
> +vaEndPicture(ctx->hwctx->display, ctx->va_context);
> +fail:
> +if (filter_params_addr)
> +vaUnmapBuffer(ctx->hwctx->display, ctx->filter_buffer);
> +av_frame_free(&output_frame);
> +return err;
> +}
> +
> +static av_cold int deint_vaapi_init(AVFilterContext *avctx)
> +{
> +DeintVAAPIContext *ctx = avctx->priv;
> +
> +ctx->va_config = VA_INVALID_ID;
> +ctx->va_context= VA_INVALID_ID;
> +ctx->filter_buffer = VA_INVALID_ID;
> +
> +return 0;
> +}
> +
> +static av_cold void deint_vaapi_uninit(AVFilterContext *avctx)
> +{
> +DeintVAAPIContext *ctx = avctx->priv;
> +
> +deint_vaapi_pipeline_uninit(avctx);
> +
> +av_buffer_unref(&ctx->input_frames_ref);
> +av_buffer_unref(&ctx->output_frames_ref);
> +av_buffer_unref(&ctx->device_ref);
> +}
> +
> +#define OFFSET(x) offsetof(DeintVAAPIContext, x)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM)
> +static const AVOption deint_vaapi_options[] = {
> +{ "mode", "Deinterlacing mode",
> + OFFSET(mode), AV_OPT_TYPE_INT, { .i64 = VAProcDeinterlacingBob },
We might want to use one of the fancier algorithms by default. Also,
docs would be nice.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ded_frame->pts != AV_NOPTS_VALUE)
> -ist->next_dts = decoded_frame->pts;
> +ist->next_dts = av_rescale_q(decoded_frame->pts, ist->st->time_base,
> AV_TIME_BASE_Q);
> else if (pkt && pkt->pts != AV_NOPTS_VALU
mplete
frames. If at the point where parse_nal_units() is called we do not have
a complete frame then something went wrong and this should be reported
or handled somehow.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lis
Quoting Mark Thompson (2016-11-29 10:52:20)
> On 29/11/16 09:07, Anton Khirnov wrote:
> > Quoting Mark Thompson (2016-11-25 00:27:11)
> >> ---
> >> Tested somewhat on Skylake GT2 and Polaris 11; on both it comes up with
> >> something which looks pretty pl
ck = avctx->framerate.den;
> +vseq->vui_time_scale= avctx->framerate.num;
> } else {
> vseq->vui_num_units_in_tick = avctx->time_base.num;
> vseq->vui_time_scale= avctx->time_base.den;
> --
> 2.10.2
ok
--
A
odec/vaapi_encode.c | 25 +
> libavcodec/vaapi_encode.h | 4
> 2 files changed, 29 insertions(+)
>
Looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
avctx->width, 16);
> +ctx->surface_height = FFALIGN(avctx->height, 16);
> +
> +return ff_vaapi_encode_init(avctx);
> +}
> +
> +#define OFFSET(x) (offsetof(VAAPIEncodeContext, codec_options_data) + \
> + offsetof(VAAPIEncodeVP8Option
of those things, and therefore it's pretty much trivial if we only
> support P frames. (That does also mean that the result is atrocious,
> so this is mainly a curiosity for now.)
I suppose it's much faster than libvpx, so it can still be rather
useful.
--
Anton Khirnov
_
Quoting Mark Thompson (2016-11-29 23:48:19)
> ---
> On 29/11/16 11:50, Anton Khirnov wrote:
> > Either one is fine with me. I guess picking the higher numbered might be
> > a little safer since it will also work in implementations that don't
> > support motion-adap
ol_size = 64;
> frames_hwctx->frame_type = MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
>
> ret = av_hwframe_ctx_init(ist->hw_frames_ctx);
> --
> 2.9.2
I think at this point we should just add an avconv option for setting
the pool
Partially based on code by Ronald S. Bultje .
---
doc/bitstream_filters.texi| 4 +
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c| 1 +
libavcodec/vp9_superframe_split_bsf.c | 146 ++
4 files changed, 152 insert
The current code stores a pointer to the packet passed to the decoder,
which is then used during get_buffer() for timestamps and side data
passthrough. However, since this is a pointer to user data which we do
not own, storing it is potentially dangerous. It is also ill defined for
the new decoding
Drop the internal manual conversion from the MP4 format to Annex B.
---
libavcodec/qsvdec_h2645.c | 74 +++
1 file changed, 11 insertions(+), 63 deletions(-)
diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index a26f150..8ac403b 10064
Significantly increases the efficiency of frame threading, since
individual frames in a superframe can now be decoded in parallel.
---
configure| 2 +-
libavcodec/vp9.c | 74 ++--
2 files changed, 14 insertions(+), 62 deletions(-)
diff
It is useful for testing/debugging and will also be used as the default
filter in the following commit adding pre-decode filtering to avoid
having a separate non-filtered codepath.
---
doc/bitstream_filters.texi | 3 +++
libavcodec/Makefile| 1 +
libavcodec/bitstream_filters.c |
Currently, the new decoding API is pretty much just a wrapper around the
old deprecated one. This is problematic, since it interferes with making
full use of the flexibility added by the new API. The old API should
also be removed at some future point.
Reorganize the code so that the new send_pack
---
configure | 1 +
libavcodec/avcodec.h | 6 ++
libavcodec/decode.c | 163 ++
libavcodec/decode.h | 2 +
libavcodec/internal.h | 6 ++
libavcodec/utils.c| 3 +
6 files changed, 169 insertions(+), 12 deletions(-)
diff
It is more natural for this codec and allows to avoid awkward constructs
like "consuming 0 bytes from input". Also, keep a reference to the input
packet to avoid unnecessary copying.
---
libavcodec/binkaudio.c | 58 --
1 file changed, 32 insertions(+
also converted binkaudio to the new API, mainly as a proof of concept. I
think eventually we should covert all the decoders consuming partial packets to
the new API, to avoid various associated ambiguities. Since it only concerns
several audio decoders, it should be doable.
--
Anton Kh
hread_mutex_lock(&p->parent->buffer_mutex);
> --
> 2.8.0.rc3.226.g39d4020
Did you see any measurable change in performance after this patch?
I used to have lot more explicit memory orders in my original version of
the patch, but then I dropped most of them, since I thought they
ecoder modify the input buffer?
And I asked you multiple times already to stop just citing warnings as
justifications for such patches. A warning may or may not be a symptom
of a problem in the code. What you should be fixed is that underlying
problem, not the warning itself.
PNMContext * const s = avctx->priv_data;
> AVFrame * const p= data;
> --
> 2.1.4
Again, how is it "inappropriate"? The input packet must not be modified
by the decoder, so buf being const is perfectly appropriate.
--
Anton Khirnov
___
t's a question for Anton, he added that option back in 2011.
Well, I only added it to replace the stuff in AVFormatParameters. But
for what my opinion here is worth (never used this device), if this
option is just for the obsolete library version then it didn't even
exist for any modern build
c.h) old, obsolete and unmaintained gcc versions. Why even
bother?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
libavcodec/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 0b44bb6..5350eb8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1186,6 +1186,9 @@ static int get_audio_frame_duration(enum AVCodecID id,
int sr, int ch, int ba
Quoting Diego Biurrun (2016-11-27 17:32:33)
> From: Alexandra Hájková
>
> ---
> libavcodec/imc.c | 45 +++--
> 1 file changed, 23 insertions(+), 22 deletions(-)
Ok
--
Anton Khirnov
___
liba
ibavcodec/indeo5.c | 127 +
> libavcodec/ivi.c| 71 ---
> libavcodec/ivi.h| 11 ++--
> 6 files changed, 206 insertions(+), 196 deletions(-)
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@
Quoting Diego Biurrun (2016-11-27 17:32:35)
> From: Alexandra Hájková
>
> ---
> libavcodec/lagarith.c| 22 +++---
> libavcodec/lagarithrac.c | 12 ++--
> libavcodec/lagarithrac.h | 6 --
> 3 files changed, 21 insertions(+), 19 deletions(-)
Quoting Diego Biurrun (2016-11-27 17:32:36)
> From: Alexandra Hájková
>
> ---
> libavcodec/metasound.c | 44 ++--
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
Ok
--
Anton Khirnov
_
Quoting Diego Biurrun (2016-11-27 17:32:37)
> From: Alexandra Hájková
>
> ---
> libavcodec/mimic.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
Ok
--
Anton Khirnov
___
libav-devel mailin
---
libavcodec/h263dec.c | 2 +-
libavcodec/h264dec.c | 2 +-
libavcodec/pthread_frame.c | 27 +++
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index e4a7227..921ff5f 100644
--- a/libavcodec/h263de
This makes sure ff_get_format() does not get called unnecessarily from
update_thread_context().
---
libavcodec/hevcdec.c | 49 ++---
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 9dd86c2
Certain hardware decoding APIs are often not thread-safe, so having the user
access decoded hardware surfaces while the decoder is running in another
thread can cause failures (this is mainly known to happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is in
Quoting Diego Biurrun (2016-12-06 23:20:45)
> On Sat, Dec 03, 2016 at 05:34:34PM +0100, Anton Khirnov wrote:
> > --- /dev/null
> > +++ b/libavcodec/hwaccel.h
> > @@ -0,0 +1,24 @@
> > +#ifndef AVCODEC_HWACCEL_H
> > +#define AVCODEC_HWACCEL_H
> > +
> >
Quoting Diego Biurrun (2016-11-25 21:57:54)
> From: Alexandra Hájková
>
> ---
>
> Rebased on top of Anton's tta cleanup.
>
> libavcodec/tta.c | 44 ++--
> 1 file changed, 22 insertions(+), 22 deletions(-)
ping
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
I know ...
>
> > Also, the middle field there should be a VA_RT_FORMAT (I suggest using the
> > macro).
>
> I know ...
>
> Yet that's the way (TM), Intel examples are using to support hevc
> encoding + vaapi...
>
> If you have better ideas I'm all ea
Quoting Luca Barbato (2016-12-12 16:01:18)
> On 12/12/2016 13:09, Anton Khirnov wrote:
> > Quoting Luca Barbato (2016-12-10 19:29:44)
> >> On 10/12/2016 18:44, Mark Thompson wrote:
> >>> Um, what? The internet thinks that P208 is a YUV 4:2:2 two-plane format
&g
---
libavcodec/h263dec.c | 2 +-
libavcodec/h264dec.c | 2 +-
libavcodec/pthread_frame.c | 35 +++
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index e4a7227..921ff5f 100644
--- a/libavcode
Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the
Quoting Luca Barbato (2016-12-02 22:01:11)
> Matches h263.
And? I don't see how that implies that this is the correct thing to do.
The h264 decoder does not invoke the parser, so it should not depend on
it.
--
Anton Khirnov
___
libav-devel
; h->short_ref[0]->f->linesize,
>(const uint8_t **)prev->f->data,
> --
> 2.11.0
Thanks, pushed.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
le hwcontext_d3d11va implementation seems to be missing from this
patch.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
progress[1] using
> atomic_init().
>
> Signed-off-by: Wan-Teh Chang
> ---
> libavcodec/pthread_frame.c | 8 ----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Pushed, thanks.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Derek Buitenhuis (2016-12-14 11:31:30)
> Module: libav
> Branch: master
> Commit: e94b9313b21c3d91a36ef064f7fe3e867616f47f
>
> Author:Derek Buitenhuis
> Committer: Anton Khirnov
> Date: Mon Dec 12 14:33:28 2016 +
>
> fate: Add h264 test for fra
Quoting Anton Khirnov (2016-12-14 11:05:49)
> Quoting Steve Lhomme (2016-12-13 14:19:03)
> > 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
This mapping has nothing to do with decoder implementations, so using
decoder names is wrong.
---
libavdevice/v4l2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 0479121..a8afe8a 100644
--- a/libavdevice/v4l2.c
+++ b/liba
---
Changelog | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index feb151c..ab7f1b6 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,9 @@ releases are sorted from youngest to oldest.
version :
- Support for spherical videos
+- Intel QSV-accelerated VP8 and VC-1 d
Partially based on a patch by Timo Rothenpieler
---
Changelog | 2 +-
configure | 3 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/hevcdec.c | 6 +-
libavcodec/vaapi_decode.c | 1 +
libavcodec/vaapi_hevc.c | 443 +
Quoting Diego Biurrun (2016-12-15 10:58:52)
> On Thu, Dec 15, 2016 at 10:32:09AM +0100, Anton Khirnov wrote:
> > Partially based on a patch by Timo Rothenpieler
> > ---
> > Changelog | 2 +-
> > configure | 3 +
> >
Quoting Diego Biurrun (2016-12-15 12:18:44)
> On Thu, Dec 15, 2016 at 12:03:36PM +0100, Anton Khirnov wrote:
> > Quoting Diego Biurrun (2016-12-15 10:58:52)
> > > On Thu, Dec 15, 2016 at 10:32:09AM +0100, Anton Khirnov wrote:
> > > > Partially based o
From: elenril
---
libavcodec/vaapi_decode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 88bd889..42f03ab 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -306,7 +306,7 @@ static int
Partially based on a patch by Timo Rothenpieler .
Additional scaling list handling fix by Jun Zhao .
---
Changelog | 2 +-
configure | 3 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/hevcdec.c | 6 +-
libavcodec/vaapi
When the input string is too large, so the second condition in if ()
fails, the code will erroneously execute the else branch, indexing the
mac_to_unicode table with a negative index.
CC: libav-sta...@libav.org
Bug-Id: 1000
Found-By: Kamil Frankowicz
---
libavformat/mov.c | 6 +-
1 file chang
CC: libav-sta...@libav.org
Bug-Id: 981
Found-By: Agostino Sarubbo
---
libavcodec/mpegvideo_parser.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 27f2985..500d124 100644
--- a/libavcodec/mpegvideo_par
For field picture, the first_field is set based on its previous value.
Before this commit, first_field is set when reading the picture
coding extension. However, in corrupted files there may be multiple
picture coding extension headers, so the final value of first_field that
is actually used during
CC: libav-sta...@libav.org
Bug-Id: 981
Found-By: Agostino Sarubbo
---
libavcodec/mpeg12dec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 2d9c99d..310169b 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcode
Calling ff_h264_field_end() when the per-field state is not properly
initialized leads to all kinds of undefined behaviour.
CC: libav-sta...@libav.org
Bug-Id: 977 978 992
---
libavcodec/h264_picture.c | 1 +
libavcodec/h264_slice.c | 4 ++--
libavcodec/h264dec.c | 3 ++-
libavcodec/h264dec
---
libavcodec/hevc_parser.c | 4 ++--
libavcodec/hevc_ps.c | 17 +
libavcodec/hevc_refs.c | 17 ++---
libavcodec/hevcdec.c | 1 -
libavcodec/hevcdec.h | 2 --
5 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/li
---
libavcodec/h264_ps.c| 9 -
libavcodec/h264_slice.c | 7 +--
libavcodec/h264dec.c| 24 ++--
3 files changed, 7 insertions(+), 33 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 8a64a33..7ee3876 100644
--- a/libavcodec/h264_p
---
doc/APIchanges | 4
libavutil/frame.c | 2 ++
libavutil/frame.h | 14 ++
libavutil/version.h | 2 +-
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 7633c99..ca95308 100644
--- a/doc/APIchanges
+++ b/doc/APIchang
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 | 26 +
libavcodec/decode.c| 96 ++
libav
It should only be set after the decoder state has been fully initialized
for using that SPS.
Fixes possible invalid reads on get_format() failure.
CC: libav-sta...@libav.org
---
libavcodec/hevcdec.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevcdec.c b/
conflict. See for example 6d3ea1957f681b3bf9c752e6d21a501cc8d4180d or
> > 3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c. While most of the root
> > causes for those incompatibilities have been long resolved, it's still
> > a good practice and relatively harmless to do.
>
> There was this idea of a single version number for all libraries.
> Maybe it's time to revisit it?
I do not think it is a good idea. IMO the libraries should be growing more
separate, not less.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Vittorio Giovara (2016-12-06 06:27:29)
> Deprecated in 05/2014.
> ---
> libavformat/avformat.h | 21 -
> libavformat/version.h | 3 ---
> 2 files changed, 24 deletions(-)
>
Ok
--
Anton Khirnov
___
l
filter/af_channelmap.c
> +++ b/libavfilter/af_channelmap.c
Looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Vittorio Giovara (2016-12-19 10:11:29)
> On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov wrote:
> > ---
> > doc/APIchanges | 4
> > libavutil/frame.c | 2 ++
> > libavutil/frame.h | 14 ++
> > libavutil/version.h | 2 +-
&g
, 136 insertions(+), 132 deletions(-)
>
LGTM
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Vittorio Giovara (2016-12-06 06:27:28)
> Deprecated in 05/2014.
> ---
> libavformat/mux.c | 7 ---
> libavformat/version.h | 3 ---
> 2 files changed, 10 deletions(-)
>
Ok
--
Anton Khirnov
___
libav-devel mailin
g which release number corresponds to
> any given library version.
I don't undertand this argument.
I also do not agree with this change, as I said earlier.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.lib
ctx
> + */
> +typedef struct AVD3D11VAFramesContext {
> +/**
> + * The surface pool. When an external pool is not provided by the caller,
> + * this will be managed (allocated and filled on init, freed on uninit)
> by
> + * libavutil.
> + * When it is provided th
Quoting Hendrik Leppkes (2016-12-18 21:37:44)
> On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov wrote:
> > ---
> > doc/APIchanges | 4
> > libavutil/frame.c | 2 ++
> > libavutil/frame.h | 14 ++
> > libavutil/version.h | 2 +-
> >
Quoting Vittorio Giovara (2016-12-06 06:27:26)
> Deprecated in 04/2013.
> ---
> libavfilter/avfilter.c | 11 ---
> libavfilter/avfilter.h | 18 --
> libavfilter/version.h | 3 ---
> 3 files changed, 32 deletions(-)
Ok
; libavcodec/vc1.c | 2 +-
> libavcodec/vc1_block.c | 2 +-
> libavcodec/wavpack.c | 2 +-
> libavformat/mpc8.c | 3 ++-
> 17 files changed, 27 insertions(+), 24 deletions(-)
>
Quoting Vittorio Giovara (2016-12-06 06:27:30)
> Deprecated in 05/2014.
> ---
> libavformat/mux.c | 11 ---
> libavformat/version.h | 4 +---
> 2 files changed, 1 insertion(+), 14 deletions(-)
>
Ok
--
Anton Khirnov
_
Quoting Vittorio Giovara (2016-12-06 06:27:27)
> Deprecated in 10/2013.
> ---
> libavfilter/avfilter.c | 5 +
> libavfilter/avfilter.h | 5 +
> libavfilter/version.h | 3 ---
> 3 files changed, 2 insertions(+), 11 deletions(-)
>
Quoting Vittorio Giovara (2016-12-06 06:27:25)
> Deprecated in 03/2013.
> ---
> libavfilter/avfilter.c | 7 ---
> libavfilter/avfilter.h | 15 ---
> libavfilter/version.h | 3 ---
> 3 files changed, 25 deletions(-)
Ok
Quoting Vittorio Giovara (2016-12-06 06:27:22)
> This disable everything that was deprecated in the past 18 months,
> with a couple of minor (but sensible) exceptions.
> Postpone any API-incompatible changes until the next bump.
>
> Signed-off-by: Vittorio Giovara
> ---
LGTM
3 ---
> 4 files changed, 58 deletions(-)
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
1 - 100 of 8906 matches
Mail list logo
