Quoting Diego Biurrun (2016-12-19 13:11:24)
> On Mon, Dec 19, 2016 at 12:57:23PM +0100, Anton Khirnov wrote:
> > Quoting Diego Biurrun (2016-12-06 23:15:48)
> > > On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote:
> > > > On Tue, Dec 6, 2016 at
range can now be simply considered a boolean.
> >
> > Signed-off-by: Vittorio Giovara
>
>
> I don't like this. You can assume this in the code if you want to, but
> it should be possible to export the difference between unsignaled and
>
e range, i sthat the data type correctly
> >> reflects the only two states in which the range can be found.
> >
> > Undefined is a perfectly valid state in my book.
>
> The problem is that the range is never undefined, or when undefined it
> is assumed to be limited. This is true in several BT specifications
> for example.
This is simply not true. When there is no information about the range,
it is undefined. We should simply make this fact clear to the caller and
leave him to deal with it. We should not invent arbitrary assumptions
and force them upon the caller.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
gt; libav/src/libavcodec/
I agree with Nicolas here, having to type one more dir level to get to
the actual files is highly annoying, and I see no real gain in this.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting wm4 (2016-12-20 16:02:20)
> On Mon, 19 Dec 2016 13:04:38 +0100
> Anton Khirnov wrote:
>
> > Quoting Steve Lhomme (2016-12-16 11:05:40)
> > > From: Steve Lhomme
> > >
>
> > > +ZeroMemory(&texDesc, sizeof(texDesc));
> >
&g
Quoting Vittorio Giovara (2016-12-19 13:18:13)
> On Mon, Dec 19, 2016 at 1:02 PM, Anton Khirnov wrote:
> > Quoting Vittorio Giovara (2016-12-19 10:11:29)
> >> I have a couple of points about this, in random order:
> >>
> >> 1. I had thought agreement was
(depending
> on when configure was run) deps on minor and micro lib versions is incorrect
> AFAICT. If somebody has a different opinion, now is the time to speak up.
That sounds wrong to me. Dynamically linking against an earlier minor
version than the one we built against is likely to fail.
---
libavcodec/vp3.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 26374cc..cb8925b 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -1983,6 +1983,7 @@ static int vp3_decode_frame(AVCodecContext *avctx,
---
libavcodec/hevc_parser.c | 6 --
libavcodec/hevc_ps.c | 33 -
libavcodec/hevc_ps.h | 2 --
libavcodec/hevc_refs.c | 19 ---
libavcodec/hevcdec.c | 7 ---
libavcodec/hevcdec.h | 2 --
6 files changed, 24 insertions(+)
It is not called from outside h264dec.c anymore.
---
libavcodec/h264dec.c | 4 ++--
libavcodec/h264dec.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 54ded03..e111d40 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264d
new world order.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
The current condition can trigger in cases where it shouldn't, with
unexpected results.
Make sure that:
- container cropping is really based on the original dimensions from the
caller
- those dimenions are discarded on size change
The code is still quite hacky and eventually should be deprecated
Extend the width/height doy to clarify that it should store coded
values.
---
doc/APIchanges | 4
libavutil/frame.c | 4
libavutil/frame.h | 28 +++-
libavutil/version.h | 2 +-
4 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/doc/APIcha
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 -
libavco
Cropping parameters are already checked for validity during SPS parsing,
no need to check them again.
---
libavcodec/h264_slice.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index db7628c..1b35c2b 100644
--- a/libavcodec/h
---
libavcodec/h264_ps.c| 9 -
libavcodec/h264_slice.c | 21 +++--
libavcodec/h264dec.c| 26 +++---
libavcodec/h264dec.h| 5 +
4 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
Section 9.2.3.2 of the spec implies that run_before must not be larger
than zeros_left.
Fixes invalid reads with corrupted files.
CC: libav-sta...@libav.org
Bug-Id: 1000
Found-By: Kamil Frankowicz
---
libavcodec/h264_cavlc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --g
The code does some nontrivial jumping around in the buffer, so it is
safer to use a checked API rather than do everything manually.
Fixes a bug in nalff parsing, where the length field is currently not
counted in the buffer size check, resulting in possible overreads with
invalid files.
CC: libav
If a read fails, current code will free the data, but leave the size
non-zero. Make sure the size is zeroed in such a case.
CC: libav-sta...@libav.org
Bug-Id: 1001
Found-By: Kamil Frankowicz
---
libavformat/matroskadec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/liba
It might be incorrectly set to 1 if the previous call exited with an
error.
CC: libav-sta...@libav.org
---
libavcodec/h264dec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 54ded03..c308274 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec
i_encode.c | 78
> +--
> libavcodec/vaapi_encode.h | 4 +--
> 2 files changed, 36 insertions(+), 46 deletions(-)
>
Looks reasonable
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ecContext *avctx,
> if (err < 0)
> return err;
> activity = 1;
> +break;
This could use more explanation.
Otherwise looks ok.
--
Anton Khirnov
___
libav-devel mail
->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 ||
>
t; 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
>
> 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
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
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 con
11VA_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
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-accel
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 inv
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
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/A
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, c
The current condition can trigger in cases where it shouldn't, with
unexpected results.
Make sure that:
- container cropping is really based on the original dimensions from the
caller
- those dimenions are discarded on size change
The code is still quite hacky and eventually should be deprecated
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 | 27 +++
libavcodec/decode.c| 117 -
libav
---
libavcodec/h264_ps.c| 9 -
libavcodec/h264_slice.c | 21 +++--
libavcodec/h264dec.c| 26 +++---
libavcodec/h264dec.h| 5 +
4 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
---
libavcodec/vp3.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 26374cc..cb8925b 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -1983,6 +1983,7 @@ static int vp3_decode_frame(AVCodecContext *avctx,
Only minor changes since last time, mainly clarifying the behaviour with hwaccel
and typo fixes.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Extend the width/height doxy to clarify that it should store coded
values.
---
doc/APIchanges | 4
libavutil/frame.c | 4
libavutil/frame.h | 28 +++-
libavutil/version.h | 2 +-
4 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/doc/APIch
---
libavcodec/hevc_parser.c | 6 --
libavcodec/hevc_ps.c | 33 -
libavcodec/hevc_ps.h | 2 --
libavcodec/hevc_refs.c | 19 ---
libavcodec/hevcdec.c | 7 ---
libavcodec/hevcdec.h | 2 --
6 files changed, 24 insertions(+)
Quoting wm4 (2017-01-10 10:26:53)
> On Tue, 10 Jan 2017 09:01:12 +0100
> Anton Khirnov wrote:
>
> > The current condition can trigger in cases where it shouldn't, with
> > unexpected results.
> > Make sure that:
> > - container cropping is really bas
---
libavcodec/x86/mpegvideoenc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/x86/mpegvideoenc.c b/libavcodec/x86/mpegvideoenc.c
index 47349d1..ead2ed1 100644
--- a/libavcodec/x86/mpegvideoenc.c
+++ b/libavcodec/x86/mpegvideoenc.c
@@ -28,7 +28,12 @@
---
libavcodec/zmbvenc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 4436bb3..dd62ce5 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -54,16 +54,18 @@ typedef struct ZmbvEncContext {
int
Avoid global state.
---
libavcodec/mpegaudiodec_template.c | 3 +-
libavcodec/mpegaudiodsp.c | 2 -
libavcodec/mpegaudiodsp.h | 7 +-
libavcodec/mpegaudiodsp_template.c | 218 +
libavcodec/x86/mpegaudiodsp.c | 12 +-
5 files changed
Avoid global state.
---
libavcodec/aarch64/mpegaudiodsp_init.c | 4 +-
libavcodec/arm/mpegaudiodsp_init_arm.c | 2 +-
libavcodec/mpc.c | 5 -
libavcodec/mpc.h | 1 -
libavcodec/mpc7.c | 1 -
libavcodec/mpc8.c
---
configure | 2 +-
libavcodec/aaccoder.c | 4 ++--
libavcodec/aacenc.c | 4 ++--
libavcodec/aacenc.h | 4 ++--
libavcodec/aic.c| 2 +-
libavcodec/amrnbdata.h | 4 ++--
libavcodec/amrwbdata.h | 4 ++-
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to
This is a constant codec property, so a capability flag is more appropriate.
---
doc/multithreading.txt | 5 +++--
libavcodec/h264dec.c | 4 +---
libavcodec/hevcdec.c | 3 +--
libavcodec/internal.h | 20 +---
libavcodec/mimic.c | 3 +--
libavcodec/m
Quoting Diego Biurrun (2017-01-10 16:37:42)
> On Tue, Jan 10, 2017 at 03:42:34PM +0100, Anton Khirnov wrote:
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3174,12 +3174,6 @@ typedef struct AVCodec {
> > * @{
> > */
> >
Quoting wm4 (2017-01-11 08:08:49)
> On Tue, 10 Jan 2017 15:42:33 +0100
> Anton Khirnov wrote:
>
> > This is a constant codec property, so a capability flag is more appropriate.
> > ---
> > doc/multithreading.txt | 5 +++--
> > libavcodec/h264dec.c |
Quoting wm4 (2017-01-10 10:29:53)
> On Tue, 10 Jan 2017 09:01:09 +0100
> Anton Khirnov wrote:
>
> > /**
> > - * width and height of the video frame
> > + * @name Video dimensions
> > + * Video frames only. The coded dimensions (in pixels) of the
Quoting Diego Biurrun (2017-01-10 12:58:04)
> On Tue, Jan 10, 2017 at 11:12:09AM +0100, Anton Khirnov wrote:
> > ---
> > configure | 2 +-
> > libavcodec/aaccoder.c | 4 ++--
> > libavcodec/aacenc.c | 4 ++--
> > lib
Quoting Vittorio Giovara (2017-01-10 13:18:46)
> On Tue, Jan 10, 2017 at 11:12 AM, Anton Khirnov wrote:
> > ---
> > libavcodec/zmbvenc.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
>
> This makes the codec FF_CODEC_CAP_INIT_THREADS
Quoting Diego Biurrun (2017-01-11 10:43:56)
> On Wed, Jan 11, 2017 at 10:16:55AM +0100, Anton Khirnov wrote:
> > Quoting wm4 (2017-01-11 08:08:49)
> > > On Tue, 10 Jan 2017 15:42:33 +0100
> > > Anton Khirnov wrote:
> > > > --- a/doc/multithreading.t
the latter -- while
those codecs are not in the top ten, they are not obscure game codecs
either. At least some of them certainly are routinely used.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/lis
e923e 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2015-08-28
>
> API changes, most recent first:
>
> +2017-xx-xx - xxx - lavc 58.xx.x - avcodec.h
> + Change scale of AVCodecContext.global_quality.
This could be a bit more
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
Ok
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
-)
>
Looks ok.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Diego Biurrun (2017-01-11 18:10:07)
> From: Alexandra Hájková
>
> ---
> libavformat/mov.c| 10 ++
> libavformat/movenc.c | 41 +
> 2 files changed, 27 insertions(+), 24 deletions(-)
>
O
aders; ++i) {
> -data->au_headers[i].size = get_bits_long(&getbitcontext,
> data->sizelength);
> -data->au_headers[i].index = get_bits_long(&getbitcontext,
> data->indexlength);
> +data->au_headers[i].size = bitstream_read(&bctx, data->s
Quoting Martin Storsjö (2017-01-13 10:55:55)
> On Fri, 13 Jan 2017, Anton Khirnov wrote:
>
> > Quoting Diego Biurrun (2017-01-11 18:10:08)
> >> From: Alexandra Hájková
> >>
> >> ---
> >> libavformat/rtpdec_h261.c | 19 ++--
---
avprobe.c| 2 +-
libavformat/avidec.c | 4 ++--
libavformat/dashenc.c| 4 ++--
libavformat/flac_picture.c | 4 ++--
libavformat/hdsenc.c | 4 ++--
libavformat/mpjpegdec.c | 2 +-
libavformat/rdt.c|
Before this commit, AVIOContext is to be freed with a plain av_free(),
which prevents us from adding any deeper structure to it.
---
doc/APIchanges| 3 +++
libavformat/avio.h| 8
libavformat/aviobuf.c | 17 ++---
libavformat/version.h | 4 ++--
4 files changed,
won't old versions of the driver misbehave?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
uses_superframe_syntax) && !s->n_cache) {
> +// passthrough
> +av_packet_move_ref(out, in);
> +goto done;
> +} else if (s->n_cache + 1 >= MAX_CACHE) {
> +av_log(ctx, AV_LOG_ERROR,
> + "Too many invisible frames");
> +
Quoting wm4 (2017-01-13 12:09:23)
> On Fri, 13 Jan 2017 12:04:36 +0100
> Anton Khirnov wrote:
>
> > Before this commit, AVIOContext is to be freed with a plain av_free(),
> > which prevents us from adding any deeper structure to it.
> > ---
> > doc/APIchanges
Quoting Hendrik Leppkes (2017-01-13 12:16:16)
> On Fri, Jan 13, 2017 at 10:04 PM, Anton Khirnov wrote:
> > Before this commit, AVIOContext is to be freed with a plain av_free(),
> > which prevents us from adding any deeper structure to it.
>
> avio_close(p) already c
1570,7 +1574,10 @@ int ff_nvenc_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
> }
>
> +nvel->cu_ctx_push_current(ctx->cu_context);
> enc_ret = nv->nvEncEncodePicture(ctx->nvenc_ctx, ¶ms);
> +nvel->cu_ctx_pop_current(&dummy);
What about all the other nvenc calls? Is this documented anywhere?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ame, frame->refresh_frame_flags);
> +
> +ctx->next_frame = frame;
> +}
> +
> +for (s = 0; s < FRAME_SLOTS; s++) {
> +if (!(frame->refresh_frame_flags & 1 << s))
nit: I'd prefer parentheses around (4 << s)
> +continue;
> +if (ctx->slot[s] && ctx->slot[s]->needs_display &&
> +ctx->slot[s]->slots == 1 << s) {
> +// We are overwriting this slot, which is last reference
> +// to the frame previously present in it. In order to be
> +// a valid stream, that frame must already have been
> +// displayed before the pts of the current frame.
> +err = vp9_reorder_make_output(bsf, out, ctx->slot[s]);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to create "
> + "output overwriting slot %d: %d.\n",
> + s, err);
> +// Clear the slot anyway, so we don't end up
> +// in an infinite loop.
> +vp9_reorder_clear_slot(ctx, s);
> +return AVERROR_INVALIDDATA;
> +}
> +return 0;
> +}
> +vp9_reorder_clear_slot(ctx, s);
> +}
> +
> +for (s = 0; s < FRAME_SLOTS; s++) {
> +if (!(frame->refresh_frame_flags & 1 << s))
> +continue;
> +ctx->slot[s] = frame;
> +}
> +frame->slots = frame->refresh_frame_flags;
> +
> +if (!frame->refresh_frame_flags) {
> +err = vp9_reorder_make_output(bsf, out, frame);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to create output "
> + "for transient frame.\n");
> +ctx->next_frame = NULL;
> +return AVERROR_INVALIDDATA;
> +}
> +if (!frame->needs_display)
> +ctx->next_frame = NULL;
> +return 0;
> +}
> +
> +ctx->next_frame = NULL;
> +return AVERROR(EAGAIN);
> +
> +fail:
> +vp9_reorder_frame_free(&frame);
> +return err;
> +}
A very general observation I have is that this function has many exit
points so that it's hard to follow what happens.
But I don't have any specific suggestions how to improve that, so feel
free to ignore this comment.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Diego Biurrun (2017-01-11 18:09:58)
> From: Alexandra Hájková
>
> ---
> libavcodec/alac.c | 65
> ---
> 1 file changed, 33 insertions(+), 32 deletions(-)
>
Ok.
--
Anton Khirnov
Quoting Luca Barbato (2017-01-16 21:39:12)
> On 13/01/2017 16:38, Luca Barbato wrote:
> > On 13/01/2017 15:16, Anton Khirnov wrote:
> >> What about all the other nvenc calls? Is this documented anywhere?
> >
> > It is not documented and before I assumed that t
sconf->coef_table = get_bits(&gb, 2);
> -sconf->long_term_prediction = get_bits1(&gb);
> -sconf->max_order= get_bits(&gb, 10);
> -sconf->block_switching = get_bits(&gb, 2);
> -sconf->bgmc = get_bits1(&g
de 100644 libavcodec/vaapi_encode_vp9.c
>
I guess this will need to be update for the new global_quality
replacement, but otherwise looks good.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Diego Biurrun (2017-01-11 18:10:00)
> From: Alexandra Hájková
>
> ---
> libavcodec/apedec.c | 47 ---
> 1 file changed, 24 insertions(+), 23 deletions(-)
>
Looks ok.
--
Anton Khirnov
___
Quoting Diego Biurrun (2017-01-11 18:10:01)
> From: Alexandra Hájková
>
> ---
> libavcodec/dxtory.c | 88
> ++---
> 1 file changed, 44 insertions(+), 44 deletions(-)
LGTM
--
Anton Khirnov
___
Quoting Mark Thompson (2017-01-21 23:10:54)
> On 13/01/17 11:07, Anton Khirnov wrote:
> > Quoting Mark Thompson (2017-01-10 00:47:55)
> >> ---
> >> The i965 driver has been updated so that this works consistently.
> >>
> >> libavcodec/vaapi_
Quoting Luca Barbato (2017-01-26 12:42:26)
> It glitches with the stale travis linux target.
I have no idea what that means.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
that avconv does not set the
bit_rate field in certain situations. If that's the case, that should be
fixed in avconv. We should not design our muxer behaviour around
limitations of one specific caller.
If you describe more fully what's the situation where bit_rate is not
set properly, I migh
Quoting Peter Große (2017-01-27 20:16:31)
> On Fri, 27 Jan 2017 19:34:42 +0100
> Anton Khirnov wrote:
>
> > If we did, I don't remember the conclusion :)
> >
> > Anyway, I agree that this is a misuse of metadata. There are at least
> > two methods for p
In this mode it tells the muxer about the bitrate of the input stream.
---
avconv.c| 3 +++
avconv.h| 5 +
avconv_opt.c| 11 +++
doc/avconv.texi | 7 +++
4 files changed, 26 insertions(+)
diff --git a/avconv.c b/avconv.c
index fe60625..94b6da2 100644
--- a/a
to use for decoding a
> + * particular section of the stream. Any previous value in the field
> + * must be unreferenced before being overwritten.
This is somewhat vague. Unreferenced by whom? The wording implies by the
caller, which contradicts the above statement that the reference is
owned by the decoder. Again, I think it'd be best to move those refs to
private hidden places and then just optionally update them with the
caller-provided values.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
This is a constant codec property, so a capability flag is more appropriate.
---
doc/multithreading.txt | 5 +++--
libavcodec/h264dec.c | 5 ++---
libavcodec/hevcdec.c | 5 ++---
libavcodec/internal.h | 20 +---
libavcodec/mimic.c | 3 +--
libavcode
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to
This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.
---
libavcodec/pthread_frame.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 7d98be7
This is fragile and dangerous, allocate separate private data for each
per-thread context.
---
libavcodec/pthread_frame.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index d4a3406..12d5481 100644
-
Currently the frame pool used by the default get_buffer2()
implementation is a single struct, allocated when opening the decoder.
A pointer to it is simply copied to each frame thread and we assume that
no thread attempts to modify it at an unexpected time. This is rather
fragile and potentially da
---
libavcodec/decode.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index d5210d0..44cab68 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -923,8 +923,10 @@ static int update_frame_pool(AVCodecContext *avctx,
AV
Use the AVFrame API to properly allocate and free frames for delayed
release.
---
libavcodec/pthread_frame.c | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index cbd409d..7d98be7
Current code is excessively complicated and hard to read. Use the same
logic as in the HEVC decoder, augmented with detection of insufficient
delay.
---
libavcodec/h264_picture.c | 2 +-
libavcodec/h264_refs.c| 18 +
libavcodec/h264_slice.c | 185 --
It is never modified anymore.
---
libavcodec/h264_ps.h| 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_ps.h b/libavcodec/h264_ps.h
index 9a32d93..1b482f3 100644
--- a/libavcodec/h264_ps.h
+++ b/libavcodec/h264_ps.h
@@ -136,
Video decoders always consume full packets.
---
libavcodec/h264dec.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 6ce0287..a68a9ad 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -628,19
---
libavcodec/h264dec.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index b92795d..6ce0287 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -699,10 +699,7 @@ static int h264_decode_frame(AVCodecContext *avctx,
This is no longer done automatically for filters marked as
hwframe-aware.
---
libavfilter/vf_scale_npp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
index 0e636a9..be1f81f 100644
--- a/libavfilter/vf_scale_npp.
Quoting Vittorio Giovara (2017-02-01 10:44:11)
> On Wed, Feb 1, 2017 at 10:25 AM, Anton Khirnov wrote:
> > Video decoders always consume full packets.
> > ---
> > libavcodec/h264dec.c | 20 +++-
> > 1 file changed, 3 insertions(+), 17 deletio
Quoting Vittorio Giovara (2017-02-01 10:47:21)
> On Wed, Feb 1, 2017 at 10:15 AM, Anton Khirnov wrote:
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index b27aa54..771520b 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
>
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
uint32_t? Sizes should have size_t as type.
Your size_t obsession is getting out of control. It makes sense for some
places, but not all of them. As is rather obvious from the patch, the
size is stored as uint32 in the bitstream, therefore it makes sense to
store it as uint32 in code.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
This will avoid every caller from hardcoding some specific alignment,
which may break in the future with new instruction sets.
---
doc/APIchanges | 4
libavutil/frame.c | 4
libavutil/frame.h | 4 +++-
libavutil/version.h | 2 +-
4 files changed, 12 insertions(+), 2 deletions(-)
---
libavfilter/x86/vf_interlace.asm | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavfilter/x86/vf_interlace.asm b/libavfilter/x86/vf_interlace.asm
index f234421..7302314 100644
--- a/libavfilter/x86/vf_interlace.asm
+++ b/libavfilter/x86/v
---
libavcodec/utils.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2978109..06a5784 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -179,17 +179,10 @@ int ff_side_data_update_matrix_encoding(AVFrame *fram
101 - 200 of 8906 matches
Mail list logo
