Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On 4/30/17, Nicolas George wrote: > Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : >> Are you working on these? Because currently I'm not. > > There is nothing to work on yet: the message you answer to is raising a > question about the global design of the internal API. That question > needs an answer before any work can be done, and I can not decide alone. > How nice, introducing bug that causes crash and then claiming there is not such bug. Which filters you consider deemed worthy to not crash? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
Signed-off-by: Paul B Mahol
---
configure | 2 +
doc/filters.texi| 10 ++
libavfilter/Makefile| 1 +
libavfilter/af_afirfilter.c | 409
libavfilter/allfilters.c| 1 +
5 files changed, 423 insertions(+)
create mode 100644 libavfilter/af_afirfilter.c
diff --git a/configure b/configure
index b3cb5b0..7fc7af4 100755
--- a/configure
+++ b/configure
@@ -3078,6 +3078,8 @@ unix_protocol_select="network"
# filters
afftfilt_filter_deps="avcodec"
afftfilt_filter_select="fft"
+afirfilter_filter_deps="avcodec"
+afirfilter_filter_select="fft"
amovie_filter_deps="avcodec avformat"
aresample_filter_deps="swresample"
ass_filter_deps="libass"
diff --git a/doc/filters.texi b/doc/filters.texi
index 119e747..ea343d1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -878,6 +878,16 @@ afftfilt="1-clip((b/nb)*b,0,1)"
@end example
@end itemize
+@section afirfilter
+
+Apply an Arbitary Frequency Impulse Response filter.
+
+This filter uses second stream as FIR coefficients.
+If second stream holds single channel, it will be used
+for all input channels in first stream, otherwise
+number of channels in second stream must be same as
+number of channels in first stream.
+
@anchor{aformat}
@section aformat
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 66c36e4..1a0f24b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -38,6 +38,7 @@ OBJS-$(CONFIG_AEMPHASIS_FILTER) += af_aemphasis.o
OBJS-$(CONFIG_AEVAL_FILTER) += aeval.o
OBJS-$(CONFIG_AFADE_FILTER) += af_afade.o
OBJS-$(CONFIG_AFFTFILT_FILTER) += af_afftfilt.o window_func.o
+OBJS-$(CONFIG_AFIRFILTER_FILTER) += af_afirfilter.o
OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
OBJS-$(CONFIG_AGATE_FILTER) += af_agate.o
OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
diff --git a/libavfilter/af_afirfilter.c b/libavfilter/af_afirfilter.c
new file mode 100644
index 000..ef2488a
--- /dev/null
+++ b/libavfilter/af_afirfilter.c
@@ -0,0 +1,409 @@
+/*
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * An arbitrary audio FIR filter
+ */
+
+#include "libavutil/audio_fifo.h"
+#include "libavutil/avassert.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+#include "libavcodec/avfft.h"
+
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+
+typedef struct FIRContext {
+const AVClass *class;
+
+int n;
+int eof_coeffs;
+int have_coeffs;
+int nb_taps;
+int fft_length;
+int nb_channels;
+int one2many;
+
+FFTContext *fft, *ifft;
+FFTComplex **fft_data;
+FFTComplex **fft_coef;
+
+AVAudioFifo *fifo[2];
+AVFrame *in[2];
+AVFrame *buffer;
+int64_t pts;
+int hop_size;
+int start, end;
+} FIRContext;
+
+static int fir_filter(FIRContext *s, AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+int start = s->start, end = s->end;
+int ret = 0, n, ch, j, k;
+int nb_samples;
+AVFrame *out;
+
+nb_samples = FFMIN(s->fft_length, av_audio_fifo_size(s->fifo[0]));
+
+s->in[0] = ff_get_audio_buffer(ctx->inputs[0], nb_samples);
+if (!s->in[0])
+return AVERROR(ENOMEM);
+
+av_audio_fifo_peek(s->fifo[0], (void **)s->in[0]->extended_data,
nb_samples);
+
+for (ch = 0; ch < outlink->channels; ch++) {
+const float *src = (float *)s->in[0]->extended_data[ch];
+float *buf = (float *)s->buffer->extended_data[ch];
+FFTComplex *fft_data = s->fft_data[ch];
+FFTComplex *fft_coef = s->fft_coef[ch];
+
+memset(fft_data, 0, sizeof(*fft_data) * s->fft_length);
+for (n = 0; n < nb_samples; n++) {
+fft_data[n].re = src[n];
+fft_data[n].im = 0;
+}
+
+av_fft_permute(s->fft, fft_data);
+av_fft_calc(s->fft, fft_data);
+
+fft_data[0].re *= fft_coef[0].re;
+fft_data[0].im *= fft_coef[0].im;
+for (n = 1; n < s->fft_length; n++) {
+const float re = fft_data[n].re;
+
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On 5/1/17, Muhammad Faiz wrote:
> On Mon, May 1, 2017 at 5:02 AM, Paul B Mahol wrote:
[...]
>> +
>> +for (ch = 0; ch < s->nb_channels; ch++) {
>> +dst = (float *)out->extended_data[ch];
>> +buf = (float *)s->buffer->extended_data[ch];
>> +
>> +for (n = 0; n < s->fft_length; n++)
>> +dst[n] = buf[n];
>> +memmove(buf, buf + s->fft_length, s->fft_length * 4);
>> +}
>
> Is this overlap-save?
>
Yes.
>
>
>> +
>> +ret = ff_filter_frame(outlink, out);
>> +}
>> +
>> +av_audio_fifo_drain(s->fifo[0], s->hop_size);
>> +av_frame_free(&s->in[0]);
>> +
>> +return ret;
>> +}
>> +
>> +static int convert_coeffs(AVFilterContext *ctx)
>> +{
>> +FIRContext *s = ctx->priv;
>> +int ch, n;
>> +
>> +s->nb_taps = av_audio_fifo_size(s->fifo[1]);
>> +if (s->nb_taps > 131072) {
>> +av_log(ctx, AV_LOG_ERROR, "Too big number of taps: %d >
>> 131072.\n", s->nb_taps);
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +for (n = 1; (1 << n) < s->nb_taps; n++);
>> +s->n = n;
>> +s->fft_length = 1 << s->n;
>> +
>> +for (ch = 0; ch < ctx->inputs[0]->channels; ch++) {
>> +s->fft_data[ch] = av_calloc(s->fft_length,
>> sizeof(**s->fft_data));
>> +if (!s->fft_data[ch])
>> +return AVERROR(ENOMEM);
>> +}
>> +
>> +for (ch = 0; ch < ctx->inputs[1]->channels; ch++) {
>> +s->fft_coef[ch] = av_calloc(s->fft_length,
>> sizeof(**s->fft_coef));
>> +if (!s->fft_coef[ch])
>> +return AVERROR(ENOMEM);
>> +}
>> +
>> +s->hop_size = s->nb_taps / 4;
>
> In theory, hop_size should be <= fft_length - nb_taps + 1
Fixed.
>
>
>
>> +if (s->hop_size <= 0) {
>> +av_log(ctx, AV_LOG_ERROR, "Too small number of taps: %d < 4.\n",
>> s->nb_taps);
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +s->buffer = ff_get_audio_buffer(ctx->inputs[0], s->fft_length * 2);
>> +if (!s->buffer)
>> +return AVERROR(ENOMEM);
>> +
>> +s->fft = av_fft_init(s->n, 0);
>> +s->ifft = av_fft_init(s->n, 1);
>> +if (!s->fft || !s->ifft)
>> +return AVERROR(ENOMEM);
>> +
>> +s->in[1] = ff_get_audio_buffer(ctx->inputs[1], s->nb_taps);
>> +if (!s->in[1])
>> +return AVERROR(ENOMEM);
>> +
>> +av_audio_fifo_read(s->fifo[1], (void **)s->in[1]->data, s->nb_taps);
>> +for (ch = 0; ch < ctx->inputs[1]->channels; ch++) {
>> +FFTComplex *fft_coef = s->fft_coef[ch];
>> +const float *re = (const float *)s->in[1]->extended_data[0 +
>> !s->one2many * ch];
>> +const float *im = (const float *)s->in[1]->extended_data[1 +
>> !s->one2many * ch];
>
> What is the meaning of imaginary coeffs in time domain?
Removed.
See new patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/mips: Add missing const qualifiers
Hi!
Attached patch fixes many warnings when compiling for mips.
Please comment, Carl Eugen
From a7d2e32806adef148496454b23b5f8fe12cbf396 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 May 2017 10:31:35 +0200
Subject: [PATCH] lavc/mips/hevc_idct_msa: Add missing const qualifier.
Fixes many warnings:
initialization discards 'const' qualifier from pointer target type
---
libavcodec/mips/hevc_idct_msa.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mips/hevc_idct_msa.c b/libavcodec/mips/hevc_idct_msa.c
index 975d91f..d483707 100644
--- a/libavcodec/mips/hevc_idct_msa.c
+++ b/libavcodec/mips/hevc_idct_msa.c
@@ -330,7 +330,7 @@ static void hevc_idct_4x4_msa(int16_t *coeffs)
static void hevc_idct_8x8_msa(int16_t *coeffs)
{
-int16_t *filter = >8x8_cnst[0];
+const int16_t *filter = >8x8_cnst[0];
v8i16 in0, in1, in2, in3, in4, in5, in6, in7;
LD_SH8(coeffs, 8, in0, in1, in2, in3, in4, in5, in6, in7);
@@ -349,7 +349,7 @@ static void hevc_idct_16x16_msa(int16_t *coeffs)
int16_t buf[256];
int16_t *buf_ptr = &buf[0];
int16_t *src = coeffs;
-int16_t *filter = >16x16_cnst[0];
+const int16_t *filter = >16x16_cnst[0];
v8i16 in0, in1, in2, in3, in4, in5, in6, in7;
v8i16 in8, in9, in10, in11, in12, in13, in14, in15;
v8i16 vec0, vec1, vec2, vec3, vec4, vec5, vec6, vec7;
@@ -429,10 +429,10 @@ static void hevc_idct_8x32_column_msa(int16_t *coeffs,
uint8_t buf_pitch,
uint8_t round)
{
uint8_t i;
-int16_t *filter_ptr0 = >32x32_cnst0[0];
-int16_t *filter_ptr1 = >32x32_cnst1[0];
-int16_t *filter_ptr2 = >32x32_cnst2[0];
-int16_t *filter_ptr3 = >32x32_cnst3[0];
+const int16_t *filter_ptr0 = >32x32_cnst0[0];
+const int16_t *filter_ptr1 = >32x32_cnst1[0];
+const int16_t *filter_ptr2 = >32x32_cnst2[0];
+const int16_t *filter_ptr3 = >32x32_cnst3[0];
int16_t *src0 = (coeffs + buf_pitch);
int16_t *src1 = (coeffs + 2 * buf_pitch);
int16_t *src2 = (coeffs + 4 * buf_pitch);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/mips/iirfilter_mips: Include config.h
Hi! Attached patch fixes a warning when compiling for mips, I suspect it also fixes usage of inline asm. Please comment, Carl Eugen From bbb8a20926b679d05af3b668a2822e6e1a97efa7 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 1 May 2017 10:35:28 +0200 Subject: [PATCH] lavc/mips/iirfilter_mips: Include config.h. Fixes the following warning: libavcodec/mips/iirfilter_mips.c:57:5: warning: "HAVE_INLINE_ASM" is not defined --- libavcodec/mips/iirfilter_mips.c |1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mips/iirfilter_mips.c b/libavcodec/mips/iirfilter_mips.c index 74f036f..3a1352a 100644 --- a/libavcodec/mips/iirfilter_mips.c +++ b/libavcodec/mips/iirfilter_mips.c @@ -52,6 +52,7 @@ * Reference: libavcodec/iirfilter.c */ +#include "config.h" #include "libavcodec/iirfilter.h" #if HAVE_INLINE_ASM -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]compat/strtod: Add missing const qualifiers
Hi!
Even without the casts, the patch reduces the number of warnings shown when
compiling compat/strtod from seven to three.
Please comment, Carl Eugen
From f376877bfabb6fba8f83acab7bd7fb76388d88fd Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 May 2017 10:49:31 +0200
Subject: [PATCH] compat/strtod: Add missing const qualifiers.
Fixes many warnings:
initialization discards 'const' qualifier from pointer target type
---
compat/strtod.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/compat/strtod.c b/compat/strtod.c
index 3a9452e..8b4243b 100644
--- a/compat/strtod.c
+++ b/compat/strtod.c
@@ -25,9 +25,9 @@
#include "libavutil/avstring.h"
#include "libavutil/mathematics.h"
-static char *check_nan_suffix(char *s)
+static const char *check_nan_suffix(const char *s)
{
-char *start = s;
+const char *start = s;
if (*s++ != '(')
return start;
@@ -44,7 +44,7 @@ double strtod(const char *, char **);
double avpriv_strtod(const char *nptr, char **endptr)
{
-char *end;
+const char *end;
double res;
/* Skip leading spaces */
@@ -81,13 +81,13 @@ double avpriv_strtod(const char *nptr, char **endptr)
!av_strncasecmp(nptr, "+0x", 3)) {
/* FIXME this doesn't handle exponents, non-integers (float/double)
* and numbers too large for long long */
-res = strtoll(nptr, &end, 16);
+res = strtoll(nptr, (char **)&end, 16);
} else {
-res = strtod(nptr, &end);
+res = strtod(nptr, (char **)&end);
}
if (endptr)
-*endptr = end;
+*endptr = (char *)end;
return res;
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : fix piz uncompress on big endian
On Sun, Apr 30, 2017 at 05:11:00PM +0200, Martin Vignali wrote: > > > > Tested-by: michael on qemu mips > > > > Ping for apply this patch (and the two fate tests) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/exr : add test for Y, B44A negative, datawindow != display window
Hello, In attach a patch to add fate tests for exr samples can be found here https://we.tl/ItuIX0BMfk and need to be put inside fate-suite/exr can be test with make fate-exr SAMPLES=fate-suite/ Theses tests increase coverage of exr.c : - rgb_b44a_half_negative_4x4 : test negative half value inside B44A bloc (the entire picture is one b44A bloc) - y_tile_zip_half_12x8 and y_scanline_zip_half_12x8 : test the luma only mode in tile and scanline - rgb_scanline_half_piz_dw_t08 : it's one of the official sample for testing datawindow/display window ( https://github.com/openexr/openexr-images/tree/master/DisplayWindow) Test when data window != display window, but data are entirely inside the display window (the rest of the picture is fill with black) Martin 0001-fate-exr-add-test-for-Y-b44A-negative-half-and-dataw.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mips: Add missing const qualifiers
On Mon, May 01, 2017 at 10:34:23AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes many warnings when compiling for mips. > > Please comment, Carl Eugen LGTM, untested though thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/decode: do not treat discarded frames as eof when draining
On Mon, 1 May 2017 07:36:35 +0700
Muhammad Faiz wrote:
> Fix fate failures:
> make fate-mov THREADS=32
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/decode.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index edfae55..e330f14 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -369,7 +369,7 @@ static int decode_simple_internal(AVCodecContext *avctx,
> AVFrame *frame)
> AVPacket *pkt = ds->in_pkt;
> // copy to ensure we do not change pkt
> AVPacket tmp;
> -int got_frame, did_split;
> +int got_frame, actual_got_frame, did_split;
> int ret;
>
> if (!pkt->data && !avci->draining) {
> @@ -431,6 +431,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> }
> emms_c();
> +actual_got_frame = got_frame;
>
> if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> if (frame->flags & AV_FRAME_FLAG_DISCARD)
> @@ -568,8 +569,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> avctx->time_base = av_inv_q(av_mul_q(avctx->framerate,
> (AVRational){avctx->ticks_per_frame, 1}));
> #endif
>
> -/* do not stop draining when got_frame != 0 or ret < 0 */
> -if (avctx->internal->draining && !got_frame) {
> +/* do not stop draining when actual_got_frame != 0 or ret < 0 */
> +/* got_frame == 0 but actual_got_frame != 0 when frame is discarded */
> +if (avctx->internal->draining && !actual_got_frame) {
> if (ret < 0) {
> /* prevent infinite loop if a decoder wrongly always return
> error on draining */
> /* reasonable nb_errors_max = maximum b frames + thread count */
I think that's reasonable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mips/iirfilter_mips: Include config.h
On Mon, May 01, 2017 at 10:37:51AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes a warning when compiling for mips, I suspect it also > fixes usage of inline asm. > > Please comment, Carl Eugen > iirfilter_mips.c |1 + > 1 file changed, 1 insertion(+) > 2c9416e78c7b93db40c774db11b45e14db785eba > 0001-lavc-mips-iirfilter_mips-Include-config.h.patch > From bbb8a20926b679d05af3b668a2822e6e1a97efa7 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Mon, 1 May 2017 10:35:28 +0200 > Subject: [PATCH] lavc/mips/iirfilter_mips: Include config.h. > > Fixes the following warning: > libavcodec/mips/iirfilter_mips.c:57:5: warning: "HAVE_INLINE_ASM" is not > defined LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: Add terse documentation of assumed C implementation defined behavior
On Fri, Apr 28, 2017 at 12:52:45PM +0200, wm4 wrote:
> On Fri, 28 Apr 2017 02:50:42 +0200
> Michael Niedermayer wrote:
>
> > Suggested-by: "Ronald S. Bultje"
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/developer.texi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index dbe1f5421f..a948113792 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -131,6 +131,11 @@ designated struct initializers (@samp{struct s x = @{
> > .i = 17 @};});
> >
> > @item
> > compound literals (@samp{x = (struct s) @{ 17, 23 @};}).
> > +
> > +@item
> > +Implementation defined behavior for signed integers is assumed to match the
> > +expected for Twos complement. Non representable values in integer casts
> > are binary
>
> Patch is ok, but "the expected for Twos complement" sounds a bit weird.
> Maybe "expected behavior"? Also "two's complement".
applied with these modifications
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/http: Ignore expired cookies
On Sun, Apr 30, 2017 at 02:25:29PM -0400, Micah Galizia wrote: > Signed-off-by: Micah Galizia > --- > libavformat/http.c | 213 > +++-- > 1 file changed, 156 insertions(+), 57 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
Hi, On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: > On 4/30/17, Nicolas George wrote: >> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : >>> Are you working on these? Because currently I'm not. >> >> There is nothing to work on yet: the message you answer to is raising a >> question about the global design of the internal API. That question >> needs an answer before any work can be done, and I can not decide alone. >> > > How nice, introducing bug that causes crash and then claiming there is > not such bug. > > Which filters you consider deemed worthy to not crash? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted until API stuff is sorted. This should also be backported to 3.3 because these issues are present in that release. Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
Hi, On Sun, Apr 30, 2017 at 1:16 PM, wm4 wrote: > I think it's probably ok to push your current patch, since the original > author of the patch who broke this probably won't fix it. I don't like the patch because it essentially duplicates the C implementation of the DSP function. If we do that here, are we going to do that everywhere? Will we get 2 DSP functions, aligned and unaligned? I foresee a mess. Michael already said that too, I believe. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
Hi, On Mon, May 1, 2017 at 12:44 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Apr 30, 2017 at 1:16 PM, wm4 wrote: > >> I think it's probably ok to push your current patch, since the original >> author of the patch who broke this probably won't fix it. > > > I don't like the patch because it essentially duplicates the C > implementation of the DSP function. If we do that here, are we going to do > that everywhere? Will we get 2 DSP functions, aligned and unaligned? I > foresee a mess. > > Michael already said that too, I believe. > Let me expand a little bit further: - if we agree that the API does not require alignment, then we should fix the DSP function (and others in other filters) to allow non-aligned or differently-aligned input data. - if not, then the data alignment should be fixed. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: > Hi, > > On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: >> On 4/30/17, Nicolas George wrote: >>> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : Are you working on these? Because currently I'm not. >>> >>> There is nothing to work on yet: the message you answer to is raising a >>> question about the global design of the internal API. That question >>> needs an answer before any work can be done, and I can not decide alone. >>> >> >> How nice, introducing bug that causes crash and then claiming there is >> not such bug. >> >> Which filters you consider deemed worthy to not crash? >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted > until API stuff is sorted. This should also be backported to 3.3 > because these issues are present in that release. > > Kyle Of course no. Reverting it will make more bug. Unless https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html and https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html are also applied. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On 5/1/17, Muhammad Faiz wrote: > On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: >> Hi, >> >> On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: >>> On 4/30/17, Nicolas George wrote: Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : > Are you working on these? Because currently I'm not. There is nothing to work on yet: the message you answer to is raising a question about the global design of the internal API. That question needs an answer before any work can be done, and I can not decide alone. >>> >>> How nice, introducing bug that causes crash and then claiming there is >>> not such bug. >>> >>> Which filters you consider deemed worthy to not crash? >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted >> until API stuff is sorted. This should also be backported to 3.3 >> because these issues are present in that release. >> >> Kyle > > Of course no. Reverting it will make more bug. > > Unless > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html > and > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html > are also applied. One of those are already reviewed, other looks like is not needed at all. Could you elaborate why it is needed? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On Tue, May 2, 2017 at 12:45 AM, Paul B Mahol wrote: > On 5/1/17, Muhammad Faiz wrote: >> On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: >>> Hi, >>> >>> On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: On 4/30/17, Nicolas George wrote: > Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : >> Are you working on these? Because currently I'm not. > > There is nothing to work on yet: the message you answer to is raising a > question about the global design of the internal API. That question > needs an answer before any work can be done, and I can not decide alone. > How nice, introducing bug that causes crash and then claiming there is not such bug. Which filters you consider deemed worthy to not crash? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted >>> until API stuff is sorted. This should also be backported to 3.3 >>> because these issues are present in that release. >>> >>> Kyle >> >> Of course no. Reverting it will make more bug. >> >> Unless >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html >> and >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html >> are also applied. > > One of those are already reviewed, other looks like is not needed at all. > Could you elaborate why it is needed? The code before the patch write to unwritable frame. test-case: ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit [a][b]; [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1]; [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1]; [a1][b1] vstack' the data will be corrupted because fixed=on enables partial_buf_size stuff Compare that without fixed=on. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On 5/1/17, Muhammad Faiz wrote: > On Tue, May 2, 2017 at 12:45 AM, Paul B Mahol wrote: >> On 5/1/17, Muhammad Faiz wrote: >>> On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: Hi, On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: > On 4/30/17, Nicolas George wrote: >> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : >>> Are you working on these? Because currently I'm not. >> >> There is nothing to work on yet: the message you answer to is raising >> a >> question about the global design of the internal API. That question >> needs an answer before any work can be done, and I can not decide >> alone. >> > > How nice, introducing bug that causes crash and then claiming there is > not such bug. > > Which filters you consider deemed worthy to not crash? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted until API stuff is sorted. This should also be backported to 3.3 because these issues are present in that release. Kyle >>> >>> Of course no. Reverting it will make more bug. >>> >>> Unless >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html >>> and >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html >>> are also applied. >> >> One of those are already reviewed, other looks like is not needed at all. >> Could you elaborate why it is needed? > > The code before the patch write to unwritable frame. > > test-case: > ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, > asplit [a][b]; > [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1]; > [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1]; > [a1][b1] vstack' > > the data will be corrupted because fixed=on enables partial_buf_size stuff > > Compare that without fixed=on. Hmm, so it seems Nicolas blocked [1/2] patch which is mandatory for [2/2] one, time without providing alternative solution. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Reviewing merges
On Mon, 24 Apr 2017, wm4 wrote: On Mon, 24 Apr 2017 21:14:15 +0200 (CEST) Marton Balint wrote: On Mon, 24 Apr 2017, Michael Niedermayer wrote: > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote: >> We have recently been able to go through six hundred or so commits in a >> month or two this way after being stuck for the longest time by a few of >> those big API changes. If we start requiring every commit to go through >> a review process on the ML then we will never catch up with the backlog. >> In short, things as they are right now are smooth. Changing it will only >> make this slower. > > Maybe, but is merging more faster also better for FFmpeg ? > I did not analyze the bugs on our bug tracker but subjectivly the > number of regressions seems much larger than a year or 2 ago. > and i just yesterday found 2 issues in a merge (which you fixed) > Yeah, I also have two I recently came across, both caused by the delayed filter initialization patch: https://trac.ffmpeg.org/ticket/6323 https://trac.ffmpeg.org/ticket/6318 Maybe someone more familiar with ffmpeg.c code can take a look? Currently I'm overworked, I can take a look later if you remind me. This is a friendly reminder :) Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On Tue, May 2, 2017 at 1:05 AM, Paul B Mahol wrote: > On 5/1/17, Muhammad Faiz wrote: >> On Tue, May 2, 2017 at 12:45 AM, Paul B Mahol wrote: >>> On 5/1/17, Muhammad Faiz wrote: On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: > Hi, > > On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: >> On 4/30/17, Nicolas George wrote: >>> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : Are you working on these? Because currently I'm not. >>> >>> There is nothing to work on yet: the message you answer to is raising >>> a >>> question about the global design of the internal API. That question >>> needs an answer before any work can be done, and I can not decide >>> alone. >>> >> >> How nice, introducing bug that causes crash and then claiming there is >> not such bug. >> >> Which filters you consider deemed worthy to not crash? >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted > until API stuff is sorted. This should also be backported to 3.3 > because these issues are present in that release. > > Kyle Of course no. Reverting it will make more bug. Unless https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html and https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html are also applied. >>> >>> One of those are already reviewed, other looks like is not needed at all. >>> Could you elaborate why it is needed? >> >> The code before the patch write to unwritable frame. >> >> test-case: >> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, >> asplit [a][b]; >> [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1]; >> [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1]; >> [a1][b1] vstack' >> >> the data will be corrupted because fixed=on enables partial_buf_size stuff >> >> Compare that without fixed=on. > > Hmm, so it seems Nicolas blocked [1/2] patch which is mandatory for [2/2] one, > time without providing alternative solution. The alternative was 383057f8e744efeaaa3648a59bc577b25b055835, of course. I approved it at that time. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
On 5/1/17, Muhammad Faiz wrote: > On Tue, May 2, 2017 at 1:05 AM, Paul B Mahol wrote: >> On 5/1/17, Muhammad Faiz wrote: >>> On Tue, May 2, 2017 at 12:45 AM, Paul B Mahol wrote: On 5/1/17, Muhammad Faiz wrote: > On Mon, May 1, 2017 at 11:22 PM, Kyle Swanson wrote: >> Hi, >> >> On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: >>> On 4/30/17, Nicolas George wrote: Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : > Are you working on these? Because currently I'm not. There is nothing to work on yet: the message you answer to is raising a question about the global design of the internal API. That question needs an answer before any work can be done, and I can not decide alone. >>> >>> How nice, introducing bug that causes crash and then claiming there >>> is >>> not such bug. >>> >>> Which filters you consider deemed worthy to not crash? >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted >> until API stuff is sorted. This should also be backported to 3.3 >> because these issues are present in that release. >> >> Kyle > > Of course no. Reverting it will make more bug. > > Unless > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206285.html > and > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206284.html > are also applied. One of those are already reviewed, other looks like is not needed at all. Could you elaborate why it is needed? >>> >>> The code before the patch write to unwritable frame. >>> >>> test-case: >>> ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, >>> asplit [a][b]; >>> [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1]; >>> [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1]; >>> [a1][b1] vstack' >>> >>> the data will be corrupted because fixed=on enables partial_buf_size >>> stuff >>> >>> Compare that without fixed=on. >> >> Hmm, so it seems Nicolas blocked [1/2] patch which is mandatory for [2/2] >> one, >> time without providing alternative solution. > > The alternative was 383057f8e744efeaaa3648a59bc577b25b055835, of > course. I approved it at that time. This is all one big mess. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Reviewing merges
On 5/1/2017 3:13 PM, Marton Balint wrote: > > On Mon, 24 Apr 2017, wm4 wrote: > >> On Mon, 24 Apr 2017 21:14:15 +0200 (CEST) >> Marton Balint wrote: >> >>> On Mon, 24 Apr 2017, Michael Niedermayer wrote: >>> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote: >>> >> We have recently been able to go through six hundred or so commits >>> in a >>> >> month or two this way after being stuck for the longest time by a >>> few of >>> >> those big API changes. If we start requiring every commit to go >>> through >>> >> a review process on the ML then we will never catch up with the >>> backlog. >>> >> In short, things as they are right now are smooth. Changing it >>> will only >>> >> make this slower. > >>> > Maybe, but is merging more faster also better for FFmpeg ? >>> > I did not analyze the bugs on our bug tracker but subjectivly the >>> > number of regressions seems much larger than a year or 2 ago. >>> > and i just yesterday found 2 issues in a merge (which you fixed) >>> > >>> Yeah, I also have two I recently came across, both caused by the >>> delayed filter initialization patch: >>> >>> https://trac.ffmpeg.org/ticket/6323 >>> https://trac.ffmpeg.org/ticket/6318 >>> >>> Maybe someone more familiar with ffmpeg.c code can take a look? >> >> Currently I'm overworked, I can take a look later if you remind me. > > This is a friendly reminder :) > > Thanks, > Marton Similarly, ticket 6227 describes a big regression introduced by this commit that i'm surprised is not reflected by any FATE test seeing that a simple "ffmpeg -i INPUT -c:v copy -c:a ENCODER OUTPUT", a very common use case, is enough to reproduce it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mips/iirfilter_mips: Include config.h
2017-05-01 16:41 GMT+02:00 Michael Niedermayer : > On Mon, May 01, 2017 at 10:37:51AM +0200, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes a warning when compiling for mips, I suspect it also >> fixes usage of inline asm. >> >> Please comment, Carl Eugen > >> iirfilter_mips.c |1 + >> 1 file changed, 1 insertion(+) >> 2c9416e78c7b93db40c774db11b45e14db785eba >> 0001-lavc-mips-iirfilter_mips-Include-config.h.patch >> From bbb8a20926b679d05af3b668a2822e6e1a97efa7 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Mon, 1 May 2017 10:35:28 +0200 >> Subject: [PATCH] lavc/mips/iirfilter_mips: Include config.h. >> >> Fixes the following warning: >> libavcodec/mips/iirfilter_mips.c:57:5: warning: "HAVE_INLINE_ASM" is not >> defined > > LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mips: Add missing const qualifiers
2017-05-01 15:10 GMT+02:00 Michael Niedermayer : > On Mon, May 01, 2017 at 10:34:23AM +0200, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes many warnings when compiling for mips. >> >> Please comment, Carl Eugen > > LGTM, untested though Patch applied (tested with Android NDK). Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 6/9] hevc_parser: remove HEVCContext usage
This gets rid of the duplicate, limited parser.
Signed-off-by: James Almer
---
Cosmetic changes only, needed to apply patch 9/9 on top of this.
libavcodec/hevc_parser.c | 177 +--
1 file changed, 32 insertions(+), 145 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 501cbc3498..57f2b2bb3e 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -24,114 +24,31 @@
#include "golomb.h"
#include "hevc.h"
-#include "hevcdec.h"
+#include "hevc_ps.h"
+#include "hevc_sei.h"
#include "h2645_parse.h"
+#include "internal.h"
#include "parser.h"
#define START_CODE 0x01 ///< start_code_prefix_one_3bytes
#define IS_IRAP_NAL(nal) (nal->type >= 16 && nal->type <= 23)
-
-#define ADVANCED_PARSER CONFIG_HEVC_DECODER
+#define IS_IDR_NAL(nal) (nal->type == HEVC_NAL_IDR_W_RADL || nal->type ==
HEVC_NAL_IDR_N_LP)
typedef struct HEVCParserContext {
ParseContext pc;
H2645Packet pkt;
HEVCParamSets ps;
+HEVCSEIContext sei;
+SliceHeader sh;
int parsed_extradata;
-#if ADVANCED_PARSER
-HEVCContext h;
-#endif
+int poc;
+int pocTid0;
} HEVCParserContext;
-#if !ADVANCED_PARSER
-static int hevc_parse_slice_header(AVCodecParserContext *s, H2645NAL *nal,
- AVCodecContext *avctx)
-{
-HEVCParserContext *ctx = s->priv_data;
-GetBitContext *gb = &nal->gb;
-
-HEVCPPS *pps;
-HEVCSPS *sps;
-unsigned int pps_id;
-
-get_bits1(gb); // first slice in pic
-if (IS_IRAP_NAL(nal))
-get_bits1(gb); // no output of prior pics
-
-pps_id = get_ue_golomb_long(gb);
-if (pps_id >= HEVC_MAX_PPS_COUNT || !ctx->ps.pps_list[pps_id]) {
-av_log(avctx, AV_LOG_ERROR, "PPS id out of range: %d\n", pps_id);
-return AVERROR_INVALIDDATA;
-}
-pps = (HEVCPPS*)ctx->ps.pps_list[pps_id]->data;
-sps = (HEVCSPS*)ctx->ps.sps_list[pps->sps_id]->data;
-
-/* export the stream parameters */
-s->coded_width = sps->width;
-s->coded_height = sps->height;
-s->width= sps->output_width;
-s->height = sps->output_height;
-s->format = sps->pix_fmt;
-avctx->profile = sps->ptl.general_ptl.profile_idc;
-avctx->level= sps->ptl.general_ptl.level_idc;
-
-/* ignore the rest for now*/
-
-return 0;
-}
-
-static int parse_nal_units(AVCodecParserContext *s, const uint8_t *buf,
- int buf_size, AVCodecContext *avctx)
-{
-HEVCParserContext *ctx = s->priv_data;
-int ret, i;
-
-ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, 0, 0,
-AV_CODEC_ID_HEVC, 1);
-if (ret < 0)
-return ret;
-
-for (i = 0; i < ctx->pkt.nb_nals; i++) {
-H2645NAL *nal = &ctx->pkt.nals[i];
-
-/* ignore everything except parameter sets and VCL NALUs */
-switch (nal->type) {
-case HEVC_NAL_VPS: ff_hevc_decode_nal_vps(&nal->gb, avctx, &ctx->ps);
break;
-case HEVC_NAL_SPS: ff_hevc_decode_nal_sps(&nal->gb, avctx, &ctx->ps,
1); break;
-case HEVC_NAL_PPS: ff_hevc_decode_nal_pps(&nal->gb, avctx, &ctx->ps);
break;
-case HEVC_NAL_TRAIL_R:
-case HEVC_NAL_TRAIL_N:
-case HEVC_NAL_TSA_N:
-case HEVC_NAL_TSA_R:
-case HEVC_NAL_STSA_N:
-case HEVC_NAL_STSA_R:
-case HEVC_NAL_BLA_W_LP:
-case HEVC_NAL_BLA_W_RADL:
-case HEVC_NAL_BLA_N_LP:
-case HEVC_NAL_IDR_W_RADL:
-case HEVC_NAL_IDR_N_LP:
-case HEVC_NAL_CRA_NUT:
-case HEVC_NAL_RADL_N:
-case HEVC_NAL_RADL_R:
-case HEVC_NAL_RASL_N:
-case HEVC_NAL_RASL_R:
-if (buf == avctx->extradata) {
-av_log(avctx, AV_LOG_ERROR, "Invalid NAL unit: %d\n",
nal->type);
-return AVERROR_INVALIDDATA;
-}
-hevc_parse_slice_header(s, nal, avctx);
-break;
-}
-}
-
-return 0;
-}
-#endif
-
/**
* Find the end of the current frame in the bitstream.
* @return the position of the first byte of the next frame, or END_NOT_FOUND
@@ -175,7 +92,6 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
return END_NOT_FOUND;
}
-#if ADVANCED_PARSER
/**
* Parse NAL units of found picture and decode some basic information.
*
@@ -188,28 +104,17 @@ static inline int parse_nal_units(AVCodecParserContext
*s, const uint8_t *buf,
int buf_size, AVCodecContext *avctx)
{
HEVCParserContext *ctx = s->priv_data;
-HEVCContext *h = &ctx->h;
-GetBitContext *gb;
-SliceHeader*sh = &h->sh;
-HEVCParamSets *ps = &h->ps;
-HEVCSEIContext *sei = &h->sei;
+SliceHeader*sh = &ctx->sh;
+HEVCParamSets *ps = &ctx->ps;
+HEVCSEIContext *sei = &ctx->sei;
int is_global = buf == avctx->extradata;
int i, ret;
-if (!h->HEVClc
[FFmpeg-devel] [PATCH 8/9] hevc_parse: decode SEI message NALUs in extradata
They may be present in hvcc style extradata.
Based on a patch by Hendrik Leppkes.
Signed-off-by: James Almer
---
libavcodec/hevc_parse.c| 21 ++---
libavcodec/hevc_parse.h| 4 ++--
libavcodec/hevcdec.c | 2 +-
libavcodec/mediacodecdec.c | 4 +++-
4 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index ee4cd54d3e..1122a60af3 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -22,8 +22,8 @@
#include "hevc_parse.h"
static int hevc_decode_nal_units(const uint8_t *buf, int buf_size,
HEVCParamSets *ps,
- int is_nalff, int nal_length_size, int
err_recognition,
- int apply_defdispwin, void *logctx)
+ HEVCSEIContext *sei, int is_nalff, int
nal_length_size,
+ int err_recognition, int apply_defdispwin,
void *logctx)
{
int i;
int ret = 0;
@@ -54,6 +54,12 @@ static int hevc_decode_nal_units(const uint8_t *buf, int
buf_size, HEVCParamSets
if (ret < 0)
goto done;
break;
+case HEVC_NAL_SEI_PREFIX:
+case HEVC_NAL_SEI_SUFFIX:
+ret = ff_hevc_decode_nal_sei(&nal->gb, logctx, sei, ps, nal->type);
+if (ret < 0)
+goto done;
+break;
default:
av_log(logctx, AV_LOG_VERBOSE, "Ignoring NAL type %d in
extradata\n", nal->type);
break;
@@ -69,8 +75,8 @@ done:
}
int ff_hevc_decode_extradata(const uint8_t *data, int size, HEVCParamSets *ps,
- int *is_nalff, int *nal_length_size, int
err_recognition,
- int apply_defdispwin, void *logctx)
+ HEVCSEIContext *sei, int *is_nalff, int
*nal_length_size,
+ int err_recognition, int apply_defdispwin, void
*logctx)
{
int ret = 0;
GetByteContext gb;
@@ -108,8 +114,9 @@ int ff_hevc_decode_extradata(const uint8_t *data, int size,
HEVCParamSets *ps,
return AVERROR_INVALIDDATA;
}
-ret = hevc_decode_nal_units(gb.buffer, nalsize, ps, *is_nalff,
*nal_length_size,
-err_recognition, apply_defdispwin,
logctx);
+ret = hevc_decode_nal_units(gb.buffer, nalsize, ps, sei,
*is_nalff,
+*nal_length_size, err_recognition,
apply_defdispwin,
+logctx);
if (ret < 0) {
av_log(logctx, AV_LOG_ERROR,
"Decoding nal unit %d %d from hvcC failed\n",
@@ -125,7 +132,7 @@ int ff_hevc_decode_extradata(const uint8_t *data, int size,
HEVCParamSets *ps,
*nal_length_size = nal_len_size;
} else {
*is_nalff = 0;
-ret = hevc_decode_nal_units(data, size, ps, *is_nalff,
*nal_length_size,
+ret = hevc_decode_nal_units(data, size, ps, sei, *is_nalff,
*nal_length_size,
err_recognition, apply_defdispwin, logctx);
if (ret < 0)
return ret;
diff --git a/libavcodec/hevc_parse.h b/libavcodec/hevc_parse.h
index 8aa46a290a..43c358f160 100644
--- a/libavcodec/hevc_parse.h
+++ b/libavcodec/hevc_parse.h
@@ -27,7 +27,7 @@
#include "hevcdec.h"
int ff_hevc_decode_extradata(const uint8_t *data, int size, HEVCParamSets *ps,
- int *is_nalff, int *nal_length_size, int
err_recognition,
- int apply_defdispwin, void *logctx);
+ HEVCSEIContext *sei, int *is_nalff, int
*nal_length_size,
+ int err_recognition, int apply_defdispwin, void
*logctx);
#endif /* AVCODEC_HEVC_PARSE_H */
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 8f235b0be1..ee001fd9f2 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3005,7 +3005,7 @@ static int hevc_decode_extradata(HEVCContext *s, uint8_t
*buf, int length)
{
int ret, i;
-ret = ff_hevc_decode_extradata(buf, length, &s->ps, &s->is_nalff,
+ret = ff_hevc_decode_extradata(buf, length, &s->ps, &s->sei, &s->is_nalff,
&s->nal_length_size,
s->avctx->err_recognition,
s->apply_defdispwin, s->avctx);
if (ret < 0)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6fd0db2fa5..ccfcb4b9ce 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -185,6 +185,7 @@ static int hevc_set_extradata(AVCodecContext *avctx,
FFAMediaFormat *format)
int ret;
HEVCParamSets ps;
+HEVCSEIContext sei;
const HEVCVPS *vps = NULL;
const HEVCPPS *pps = NULL;
@@ -200,9 +201,10 @@ static int hevc_set_extradata(AVCodecContext *avctx,
FFAMediaFormat *format)
[FFmpeg-devel] [PATCH 9/9] hevc_parser: move slice header parsing to its own function
Signed-off-by: James Almer
---
libavcodec/hevc_parser.c | 227 +--
1 file changed, 120 insertions(+), 107 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 57f2b2bb3e..4f41b78f66 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -92,6 +92,122 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
return END_NOT_FOUND;
}
+static int hevc_parse_slice_header(AVCodecParserContext *s, H2645NAL *nal,
+ AVCodecContext *avctx)
+{
+HEVCParserContext *ctx = s->priv_data;
+HEVCParamSets *ps = &ctx->ps;
+HEVCSEIContext *sei = &ctx->sei;
+SliceHeader *sh = &ctx->sh;
+GetBitContext *gb = &nal->gb;
+int i, num = 0, den = 0;
+
+sh->first_slice_in_pic_flag = get_bits1(gb);
+s->picture_structure = sei->picture_timing.picture_struct;
+s->field_order = sei->picture_timing.picture_struct;
+
+if (IS_IRAP_NAL(nal)) {
+s->key_frame = 1;
+sh->no_output_of_prior_pics_flag = get_bits1(gb);
+}
+
+sh->pps_id = get_ue_golomb(gb);
+if (sh->pps_id >= HEVC_MAX_PPS_COUNT || !ps->pps_list[sh->pps_id]) {
+av_log(avctx, AV_LOG_ERROR, "PPS id out of range: %d\n", sh->pps_id);
+return AVERROR_INVALIDDATA;
+}
+ps->pps = (HEVCPPS*)ps->pps_list[sh->pps_id]->data;
+
+if (ps->pps->sps_id >= HEVC_MAX_SPS_COUNT ||
!ps->sps_list[ps->pps->sps_id]) {
+av_log(avctx, AV_LOG_ERROR, "SPS id out of range: %d\n",
ps->pps->sps_id);
+return AVERROR_INVALIDDATA;
+}
+if (ps->sps != (HEVCSPS*)ps->sps_list[ps->pps->sps_id]->data) {
+ps->sps = (HEVCSPS*)ps->sps_list[ps->pps->sps_id]->data;
+ps->vps = (HEVCVPS*)ps->vps_list[ps->sps->vps_id]->data;
+}
+
+s->coded_width = ps->sps->width;
+s->coded_height = ps->sps->height;
+s->width= ps->sps->output_width;
+s->height = ps->sps->output_height;
+s->format = ps->sps->pix_fmt;
+avctx->profile = ps->sps->ptl.general_ptl.profile_idc;
+avctx->level= ps->sps->ptl.general_ptl.level_idc;
+
+if (ps->vps->vps_timing_info_present_flag) {
+num = ps->vps->vps_num_units_in_tick;
+den = ps->vps->vps_time_scale;
+} else if (ps->sps->vui.vui_timing_info_present_flag) {
+num = ps->sps->vui.vui_num_units_in_tick;
+den = ps->sps->vui.vui_time_scale;
+}
+
+if (num != 0 && den != 0)
+av_reduce(&avctx->framerate.den, &avctx->framerate.num,
+ num, den, 1 << 30);
+
+if (!sh->first_slice_in_pic_flag) {
+int slice_address_length;
+
+if (ps->pps->dependent_slice_segments_enabled_flag)
+sh->dependent_slice_segment_flag = get_bits1(gb);
+else
+sh->dependent_slice_segment_flag = 0;
+
+slice_address_length = av_ceil_log2_c(ps->sps->ctb_width *
+ ps->sps->ctb_height);
+sh->slice_segment_addr = get_bitsz(gb, slice_address_length);
+if (sh->slice_segment_addr >= ps->sps->ctb_width *
ps->sps->ctb_height) {
+av_log(avctx, AV_LOG_ERROR, "Invalid slice segment address: %u.\n",
+ sh->slice_segment_addr);
+return AVERROR_INVALIDDATA;
+}
+} else
+sh->dependent_slice_segment_flag = 0;
+
+if (sh->dependent_slice_segment_flag)
+return 0; /* break; */
+
+for (i = 0; i < ps->pps->num_extra_slice_header_bits; i++)
+skip_bits(gb, 1); // slice_reserved_undetermined_flag[]
+
+sh->slice_type = get_ue_golomb(gb);
+if (!(sh->slice_type == HEVC_SLICE_I || sh->slice_type == HEVC_SLICE_P ||
+ sh->slice_type == HEVC_SLICE_B)) {
+av_log(avctx, AV_LOG_ERROR, "Unknown slice type: %d.\n",
+ sh->slice_type);
+return AVERROR_INVALIDDATA;
+}
+s->pict_type = sh->slice_type == HEVC_SLICE_B ? AV_PICTURE_TYPE_B :
+ sh->slice_type == HEVC_SLICE_P ? AV_PICTURE_TYPE_P :
+ AV_PICTURE_TYPE_I;
+
+if (ps->pps->output_flag_present_flag)
+sh->pic_output_flag = get_bits1(gb);
+
+if (ps->sps->separate_colour_plane_flag)
+sh->colour_plane_id = get_bits(gb, 2);
+
+if (!IS_IDR_NAL(nal)) {
+sh->pic_order_cnt_lsb = get_bits(gb, ps->sps->log2_max_poc_lsb);
+s->output_picture_number = ctx->poc = ff_hevc_compute_poc(ps->sps,
ctx->pocTid0, sh->pic_order_cnt_lsb, nal->type);
+} else
+s->output_picture_number = ctx->poc = 0;
+
+if (nal->temporal_id == 0 &&
+nal->type != HEVC_NAL_TRAIL_N &&
+nal->type != HEVC_NAL_TSA_N &&
+nal->type != HEVC_NAL_STSA_N &&
+nal->type != HEVC_NAL_RADL_N &&
+nal->type != HEVC_NAL_RASL_N &&
+nal->type != HEVC_NAL_RADL_R &&
+nal->type != HEVC_NAL_RASL_R)
+ctx->pocTid0 = ctx->poc;
+
+return 1; /* no need to
[FFmpeg-devel] [PATCH] avcodec/flicvideo: Check for chunk overread
Fixes integer overflow
Fixes: 1292/clusterfuzz-testcase-minimized-5795512143839232
Signed-off-by: Michael Niedermayer
---
libavcodec/flicvideo.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
index b1b7b5a42f..7f9b871dc7 100644
--- a/libavcodec/flicvideo.c
+++ b/libavcodec/flicvideo.c
@@ -444,8 +444,12 @@ static int flic_decode_frame_8BPP(AVCodecContext *avctx,
break;
}
-if (stream_ptr_after_chunk - bytestream2_tell(&g2) > 0)
+if (stream_ptr_after_chunk - bytestream2_tell(&g2) >= 0) {
bytestream2_skip(&g2, stream_ptr_after_chunk -
bytestream2_tell(&g2));
+} else {
+av_log(avctx, AV_LOG_ERROR, "Chunk overread\n");
+break;
+}
frame_size -= chunk_size;
num_chunks--;
@@ -742,6 +746,13 @@ static int flic_decode_frame_15_16BPP(AVCodecContext
*avctx,
break;
}
+if (stream_ptr_after_chunk - bytestream2_tell(&g2) >= 0) {
+bytestream2_skip(&g2, stream_ptr_after_chunk -
bytestream2_tell(&g2));
+} else {
+av_log(avctx, AV_LOG_ERROR, "Chunk overread\n");
+break;
+}
+
frame_size -= chunk_size;
num_chunks--;
}
@@ -1016,6 +1027,13 @@ static int flic_decode_frame_24BPP(AVCodecContext *avctx,
break;
}
+if (stream_ptr_after_chunk - bytestream2_tell(&g2) >= 0) {
+bytestream2_skip(&g2, stream_ptr_after_chunk -
bytestream2_tell(&g2));
+} else {
+av_log(avctx, AV_LOG_ERROR, "Chunk overread\n");
+break;
+}
+
frame_size -= chunk_size;
num_chunks--;
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/decode: also check for FF_CODEC_CAP_SETS_PKT_DTS in audio decoders
Signed-off-by: James Almer
---
libavcodec/decode.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index edfae5583c..a54653f5a0 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -413,9 +413,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
} else {
ret = avctx->codec->decode(avctx, frame, &got_frame, &tmp);
+if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
+frame->pkt_dts = pkt->dts;
if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
-frame->pkt_dts = pkt->dts;
if(!avctx->has_b_frames)
frame->pkt_pos = pkt->pos;
//FIXME these should be under if(!avctx->has_b_frames)
@@ -426,8 +426,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!frame->height) frame->height
= avctx->height;
if (frame->format == AV_PIX_FMT_NONE) frame->format
= avctx->pix_fmt;
}
-} else if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
-frame->pkt_dts = pkt->dts;
}
}
emms_c();
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/vp9: don't set AVFrame.pkt_dts
decode.c already sets it to the default value.
Signed-off-by: James Almer
---
libavcodec/vp9.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 4d7310f6d4..3147ffa0db 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1125,7 +1125,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
((AVFrame *)frame)->pkt_pts = pkt->pts;
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-((AVFrame *)frame)->pkt_dts = pkt->dts;
for (i = 0; i < 8; i++) {
if (s->next_refs[i].f->buf[0])
ff_thread_release_buffer(avctx, &s->next_refs[i]);
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/gifdec: don't set AVFrame.pkt_dts
decode.c already sets it to the default value.
Signed-off-by: James Almer
---
libavcodec/gifdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 2eeed4c4c7..3d90210737 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -467,7 +467,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
s->frame->pkt_pts = avpkt->pts;
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-s->frame->pkt_dts = avpkt->dts;
s->frame->pkt_duration = avpkt->duration;
if (avpkt->size >= 6) {
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Suppress the "above array bounds" warning.
On 2017/4/30 20:47, Mark Thompson wrote:
> On 26/04/17 07:44, Jun Zhao wrote:
>> From f3678e0ceb691b6df5957a2c3d26d4f0d91d4ff5 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Wed, 26 Apr 2017 14:00:56 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h265: Suppress the "above array bounds"
>> warning.
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> setting the layer_id_included_flag lead to a potential array out of bounds,
>> build warning message as follow:
>> libavcodec/vaapi_encode_h265.c: In function
>> ‘vaapi_encode_h265_write_sequence_header’:
>> libavcodec/vaapi_encode_h265.c:305:49: warning: array subscript is above
>> array bounds [-Warray-bounds]
>
> Can you explain what the aim of this is? You haven't actually set any of the
> layer_id_included_flag in this patch, so is there more to follow dealing with
> the layers / layer sets?
>
> In any case, the dimensions of the array should probably be
> [MAX_LAYER_SETS][MAX_LAYERS] rather than the current values. (With
> MAX_LAYER_SETS having value 1 currently, but more if you intend to add more.)
Because in vaapi_encode_h265_write_vps(), when setting the
layer_id_included_flag, the index i start from 1, it's a potential above array
bounds issue when MAX_LAYERS == 1.
>
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/vaapi_encode_h265.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>> index 6e008b7b9c..1b2a49806b 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> @@ -66,7 +66,7 @@ typedef struct VAAPIEncodeH265MiscSequenceParams {
>> unsigned int vps_num_layer_sets_minus1;
>> unsigned int sps_max_sub_layers_minus1;
>> char sps_temporal_id_nesting_flag;
>> -char layer_id_included_flag[MAX_LAYERS][64];
>> +char layer_id_included_flag[MAX_LAYERS+1][64];
>>
>> // Profile/tier/level parameters.
>> char general_profile_compatibility_flag[32];
>> --
>> 2.11.0
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/http: Ignore expired cookies
On 2017-05-01 12:09 PM, Michael Niedermayer wrote: On Sun, Apr 30, 2017 at 02:25:29PM -0400, Micah Galizia wrote: Signed-off-by: Micah Galizia --- libavformat/http.c | 213 +++-- 1 file changed, 156 insertions(+), 57 deletions(-) applied thx TYVM. If I fix the name of on the second patch (for the unit tests) can I get that in too? I figure it can only help prevent future breaks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: count packets when queued
Because write_packet() fakely writes packets to muxer by queueing
them when muxer hasn't been initialized, it should also increment
frame_number fakely.
This is required because code in do_streamcopy() rely on
frame_number.
Should fix Ticket6227
Signed-off-by: Muhammad Faiz
---
ffmpeg.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index bf04a6c..023cb98 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -669,12 +669,28 @@ static void close_all_output_streams(OutputStream *ost,
OSTFinished this_stream,
}
}
-static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost)
+static void write_packet2(OutputFile *of, AVPacket *pkt, OutputStream *ost,
int unqueue)
{
AVFormatContext *s = of->ctx;
AVStream *st = ost->st;
int ret;
+/*
+ * Audio encoders may split the packets -- #frames in != #packets out.
+ * But there is no reordering, so we can limit the number of output packets
+ * by simply dropping them here.
+ * Counting encoded video frames needs to be done separately because of
+ * reordering, see do_video_out()
+ */
+/* do not count the packet when unqueued because it has been counted when
queued */
+if (!(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
ost->encoding_needed) && !unqueue) {
+if (ost->frame_number >= ost->max_frames) {
+av_packet_unref(pkt);
+return;
+}
+ost->frame_number++;
+}
+
if (!of->header_written) {
AVPacket tmp_pkt = {0};
/* the muxer is not initialized yet, buffer the packet */
@@ -703,20 +719,6 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost)
(st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO && audio_sync_method <
0))
pkt->pts = pkt->dts = AV_NOPTS_VALUE;
-/*
- * Audio encoders may split the packets -- #frames in != #packets out.
- * But there is no reordering, so we can limit the number of output packets
- * by simply dropping them here.
- * Counting encoded video frames needs to be done separately because of
- * reordering, see do_video_out()
- */
-if (!(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
ost->encoding_needed)) {
-if (ost->frame_number >= ost->max_frames) {
-av_packet_unref(pkt);
-return;
-}
-ost->frame_number++;
-}
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
int i;
uint8_t *sd = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_STATS,
@@ -802,6 +804,11 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost)
av_packet_unref(pkt);
}
+static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost)
+{
+write_packet2(of, pkt, ost, 0);
+}
+
static void close_output_stream(OutputStream *ost)
{
OutputFile *of = output_files[ost->file_index];
@@ -2972,7 +2979,7 @@ static int check_init_output_file(OutputFile *of, int
file_index)
while (av_fifo_size(ost->muxing_queue)) {
AVPacket pkt;
av_fifo_generic_read(ost->muxing_queue, &pkt, sizeof(pkt), NULL);
-write_packet(of, &pkt, ost);
+write_packet2(of, &pkt, ost, 1);
}
}
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/http: Ignore expired cookies
On Mon, May 01, 2017 at 09:11:11PM -0400, Micah Galizia wrote: > On 2017-05-01 12:09 PM, Michael Niedermayer wrote: > >On Sun, Apr 30, 2017 at 02:25:29PM -0400, Micah Galizia wrote: > >>Signed-off-by: Micah Galizia > >>--- > >> libavformat/http.c | 213 > >> +++-- > >> 1 file changed, 156 insertions(+), 57 deletions(-) > >applied > > > >thx > > TYVM. If I fix the name of on the second patch (for the unit tests) > can I get that in too? I figure it can only help prevent future > breaks. i think i forgotten about that yes please repost with fixed name [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffmpeg: treat audio streams with no parsed packets like unknown streams
---
ffmpeg_opt.c | 8
1 file changed, 8 insertions(+)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index d1fe8742ff..5ed29d717e 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2255,6 +2255,14 @@ loop_end:
if(o->data_disable && ist->st->codecpar->codec_type ==
AVMEDIA_TYPE_DATA)
continue;
+if (ignore_unknown_streams &&
+ist->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+ist->st->codecpar->sample_rate <= 0) {
+av_log(NULL, AV_LOG_WARNING, "Skipping stream #%d:%d - not
parsed.\n",
+ map->file_index, map->stream_index);
+continue;
+}
+
ost = NULL;
switch (ist->st->codecpar->codec_type) {
case AVMEDIA_TYPE_VIDEO: ost = new_video_stream (o,
oc, src_idx); break;
--
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavf/utils: bail early if we don't see any packets in an MPEGTS stream
---
libavformat/utils.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index ba82a766dc..4028d8dbcb 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3505,6 +3505,8 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
int64_t max_analyze_duration = ic->max_analyze_duration;
int64_t max_stream_analyze_duration;
int64_t max_subtitle_analyze_duration;
+int64_t max_empty_analyze_duration;
+int skip_empty_streams = 0;
int64_t probesize = ic->probesize;
int eof_reached = 0;
int *missing_streams = av_opt_ptr(ic->iformat->priv_class, ic->priv_data,
"missing_streams");
@@ -3515,14 +3517,18 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
max_stream_analyze_duration = max_analyze_duration;
max_subtitle_analyze_duration = max_analyze_duration;
+max_empty_analyze_duration = max_analyze_duration;
if (!max_analyze_duration) {
+max_empty_analyze_duration =
max_stream_analyze_duration =
max_analyze_duration= 5*AV_TIME_BASE;
max_subtitle_analyze_duration = 30*AV_TIME_BASE;
if (!strcmp(ic->iformat->name, "flv"))
max_stream_analyze_duration = 90*AV_TIME_BASE;
-if (!strcmp(ic->iformat->name, "mpeg") || !strcmp(ic->iformat->name,
"mpegts"))
+if (!strcmp(ic->iformat->name, "mpeg") || !strcmp(ic->iformat->name,
"mpegts")) {
max_stream_analyze_duration = 7*AV_TIME_BASE;
+max_empty_analyze_duration = 2*AV_TIME_BASE;
+}
}
if (ic->pb)
@@ -3628,6 +3634,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
int fps_analyze_framecount = 20;
st = ic->streams[i];
+
+if (st->codec_info_nb_frames == 0 &&
+st->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE &&
+skip_empty_streams)
+continue;
+
if (!has_codec_parameters(st, NULL))
break;
/* If the timebase is coarse (like the usual millisecond precision
@@ -3791,6 +3803,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_packet_unref(pkt);
break;
}
+
+if (t >= max_empty_analyze_duration)
+skip_empty_streams = 1;
+
if (pkt->duration) {
if (avctx->codec_type == AVMEDIA_TYPE_SUBTITLE && pkt->pts !=
AV_NOPTS_VALUE && pkt->pts >= st->start_time) {
st->info->codec_info_duration = FFMIN(pkt->pts -
st->start_time, st->info->codec_info_duration + pkt->duration);
--
2.11.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: count packets when queued
On 5/1/2017 9:51 PM, Muhammad Faiz wrote:
> Because write_packet() fakely writes packets to muxer by queueing
> them when muxer hasn't been initialized, it should also increment
> frame_number fakely.
> This is required because code in do_streamcopy() rely on
> frame_number.
>
> Should fix Ticket6227
>
> Signed-off-by: Muhammad Faiz
> ---
> ffmpeg.c | 39 +++
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index bf04a6c..023cb98 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -669,12 +669,28 @@ static void close_all_output_streams(OutputStream *ost,
> OSTFinished this_stream,
> }
> }
>
> -static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost)
> +static void write_packet2(OutputFile *of, AVPacket *pkt, OutputStream *ost,
> int unqueue)
> {
> AVFormatContext *s = of->ctx;
> AVStream *st = ost->st;
> int ret;
>
> +/*
> + * Audio encoders may split the packets -- #frames in != #packets out.
> + * But there is no reordering, so we can limit the number of output
> packets
> + * by simply dropping them here.
> + * Counting encoded video frames needs to be done separately because of
> + * reordering, see do_video_out()
> + */
> +/* do not count the packet when unqueued because it has been counted
> when queued */
> +if (!(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> ost->encoding_needed) && !unqueue) {
> +if (ost->frame_number >= ost->max_frames) {
> +av_packet_unref(pkt);
> +return;
> +}
> +ost->frame_number++;
> +}
> +
> if (!of->header_written) {
> AVPacket tmp_pkt = {0};
> /* the muxer is not initialized yet, buffer the packet */
> @@ -703,20 +719,6 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
> OutputStream *ost)
> (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO && audio_sync_method
> < 0))
> pkt->pts = pkt->dts = AV_NOPTS_VALUE;
>
> -/*
> - * Audio encoders may split the packets -- #frames in != #packets out.
> - * But there is no reordering, so we can limit the number of output
> packets
> - * by simply dropping them here.
> - * Counting encoded video frames needs to be done separately because of
> - * reordering, see do_video_out()
> - */
> -if (!(st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> ost->encoding_needed)) {
> -if (ost->frame_number >= ost->max_frames) {
> -av_packet_unref(pkt);
> -return;
> -}
> -ost->frame_number++;
> -}
> if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
> int i;
> uint8_t *sd = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_STATS,
> @@ -802,6 +804,11 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
> OutputStream *ost)
> av_packet_unref(pkt);
> }
>
> +static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost)
> +{
> +write_packet2(of, pkt, ost, 0);
> +}
It would be better to instead change the signature of write_packet()
with the addition of the unqueue parameter and update all three calls to
it rather than turning it into a wrapper.
Can confirm in any case that this fixes the packet dropping behavior.
> +
> static void close_output_stream(OutputStream *ost)
> {
> OutputFile *of = output_files[ost->file_index];
> @@ -2972,7 +2979,7 @@ static int check_init_output_file(OutputFile *of, int
> file_index)
> while (av_fifo_size(ost->muxing_queue)) {
> AVPacket pkt;
> av_fifo_generic_read(ost->muxing_queue, &pkt, sizeof(pkt), NULL);
> -write_packet(of, &pkt, ost);
> +write_packet2(of, &pkt, ost, 1);
> }
> }
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream
From e39078e9fe02c8d77c5e28436aef4d80a2d7b3a0 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Tue, 2 May 2017 10:36:55 +0800
Subject: [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC
stream.
Add aud option to support insert AUD nal in AVC stream. Default is
disable.
Signed-off-by: Jun Zhao
Signed-off-by: Yi A Wang
---
libavcodec/vaapi_encode.c | 15 ++
libavcodec/vaapi_encode.h | 4
libavcodec/vaapi_encode_h264.c | 45 ++
3 files changed, 64 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 7e9c00f51d..77a10f98a7 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -236,6 +236,21 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
goto fail;
}
+if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_RAW_DATA &&
+ctx->codec->write_aud_header) {
+bit_len = 8 * sizeof(data);
+err = ctx->codec->write_aud_header(avctx, pic, data, &bit_len);
+if (err < 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed to write aud "
+ "header %d: %d.\n", err);
+goto fail;
+}
+err = vaapi_encode_make_packed_header(avctx, pic,
VAEncPackedHeaderRawData,
+ data, bit_len);
+if (err < 0)
+goto fail;
+}
+
if (pic->type == PICTURE_TYPE_IDR) {
if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
ctx->codec->write_sequence_header) {
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 0edf27e4cb..09a5d87f7d 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -267,6 +267,10 @@ typedef struct VAAPIEncodeType {
VAAPIEncodePicture *pic,
int index, int *type,
char *data, size_t *data_len);
+ // Write an AU packed header, called by AVC encoder to insert AUD
+ int(*write_aud_header)(AVCodecContext *avctx,
+VAAPIEncodePicture *pic,
+char *data, size_t *data_len);
} VAAPIEncodeType;
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 47d0c9496a..7fa9ca70e0 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -168,6 +168,7 @@ typedef struct VAAPIEncodeH264Options {
int qp;
int quality;
int low_power;
+int aud;
} VAAPIEncodeH264Options;
@@ -750,6 +751,41 @@ static int
vaapi_encode_h264_write_slice_header(AVCodecContext *avctx,
tmp, header_len);
}
+static int vaapi_encode_h264_write_aud_header(AVCodecContext *avctx,
+ VAAPIEncodePicture *pic,
+ char *data, size_t *data_len)
+{
+VAAPIEncodeContext *ctx = avctx->priv_data;
+PutBitContext pbc;
+char tmp[256];
+size_t header_len;
+int primary_pic_type;
+
+init_put_bits(&pbc, tmp, sizeof(tmp));
+vaapi_encode_h264_write_nal_header(&pbc, H264_NAL_AUD, 0);
+switch (pic->type) {
+case PICTURE_TYPE_IDR:
+case PICTURE_TYPE_I:
+primary_pic_type = 0;
+break;
+case PICTURE_TYPE_P:
+primary_pic_type = 1;
+break;
+case PICTURE_TYPE_B:
+primary_pic_type = 2;
+break;
+default:
+av_assert0(0 && "unknown pic type");
+break;
+}
+write_u(&pbc, 3, primary_pic_type, primary_pic_type);
+vaapi_encode_h264_write_trailing_rbsp(&pbc);
+header_len = put_bits_count(&pbc);
+flush_put_bits(&pbc);
+return ff_vaapi_encode_h26x_nal_unit_to_byte_stream(data, data_len,
+tmp, header_len);
+}
+
static int vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
VAAPIEncodePicture *pic,
int index, int *type,
@@ -1180,6 +1216,8 @@ static const VAAPIEncodeType vaapi_encode_type_h264 = {
.write_slice_header= &vaapi_encode_h264_write_slice_header,
.write_extra_header= &vaapi_encode_h264_write_extra_header,
+
+.write_aud_header = &vaapi_encode_h264_write_aud_header,
};
static av_cold int vaapi_encode_h264_init(AVCodecContext *avctx)
@@ -1265,6 +1303,11 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext
*avctx)
VA_ENC_PACKED_HEADER_SLICE| // Slice headers.
VA_ENC_PACKED_HEADER_MISC; // SEI.
+if (opt->aud == 1) {
+ctx->va_packed_headers |=
+VA_ENC_PACKED_HEADER_RAW_DATA;
+}
+
ctx->surface_width = FFALIGN(avctx->width, 16);
ctx->surface_height = FFALIGN(avctx->height, 16);
@@ -1282,6 +1
[FFmpeg-devel] [PATCH] avformat/nut: add DSDs support
codec tags for DSDs are similar to PCMs: 'D', where
'D' means DSD, or pulse-Density-modulation,
is 'L' for LSB-first, 'M' for MSB-first
is 'D' for default, 'P' for planar
is always binary one :)
---
libavformat/nut.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/nut.c b/libavformat/nut.c
index 592fe4d..a886cb6 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -204,6 +204,10 @@ const AVCodecTag ff_nut_audio_extra_tags[] = {
{ AV_CODEC_ID_MP3, MKTAG('M', 'P', '3', ' ') },
{ AV_CODEC_ID_OPUS, MKTAG('O', 'p', 'u', 's') },
{ AV_CODEC_ID_WAVPACK, MKTAG('w', 'v', 'p', 'k') },
+{ AV_CODEC_ID_DSD_LSBF, MKTAG('D', 'L', 'D', 1 ) },
+{ AV_CODEC_ID_DSD_MSBF, MKTAG('D', 'M', 'D', 1 ) },
+{ AV_CODEC_ID_DSD_LSBF_PLANAR, MKTAG('D', 'L', 'P', 1 ) },
+{ AV_CODEC_ID_DSD_MSBF_PLANAR, MKTAG('D', 'M', 'P', 1 ) },
{ AV_CODEC_ID_NONE, 0 }
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/gifdec: don't set AVFrame.pkt_dts
On 5/2/17, James Almer wrote:
> decode.c already sets it to the default value.
>
> Signed-off-by: James Almer
> ---
> libavcodec/gifdec.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
> index 2eeed4c4c7..3d90210737 100644
> --- a/libavcodec/gifdec.c
> +++ b/libavcodec/gifdec.c
> @@ -467,7 +467,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
> s->frame->pkt_pts = avpkt->pts;
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
> -s->frame->pkt_dts = avpkt->dts;
> s->frame->pkt_duration = avpkt->duration;
>
> if (avpkt->size >= 6) {
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
