Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter

[Muhammad Faiz]

On Mon, May 1, 2017 at 3:30 PM, Paul B Mahol  wrote:
> 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;

Probably you may use rdft for performance reason.



> +
> +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)

[FFmpeg-devel] [PATCH v2] ffmpeg: count packets when queued

[Muhammad Faiz]

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 | 38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index bf04a6c..e798d92 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_packet(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,
@@ -861,10 +863,10 @@ static void output_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost)
 goto finish;
 idx++;
 } else
-write_packet(of, pkt, ost);
+write_packet(of, pkt, ost, 0);
 }
 } else
-write_packet(of, pkt, ost);
+write_packet(of, pkt, ost, 0);
 
 finish:
 if (ret < 0 && ret != AVERROR_EOF) {
@@ -2972,7 +2974,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_packet(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 2/2] lavf/utils: bail early if we don't see any packets in an MPEGTS stream

[Matthias Hunstock]

Am 02.05.2017 um 03:42 schrieb Rodger Combs:
> +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;
> +}
>  }

What's the origin of "max_empty_analyze_duration = 2*AV_TIME_BASE;", I
mean why 2*timebase and not 1 or 3 or 10 ?

Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/utils: bail early if we don't see any packets in an MPEGTS stream

[Rodger Combs]

> On May 2, 2017, at 03:59, Matthias Hunstock  wrote:
> 
> Am 02.05.2017 um 03:42 schrieb Rodger Combs:
>> +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;
>> +}
>> }
> 
> What's the origin of "max_empty_analyze_duration = 2*AV_TIME_BASE;", I
> mean why 2*timebase and not 1 or 3 or 10 ?

Same as any of the other constants here, I'd imagine: seemed about right and 
worked. I'm actually considering changing it to 1, though.
This doesn't apply to subtitle streams, and audio or video streams generally 
have at least several packets per second, so streams that are actually active 
_shouldn't_ be affected even with the smaller value.

> 
> Matthias
> ___
> 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 2/2] lavf/utils: bail early if we don't see any packets in an MPEGTS stream

[Matthias Hunstock]

Am 02.05.2017 um 11:07 schrieb Rodger Combs:
> This doesn't apply to subtitle streams, and audio or video streams generally 
> have at least several packets per second, so streams that are actually active 
> _shouldn't_ be affected even with the smaller value.

I think this is a dangerous assumption, but it seems using
max_analyze_duration option overrides that max_empty_analyze_duration
default value. So there is a loophole for special cases.

Matthias
___
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

[Muhammad Faiz]

On Mon, May 1, 2017 at 11:45 PM, Ronald S. Bultje  wrote:
> 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.

My opinion:
- for short term, the data alignment should be fixed.
- for long term, the framework should support non-aligned data. No needs for
  the DSP function to support non-aligned data. Instead ensure the framework
  to send aligned data to filters/codecs which require it. As Michael suggested,
  this can be achieved by using flags/required_alignment similar to
need_writable.

Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: separate macro arguments with commas

[Benoit Fouet]

Hi,


On 28/04/2017 21:58, Matthieu Bouron wrote:
> Untested: fixes ticket #6324.
> ---
>  libavcodec/aarch64/simple_idct_neon.S | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/aarch64/simple_idct_neon.S 
> b/libavcodec/aarch64/simple_idct_neon.S
> index 52273420f9..d31f72a609 100644
> --- a/libavcodec/aarch64/simple_idct_neon.S
> +++ b/libavcodec/aarch64/simple_idct_neon.S
> @@ -61,19 +61,19 @@ endconst
>  br  x10
>  .endm
>  
> -.macro smull1 a b c
> +.macro smull1 a, b, c
>  smull   \a, \b, \c
>  .endm
>  
> -.macro smlal1 a b c
> +.macro smlal1 a, b, c
>  smlal   \a, \b, \c
>  .endm
>  
> -.macro smlsl1 a b c
> +.macro smlsl1 a, b, c
>  smlsl   \a, \b, \c
>  .endm
>  
> -.macro idct_col4_top y1 y2 y3 y4 i l
> +.macro idct_col4_top y1, y2, y3, y4, i, l
>  smull\i v7.4S,  \y3\().\l, z2
>  smull\i v16.4S, \y3\().\l, z6
>  smull\i v17.4S, \y2\().\l, z1
> @@ -91,7 +91,7 @@ endconst
>  smlsl\i v6.4S,  \y4\().\l, z5
>  .endm
>  
> -.macro idct_row4_neon y1 y2 y3 y4 pass
> +.macro idct_row4_neon y1, y2, y3, y4, pass
>  ld1 {\y1\().2D-\y2\().2D}, [x2], #32
>  moviv23.4S, #1<<2, lsl #8
>  orr v5.16B, \y1\().16B, \y2\().16B
> @@ -153,7 +153,7 @@ endconst
>  trn2\y4\().4S, v17.4S, v19.4S
>  .endm
>  
> -.macro declare_idct_col4_neon i l
> +.macro declare_idct_col4_neon i, l
>  function idct_col4_neon\i
>  dup v23.4H, z4c
>  .if \i == 1

Sounds sane, but shouldn't we be doing this for all instances of
multiple arguments macros without commas?

Thanks
-- 
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/nut: add DSDs support

[Michael Niedermayer]

On Tue, May 02, 2017 at 12:33:34PM +0900, Takayuki 'January June' Suwa wrote:
> 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 :)

please send a patch to nut-devel first that updates
nut4cc.txt

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream

[Michael Niedermayer]

On Tue, May 02, 2017 at 10:49:50AM +0800, Jun Zhao wrote:
>  vaapi_encode.c  |   15 +++
>  vaapi_encode.h  |4 
>  vaapi_encode_h264.c |   45 +
>  3 files changed, 64 insertions(+)
> 32cb532f5b6e7a3237b3997a79a93bf54b02660f  
> 0001-lavc-vaapi_encode_h264-add-option-to-insert-AUD-nal-.patch
> 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);

the %d(s) and the argument doesnt match up

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Fix jp2 inner atom size used for overread checks

[Carl Eugen Hoyos]

Hi!

The atom2_size variable when reading the inner atoms of a jp2 header 
is not reduced after reading the first 64 bit of the atom, the 
variable is used later for several checks to avoid overreads.

Please comment, Carl Eugen
From 8519c62b141953ecbd47f4eb9572a54db29bfec3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 2 May 2017 16:09:11 +0200
Subject: [PATCH] lavc/jpeg2000dec: Fix jp2 inner atom size used for overread
 checks.

---
 libavcodec/jpeg2000dec.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index e9f5f51..ab814ca 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1982,6 +1982,7 @@ static int jp2_find_codestream(Jpeg2000DecoderContext *s)
 atom2_end  = bytestream2_tell(&s->g) + atom2_size - 8;
 if (atom2_size < 8 || atom2_end > atom_end || atom2_end < 
atom2_size)
 break;
+atom2_size -= 8;
 if (atom2 == JP2_CODESTREAM) {
 return 1;
 } else if (atom2 == MKBETAG('c','o','l','r') && atom2_size >= 
7) {
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Read resolution box from jp2 files

[Carl Eugen Hoyos]

Hi!

Attached patch allows reading the aspect ratio from jpeg2000 files.
Kakadu allows to produce samples, the "aspect" is defined as the 
horizontal and vertical resolution as in tiff.

Please comment, Carl Eugen
From 9955a76ea9abd6ad0c79b4e3d7fe74d4cf292aa6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 2 May 2017 16:01:02 +0200
Subject: [PATCH] lavc/jpeg2000dec: Read the resolution box from jp2 files.

---
 libavcodec/jpeg2000dec.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index e9f5f51..3e1cc00 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -26,6 +26,7 @@
  */
 
 #include 
+#include 
 
 #include "libavutil/attributes.h"
 #include "libavutil/avassert.h"
@@ -106,6 +107,7 @@ typedef struct Jpeg2000DecoderContext {
 int tile_width, tile_height;
 unsignednumXtiles, numYtiles;
 int maxtilelen;
+AVRational  resolution;
 
 Jpeg2000CodingStyle codsty[4];
 Jpeg2000QuantStyle  qntsty[4];
@@ -2043,6 +2045,34 @@ static int jp2_find_codestream(Jpeg2000DecoderContext *s)
 if (cn < 4 && asoc < 4)
 s->cdef[cn] = asoc;
 }
+} else if (atom2 == MKBETAG('r','e','s',' ') && atom2_size >= 
18) {
+int64_t vnum, vden, hnum, hden, vexp, hexp;
+uint32_t resx;
+bytestream2_skip(&s->g, 4);
+resx = bytestream2_get_be32u(&s->g);
+if (resx != MKBETAG('r','e','s','c') && resx != 
MKBETAG('r','e','s','d')) {
+bytestream2_seek(&s->g, atom2_end, SEEK_SET);
+continue;
+}
+vnum = bytestream2_get_be16u(&s->g);
+vden = bytestream2_get_be16u(&s->g);
+hnum = bytestream2_get_be16u(&s->g);
+hden = bytestream2_get_be16u(&s->g);
+vexp = bytestream2_get_byteu(&s->g);
+hexp = bytestream2_get_byteu(&s->g);
+if (vexp > hexp) {
+vexp -= hexp;
+hexp = 0;
+} else {
+hexp -= vexp;
+vexp = 0;
+}
+if (   INT64_MAX / (hnum * vden) > pow(10, hexp)
+&& INT64_MAX / (vnum * hden) > pow(10, vexp))
+av_reduce(&s->resolution.num, &s->resolution.den,
+  hnum * vden * pow(10, hexp),
+  vnum * hden * pow(10, vexp),
+  INT32_MAX);
 }
 bytestream2_seek(&s->g, atom2_end, SEEK_SET);
 } while (atom_end - atom2_end >= 8);
@@ -2125,6 +2155,13 @@ static int jpeg2000_decode_frame(AVCodecContext *avctx, 
void *data,
 
 if (s->avctx->pix_fmt == AV_PIX_FMT_PAL8)
 memcpy(picture->data[1], s->palette, 256 * sizeof(uint32_t));
+if (   s->resolution.num && s->resolution.den
+&& INT64_MAX / avctx->width  > s->resolution.den
+&& INT64_MAX / avctx->height > s->resolution.num)
+av_reduce(&avctx->sample_aspect_ratio.num, 
&avctx->sample_aspect_ratio.den,
+  (int64_t)avctx->width  * s->resolution.den,
+  (int64_t)avctx->height * s->resolution.num,
+  INT32_MAX);
 
 return bytestream2_tell(&s->g);
 
-- 
1.7.10.4

___
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

[Nicolas George]

Le duodi 12 floréal, an CCXXV, Paul B Mahol a écrit :
> This is all one big mess.

It is, but I will not take responsibility when it is not mine.

Libavfilter was in need of a serious overhaul. I do not see you denying
it, and you suffered from the limitations it was causing as much as
anybody else. I have undertaken that overhaul, and the help I received
from other developers in that project has been scarce, to say the least.

I do not complain, I can manage on my own; it will take longer, but I am
in no rush. But I will not let the complaints of the inspectors of
finished work trouble me.

An overhaul of this magnitude is sure to introduce bugs. This one did,
and I made a point of fixing them. My work tree is currently set up to
investigate the problem with shortest and dualinput. Once again, feel
free to offer help.

An overhaul of this magnitude is also sure to reveal bugs that were
already present in the code base and just did not manifest due to
undocumented specifics of the old implementation.

The crash we are discussing is caused by the new code violating the
unwritten un-agreed-upon rule that it must keep the data extra-aligned.
Except there is no such thing as an "unwritten un-agreed-upon rule". The
cause of the crash is the code in libmp3lame relying on this unwritten
un-agreed-upon rule. I strongly suspect it can be triggered by an
application without using libavfilter at all.

For now, fixing libmp3lame is the correct solution, and this patch does
it. I think it is not the best long-term solution, but that is not for
me to say.

Another solution would be to write the rule. If somebody does, then I
will implement the code needed to respect it in libavfilter.

But I will not raise another finger to write the rule, because whatever
I do I will be blamed, and I am fed up with that attitude.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/rtsp: check return value of read in ff_rtsp_read_reply()

[Daniel Richard G.]

Resending...

On Mon, 2017 Apr 17 01:12-0400, Daniel Richard G. wrote:
> In the course of testing RTSP streaming of CCTV video via the FFmpeg
> API, I have found some Valgrind uninitialized-memory errors due to what
> appear to be short/failed reads in ffurl_read_complete().
> 
> The calling function ff_rtsp_read_reply() was not checking the return
> value, and so the library went on to parse garbage in an
> uninitialized heap-allocated buffer.
> 
> The attached patch adds logic to check the return value and bail
> out on error.
> 
> 
> --Daniel
> 

-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
From 477cbd18b630365d612da173201c2e4ee763d7d4 Mon Sep 17 00:00:00 2001
From: Daniel Richard G 
Date: Sun, 16 Apr 2017 23:12:53 -0400
Subject: [PATCH] avformat/rtsp: check return value of read in ff_rtsp_read_reply()

Signed-off-by: Daniel Richard G 
---
 libavformat/rtsp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 261e970..da962fb 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1218,7 +1218,11 @@ start:
 content = av_malloc(content_length + 1);
 if (!content)
 return AVERROR(ENOMEM);
-ffurl_read_complete(rt->rtsp_hd, content, content_length);
+ret = ffurl_read_complete(rt->rtsp_hd, content, content_length);
+if (ret != content_length) {
+av_freep(&content);
+return AVERROR_EOF;
+}
 content[content_length] = '\0';
 }
 if (content_ptr)
-- 
2.9.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Read resolution box from jp2 files

[Nicolas George]

Le tridi 13 floréal, an CCXXV, Carl Eugen Hoyos a écrit :
> Attached patch allows reading the aspect ratio from jpeg2000 files.
> Kakadu allows to produce samples, the "aspect" is defined as the 
> horizontal and vertical resolution as in tiff.

Did you test what happens with this patch if you try to read two frames
with the same context (for example with the image2 demuxer), the first
frame has a non-square-pixels resolution defined and the second has no
resolution indication at all?

The correct result would be to have a sample aspect ratio on the first
frame and not on the second.

But with this code, since the first resolution is stored in the context
and never cleared, it looks like it will be kept for the remaining
images.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Read resolution box from jp2 files

[Carl Eugen Hoyos]

2017-05-02 16:21 GMT+02:00 Nicolas George :
> Le tridi 13 floréal, an CCXXV, Carl Eugen Hoyos a écrit :
>> Attached patch allows reading the aspect ratio from jpeg2000 files.
>> Kakadu allows to produce samples, the "aspect" is defined as the
>> horizontal and vertical resolution as in tiff.
>
> Did you test what happens with this patch if you try to read two frames
> with the same context (for example with the image2 demuxer), the first
> frame has a non-square-pixels resolution defined and the second has no
> resolution indication at all?
>
> The correct result would be to have a sample aspect ratio on the first
> frame and not on the second.
>
> But with this code, since the first resolution is stored in the context
> and never cleared, it looks like it will be kept for the remaining
> images.

New, fixed patch attached.
(There also was another bug.)

Thank you, Carl Eugen
From 027d46030354c99ce496d299ff3c95e739ecdda2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 2 May 2017 16:27:47 +0200
Subject: [PATCH] lavc/jpeg2000dec: Read the sample aspect ratio from the jp2
 resolution box.

---
 libavcodec/jpeg2000dec.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index e9f5f51..17ca257 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -26,6 +26,7 @@
  */
 
 #include 
+#include 
 
 #include "libavutil/attributes.h"
 #include "libavutil/avassert.h"
@@ -106,6 +107,7 @@ typedef struct Jpeg2000DecoderContext {
 int tile_width, tile_height;
 unsignednumXtiles, numYtiles;
 int maxtilelen;
+AVRational  sar;
 
 Jpeg2000CodingStyle codsty[4];
 Jpeg2000QuantStyle  qntsty[4];
@@ -1982,6 +1984,7 @@ static int jp2_find_codestream(Jpeg2000DecoderContext *s)
 atom2_end  = bytestream2_tell(&s->g) + atom2_size - 8;
 if (atom2_size < 8 || atom2_end > atom_end || atom2_end < atom2_size)
 break;
+atom2_size -= 8;
 if (atom2 == JP2_CODESTREAM) {
 return 1;
 } else if (atom2 == MKBETAG('c','o','l','r') && atom2_size >= 7) {
@@ -2043,6 +2046,34 @@ static int jp2_find_codestream(Jpeg2000DecoderContext *s)
 if (cn < 4 && asoc < 4)
 s->cdef[cn] = asoc;
 }
+} else if (atom2 == MKBETAG('r','e','s',' ') && atom2_size >= 18) {
+int64_t vnum, vden, hnum, hden, vexp, hexp;
+uint32_t resx;
+bytestream2_skip(&s->g, 4);
+resx = bytestream2_get_be32u(&s->g);
+if (resx != MKBETAG('r','e','s','c') && resx != MKBETAG('r','e','s','d')) {
+bytestream2_seek(&s->g, atom2_end, SEEK_SET);
+continue;
+}
+vnum = bytestream2_get_be16u(&s->g);
+vden = bytestream2_get_be16u(&s->g);
+hnum = bytestream2_get_be16u(&s->g);
+hden = bytestream2_get_be16u(&s->g);
+vexp = bytestream2_get_byteu(&s->g);
+hexp = bytestream2_get_byteu(&s->g);
+if (vexp > hexp) {
+vexp -= hexp;
+hexp = 0;
+} else {
+hexp -= vexp;
+vexp = 0;
+}
+if (   INT64_MAX / (hnum * vden) > pow(10, hexp)
+&& INT64_MAX / (vnum * hden) > pow(10, vexp))
+av_reduce(&s->sar.den, &s->sar.num,
+  hnum * vden * pow(10, hexp),
+  vnum * hden * pow(10, vexp),
+  INT32_MAX);
 }
 bytestream2_seek(&s->g, atom2_end, SEEK_SET);
 } while (atom_end - atom2_end >= 8);
@@ -2125,6 +2156,9 @@ static int jpeg2000_decode_frame(AVCodecContext *avctx, void *data,
 
 if (s->avctx->pix_fmt == AV_PIX_FMT_PAL8)
 memcpy(picture->data[1], s->palette, 256 * sizeof(uint32_t));
+if (s->sar.num && s->sar.den)
+avctx->sample_aspect_ratio = s->sar;
+s->sar.num = s->sar.den = 0;
 
 return bytestream2_tell(&s->g);
 
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/utils: bail early if we don't see any packets in an MPEGTS stream

[Michael Niedermayer]

On Mon, May 01, 2017 at 08:42:18PM -0500, Rodger Combs wrote:
> ---
>  libavformat/utils.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)

this breaks
./ffmpeg -i  ~/tickets/3673/no-video-stream_cut.flv  -an  -vcodec copy -f 
framecrc -

https://trac.ffmpeg.org/raw-attachment/ticket/3673/no-video-stream_cut.flv


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

2017-04-29 18:15 GMT+02:00 Thomas Mundt :

> 2017-04-20 23:54 GMT+02:00 Thomas Mundt :
>
>> Patch attached...
>>
>> Ping
>

Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Paul B Mahol]

On 5/2/17, Thomas Mundt  wrote:
> 2017-04-29 18:15 GMT+02:00 Thomas Mundt :
>
>> 2017-04-20 23:54 GMT+02:00 Thomas Mundt :
>>
>>> Patch attached...
>>>
>>> Ping
>>
>
> Ping
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Michael? Gonna apply this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[James Almer]

On 5/2/2017 1:49 PM, Paul B Mahol wrote:
> On 5/2/17, Thomas Mundt  wrote:
>> 2017-04-29 18:15 GMT+02:00 Thomas Mundt :
>>
>>> 2017-04-20 23:54 GMT+02:00 Thomas Mundt :
>>>
 Patch attached...

 Ping
>>>
>>
>> Ping
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> Michael? Gonna apply this?

Applied it since i reviewed it in part.
___
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

[wm4]

On Tue, 2 May 2017 16:16:35 +0200
Nicolas George  wrote:

> Le duodi 12 floréal, an CCXXV, Paul B Mahol a écrit :
> > This is all one big mess.  
> 
> It is, but I will not take responsibility when it is not mine.
> 
> Libavfilter was in need of a serious overhaul. I do not see you denying
> it, and you suffered from the limitations it was causing as much as
> anybody else. I have undertaken that overhaul, and the help I received
> from other developers in that project has been scarce, to say the least.

That doesn't free you from the responsibility to keep things in a
reasonably working state.

> I do not complain, I can manage on my own; it will take longer, but I am
> in no rush. But I will not let the complaints of the inspectors of
> finished work trouble me.

I can understand that attitude, but if a fix takes "longer" and
meanwhile certain filters or encoders crash left and right in git
master and even in the latest FFmpeg release, there's a need to act
quickly, even if it means reverting certain patches.

I don't want to blame anyone (and I ask you not to blame others either,
like you did above), but please fix/avoid crashing bugs?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: don't set AVFrame.pkt_dts

[wm4]

On Mon,  1 May 2017 20:52:14 -0300
James Almer  wrote:

> 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]);

Is there any possibility the "default" value is actually wrong? It
assumes a fixed delay etc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 1 May 2017 15:29:22 -0300
James Almer  wrote:

> 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.

Seems like Muhammad Faiz has a patch for this.

Will try to look at the other 2 issues tonight, if they're not the same
as 6227.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: don't set AVFrame.pkt_dts

[James Almer]

On 5/2/2017 2:19 PM, wm4 wrote:
> On Mon,  1 May 2017 20:52:14 -0300
> James Almer  wrote:
> 
>> 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]);
> 
> Is there any possibility the "default" value is actually wrong? It
> assumes a fixed delay etc.

The default is set after the AVCodec.decode() call (unless the
FF_CODEC_CAP_SETS_PKT_DTS cap is set), so the above is overwritten by
it, and considering it's also pkt->dts, I assume no?
But if the above line is required, then perhaps the
FF_CODEC_CAP_SETS_PKT_DTS cap should be set.

I may be missing something, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] ffmpeg: count packets when queued

[Michael Niedermayer]

On Tue, May 02, 2017 at 02:39:46PM +0700, 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 | 38 --
>  1 file changed, 20 insertions(+), 18 deletions(-)

probably ok

i think in the long run all this queeuing stuff should be moved into
libavformat (there are already queues in there as well) and
not require logic in the user apps, thats off topic though

Also, is there an simple testcase ? if so please add it to fate

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Trac notification not working

[Home-Email]

I hope this is the right place to send the following notification.
I tried to use the Trac system but was locked out by the sign-up
procedure. It has been going on for so long I have forgotten what I was
going to send as a bug report.

The following message is at the head of any trac.ffmpeg.org document I
open:

"Warning: Your permissions have been limited until you verify your
email address."

It contains a link to https://trac.ffmpeg.org/verify_email
where Verify Email tells me:

"An email was sent to inhisst...@eastex.net with a token to verify your
new address. Please check your email and enter the token in the form
below.
You can change your email address, if it is incorrect."

but despite clearing out my spam catcher regularly I have not seen any
verification emails sent to my address.  As you can see the email
address matches the one I am sending from today.

I am at a loss for how to proceed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] This fixes ISO date formatissue when manifest created by this muxer is not playable in most players. This ensures compatibility with dash standard. Tested on many players (d

[MFojtak]

Currently this muxer does not work at all. I don't know if 000Z would make 
it compatible with more player as I don't know any. However, adding Z makes 
it compatible with most popular ones like dash.js and shaka. Having this 
muxer working properly would bring more attention to it and maybe in the 
future somebody tests it with more players. But for now I suggest to roll 
out the change and "unblock" this muxer for some real wold use. Also, it 
would be great to make this muxer codec and container agnostic as it works 
with h264 and mp4 only. But again, nobody would bother if the muxer doesn't 
work at all with browsers. 
 -- Původní e-mail --
Od: Aaron Levinson 
Komu: FFmpeg development discussions and patches 
Datum: 30. 4. 2017 20:47:59
Předmět: Re: [FFmpeg-devel] [PATCH] This fixes ISO date formatissue when 
manifest created by this muxer is not playable in most players. This ensures
compatibility with dash standard. Tested on many players (dashj.js, shaka, 
VLC, etc.) 
"On 4/26/2017 4:27 AM, mfojtak wrote: 
> --- 
> libavformat/dashenc.c | 2 +- 
> 1 file changed, 1 insertion(+), 1 deletion(-) 
> 
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c 
> index 6232c70..fe1d6c2 100644 
> --- a/libavformat/dashenc.c 
> +++ b/libavformat/dashenc.c 
> @@ -433,7 +433,7 @@ static void format_date_now(char *buf, int size) 
> struct tm *ptm, tmbuf; 
> ptm = gmtime_r(&t, &tmbuf); 
> if (ptm) { 
> - if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S", ptm)) 
> + if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%SZ", ptm)) 
> buf[0] = '\0'; 
> } 
> } 
> 

This change appears to be correct. I wasn't previously knowledgeable 
about the 'Z' suffix, but I looked into it and it is documented in ISO 
8601 (https://en.wikipedia.org/wiki/ISO_8601 and also 
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15 ). 

On a separate note, the actual format is: -MM-DDTHH:mm:ss.sssZ . 
The ".sss" part is missing from this implementation, which represents 
milliseconds. According to the specification, ".sss" may be absent, but 
maybe it would work with even more players if it were included. 
Technically, the specification states that an absent time-zone offset 
should be treated as 'Z', which indicates that the code was already 
compliant without the 'Z', even if it didn't work with most players. 
strftime() doesn't handle milliseconds, but perhaps it ought to populate 
milliseconds anyway as follows: 

if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S.000Z", ptm)) 

Aaron Levinson 
"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fixes the issue https://trac.ffmpeg.org/ticket/6338

[Vineet Goel]

---

 libavformat/http.c | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/libavformat/http.c b/libavformat/http.c

index 293a8a7..27b52fe 100644

--- a/libavformat/http.c

+++ b/libavformat/http.c

@@ -1094,7 +1094,7 @@ static int http_connect(URLContext *h, const char
*path, const char *local_path,

"Content-Type: %s\r\n", s->content_type);

 if (!has_header(s->headers, "\r\nCookie: ") && s->cookies) {

 char *cookies = NULL;

-if (!get_cookies(s, &cookies, path, hoststr) && cookies) {

+if (!get_cookies(s, &cookies, local_path, hoststr) && cookies) {

 len += av_strlcatf(headers + len, sizeof(headers) - len,

"Cookie: %s\r\n", cookies);

 av_free(cookies);

-- 

2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: treat audio streams with no parsed packets like unknown streams

[Michael Niedermayer]

On Mon, May 01, 2017 at 08:42:17PM -0500, Rodger Combs wrote:
> ---
>  ffmpeg_opt.c | 8 
>  1 file changed, 8 insertions(+)

probably ok

please also add a testcase to fate for this

[...]
-- 
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

Re: [FFmpeg-devel] Trac notification not working

[Michael Niedermayer]

On Sun, Apr 30, 2017 at 02:08:32PM -0500, Home-Email wrote:
> I hope this is the right place to send the following notification.
> I tried to use the Trac system but was locked out by the sign-up
> procedure. It has been going on for so long I have forgotten what I was
> going to send as a bug report.
> 
> The following message is at the head of any trac.ffmpeg.org document I
> open:
> 
> "Warning: Your permissions have been limited until you verify your
> email address."
> 
> It contains a link to https://trac.ffmpeg.org/verify_email
> where Verify Email tells me:
> 
> "An email was sent to inhisst...@eastex.net with a token to verify your
> new address. Please check your email and enter the token in the form
> below.
> You can change your email address, if it is incorrect."
> 
> but despite clearing out my spam catcher regularly I have not seen any
> verification emails sent to my address.  As you can see the email
> address matches the one I am sending from today.
> 
> I am at a loss for how to proceed.

a quick look at the logs shows several lines with
"host etnhn06.eastex.net[66.171.0.52] refused to talk to me: 521 This system is 
configured to reject mail from 79.124.17.100"

So it seems your mail server rejects mail from our server

I suggest you look at why your server rejects mail or use a different
mail provider

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fixes the issue https://trac.ffmpeg.org/ticket/6338

[Michael Niedermayer]

On Mon, May 01, 2017 at 01:01:34PM +0530, Vineet Goel wrote:
> ---
> 
>  libavformat/http.c | 2 +-
> 
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> 
> index 293a8a7..27b52fe 100644
> 
> --- a/libavformat/http.c
> 
> +++ b/libavformat/http.c

this patch is corrupted by empty lines


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: don't set AVFrame.pkt_dts

[wm4]

On Tue, 2 May 2017 14:50:32 -0300
James Almer  wrote:

> On 5/2/2017 2:19 PM, wm4 wrote:
> > On Mon,  1 May 2017 20:52:14 -0300
> > James Almer  wrote:
> >   
> >> 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]);  
> > 
> > Is there any possibility the "default" value is actually wrong? It
> > assumes a fixed delay etc.  
> 
> The default is set after the AVCodec.decode() call (unless the
> FF_CODEC_CAP_SETS_PKT_DTS cap is set), so the above is overwritten by
> it, and considering it's also pkt->dts, I assume no?
> But if the above line is required, then perhaps the
> FF_CODEC_CAP_SETS_PKT_DTS cap should be set.
> 
> I may be missing something, though.

Yeah, you're right, it's going to be overwritten, and it always was
this way. So the patch can't change behavior.

Just wondering whether originally there was an intention to set this
directly, i.e. whether we should just set FF_CODEC_CAP_SETS_PKT_DTS.
___
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

[Muhammad Faiz]

On Mon, May 1, 2017 at 9:01 PM, wm4  wrote:
> 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.

Applied.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter

[Paul B Mahol]

On 5/2/17, Muhammad Faiz  wrote:
> On Mon, May 1, 2017 at 3:30 PM, Paul B Mahol  wrote:
>> 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;
>
> Probably you may use rdft for performance reason.

I will concentrate on correctness of output first.

>
>
>
>> +
>> +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

Re: [FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Fix jp2 inner atom size used for overread checks

[Michael Niedermayer]

On Tue, May 02, 2017 at 04:13:07PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> The atom2_size variable when reading the inner atoms of a jp2 header 
> is not reduced after reading the first 64 bit of the atom, the 
> variable is used later for several checks to avoid overreads.
> 
> Please comment, Carl Eugen

LGTM, thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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 v2] ffmpeg: count packets when queued

[Muhammad Faiz]

On Wed, May 3, 2017 at 12:58 AM, Michael Niedermayer
 wrote:
> On Tue, May 02, 2017 at 02:39:46PM +0700, 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 | 38 --
>>  1 file changed, 20 insertions(+), 18 deletions(-)
>
> probably ok

Applied.

>
> i think in the long run all this queeuing stuff should be moved into
> libavformat (there are already queues in there as well) and
> not require logic in the user apps, thats off topic though
>
> Also, is there an simple testcase ? if so please add it to fate

No. Maybe testcase in ticket entry can be a candidate.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]compat/strtod: Add missing const qualifiers

[Aaron Levinson]

On 5/1/2017 1:51 AM, Carl Eugen Hoyos wrote:

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


LGTM

Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream

[Mark Thompson]

On 02/05/17 03:49, Jun Zhao wrote:
> 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(+)

This puts the AUDs in the wrong place?

./ffmpeg_g -y -vaapi_device /dev/dri/renderD128 -hwaccel vaapi 
-hwaccel_output_format vaapi -i in.mp4 -an -c:v h264_vaapi -aud 1 -b 5M 
-maxrate 5M out.h264

IDR frame:

  00 00 00 01 67 64 00 33  ac 2e c0 78 02 27 e5 c0  |gd.3...x.'..|  
<- SPS
0010  44 00 00 03 00 04 00 00  03 01 e3 89 80 00 98 96  |D...|
0020  00 01 31 2c bd ce 01 e1  10 8a 70 00 00 00 01 68  |..1,..ph|  
<- PPS
0030  ee 38 b0 00 00 00 01 06  00 07 80 83 d6 00 00 03  |.8..|  
<- SEI
0040  00 40 01 04 00 00 03 00  02 05 79 59 94 8b 28 11  |.@yY..(.|
0050  ec 45 af 96 75 19 d4 1f  ea a9 4d 4c 61 76 63 35  |.E..u.MLavc5|
0060  37 2e 39 33 2e 31 30 30  20 2f 20 56 41 41 50 49  |7.93.100 / VAAPI|
0070  20 30 2e 34 30 2e 30 20  2f 20 49 6e 74 65 6c 20  | 0.40.0 / Intel |
0080  69 39 36 35 20 64 72 69  76 65 72 20 66 6f 72 20  |i965 driver for |
0090  49 6e 74 65 6c 28 52 29  20 43 68 65 72 72 79 56  |Intel(R) CherryV|
00a0  69 65 77 20 2d 20 31 2e  38 2e 32 2e 70 72 65 31  |iew - 1.8.2.pre1|
00b0  20 28 31 2e 38 2e 31 2d  35 35 2d 67 39 39 36 65  | (1.8.1-55-g996e|
00c0  63 65 64 29 80 00 00 00  01 09 10 00 00 00 01 65  |ced)...e|  
<- AUD, IDR slice
00d0  b8 04 0f fe c5 c0 00 ce  c7 8f f2 87 2b 23 ba dd  |+#..|
00e0  b5 a3 38 20 c6 f1 d3 00  00 03 00 00 03 00 00 03  |..8 |
00f0  00 00 03 00 00 12 8f f3  09 91 c0 00 00 03 00 05  ||
0100  14 00 00 03 02 26 00 00  03 01 37 00 00 03 00 d4  |.&7.|
0110  00 00 03 00 c9 00 00 03  00 e2 00 00 03 00 fe 00  ||
0120  00 03 01 32 00 00 03 02  1a 00 00 04 04 00 00 06  |...2|
0130  28 00 00 0e c0 00 00 03  00 00 03 00 00 03 00 00  |(...|
0140  03 00 00 03 00 00 03 00  00 03 00 00 03 00 00 03  ||

Normal frame:

0250  00 03 00 00 03 00 00 03  00 00 03 00 00 03 00 00  ||
0260  03 00 00 03 00 00 03 00  01 01 00 00 00 01 06 01  ||  
<- SEI
0270  04 00 00 03 02 06 80 00  00 00 01 09 30 00 00 00  |0...|  
<- AUD
0280  01 21 e0 26 3f 00 00 03  00 00 03 00 00 03 00 00  |.!.&?...|  
<- Non-IDR slice
0290  03 00 00 03 00 00 03 00  00 03 00 00 03 00 00 03  ||

(Braswell N3700, i965 driver from git as of an hour ago.)

> 
> 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;

You don't need a separate function - this is what write_extra_header is for.


> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 47

Re: [FFmpeg-devel] [PATCH] avcodec/decode: also check for FF_CODEC_CAP_SETS_PKT_DTS in audio decoders

[Michael Niedermayer]

On Mon, May 01, 2017 at 08:32:47PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/decode.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

should be ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
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.

[Mark Thompson]

On 02/05/17 01:10, Jun Zhao wrote:
> 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. 

With current settings (i.e. MAX_LAYERS is 1 and vps_num_layer_sets_minus1 is 0) 
none of the layer_id_included_flag are written - that code is only present now 
so that the function matches the standard.

If you want to add more layers / layer sets, then indeed the constants would 
need to be changed to reflect that.

>>> 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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream

[Mark Thompson]

On 02/05/17 21:23, Mark Thompson wrote:
> On 02/05/17 03:49, Jun Zhao wrote:
>> 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(+)
> 
> ...

I should probably also note that there are plans to replace all the raw 
bitstream writing code upstream, with common code shared with other cases 
(bitstream filters) rather than having it ad-hoc inside the individual VAAPI 
encode files.

  (As yet 
very incomplete, VAAPI not yet touched.)

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Michael Niedermayer]

On Tue, May 02, 2017 at 06:49:07PM +0200, Paul B Mahol wrote:
> On 5/2/17, Thomas Mundt  wrote:
> > 2017-04-29 18:15 GMT+02:00 Thomas Mundt :
> >
> >> 2017-04-20 23:54 GMT+02:00 Thomas Mundt :
> >>
> >>> Patch attached...
> >>>
> >>> Ping
> >>
> >
> > Ping
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> Michael? Gonna apply this?

i would but james was faster :)

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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] This fixes ISO date formatissue when manifest created by this muxer is not playable in most players. This ensures compatibility with dash standard. Tested on many players (d

[Aaron Levinson]

On 5/1/2017 11:06 PM, MFojtak wrote:

Currently this muxer does not work at all. I don't know if 000Z would make
it compatible with more player as I don't know any. However, adding Z makes
it compatible with most popular ones like dash.js and shaka. Having this
muxer working properly would bring more attention to it and maybe in the
future somebody tests it with more players. But for now I suggest to roll
out the change and "unblock" this muxer for some real wold use. Also, it
would be great to make this muxer codec and container agnostic as it works
with h264 and mp4 only. But again, nobody would bother if the muxer doesn't
work at all with browsers.


I think your original patch is fine, and I only offered the possibility 
that adding ".000Z" might be even better than just "Z".  I don't have 
push privileges, so I can't commit your patch, but hopefully someone 
else will do so.


Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] This fixes ISO date formatissue when manifest created by this muxer is not playable in most players. This ensures compatibility with dash standard. Tested on many players (d

[wm4]

On Tue, 2 May 2017 14:17:33 -0700
Aaron Levinson  wrote:

> On 5/1/2017 11:06 PM, MFojtak wrote:
> > Currently this muxer does not work at all. I don't know if 000Z would make
> > it compatible with more player as I don't know any. However, adding Z makes
> > it compatible with most popular ones like dash.js and shaka. Having this
> > muxer working properly would bring more attention to it and maybe in the
> > future somebody tests it with more players. But for now I suggest to roll
> > out the change and "unblock" this muxer for some real wold use. Also, it
> > would be great to make this muxer codec and container agnostic as it works
> > with h264 and mp4 only. But again, nobody would bother if the muxer doesn't
> > work at all with browsers.  
> 
> I think your original patch is fine, and I only offered the possibility 
> that adding ".000Z" might be even better than just "Z".  I don't have 
> push privileges, so I can't commit your patch, but hopefully someone 
> else will do so.

Before someone pushes it, please fix the commit message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3 1/9] hevcdec: remove HEVCContext usage from hevc_sei

[James Almer]

Based on the H264 SEI implementation.

Signed-off-by: James Almer 
---
 libavcodec/hevc_parser.c |   9 +--
 libavcodec/hevc_refs.c   |   4 +-
 libavcodec/hevc_sei.c| 144 ++-
 libavcodec/hevcdec.c |  90 ++---
 libavcodec/hevcdec.h |  94 +++
 5 files changed, 177 insertions(+), 164 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 310428d0ff..f82f9fdf5e 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -192,6 +192,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 GetBitContext  *gb;
 SliceHeader*sh = &h->sh;
 HEVCParamSets *ps = &h->ps;
+HEVCSEIContext *sei = &h->sei;
 H2645Packet   *pkt = &ctx->pkt;
 const uint8_t *buf_end = buf + buf_size;
 int state = -1, i;
@@ -212,7 +213,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 
 h->avctx = avctx;
 
-ff_hevc_reset_sei(h);
+ff_hevc_reset_sei(sei);
 
 if (!buf_size)
 return 0;
@@ -265,7 +266,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 break;
 case HEVC_NAL_SEI_PREFIX:
 case HEVC_NAL_SEI_SUFFIX:
-ff_hevc_decode_nal_sei(h);
+ff_hevc_decode_nal_sei(gb, avctx, sei, ps, h->nal_unit_type);
 break;
 case HEVC_NAL_TRAIL_N:
 case HEVC_NAL_TRAIL_R:
@@ -290,8 +291,8 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 }
 
 sh->first_slice_in_pic_flag = get_bits1(gb);
-s->picture_structure = h->picture_struct;
-s->field_order = h->picture_struct;
+s->picture_structure = h->sei.picture_timing.picture_struct;
+s->field_order = h->sei.picture_timing.picture_struct;
 
 if (IS_IRAP(h)) {
 s->key_frame = 1;
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 9103c84686..6810ffaf17 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -109,8 +109,8 @@ static HEVCFrame *alloc_frame(HEVCContext *s)
 for (j = 0; j < frame->ctb_count; j++)
 frame->rpl_tab[j] = (RefPicListTab *)frame->rpl_buf->data;
 
-frame->frame->top_field_first  = s->picture_struct == 
AV_PICTURE_STRUCTURE_TOP_FIELD;
-frame->frame->interlaced_frame = (s->picture_struct == 
AV_PICTURE_STRUCTURE_TOP_FIELD) || (s->picture_struct == 
AV_PICTURE_STRUCTURE_BOTTOM_FIELD);
+frame->frame->top_field_first  = s->sei.picture_timing.picture_struct 
== AV_PICTURE_STRUCTURE_TOP_FIELD;
+frame->frame->interlaced_frame = (s->sei.picture_timing.picture_struct 
== AV_PICTURE_STRUCTURE_TOP_FIELD) || (s->sei.picture_timing.picture_struct == 
AV_PICTURE_STRUCTURE_BOTTOM_FIELD);
 
 if (s->avctx->hwaccel) {
 const AVHWAccel *hwaccel = s->avctx->hwaccel;
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index bb299d5a9f..679a18b3d8 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -53,13 +53,12 @@ enum HEVC_SEI_TYPE {
 SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
 };
 
-static int decode_nal_sei_decoded_picture_hash(HEVCContext *s)
+static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s, 
GetBitContext *gb)
 {
 int cIdx, i;
 uint8_t hash_type;
 //uint16_t picture_crc;
 //uint32_t picture_checksum;
-GetBitContext *gb = &s->HEVClc->gb;
 hash_type = get_bits(gb, 8);
 
 for (cIdx = 0; cIdx < 3/*((s->sps->chroma_format_idc == 0) ? 1 : 3)*/; 
cIdx++) {
@@ -78,9 +77,8 @@ static int decode_nal_sei_decoded_picture_hash(HEVCContext *s)
 return 0;
 }
 
-static int decode_nal_sei_mastering_display_info(HEVCContext *s)
+static int decode_nal_sei_mastering_display_info(HEVCSEIMasteringDisplay *s, 
GetBitContext *gb)
 {
-GetBitContext *gb = &s->HEVClc->gb;
 int i;
 // Mastering primaries
 for (i = 0; i < 3; i++) {
@@ -92,38 +90,35 @@ static int 
decode_nal_sei_mastering_display_info(HEVCContext *s)
 s->white_point[1] = get_bits(gb, 16);
 
 // Max and min luminance of mastering display
-s->max_mastering_luminance = get_bits_long(gb, 32);
-s->min_mastering_luminance = get_bits_long(gb, 32);
+s->max_luminance = get_bits_long(gb, 32);
+s->min_luminance = get_bits_long(gb, 32);
 
 // As this SEI message comes before the first frame that references it,
 // initialize the flag to 2 and decrement on IRAP access unit so it
 // persists for the coded video sequence (e.g., between two IRAPs)
-s->sei_mastering_display_info_present = 2;
+s->present = 2;
 return 0;
 }
 
-static int decode_nal_sei_content_light_info(HEVCContext *s)
+static int decode_nal_sei_content_light_info(HEVCSEIContentLight *s, 
GetBitContext *gb)
 {
-GetBitContext *gb = &s->HEVClc->gb;
 // Max and avera

[FFmpeg-devel] [PATCH v2 0/9] Removing HEVCContext depencencies

[James Almer]

Some changes and fixes suggested on IRC. Some patches are v3 as they have
been sent before outside the previous set.

James Almer (9):
  hevcdec: remove HEVCContext usage from hevc_sei
  hevcdec: move SEI message parsing into a separate header
  hevcdec: remove HEVCContext usage from ff_hevc_compute_poc()
  hevcdec: move SliceHeader struct definition to hevc_ps
  hevc_parser: use ff_h2645_packet_split() to parse NAL units
  hevc_parser: remove HEVCContext usage
  hevc_parser: move slice header parsing to its own function
  hevc_parse: decode SEI message NALUs in extradata
  doc/libav_merge: remove line about ADVANCED_PARSER

 doc/libav-merge.txt|   1 -
 libavcodec/Makefile|   4 +-
 libavcodec/hevc_parse.c|  21 ++-
 libavcodec/hevc_parse.h|   7 +-
 libavcodec/hevc_parser.c   | 415 -
 libavcodec/hevc_ps.c   |  23 +++
 libavcodec/hevc_ps.h   |  88 ++
 libavcodec/hevc_refs.c |  27 +--
 libavcodec/hevc_sei.c  | 193 +
 libavcodec/hevc_sei.h  | 125 ++
 libavcodec/hevcdec.c   |  94 +-
 libavcodec/hevcdec.h   | 137 +--
 libavcodec/mediacodecdec.c |   4 +-
 13 files changed, 532 insertions(+), 607 deletions(-)
 create mode 100644 libavcodec/hevc_sei.h

-- 
2.12.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/9] hevcdec: remove HEVCContext usage from ff_hevc_compute_poc()

[James Almer]

Move it to hevc_ps as well. This is in preparation for a following patch.

Signed-off-by: James Almer 
---
 libavcodec/hevc_parser.c |  2 +-
 libavcodec/hevc_ps.c | 23 +++
 libavcodec/hevc_ps.h |  5 +
 libavcodec/hevc_refs.c   | 23 ---
 libavcodec/hevcdec.c |  2 +-
 libavcodec/hevcdec.h |  5 -
 6 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index f82f9fdf5e..9e7fa621ce 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -379,7 +379,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 
 if (!IS_IDR(h)) {
 sh->pic_order_cnt_lsb = get_bits(gb, 
ps->sps->log2_max_poc_lsb);
-s->output_picture_number = h->poc = ff_hevc_compute_poc(h, 
sh->pic_order_cnt_lsb);
+s->output_picture_number = h->poc = 
ff_hevc_compute_poc(h->ps.sps, h->pocTid0, sh->pic_order_cnt_lsb, 
h->nal_unit_type);
 } else
 s->output_picture_number = h->poc = 0;
 
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 6d67dd9c69..b5a970e4f7 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1665,3 +1665,26 @@ err:
 av_buffer_unref(&pps_buf);
 return ret;
 }
+
+int ff_hevc_compute_poc(const HEVCSPS *sps, int pocTid0, int poc_lsb, int 
nal_unit_type)
+{
+int max_poc_lsb  = 1 << sps->log2_max_poc_lsb;
+int prev_poc_lsb = pocTid0 % max_poc_lsb;
+int prev_poc_msb = pocTid0 - prev_poc_lsb;
+int poc_msb;
+
+if (poc_lsb < prev_poc_lsb && prev_poc_lsb - poc_lsb >= max_poc_lsb / 2)
+poc_msb = prev_poc_msb + max_poc_lsb;
+else if (poc_lsb > prev_poc_lsb && poc_lsb - prev_poc_lsb > max_poc_lsb / 
2)
+poc_msb = prev_poc_msb - max_poc_lsb;
+else
+poc_msb = prev_poc_msb;
+
+// For BLA picture types, POCmsb is set to 0.
+if (nal_unit_type == HEVC_NAL_BLA_W_LP   ||
+nal_unit_type == HEVC_NAL_BLA_W_RADL ||
+nal_unit_type == HEVC_NAL_BLA_N_LP)
+poc_msb = 0;
+
+return poc_msb + poc_lsb;
+}
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index b0a17bc8f0..45ef9daf1f 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -344,4 +344,9 @@ int ff_hevc_decode_short_term_rps(GetBitContext *gb, 
AVCodecContext *avctx,
 int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
uint8_t *buf, int buf_size);
 
+/**
+ * Compute POC of the current frame and return it.
+ */
+int ff_hevc_compute_poc(const HEVCSPS *sps, int pocTid0, int poc_lsb, int 
nal_unit_type);
+
 #endif /* AVCODEC_HEVC_PS_H */
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 6810ffaf17..fc1385ca55 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -516,29 +516,6 @@ fail:
 return ret;
 }
 
-int ff_hevc_compute_poc(HEVCContext *s, int poc_lsb)
-{
-int max_poc_lsb  = 1 << s->ps.sps->log2_max_poc_lsb;
-int prev_poc_lsb = s->pocTid0 % max_poc_lsb;
-int prev_poc_msb = s->pocTid0 - prev_poc_lsb;
-int poc_msb;
-
-if (poc_lsb < prev_poc_lsb && prev_poc_lsb - poc_lsb >= max_poc_lsb / 2)
-poc_msb = prev_poc_msb + max_poc_lsb;
-else if (poc_lsb > prev_poc_lsb && poc_lsb - prev_poc_lsb > max_poc_lsb / 
2)
-poc_msb = prev_poc_msb - max_poc_lsb;
-else
-poc_msb = prev_poc_msb;
-
-// For BLA picture types, POCmsb is set to 0.
-if (s->nal_unit_type == HEVC_NAL_BLA_W_LP   ||
-s->nal_unit_type == HEVC_NAL_BLA_W_RADL ||
-s->nal_unit_type == HEVC_NAL_BLA_N_LP)
-poc_msb = 0;
-
-return poc_msb + poc_lsb;
-}
-
 int ff_hevc_frame_nb_refs(HEVCContext *s)
 {
 int ret = 0;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 2a02edab28..8f235b0be1 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -541,7 +541,7 @@ static int hls_slice_header(HEVCContext *s)
 int poc, pos;
 
 sh->pic_order_cnt_lsb = get_bits(gb, s->ps.sps->log2_max_poc_lsb);
-poc = ff_hevc_compute_poc(s, sh->pic_order_cnt_lsb);
+poc = ff_hevc_compute_poc(s->ps.sps, s->pocTid0, 
sh->pic_order_cnt_lsb, s->nal_unit_type);
 if (!sh->first_slice_in_pic_flag && poc != s->poc) {
 av_log(s->avctx, AV_LOG_WARNING,
"Ignoring POC change between slices: %d -> %d\n", 
s->poc, poc);
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index cc7fc7e35f..d8494ee6b1 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -579,11 +579,6 @@ void ff_hevc_clear_refs(HEVCContext *s);
  */
 void ff_hevc_flush_dpb(HEVCContext *s);
 
-/**
- * Compute POC of the current frame and return it.
- */
-int ff_hevc_compute_poc(HEVCContext *s, int poc_lsb);
-
 RefPicList *ff_hevc_get_ref_list(HEVCContext *s, HEVCFrame *frame,
  int x0, int y0);
 
-- 
2.12.1

_

[FFmpeg-devel] [PATCH v3 2/9] hevcdec: move SEI message parsing into a separate header

[James Almer]

It doesn't depend on hevcdec anymore.

Signed-off-by: James Almer 
---
 libavcodec/hevc_sei.c |  47 ---
 libavcodec/hevc_sei.h | 125 ++
 libavcodec/hevcdec.h  |  67 +--
 3 files changed, 136 insertions(+), 103 deletions(-)
 create mode 100644 libavcodec/hevc_sei.h

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 679a18b3d8..c5054bfaab 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -23,35 +23,8 @@
  */
 
 #include "golomb.h"
-#include "hevcdec.h"
-
-enum HEVC_SEI_TYPE {
-SEI_TYPE_BUFFERING_PERIOD = 0,
-SEI_TYPE_PICTURE_TIMING   = 1,
-SEI_TYPE_PAN_SCAN_RECT= 2,
-SEI_TYPE_FILLER_PAYLOAD   = 3,
-SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35   = 4,
-SEI_TYPE_USER_DATA_UNREGISTERED   = 5,
-SEI_TYPE_RECOVERY_POINT   = 6,
-SEI_TYPE_SCENE_INFO   = 9,
-SEI_TYPE_FULL_FRAME_SNAPSHOT  = 15,
-SEI_TYPE_PROGRESSIVE_REFINEMENT_SEGMENT_START = 16,
-SEI_TYPE_PROGRESSIVE_REFINEMENT_SEGMENT_END   = 17,
-SEI_TYPE_FILM_GRAIN_CHARACTERISTICS   = 19,
-SEI_TYPE_POST_FILTER_HINT = 22,
-SEI_TYPE_TONE_MAPPING_INFO= 23,
-SEI_TYPE_FRAME_PACKING= 45,
-SEI_TYPE_DISPLAY_ORIENTATION  = 47,
-SEI_TYPE_SOP_DESCRIPTION  = 128,
-SEI_TYPE_ACTIVE_PARAMETER_SETS= 129,
-SEI_TYPE_DECODING_UNIT_INFO   = 130,
-SEI_TYPE_TEMPORAL_LEVEL0_INDEX= 131,
-SEI_TYPE_DECODED_PICTURE_HASH = 132,
-SEI_TYPE_SCALABLE_NESTING = 133,
-SEI_TYPE_REGION_REFRESH_INFO  = 134,
-SEI_TYPE_MASTERING_DISPLAY_INFO   = 137,
-SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
-};
+#include "hevc_ps.h"
+#include "hevc_sei.h"
 
 static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s, 
GetBitContext *gb)
 {
@@ -294,26 +267,26 @@ static int decode_nal_sei_prefix(GetBitContext *gb, 
HEVCSEIContext *s, const HEV
 switch (type) {
 case 256:  // Mismatched value from HM 8.1
 return decode_nal_sei_decoded_picture_hash(&s->picture_hash, gb);
-case SEI_TYPE_FRAME_PACKING:
+case HEVC_SEI_TYPE_FRAME_PACKING:
 return decode_nal_sei_frame_packing_arrangement(&s->frame_packing, gb);
-case SEI_TYPE_DISPLAY_ORIENTATION:
+case HEVC_SEI_TYPE_DISPLAY_ORIENTATION:
 return decode_nal_sei_display_orientation(&s->display_orientation, gb);
-case SEI_TYPE_PICTURE_TIMING:
+case HEVC_SEI_TYPE_PICTURE_TIMING:
 {
 int ret = decode_pic_timing(s, gb, ps, logctx);
 av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
 skip_bits(gb, 8 * size);
 return ret;
 }
-case SEI_TYPE_MASTERING_DISPLAY_INFO:
+case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
 return decode_nal_sei_mastering_display_info(&s->mastering_display, 
gb);
-case SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
+case HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
 return decode_nal_sei_content_light_info(&s->content_light, gb);
-case SEI_TYPE_ACTIVE_PARAMETER_SETS:
+case HEVC_SEI_TYPE_ACTIVE_PARAMETER_SETS:
 active_parameter_sets(s, gb, logctx);
 av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
 return 0;
-case SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
+case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
 return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
 default:
 av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
@@ -326,7 +299,7 @@ static int decode_nal_sei_suffix(GetBitContext *gb, 
HEVCSEIContext *s,
  int type, int size, void *logctx)
 {
 switch (type) {
-case SEI_TYPE_DECODED_PICTURE_HASH:
+case HEVC_SEI_TYPE_DECODED_PICTURE_HASH:
 return decode_nal_sei_decoded_picture_hash(&s->picture_hash, gb);
 default:
 av_log(logctx, AV_LOG_DEBUG, "Skipped SUFFIX SEI %d\n", type);
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
new file mode 100644
index 00..2687f449bf
--- /dev/null
+++ b/libavcodec/hevc_sei.h
@@ -0,0 +1,125 @@
+/*
+ * HEVC Supplementary Enhancement Information messages
+ *
+ * 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 F

[FFmpeg-devel] [PATCH v2 4/9] hevcdec: move SliceHeader struct definition to hevc_ps

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/hevc_ps.h | 83 
 libavcodec/hevcdec.h | 83 
 2 files changed, 83 insertions(+), 83 deletions(-)

diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 45ef9daf1f..016f0075d4 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -39,6 +39,89 @@ typedef struct ShortTermRPS {
 uint8_t used[32];
 } ShortTermRPS;
 
+typedef struct LongTermRPS {
+int poc[32];
+uint8_t used[32];
+uint8_t nb_refs;
+} LongTermRPS;
+
+typedef struct SliceHeader {
+unsigned int pps_id;
+
+///< address (in raster order) of the first block in the current slice 
segment
+unsigned int   slice_segment_addr;
+///< address (in raster order) of the first block in the current slice
+unsigned int   slice_addr;
+
+enum HEVCSliceType slice_type;
+
+int pic_order_cnt_lsb;
+
+uint8_t first_slice_in_pic_flag;
+uint8_t dependent_slice_segment_flag;
+uint8_t pic_output_flag;
+uint8_t colour_plane_id;
+
+///< RPS coded in the slice header itself is stored here
+int short_term_ref_pic_set_sps_flag;
+int short_term_ref_pic_set_size;
+ShortTermRPS slice_rps;
+const ShortTermRPS *short_term_rps;
+int long_term_ref_pic_set_size;
+LongTermRPS long_term_rps;
+unsigned int list_entry_lx[2][32];
+
+uint8_t rpl_modification_flag[2];
+uint8_t no_output_of_prior_pics_flag;
+uint8_t slice_temporal_mvp_enabled_flag;
+
+unsigned int nb_refs[2];
+
+uint8_t slice_sample_adaptive_offset_flag[3];
+uint8_t mvd_l1_zero_flag;
+
+uint8_t cabac_init_flag;
+uint8_t disable_deblocking_filter_flag; ///< 
slice_header_disable_deblocking_filter_flag
+uint8_t slice_loop_filter_across_slices_enabled_flag;
+uint8_t collocated_list;
+
+unsigned int collocated_ref_idx;
+
+int slice_qp_delta;
+int slice_cb_qp_offset;
+int slice_cr_qp_offset;
+
+uint8_t cu_chroma_qp_offset_enabled_flag;
+
+int beta_offset;///< beta_offset_div2 * 2
+int tc_offset;  ///< tc_offset_div2 * 2
+
+unsigned int max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
+
+unsigned *entry_point_offset;
+int * offset;
+int * size;
+int num_entry_point_offsets;
+
+int8_t slice_qp;
+
+uint8_t luma_log2_weight_denom;
+int16_t chroma_log2_weight_denom;
+
+int16_t luma_weight_l0[16];
+int16_t chroma_weight_l0[16][2];
+int16_t chroma_weight_l1[16][2];
+int16_t luma_weight_l1[16];
+
+int16_t luma_offset_l0[16];
+int16_t chroma_offset_l0[16][2];
+
+int16_t luma_offset_l1[16];
+int16_t chroma_offset_l1[16][2];
+
+int slice_ctb_addr_rs;
+} SliceHeader;
+
 typedef struct HEVCWindow {
 unsigned int left_offset;
 unsigned int right_offset;
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index d8494ee6b1..d5d6bbcdb6 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -227,12 +227,6 @@ enum ScanType {
 SCAN_VERT,
 };
 
-typedef struct LongTermRPS {
-int poc[32];
-uint8_t used[32];
-uint8_t nb_refs;
-} LongTermRPS;
-
 typedef struct RefPicList {
 struct HEVCFrame *ref[HEVC_MAX_REFS];
 int list[HEVC_MAX_REFS];
@@ -244,83 +238,6 @@ typedef struct RefPicListTab {
 RefPicList refPicList[2];
 } RefPicListTab;
 
-typedef struct SliceHeader {
-unsigned int pps_id;
-
-///< address (in raster order) of the first block in the current slice 
segment
-unsigned int   slice_segment_addr;
-///< address (in raster order) of the first block in the current slice
-unsigned int   slice_addr;
-
-enum HEVCSliceType slice_type;
-
-int pic_order_cnt_lsb;
-
-uint8_t first_slice_in_pic_flag;
-uint8_t dependent_slice_segment_flag;
-uint8_t pic_output_flag;
-uint8_t colour_plane_id;
-
-///< RPS coded in the slice header itself is stored here
-int short_term_ref_pic_set_sps_flag;
-int short_term_ref_pic_set_size;
-ShortTermRPS slice_rps;
-const ShortTermRPS *short_term_rps;
-int long_term_ref_pic_set_size;
-LongTermRPS long_term_rps;
-unsigned int list_entry_lx[2][32];
-
-uint8_t rpl_modification_flag[2];
-uint8_t no_output_of_prior_pics_flag;
-uint8_t slice_temporal_mvp_enabled_flag;
-
-unsigned int nb_refs[2];
-
-uint8_t slice_sample_adaptive_offset_flag[3];
-uint8_t mvd_l1_zero_flag;
-
-uint8_t cabac_init_flag;
-uint8_t disable_deblocking_filter_flag; ///< 
slice_header_disable_deblocking_filter_flag
-uint8_t slice_loop_filter_across_slices_enabled_flag;
-uint8_t collocated_list;
-
-unsigned int collocated_ref_idx;
-
-int slice_qp_delta;
-int slice_cb_qp_offset;
-int slice_cr_qp_offset;
-
-uint8_t cu_chroma_qp_offset_enabled_flag;
-
-int beta_offset;///< beta_offset_div2 * 2
-int tc_offset;  ///< tc_offset_div2 * 2
-
-unsigned int max_num_merge_

[FFmpeg-devel] [PATCH v3 5/9] hevc_parser: use ff_h2645_packet_split() to parse NAL units

[James Almer]

This simplifies the code considerably.

Signed-off-by: James Almer 
---
 libavcodec/hevc_parser.c | 50 ++--
 1 file changed, 10 insertions(+), 40 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 9e7fa621ce..501cbc3498 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -193,11 +193,8 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 SliceHeader*sh = &h->sh;
 HEVCParamSets *ps = &h->ps;
 HEVCSEIContext *sei = &h->sei;
-H2645Packet   *pkt = &ctx->pkt;
-const uint8_t *buf_end = buf + buf_size;
-int state = -1, i;
-H2645NAL *nal;
 int is_global = buf == avctx->extradata;
+int i, ret;
 
 if (!h->HEVClc)
 h->HEVClc = av_mallocz(sizeof(HEVCLocalContext));
@@ -215,44 +212,18 @@ static inline int parse_nal_units(AVCodecParserContext 
*s, const uint8_t *buf,
 
 ff_hevc_reset_sei(sei);
 
-if (!buf_size)
-return 0;
-
-if (pkt->nals_allocated < 1) {
-H2645NAL *tmp = av_realloc_array(pkt->nals, 1, sizeof(*tmp));
-if (!tmp)
-return AVERROR(ENOMEM);
-pkt->nals = tmp;
-memset(pkt->nals, 0, sizeof(*tmp));
-pkt->nals_allocated = 1;
-}
-
-nal = &pkt->nals[0];
+ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, 0, 0,
+AV_CODEC_ID_HEVC, 1);
+if (ret < 0)
+return ret;
 
-for (;;) {
-int src_length, consumed;
-int ret;
+for (i = 0; i < ctx->pkt.nb_nals; i++) {
+H2645NAL *nal = &ctx->pkt.nals[i];
 int num = 0, den = 0;
-buf = avpriv_find_start_code(buf, buf_end, &state);
-if (--buf + 2 >= buf_end)
-break;
-src_length = buf_end - buf;
-
-h->nal_unit_type = (*buf >> 1) & 0x3f;
-h->temporal_id   = (*(buf + 1) & 0x07) - 1;
-if (h->nal_unit_type <= HEVC_NAL_CRA_NUT) {
-// Do not walk the whole buffer just to decode slice segment header
-if (src_length > 20)
-src_length = 20;
-}
-
-consumed = ff_h2645_extract_rbsp(buf, src_length, nal, 1);
-if (consumed < 0)
-return consumed;
 
-ret = init_get_bits8(gb, nal->data + 2, nal->size);
-if (ret < 0)
-return ret;
+h->nal_unit_type = nal->type;
+h->temporal_id   = nal->temporal_id;
+*gb = nal->gb;
 
 switch (h->nal_unit_type) {
 case HEVC_NAL_VPS:
@@ -395,7 +366,6 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 
 return 0; /* no need to evaluate the rest */
 }
-buf += consumed;
 }
 /* didn't find a picture! */
 if (!is_global)
-- 
2.12.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 9/9] doc/libav_merge: remove line about ADVANCED_PARSER

[James Almer]

It's been addressed.

Signed-off-by: James Almer 
---
 doc/libav-merge.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
index 6f052ec2eb..da9e2757f5 100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@ -105,7 +105,6 @@ Collateral damage that needs work locally:
 
 - Merge proresdec2.c and proresdec_lgpl.c
 - Merge proresenc_anatoliy.c and proresenc_kostya.c
-- Remove ADVANCED_PARSER in libavcodec/hevc_parser.c
 - Fix MIPS AC3 downmix
 - hlsenc encryption support may need some adjustment (see edc43c571d)
 
-- 
2.12.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3 6/9] hevc_parser: remove HEVCContext usage

[James Almer]

This gets rid of the duplicate, limited parser.

Signed-off-by: James Almer 
---
 libavcodec/Makefile  |   2 +-
 libavcodec/hevc_parser.c | 177 +--
 2 files changed, 33 insertions(+), 146 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 21cd81c6b2..f879a17635 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -953,7 +953,7 @@ OBJS-$(CONFIG_GSM_PARSER)  += gsm_parser.o
 OBJS-$(CONFIG_H261_PARSER) += h261_parser.o
 OBJS-$(CONFIG_H263_PARSER) += h263_parser.o
 OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o h264data.o
-OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o
+OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o hevc_sei.o
 OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o
 OBJS-$(CONFIG_MLP_PARSER)  += mlp_parser.o mlp.o
 OBJS-$(CONFIG_MPEG4VIDEO_PARSER)   += mpeg4video_parser.o h263.o \
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

[FFmpeg-devel] [PATCH v2 8/9] hevc_parse: decode SEI message NALUs in extradata

[James Almer]

They may be available in hvcc style extradata.

Based on a patch by Hendrik Leppkes.

Signed-off-by: James Almer 
---
 libavcodec/Makefile|  6 +++---
 libavcodec/hevc_parse.c| 21 ++---
 libavcodec/hevc_parse.h|  7 ---
 libavcodec/hevcdec.c   |  2 +-
 libavcodec/mediacodecdec.c |  4 +++-
 5 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f879a17635..5ebba99ffb 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -80,7 +80,7 @@ OBJS-$(CONFIG_H264DSP) += h264dsp.o h264idct.o
 OBJS-$(CONFIG_H264PARSE)   += h264_parse.o h2645_parse.o h264_ps.o
 OBJS-$(CONFIG_H264PRED)+= h264pred.o
 OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
-OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o hevc_ps.o
+OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o hevc_ps.o 
hevc_sei.o
 OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
 OBJS-$(CONFIG_HUFFMAN) += huffman.o
 OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
@@ -338,7 +338,7 @@ OBJS-$(CONFIG_H264_VAAPI_ENCODER)  += 
vaapi_encode_h264.o vaapi_encode_h26x.
 OBJS-$(CONFIG_H264_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o
 OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
 OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
-OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o hevc_sei.o \
+OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
   hevc_cabac.o hevc_refs.o hevcpred.o  
  \
   hevcdsp.o hevc_filter.o hevc_data.o
 OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuvid.o
@@ -953,7 +953,7 @@ OBJS-$(CONFIG_GSM_PARSER)  += gsm_parser.o
 OBJS-$(CONFIG_H261_PARSER) += h261_parser.o
 OBJS-$(CONFIG_H263_PARSER) += h263_parser.o
 OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o h264data.o
-OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o hevc_sei.o
+OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o
 OBJS-$(CONFIG_MJPEG_PARSER)+= mjpeg_parser.o
 OBJS-$(CONFIG_MLP_PARSER)  += mlp_parser.o mlp.o
 OBJS-$(CONFIG_MPEG4VIDEO_PARSER)   += mpeg4video_parser.o h263.o \
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;
-

[FFmpeg-devel] [PATCH v2 7/9] hevc_parser: move slice header parsing to its own function

[James Almer]

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/dcaenc: Initial implementation of ADPCM encoding for DCA encoder

[Даниил Чередник]

Hi.

This patch introduces initial implementation of subband ADPCM encoding for
DCA codec.

Some results:

sample:

https://yadi.sk/d/B_3sVskM3HZiWK - original

https://yadi.sk/d/7CK47Nt63HZiWf - without adpcm

https://yadi.sk/d/25q1JDV93HZiWq - with adpcm

chirp tone:

https://yadi.sk/i/tZKHoJ1d3HZk4c

Right now this feature is disabled by default. But it is ready to try
using -dca_adpcm 1 option.

There are some issues, should be solved before enabling this feature by
default:

1. Speed up: I am trying to find best filter in each subband. But with real
signal, usually only few subbands has significant prediction gain. The idea
is try to analyze FFT spectrum (which is already calculated), to check is
particular subband looks like tonal or noise. If subband is noise like - do
not try to find best LPC predictor.

2. Modify psychoacoustic to use prediction gain for bit allocation. Right
now ADPCM encoded block can get some extra bits.

3. Tuning the prediction gain threshold.


Thank you.
-- 
Daniil Cherednik


0001-avcodec-dcaenc-Initial-implementation-of-ADPCM-encod.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Fix libopus detection

[Aaron Levinson]

On 4/25/2017 1:19 AM, Carl Eugen Hoyos wrote:

2017-04-13 1:08 GMT+02:00 Carl Eugen Hoyos :

2017-03-30 1:52 GMT+02:00 James Almer :

On 3/29/2017 7:47 PM, Carl Eugen Hoyos wrote:

Hi!

Attached patch fixes a compilation error here.

Please test for success, Carl Eugen


0001-configure-Fix-libopus-detection.patch


From 600b568651c60f8de609f211c814b5cd0640e584 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 30 Mar 2017 00:45:06 +0200
Subject: [PATCH] configure: Fix libopus detection.

Avoids a compilation error for old libopus.
Regression since 37941878
---
 configure |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a84b126..76a287e 100755
--- a/configure
+++ b/configure
@@ -5797,7 +5797,7 @@ enabled libopenjpeg   && { { check_lib 
openjpeg-2.1/openjpeg.h opj_version -
{ check_lib openjpeg.h opj_version -lopenjpeg 
-DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
die "ERROR: libopenjpeg not found"; }
 enabled libopenmpt&& require_pkg_config "libopenmpt >= 0.2.6557" 
libopenmpt/libopenmpt.h openmpt_module_create
-enabled libopus   && require_pkg_config opus opus_multistream.h 
opus_multistream_decoder_create
+enabled libopus   && require_pkg_config opus opus_multistream.h 
opus_multistream_surround_encoder_create


Should be ok,



but strictly speaking, this function is needed by the
encoder and not the decoder. Something like

enabled libopus   && {
enabled libopus_decoder && {
require_pkg_config opus opus_multistream.h 
opus_multistream_decoder_create
}
enabled libopus_encoder && {
use_pkg_config "opus >= 1.1" opus_multistream.h 
opus_multistream_surround_encoder_create ||
disable libopus_encoder;
}
}


Please commit this if you prefer it.


Ping.


Perhaps you could submit a new patch that modifies configure in the 
fashion suggested by James Almer.  Technically, it is possible to enable 
the libopus decoder independently of the libopus encoder, and if that is 
done, it won't build libopusenc.c.  But, with your original patch, it 
won't even permit configure to succeed even though such a build would be 
possible.  It is true that the approach currently taken in configure 
doesn't distinguish between encoding and decoding, but the patch as 
originally proposed just trades decoding API requirements for encoding 
API requirements.


Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Clarification about bits_per_coded_sample vs bits_per_raw_sample

[Shawn Singh]

Hello,

We are trying to understand two fields in AVCodecParameters:
 bits_per_coded_sample and bits_per_raw_sample.

In the comments in libavcodec/avcodec.h, bits_per_coded_sample is described
as "the bitrate per sample".   This sounds like (encoded bitrate / sample
rate), for example 128 kbps 44.1 kHz audio stream would be 3 bits per coded
audio sample.  But, the code usage suggests that this field is actually
"the bit depth of each sample, if the sample was uncompressed", which is
also similar to the comments and usage for bits_per_raw_sample.  For
example, the mov.c demuxing initializes bits_per_coded_sample when parsing
the "sample size" field of the mp4 AudioSampleEntry (in the stsd atom, for
both audio and video).

Various codecs/formats initialize one value, or the other, or both in
different times.  For example, pcm.c audio codec sets bits_per_coded_sample
on encoding, and bits_per_raw_sample on decoding.  But the mov.c demuxer
and movenc.c muxer both use bits_per_coded_sample for muxing.

So, what really is the difference between these two values?   Is it
possible that these fields should just be merged into one field?   Or if
there is a pattern we don't see, perhaps only the comments need to be
updated?

Best Regards,
Shawn Singh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 1 May 2017 15:29:22 -0300
James Almer  wrote:

> 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

Rather tricky to fix, so I didn't. The problem is that the filter graph
remains unconfigured, so it can't know about unconnected outputs. It
remains unconfigured because the first input file is connected to two
filters (one trivial that keeps shuffling input to the output file, and
one connected to the unconfigured graph). To get the graph configured,
the second input file would have to decode 1 frame - this doesn't
happen because there's nothing in ffmpeg.c scheduling that would make
the second input file produce output.

The scheduling should be fixed. In theory it would be best to move the
input "duplication" (single input to several filter inputs) into
libavfilter, and make libavfilter do proper data flow that blocks
instead of queuing up frames until OOM.

but I'm not sure how to do that, so I posted a hacky fix for it that
checks for unconnected outputs on start, instead of in the old place.

> >>> https://trac.ffmpeg.org/ticket/6318

Works here, I suspect it was the same as one of the other issues that
was fixed recently.

> >>>
> >>> 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

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg: check for unconnected outputs

[wm4]

Fixes e.g.:

ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex 
"[0:v][1:v]psnr[out]" -f null none
---
 ffmpeg.h|  1 +
 ffmpeg_filter.c | 15 +++
 ffmpeg_opt.c|  2 ++
 3 files changed, 18 insertions(+)

diff --git a/ffmpeg.h b/ffmpeg.h
index 4d0456c1fb..d34561275a 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -638,6 +638,7 @@ void choose_sample_fmt(AVStream *st, AVCodec *codec);
 
 int configure_filtergraph(FilterGraph *fg);
 int configure_output_filter(FilterGraph *fg, OutputFilter *ofilter, 
AVFilterInOut *out);
+void check_filter_outputs(void);
 int ist_in_filtergraph(FilterGraph *fg, InputStream *ist);
 int filtergraph_is_simple(FilterGraph *fg);
 int init_simple_filtergraph(InputStream *ist, OutputStream *ost);
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 896161a869..817f48f473 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -678,6 +678,21 @@ int configure_output_filter(FilterGraph *fg, OutputFilter 
*ofilter, AVFilterInOu
 }
 }
 
+void check_filter_outputs(void)
+{
+int i;
+for (i = 0; i < nb_filtergraphs; i++) {
+int n;
+for (n = 0; n < filtergraphs[i]->nb_outputs; n++) {
+OutputFilter *output = filtergraphs[i]->outputs[n];
+if (!output->ost) {
+av_log(NULL, AV_LOG_FATAL, "Filter %s has an unconnected 
output\n", output->name);
+exit_program(1);
+}
+}
+}
+}
+
 static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
 {
 AVFormatContext *avf = input_files[ist->file_index]->ctx;
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index d1fe8742ff..e73a61059f 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3260,6 +3260,8 @@ int ffmpeg_parse_options(int argc, char **argv)
 goto fail;
 }
 
+check_filter_outputs();
+
 fail:
 uninit_parse_context(&octx);
 if (ret < 0) {
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Clarification about bits_per_coded_sample vs bits_per_raw_sample

[wm4]

On Tue, 2 May 2017 18:01:37 -0400
Shawn Singh  wrote:

> Hello,
> 
> We are trying to understand two fields in AVCodecParameters:
>  bits_per_coded_sample and bits_per_raw_sample.
> 
> In the comments in libavcodec/avcodec.h, bits_per_coded_sample is described
> as "the bitrate per sample".   This sounds like (encoded bitrate / sample
> rate), for example 128 kbps 44.1 kHz audio stream would be 3 bits per coded
> audio sample.  But, the code usage suggests that this field is actually
> "the bit depth of each sample, if the sample was uncompressed", which is
> also similar to the comments and usage for bits_per_raw_sample.  For
> example, the mov.c demuxing initializes bits_per_coded_sample when parsing
> the "sample size" field of the mp4 AudioSampleEntry (in the stsd atom, for
> both audio and video).
> 
> Various codecs/formats initialize one value, or the other, or both in
> different times.  For example, pcm.c audio codec sets bits_per_coded_sample
> on encoding, and bits_per_raw_sample on decoding.  But the mov.c demuxer
> and movenc.c muxer both use bits_per_coded_sample for muxing.
> 
> So, what really is the difference between these two values?   Is it
> possible that these fields should just be merged into one field?   Or if
> there is a pattern we don't see, perhaps only the comments need to be
> updated?

That is indeed not very clear. Here's my guess (from my hazy memory and
a superficial look at the code):

bits_per_coded_sample is the "proper" value, and used as parameter for
the decoder, while bits_per_raw_sample signals that not all bits in the
_decoded_ data are used. For example, a codec could use
bits_per_codec_sample as a mandatory parameter for the decoder (and
that tells the decoder something about how a bitstream needs to be
decoded). On the other hand, it might set bits_per_raw_sample to signal
that the decoded PCM stream has a certain bit resolution. For example,
some codecs support 24 bit audio, which is output as 32 bits, but with
bits_per_raw_sample set to 24 (the 8 LSBs will be set to 0).

Hopefully others have better explanations.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: port to the new bitstream filter API

[James Almer]

On 4/28/2017 9:27 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/concatdec.c | 94 
> -
>  1 file changed, 30 insertions(+), 64 deletions(-)

Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/decode: also check for FF_CODEC_CAP_SETS_PKT_DTS in audio decoders

[James Almer]

On 5/2/2017 5:38 PM, Michael Niedermayer wrote:
> On Mon, May 01, 2017 at 08:32:47PM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/decode.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> should be ok
> 
> thx

Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] cuvid: support AVCodecContext.hw_device_ctx API

[wm4]

This is a newer API that is intended for decoders like the cuvid
wrapper. Until now, the wrapper required to set an awkward
"incomplete" hw_frames_ctx to set the device. Now the device
can be set directly, and the user can get AV_PIX_FMT_CUDA output
for a specific device simply by setting hw_device_ctx.

This still does a dummy ff_get_format() call at init time, and should
be fully backward compatible.
---
Not sure how to test correctly - it worked with mpv even when I
accidentally didn't use the correct VO device.
---
 libavcodec/cuvid.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 288083423e..3453003965 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -802,9 +802,17 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
 goto error;
 }
 } else {
-ret = av_hwdevice_ctx_create(&ctx->hwdevice, AV_HWDEVICE_TYPE_CUDA, 
ctx->cu_gpu, NULL, 0);
-if (ret < 0)
-goto error;
+if (avctx->hw_device_ctx) {
+ctx->hwdevice = av_buffer_ref(avctx->hw_device_ctx);
+if (!ctx->hwdevice) {
+ret = AVERROR(ENOMEM);
+goto error;
+}
+} else {
+ret = av_hwdevice_ctx_create(&ctx->hwdevice, 
AV_HWDEVICE_TYPE_CUDA, ctx->cu_gpu, NULL, 0);
+if (ret < 0)
+goto error;
+}
 
 ctx->hwframe = av_hwframe_ctx_alloc(ctx->hwdevice);
 if (!ctx->hwframe) {
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: port to the new bitstream filter API

[wm4]

On Fri, 28 Apr 2017 21:27:56 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavformat/concatdec.c | 94 
> -
>  1 file changed, 30 insertions(+), 64 deletions(-)
> 
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index dd52e4d366..fa9443ff78 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -34,8 +34,7 @@ typedef enum ConcatMatchMode {
>  } ConcatMatchMode;
>  
>  typedef struct ConcatStream {
> -AVBitStreamFilterContext *bsf;
> -AVCodecContext *avctx;
> +AVBSFContext *bsf;
>  int out_stream_index;
>  } ConcatStream;
>  
> @@ -196,7 +195,8 @@ static int detect_stream_specific(AVFormatContext *avf, 
> int idx)
>  ConcatContext *cat = avf->priv_data;
>  AVStream *st = cat->avf->streams[idx];
>  ConcatStream *cs = &cat->cur_file->streams[idx];
> -AVBitStreamFilterContext *bsf;
> +const AVBitStreamFilter *filter;
> +AVBSFContext *bsf;
>  int ret;
>  
>  if (cat->auto_convert && st->codecpar->codec_id == AV_CODEC_ID_H264) {
> @@ -206,29 +206,28 @@ static int detect_stream_specific(AVFormatContext *avf, 
> int idx)
>  return 0;
>  av_log(cat->avf, AV_LOG_INFO,
> "Auto-inserting h264_mp4toannexb bitstream filter\n");
> -if (!(bsf = av_bitstream_filter_init("h264_mp4toannexb"))) {
> +filter = av_bsf_get_by_name("h264_mp4toannexb");
> +if (!filter) {
>  av_log(avf, AV_LOG_ERROR, "h264_mp4toannexb bitstream filter "
> "required for H.264 streams\n");
>  return AVERROR_BSF_NOT_FOUND;
>  }
> +ret = av_bsf_alloc(filter, &bsf);
> +if (ret < 0)
> +return ret;
>  cs->bsf = bsf;
>  
> -cs->avctx = avcodec_alloc_context3(NULL);
> -if (!cs->avctx)
> -return AVERROR(ENOMEM);
> -
> -/* This really should be part of the bsf work.
> -   Note: input bitstream filtering will not work with bsf that
> -   create extradata from the first packet. */
> -av_freep(&st->codecpar->extradata);
> -st->codecpar->extradata_size = 0;
> +ret = avcodec_parameters_copy(bsf->par_in, st->codecpar);
> +if (ret < 0)
> +   return ret;
>  
> -ret = avcodec_parameters_to_context(cs->avctx, st->codecpar);
> -if (ret < 0) {
> -avcodec_free_context(&cs->avctx);
> +ret = av_bsf_init(bsf);
> +if (ret < 0)
>  return ret;
> -}
>  
> +ret = avcodec_parameters_copy(st->codecpar, bsf->par_out);
> +if (ret < 0)
> +return ret;
>  }
>  return 0;
>  }
> @@ -291,8 +290,11 @@ static int match_streams(AVFormatContext *avf)
>  memset(map + cat->cur_file->nb_streams, 0,
> (cat->avf->nb_streams - cat->cur_file->nb_streams) * 
> sizeof(*map));
>  
> -for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++)
> +for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++) {
>  map[i].out_stream_index = -1;
> +if ((ret = detect_stream_specific(avf, i)) < 0)
> +return ret;
> +}
>  switch (cat->stream_match_mode) {
>  case MATCH_ONE_TO_ONE:
>  ret = match_streams_one_to_one(avf);
> @@ -305,9 +307,6 @@ static int match_streams(AVFormatContext *avf)
>  }
>  if (ret < 0)
>  return ret;
> -for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++)
> -if ((ret = detect_stream_specific(avf, i)) < 0)
> -return ret;
>  cat->cur_file->nb_streams = cat->avf->nb_streams;
>  return 0;
>  }
> @@ -370,10 +369,8 @@ static int concat_read_close(AVFormatContext *avf)
>  for (i = 0; i < cat->nb_files; i++) {
>  av_freep(&cat->files[i].url);
>  for (j = 0; j < cat->files[i].nb_streams; j++) {
> -if (cat->files[i].streams[j].avctx)
> -avcodec_free_context(&cat->files[i].streams[j].avctx);
>  if (cat->files[i].streams[j].bsf)
> -av_bitstream_filter_close(cat->files[i].streams[j].bsf);
> +av_bsf_free(&cat->files[i].streams[j].bsf);
>  }
>  av_freep(&cat->files[i].streams);
>  av_dict_free(&cat->files[i].metadata);
> @@ -524,56 +521,25 @@ static int open_next_file(AVFormatContext *avf)
>  
>  static int filter_packet(AVFormatContext *avf, ConcatStream *cs, AVPacket 
> *pkt)
>  {
> -AVStream *st = avf->streams[cs->out_stream_index];
> -AVBitStreamFilterContext *bsf;
> -AVPacket pkt2;
>  int ret;
>  
>  av_assert0(cs->out_stream_index >= 0);
> -for (bsf = cs->bsf; bsf; bsf = bsf->next) {
> -pkt2 = *pkt;
> -
> -ret = av_bitstream_filter_filter(bsf, cs->avctx, NULL,
> - &pkt2.data, &pkt2.size,
> - pkt->data, pkt->size,
> - 

[FFmpeg-devel] [PATCH 2/2] libavformat/tests: Add http cookie tests cases to fate

[Micah Galizia]

Signed-off-by: Micah Galizia 
---
 libavformat/Makefile   |   1 +
 libavformat/tests/http.c   | 186 +
 tests/fate/libavformat.mak |   5 ++
 tests/ref/fate/http|  30 
 4 files changed, 222 insertions(+)
 create mode 100644 libavformat/tests/http.c
 create mode 100644 tests/ref/fate/http

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6bdfbe6789..640a348c2f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -598,6 +598,7 @@ SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
 
 TESTPROGS = seek\
 url \
+http\
 #   async   \
 
 FIFO-MUXER-TESTPROGS-$(CONFIG_NETWORK)   += fifo_muxer
diff --git a/libavformat/tests/http.c b/libavformat/tests/http.c
new file mode 100644
index 00..76a70ae814
--- /dev/null
+++ b/libavformat/tests/http.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (c) 2017 Micah Galizia
+ *
+ * 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
+ */
+
+#include "libavformat/http.c"
+#include "libavformat/avio.h"
+
+typedef struct GetCookiesTestCase {
+const char *set_cookie;
+const char *cookie_str;
+const char *path;
+const char *domain;
+} GetCookiesTestCase;
+
+// Don't go past Tue, 19 Jan 2038 03:14:07 GMT or 32-bit time_t overflows
+GetCookiesTestCase get_cookies_tests[] = {
+/* Test good and expired cookie. Should be acceptable */
+{"first=\"good\"; Domain=.test.com; Path=/\nsecond=great; 
domain=.test.com; path=/; HttpOnly",
+ "first=\"good\"; second=great", "/hello", "cookie.test.com"},
+
+ /* Test good and expired cookie. Should be acceptable */
+{"expired=\"really_old\"; Domain=.test.com; Expires=Thu, 01 Jan 1970 
00:00:10 GMT; Path=/\ngood=not_expired; domain=.test.com; path=/; expires=Tue, 
19 Jan 2038 03:14:07 GMT; HttpOnly",
+ "good=not_expired", "/hello", "cookie.test.com"},
+
+/* Test a good and expired cookie in the neulion format.
+ * Should be acceptable */
+{"expired=\"really_old\"; Domain=.test.com; Expires=Thu, 01-Jan-1970 
00:00:10 GMT; Path=/\nneulion=not_expired; domain=.test.com; path=/; 
expires=Tue, 19-Jan-2038 03:14:07 GMT; HttpOnly",
+ "neulion=not_expired", "/hello", "cookie.test.com"},
+
+/* Test an expiry date without the day of week specified */
+{"no_day=still_ok; domain=.test.com; path=/; expires=19 Jan 2038 03:14:07 
GMT; HttpOnly",
+ "no_day=still_ok", "/hello", "cookie.test.com"},
+
+/* Test a date that cannot be parsed. Allow the cookie */
+{"unparsable_date=allow_cookie; domain=.test.com; path=/; expires=19 Jon 
2038 03:14:07 GMT; HttpOnly",
+ "unparsable_date=allow_cookie", "/hello", "cookie.test.com"},
+
+/* Test a cookie that has a different domain. Do not use the cookie */
+{"different_domain=exclude; domain=.nottest.com; path=/; expires=19 Jan 
2038 03:14:07 GMT; HttpOnly",
+ NULL, "/hello", "cookie.test.com"},
+
+/* Test a set-cookie that has no spaces */
+
{"no_spaces=no_big_deal;domain=.test.com;path=/;expires=Tue,19Jan203803:14:07GMT;HttpOnly",
+ "no_spaces=no_big_deal", "/hello", "cookie.test.com"},
+
+/* Test a set-cookie that has no spaces and is expired. Excluded */
+
{"no_spaces_expired=not_ok;domain=.test.com;path=/;expires=Thu01Jan197010GMT;HttpOnly",
+ NULL, "/hello", "cookie.test.com"},
+
+/* Test a set-cookie with a date that is too long. */
+{"long=handled;domain=.test.com;path=/;expires=Tue, 19 Jan 2038 
03:14:07GMTGMTGMTGMTGMTGMT;HttpOnly",
+ "long=handled", "/hello", "cookie.test.com"},
+
+/* Test a set-cookie with a date that starts with too many characters */
+{"bad_start=ok;domain=.test.com;path=/;expires=BooBooBooTue, 19 Jan 2038 
03:14:07;HttpOnly",
+ "bad_start=ok", "/hello", "cookie.test.com"},
+
+{NULL}
+};
+
+
+static int test_get_cookies(void)
+{
+URLContext *c = NULL;
+char *cookies = NULL;
+HTTPContext http;
+
+if (ffurl_alloc(&c, "http://test.com";, AVIO_FLAG_READ, NULL) < 0) {
+printf("Unable to allocate 

Re: [FFmpeg-devel] [PATCH 2/2] Add http cookie tests cases to fate

[Micah Galizia]

Hello,

Same patch with corrected name.

Thanks in advance.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Observe Set-Cookie headers in HLS streams

[Micah Galizia]

Hi,

I was hoping to get this one in too so I've named the patch appropriately.

With this change, cookie authenticated streams (eg: Neulion) should play 
properly again.

Thanks,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers

[Micah Galizia]

Signed-off-by: Micah Galizia 
---
 libavformat/hls.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..643d50e1da 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,14 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
 if (ret >= 0) {
 // update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(&c->cookies, "cookies", u);
+char *new_cookies = NULL;
+
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
(uint8_t**)&new_cookies);
+if (new_cookies) {
+av_free(c->cookies);
+c->cookies = new_cookies;
+}
+
 av_dict_set(&opts, "cookies", c->cookies, 0);
 }
 
@@ -1608,7 +1614,7 @@ static int hls_close(AVFormatContext *s)
 
 static int hls_read_header(AVFormatContext *s)
 {
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
+void *u = s->pb;
 HLSContext *c = s->priv_data;
 int ret = 0, i;
 int highest_cur_seq_no = 0;
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

2017-05-02 19:14 GMT+02:00 James Almer :

> On 5/2/2017 1:49 PM, Paul B Mahol wrote:
> > On 5/2/17, Thomas Mundt  wrote:
> >> 2017-04-29 18:15 GMT+02:00 Thomas Mundt :
> >>
> >>> 2017-04-20 23:54 GMT+02:00 Thomas Mundt :
> >>>
>  Patch attached...
> 
>  Ping
> >>>
> >>
> >> Ping
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Michael? Gonna apply this?
>
> Applied it since i reviewed it in part.
>

Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers

[wm4]

On Tue,  2 May 2017 20:47:06 -0400
Micah Galizia  wrote:

> Signed-off-by: Micah Galizia 
> ---
>  libavformat/hls.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4350..643d50e1da 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -630,8 +630,14 @@ static int open_url(AVFormatContext *s, AVIOContext 
> **pb, const char *url,
>  ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
>  if (ret >= 0) {
>  // update cookies on http response with setcookies.
> -void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> -update_options(&c->cookies, "cookies", u);
> +char *new_cookies = NULL;
> +
> +av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
> (uint8_t**)&new_cookies);
> +if (new_cookies) {
> +av_free(c->cookies);
> +c->cookies = new_cookies;
> +}
> +
>  av_dict_set(&opts, "cookies", c->cookies, 0);
>  }
>  
> @@ -1608,7 +1614,7 @@ static int hls_close(AVFormatContext *s)
>  
>  static int hls_read_header(AVFormatContext *s)
>  {
> -void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> +void *u = s->pb;
>  HLSContext *c = s->priv_data;
>  int ret = 0, i;
>  int highest_cur_seq_no = 0;

Not comfortable with this without knowing what the purpose of this
CUSTOM_IO check was.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: check for unconnected outputs

[Steven Liu]

2017-05-03 7:06 GMT+08:00 wm4 :

> Fixes e.g.:
>
> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex
> "[0:v][1:v]psnr[out]" -f null none
> ---
>  ffmpeg.h|  1 +
>  ffmpeg_filter.c | 15 +++
>  ffmpeg_opt.c|  2 ++
>  3 files changed, 18 insertions(+)
>
> diff --git a/ffmpeg.h b/ffmpeg.h
> index 4d0456c1fb..d34561275a 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -638,6 +638,7 @@ void choose_sample_fmt(AVStream *st, AVCodec *codec);
>
>  int configure_filtergraph(FilterGraph *fg);
>  int configure_output_filter(FilterGraph *fg, OutputFilter *ofilter,
> AVFilterInOut *out);
> +void check_filter_outputs(void);
>  int ist_in_filtergraph(FilterGraph *fg, InputStream *ist);
>  int filtergraph_is_simple(FilterGraph *fg);
>  int init_simple_filtergraph(InputStream *ist, OutputStream *ost);
> diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
> index 896161a869..817f48f473 100644
> --- a/ffmpeg_filter.c
> +++ b/ffmpeg_filter.c
> @@ -678,6 +678,21 @@ int configure_output_filter(FilterGraph *fg,
> OutputFilter *ofilter, AVFilterInOu
>  }
>  }
>
> +void check_filter_outputs(void)
> +{
> +int i;
> +for (i = 0; i < nb_filtergraphs; i++) {
> +int n;
> +for (n = 0; n < filtergraphs[i]->nb_outputs; n++) {
> +OutputFilter *output = filtergraphs[i]->outputs[n];
> +if (!output->ost) {
> +av_log(NULL, AV_LOG_FATAL, "Filter %s has an unconnected
> output\n", output->name);
> +exit_program(1);
> +}
> +}
> +}
> +}
> +
>  static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
>  {
>  AVFormatContext *avf = input_files[ist->file_index]->ctx;
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index d1fe8742ff..e73a61059f 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -3260,6 +3260,8 @@ int ffmpeg_parse_options(int argc, char **argv)
>  goto fail;
>  }
>
> +check_filter_outputs();
> +
>  fail:
>  uninit_parse_context(&octx);
>  if (ret < 0) {
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM


Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/jpeg2000dec: Fix jp2 inner atom size used for overread checks

[Carl Eugen Hoyos]

2017-05-02 21:06 GMT+02:00 Michael Niedermayer :
> On Tue, May 02, 2017 at 04:13:07PM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> The atom2_size variable when reading the inner atoms of a jp2 header
>> is not reduced after reading the first 64 bit of the atom, the
>> variable is used later for several checks to avoid overreads.
>>
>> Please comment, Carl Eugen
>
> LGTM, thx

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] avformat/hlsenc: hold old key info when append list

[Aaron Levinson]

On 4/27/2017 7:21 PM, Steven Liu wrote:

2017-04-26 7:30 GMT+08:00 Steven Liu :


fix ticket id: #6353

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 27c8e3355d..3ec0f330fb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -810,6 +810,7 @@ static int parse_playlist(AVFormatContext *s, const
char *url)
 int64_t new_start_pos;
 char line[1024];
 const char *ptr;
+const char *end;

 if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
&s->interrupt_callback, NULL,
@@ -842,6 +843,29 @@ static int parse_playlist(AVFormatContext *s, const
char *url)
 } else if (av_strstart(line, "#EXTINF:", &ptr)) {
 is_segment = 1;
 hls->duration = atof(ptr);
+} else if (av_stristart(line, "#EXT-X-KEY:", &ptr)) {
+ptr = av_stristr(line, "URI=\"");
+if (ptr) {
+ptr += strlen("URI=\"");
+end = av_stristr(ptr, ",");
+if (end) {
+av_strlcpy(hls->key_uri, ptr, end - ptr);
+} else {
+av_strlcpy(hls->key_uri, ptr, sizeof(hls->key_uri));


I know that this patch has already been applied (although it didn't get 
any reviews on the ML), but I think that there are some issues with it. 
First, it seems that both av_strlcpy() cases above will copy the 
terminating '\"' character into hls->key_uri.  Perhaps that won't cause 
an issue in practice, but it is likely not the intended result.  Second, 
with both av_strlcpy() calls that use a length of end - ptr, this could 
in theory result in a buffer overrun depending on how long the URI is, 
since the destination buffers have a fixed size.  This issue is 
prevented in the second call to av_strlcpy(), since it uses 
sizeof(hls->key_uri), but it is a potential issue with the first calls 
(note that this comment applies to the IV=0x code below).  If you want 
to use av_strlcpy(), either make sure that end - ptr is less than or 
equal to sizeof(hls->key_uri) or do something like *end = 0 first and 
then use av_strlcpy(hls->key_uri, ptr, sizeof(hls->key_uri)).


In addition, based on the EXT-X-KEY example at 
https://developer.apple.com/library/content/technotes/tn2288/_index.html 
, it would appear that an EXT-X-KEY declaration may span multiple lines. 
 Your solution will not work properly in this case.


Aaron Levinson


+}
+}
+
+ptr = av_stristr(line, "IV=0x");
+if (ptr) {
+ptr += strlen("IV=0x");
+end = av_stristr(ptr, ",");
+if (end) {
+av_strlcpy(hls->iv_string, ptr, end - ptr);
+} else {
+av_strlcpy(hls->iv_string, ptr,
sizeof(hls->iv_string));
+}
+}
+
 } else if (av_strstart(line, "#", NULL)) {
 continue;
 } else if (line[0]) {
--
2.11.0 (Apple Git-81)



Applied!


Thanks

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: check for unconnected outputs

[Carl Eugen Hoyos]

2017-05-03 1:06 GMT+02:00 wm4 :
> Fixes e.g.:
>
> ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex 
> "[0:v][1:v]psnr[out]" -f null none

Please mention the ticket number in the commit message.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Marton Balint]

On Wed, 3 May 2017, wm4 wrote:


>>> https://trac.ffmpeg.org/ticket/6323


Rather tricky to fix, so I didn't. The problem is that the filter graph
remains unconfigured, so it can't know about unconnected outputs. It
remains unconfigured because the first input file is connected to two
filters (one trivial that keeps shuffling input to the output file, and
one connected to the unconfigured graph). To get the graph configured,
the second input file would have to decode 1 frame - this doesn't
happen because there's nothing in ffmpeg.c scheduling that would make
the second input file produce output.

The scheduling should be fixed. In theory it would be best to move the
input "duplication" (single input to several filter inputs) into
libavfilter, and make libavfilter do proper data flow that blocks
instead of queuing up frames until OOM.

but I'm not sure how to do that, so I posted a hacky fix for it that
checks for unconnected outputs on start, instead of in the old place.



Thanks!


>>> https://trac.ffmpeg.org/ticket/6318


Works here, I suspect it was the same as one of the other issues that
was fixed recently.


The original report is a bit vague, have you also tried the command line I 
provied?


ffmpeg -threads 11 -i "DNxHD_4_Mono_Channels.mov" -filter_complex 
"[0:v]null[vout];[0:a:0][0:a:1]amerge[aout]" -map [vout] -map [aout] 
"test.mp4"


It fails for me even with the current git master. Maybe with the increased 
number of threads, the video decoding becomes "so delayed" that lavfi 
rejects you to push all audio frames into the filter graph which you got 
before you get a decoded video frame? Although I don't see why this issue 
appeared with the delayed filter initialization.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream

[Jun Zhao]

On 2017/5/2 22:08, Michael Niedermayer wrote:
> On Tue, May 02, 2017 at 10:49:50AM +0800, Jun Zhao wrote:
>>  vaapi_encode.c  |   15 +++
>>  vaapi_encode.h  |4 
>>  vaapi_encode_h264.c |   45 +
>>  3 files changed, 64 insertions(+)
>> 32cb532f5b6e7a3237b3997a79a93bf54b02660f  
>> 0001-lavc-vaapi_encode_h264-add-option-to-insert-AUD-nal-.patch
>> 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);
> 
> the %d(s) and the argument doesnt match up

will fix in the V2 patch, tks.

> 
> [...]
> 
> 
> 
> ___
> 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] lavc/vaapi_encode_h264: add option to insert AUD nal to AVC stream

[Jun Zhao]

On 2017/5/3 4:23, Mark Thompson wrote:
> On 02/05/17 03:49, Jun Zhao wrote:
>> 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(+)
> 
> This puts the AUDs in the wrong place?
> 
> ./ffmpeg_g -y -vaapi_device /dev/dri/renderD128 -hwaccel vaapi 
> -hwaccel_output_format vaapi -i in.mp4 -an -c:v h264_vaapi -aud 1 -b 5M 
> -maxrate 5M out.h264
> 
> IDR frame:
> 
>   00 00 00 01 67 64 00 33  ac 2e c0 78 02 27 e5 c0  
> |gd.3...x.'..|  <- SPS
> 0010  44 00 00 03 00 04 00 00  03 01 e3 89 80 00 98 96  |D...|
> 0020  00 01 31 2c bd ce 01 e1  10 8a 70 00 00 00 01 68  
> |..1,..ph|  <- PPS
> 0030  ee 38 b0 00 00 00 01 06  00 07 80 83 d6 00 00 03  
> |.8..|  <- SEI
> 0040  00 40 01 04 00 00 03 00  02 05 79 59 94 8b 28 11  |.@yY..(.|
> 0050  ec 45 af 96 75 19 d4 1f  ea a9 4d 4c 61 76 63 35  |.E..u.MLavc5|
> 0060  37 2e 39 33 2e 31 30 30  20 2f 20 56 41 41 50 49  |7.93.100 / VAAPI|
> 0070  20 30 2e 34 30 2e 30 20  2f 20 49 6e 74 65 6c 20  | 0.40.0 / Intel |
> 0080  69 39 36 35 20 64 72 69  76 65 72 20 66 6f 72 20  |i965 driver for |
> 0090  49 6e 74 65 6c 28 52 29  20 43 68 65 72 72 79 56  |Intel(R) CherryV|
> 00a0  69 65 77 20 2d 20 31 2e  38 2e 32 2e 70 72 65 31  |iew - 1.8.2.pre1|
> 00b0  20 28 31 2e 38 2e 31 2d  35 35 2d 67 39 39 36 65  | (1.8.1-55-g996e|
> 00c0  63 65 64 29 80 00 00 00  01 09 10 00 00 00 01 65  
> |ced)...e|  <- AUD, IDR slice
> 00d0  b8 04 0f fe c5 c0 00 ce  c7 8f f2 87 2b 23 ba dd  |+#..|
> 00e0  b5 a3 38 20 c6 f1 d3 00  00 03 00 00 03 00 00 03  |..8 |
> 00f0  00 00 03 00 00 12 8f f3  09 91 c0 00 00 03 00 05  ||
> 0100  14 00 00 03 02 26 00 00  03 01 37 00 00 03 00 d4  |.&7.|
> 0110  00 00 03 00 c9 00 00 03  00 e2 00 00 03 00 fe 00  ||
> 0120  00 03 01 32 00 00 03 02  1a 00 00 04 04 00 00 06  |...2|
> 0130  28 00 00 0e c0 00 00 03  00 00 03 00 00 03 00 00  |(...|
> 0140  03 00 00 03 00 00 03 00  00 03 00 00 03 00 00 03  ||
> 
> Normal frame:
> 
> 0250  00 03 00 00 03 00 00 03  00 00 03 00 00 03 00 00  ||
> 0260  03 00 00 03 00 00 03 00  01 01 00 00 00 01 06 01  
> ||  <- SEI
> 0270  04 00 00 03 02 06 80 00  00 00 01 09 30 00 00 00  
> |0...|  <- AUD
> 0280  01 21 e0 26 3f 00 00 03  00 00 03 00 00 03 00 00  
> |.!.&?...|  <- Non-IDR slice
> 0290  03 00 00 03 00 00 03 00  00 03 00 00 03 00 00 03  ||
> 
> (Braswell N3700, i965 driver from git as of an hour ago.)

I have verified in Skylake, i965 driver fix this issue in GEN9 with the commit 
fd52137
in master branch, but don't fix in Braswell GEN8, open a issue to i965 driver
https://github.com/01org/intel-vaapi-driver/issues/155

> 
>>
>> 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

[FFmpeg-devel] [PATCH] lavf/utils: bail early if we don't see any packets in an MPEGTS stream

[Rodger Combs]

---
 libavformat/utils.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index ba82a766dc..80895b31f0 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,20 @@ 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"))
+if (!strcmp(ic->iformat->name, "flv")) {
+max_empty_analyze_duration =
 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 +3636,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 +3805,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

[FFmpeg-devel] [PATCH 2/2] libavcodec/mpeg4videodec: Convert sprite_offset to 64bit

[Michael Niedermayer]

This avoids intermediates from overflowing (the final values are checked)
Fixes: runtime error: signed integer overflow: -167712 + -2147352576 cannot be 
represented in type 'int'

Fixes: 1298/clusterfuzz-testcase-minimized-5955580877340672

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpeg4videodec.c | 102 ++---
 1 file changed, 50 insertions(+), 52 deletions(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 791a07..39f177f8d0 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -178,6 +178,7 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 int min_ab, i, w2, h2, w3, h3;
 int sprite_ref[4][2];
 int virtual_ref[2][2];
+int64_t sprite_offset[2][2];
 
 // only true for rectangle shapes
 const int vop_ref[4][2] = { { 0, 0 }, { s->width, 0 },
@@ -257,10 +258,10 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 
 switch (ctx->num_sprite_warping_points) {
 case 0:
-s->sprite_offset[0][0] =
-s->sprite_offset[0][1] =
-s->sprite_offset[1][0] =
-s->sprite_offset[1][1] = 0;
+sprite_offset[0][0]=
+sprite_offset[0][1]=
+sprite_offset[1][0]=
+sprite_offset[1][1]= 0;
 s->sprite_delta[0][0]  = a;
 s->sprite_delta[0][1]  =
 s->sprite_delta[1][0]  = 0;
@@ -269,11 +270,11 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 ctx->sprite_shift[1]   = 0;
 break;
 case 1: // GMC only
-s->sprite_offset[0][0] = sprite_ref[0][0] - a * vop_ref[0][0];
-s->sprite_offset[0][1] = sprite_ref[0][1] - a * vop_ref[0][1];
-s->sprite_offset[1][0] = ((sprite_ref[0][0] >> 1) | (sprite_ref[0][0] 
& 1)) -
+sprite_offset[0][0]= sprite_ref[0][0] - a * vop_ref[0][0];
+sprite_offset[0][1]= sprite_ref[0][1] - a * vop_ref[0][1];
+sprite_offset[1][0]= ((sprite_ref[0][0] >> 1) | (sprite_ref[0][0] 
& 1)) -
  a * (vop_ref[0][0] / 2);
-s->sprite_offset[1][1] = ((sprite_ref[0][1] >> 1) | (sprite_ref[0][1] 
& 1)) -
+sprite_offset[1][1]= ((sprite_ref[0][1] >> 1) | (sprite_ref[0][1] 
& 1)) -
  a * (vop_ref[0][1] / 2);
 s->sprite_delta[0][0]  = a;
 s->sprite_delta[0][1]  =
@@ -283,22 +284,22 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 ctx->sprite_shift[1]   = 0;
 break;
 case 2:
-s->sprite_offset[0][0] = (sprite_ref[0][0] * (1 << alpha + rho)) +
+sprite_offset[0][0]= (sprite_ref[0][0] * (1 << alpha + rho)) +
  (-r * sprite_ref[0][0] + virtual_ref[0][0]) *
  (-vop_ref[0][0]) +
  (r * sprite_ref[0][1] - virtual_ref[0][1]) *
  (-vop_ref[0][1]) + (1 << (alpha + rho - 1));
-s->sprite_offset[0][1] = (sprite_ref[0][1] * (1 << alpha + rho)) +
+sprite_offset[0][1]= (sprite_ref[0][1] * (1 << alpha + rho)) +
  (-r * sprite_ref[0][1] + virtual_ref[0][1]) *
  (-vop_ref[0][0]) +
  (-r * sprite_ref[0][0] + virtual_ref[0][0]) *
  (-vop_ref[0][1]) + (1 << (alpha + rho - 1));
-s->sprite_offset[1][0] = ((-r * sprite_ref[0][0] + virtual_ref[0][0]) *
+sprite_offset[1][0]= ((-r * sprite_ref[0][0] + virtual_ref[0][0]) *
   (-2 * vop_ref[0][0] + 1) +
   (r * sprite_ref[0][1] - virtual_ref[0][1]) *
   (-2 * vop_ref[0][1] + 1) + 2 * w2 * r *
   sprite_ref[0][0] - 16 * w2 + (1 << (alpha + 
rho + 1)));
-s->sprite_offset[1][1] = ((-r * sprite_ref[0][1] + virtual_ref[0][1]) *
+sprite_offset[1][1]= ((-r * sprite_ref[0][1] + virtual_ref[0][1]) *
   (-2 * vop_ref[0][0] + 1) +
   (-r * sprite_ref[0][0] + virtual_ref[0][0]) *
   (-2 * vop_ref[0][1] + 1) + 2 * w2 * r *
@@ -315,30 +316,22 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 min_ab = FFMIN(alpha, beta);
 w3 = w2 >> min_ab;
 h3 = h2 >> min_ab;
-s->sprite_offset[0][0] = (sprite_ref[0][0] * (1<<(alpha + beta + rho - 
min_ab))) +
- (-r * sprite_ref[0][0] + virtual_ref[0][0]) *
- h3 * (-vop_ref[0][0]) +
- (-r * sprite_ref[0][0] + virtual

[FFmpeg-devel] [PATCH 1/2] avcodec/avpacket: Use av_copy_packet_side_data() in av_packet_copy_props()

[Michael Niedermayer]

Fixes timeout
Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/avpacket.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 4bf830bb8a..ff7ee730a4 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -557,6 +557,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 dst->flags= src->flags;
 dst->stream_index = src->stream_index;
 
+if (!dst->side_data_elems);
+return av_copy_packet_side_data(dst, src);
+
 for (i = 0; i < src->side_data_elems; i++) {
  enum AVPacketSideDataType type = src->side_data[i].type;
  int size  = src->side_data[i].size;
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] videotoolbox: add hwcontext support

[wm4]

This adds tons of code for no other benefit than making VideoToolbox
support conform with the new hwaccel API (using hw_device_ctx and
hw_frames_ctx).

Since VideoToolbox decoding does not actually require the user to
allocate frames, the new code does mostly nothing.

One benefit is that ffmpeg_videotoolbox.c can be dropped once generic
hwaccel support for ffmpeg.c is merged from Libav.

Does not consider VDA or VideoToolbox encoding.

Fun fact: the frame transfer functions are copied from vaapi, as the
mapping makes copying generic boilerplate. Mapping itself is not
exported by the VT code, because I don't know how to test.

TODO: API bumps
---
 doc/APIchanges |   8 ++
 libavcodec/vda_vt_internal.h   |   7 ++
 libavcodec/videotoolbox.c  | 186 ++--
 libavutil/Makefile |   3 +
 libavutil/hwcontext.c  |   3 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_internal.h |   1 +
 libavutil/hwcontext_videotoolbox.c | 243 +
 libavutil/hwcontext_videotoolbox.h |  54 +
 9 files changed, 496 insertions(+), 10 deletions(-)
 create mode 100644 libavutil/hwcontext_videotoolbox.c
 create mode 100644 libavutil/hwcontext_videotoolbox.h

diff --git a/doc/APIchanges b/doc/APIchanges
index fcd3423d58..71f5563f03 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,14 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-05-03 - xx - lavc 57.xx.100 - avcodec.h
+  VideoToolbox hardware accelerated decoding now supports the new hwaccel API,
+  which can create the decoder context and allocate hardware frame 
automatically.
+  See AVCodecContext.hw_device_ctx and AVCodecContext.hw_frames_ctx.
+
+2017-05-03 - xx - lavu 57.xx.100 - hwcontext.h
+  Add AV_HWDEVICE_TYPE_VIDEOTOOLBOX and implementation.
+
 2017-04-11 - 8378466507 - lavu 55.61.100 - avstring.h
   Add av_strireplace().
 
diff --git a/libavcodec/vda_vt_internal.h b/libavcodec/vda_vt_internal.h
index 9ff63ccc52..e55a813899 100644
--- a/libavcodec/vda_vt_internal.h
+++ b/libavcodec/vda_vt_internal.h
@@ -40,6 +40,13 @@ typedef struct VTContext {
 
 // The core video buffer
 CVImageBufferRefframe;
+
+// Current dummy frames context (depends on exact CVImageBufferRef params).
+struct AVBufferRef *cached_hw_frames_ctx;
+
+// Non-NULL if the new hwaccel API is used. This is only a separate struct
+// to ease compatibility with the old API.
+struct AVVideotoolboxContext *vt_ctx;
 } VTContext;
 
 int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, AVFrame *frame);
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 67adad53ed..910ac25ea7 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -23,11 +23,13 @@
 #include "config.h"
 #if CONFIG_VIDEOTOOLBOX
 #  include "videotoolbox.h"
+#  include "libavutil/hwcontext_videotoolbox.h"
 #else
 #  include "vda.h"
 #endif
 #include "vda_vt_internal.h"
 #include "libavutil/avutil.h"
+#include "libavutil/hwcontext.h"
 #include "bytestream.h"
 #include "h264dec.h"
 #include "mpegvideo.h"
@@ -188,6 +190,79 @@ int ff_videotoolbox_uninit(AVCodecContext *avctx)
 }
 
 #if CONFIG_VIDEOTOOLBOX
+// Return the AVVideotoolboxContext that matters currently. Where it comes from
+// depends on the API used.
+static AVVideotoolboxContext *videotoolbox_get_context(AVCodecContext *avctx)
+{
+// Somewhat tricky because the API user can call 
av_videotoolbox_default_free()
+// at any time.
+if (avctx->internal && avctx->internal->hwaccel_priv_data) {
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+if (vtctx->vt_ctx)
+return vtctx->vt_ctx;
+}
+return avctx->hwaccel_context;
+}
+
+static int videotoolbox_buffer_create(AVCodecContext *avctx, AVFrame *frame)
+{
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+CVPixelBufferRef pixbuf = (CVPixelBufferRef)vtctx->frame;
+OSType pixel_format = CVPixelBufferGetPixelFormatType(pixbuf);
+enum AVPixelFormat sw_format = 
av_map_videotoolbox_format_to_pixfmt(pixel_format);
+int width = CVPixelBufferGetWidth(pixbuf);
+int height = CVPixelBufferGetHeight(pixbuf);
+AVHWFramesContext *cached_frames;
+int ret;
+
+ret = ff_videotoolbox_buffer_create(vtctx, frame);
+if (ret < 0)
+return ret;
+
+// Old API code path.
+if (!vtctx->cached_hw_frames_ctx)
+return 0;
+
+// We can still return frames with unknown underlying format, except we 
need
+// "some" AVPixelFormat for it. Use AV_PIX_FMT_VIDEOTOOLBOX to signal an
+// opaque/unknown format, which is very sketchy, but you can't sue me.
+if (sw_format == AV_PIX_FMT_NONE)
+sw_format = AV_PIX_FMT_VIDEOTOOLBOX;
+
+cached_frames = (AVHWFramesContext*)vtctx->cached_hw_frames_ctx->data;
+
+if (cached_frames->sw_format != sw_format ||
+cached_fra

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avpacket: Use av_copy_packet_side_data() in av_packet_copy_props()

[wm4]

On Wed,  3 May 2017 05:21:50 +0200
Michael Niedermayer  wrote:

> Fixes timeout
> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avpacket.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 4bf830bb8a..ff7ee730a4 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -557,6 +557,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  dst->flags= src->flags;
>  dst->stream_index = src->stream_index;
>  
> +if (!dst->side_data_elems);
> +return av_copy_packet_side_data(dst, src);
> +
>  for (i = 0; i < src->side_data_elems; i++) {
>   enum AVPacketSideDataType type = src->side_data[i].type;
>   int size  = src->side_data[i].size;

This doesn't look right...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avpacket: Use av_copy_packet_side_data() in av_packet_copy_props()

[James Almer]

On 5/3/2017 12:21 AM, Michael Niedermayer wrote:
> Fixes timeout
> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avpacket.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 4bf830bb8a..ff7ee730a4 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -557,6 +557,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  dst->flags= src->flags;
>  dst->stream_index = src->stream_index;
>  
> +if (!dst->side_data_elems);
> +return av_copy_packet_side_data(dst, src);.

This is a deprecated function, so ideally you'd use something else.

How does this fixes the problem anyway? The code below copies the
packet's side data as well.

> +
>  for (i = 0; i < src->side_data_elems; i++) {
>   enum AVPacketSideDataType type = src->side_data[i].type;
>   int size  = src->side_data[i].size;
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Initial implementation of ADPCM encoding for DCA encoder

[Rostislav Pehlivanov]

On 2 May 2017 at 22:53, Даниил Чередник  wrote:

> Hi.
>
> This patch introduces initial implementation of subband ADPCM encoding for
> DCA codec.
>
> Some results:
>
> sample:
>
> https://yadi.sk/d/B_3sVskM3HZiWK - original
>
> https://yadi.sk/d/7CK47Nt63HZiWf - without adpcm
>
> https://yadi.sk/d/25q1JDV93HZiWq - with adpcm
>
> chirp tone:
>
> https://yadi.sk/i/tZKHoJ1d3HZk4c
>
> Right now this feature is disabled by default. But it is ready to try
> using -dca_adpcm 1 option.
>
> There are some issues, should be solved before enabling this feature by
> default:
>
> 1. Speed up: I am trying to find best filter in each subband. But with real
> signal, usually only few subbands has significant prediction gain. The idea
> is try to analyze FFT spectrum (which is already calculated), to check is
> particular subband looks like tonal or noise. If subband is noise like - do
> not try to find best LPC predictor.
>
> 2. Modify psychoacoustic to use prediction gain for bit allocation. Right
> now ADPCM encoded block can get some extra bits.
>
> 3. Tuning the prediction gain threshold.
>
>
> Thank you.
> --
> Daniil Cherednik
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>+static int64_t calc_corr(const int32_t *x, int len, int j, int k)

Add inline attrib? Seems appropriate here.


>+for (n = 0; n < len; n++) {
>+s += MUL64(x[n-j], x[n-k]);
>+}

For loops with 1 line we leave the brackets out.


>+for (i = 0; i <= DCA_ADPCM_COEFFS; i++) {
>+for (j = i; j <= DCA_ADPCM_COEFFS; j++) {
>+corr[k++] = calc_corr(in+4, len, i, j);
>+}
>+}

Same


>+for (i = 0; i < len + DCA_ADPCM_COEFFS; i++) {
>+max |= FFABS(in[i]);
>+}

Same


>for (ch = 0; ch < c->fullband_channels; ch++) {
>+for (band = 0; band < 32; band++) {
>+if (c->prediction_mode[ch][band] >= 0) {
>+quantize_adpcm_subband(c, ch, band);
>+}
>+}
>+}

Same


>+for (ch = 0; ch < c->fullband_channels; ch++) {
>+for (band = 0; band < 32; band++) {
>+if (c->prediction_mode[ch][band] == -1) {
>+for (sample = 0; sample < SUBBAND_SAMPLES; sample++) {
>+c->quantized[ch][band][sample] =
quantize_value(c->subband[ch][band][sample], c->quant[ch][band]);
>+}
>+}
>+}
>+}

Same, 4 whole whitespace lines added here.


>+if (c->bitrate_index == 3) {
>+step_size = ff_dca_lossless_quant[c->abits[ch][band]];
>+} else {
>+step_size = ff_dca_lossy_quant[c->abits[ch][band]];
>+}

Same


>for (;;) {

while (1) {

>+if (i++ == last_pos)
>+break;

Better yet remove the infinite loop and just use a normal for () loop.


>+static inline void ff_dca_core_dequantize(int32_t *output, const int32_t
*input,
>+  int32_t step_size, int32_t scale, int
residual, int len)

Fix second line's alignment.


>+struct premultiplied_coeffs {
>+int32_t aa[10];
>+};

I think it would be simpler to just use int32_t premultiplied_coeffs[10]
instead of a struct.


Apart from these style issues patch looks fine. I'll be able to test it in
a day.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: hold old key info when append list

[Steven Liu]

2017-05-03 9:49 GMT+08:00 Aaron Levinson :

> On 4/27/2017 7:21 PM, Steven Liu wrote:
>
>> 2017-04-26 7:30 GMT+08:00 Steven Liu :
>>
>> fix ticket id: #6353
>>>
>>> Signed-off-by: Steven Liu 
>>> ---
>>>  libavformat/hlsenc.c | 24 
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 27c8e3355d..3ec0f330fb 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -810,6 +810,7 @@ static int parse_playlist(AVFormatContext *s, const
>>> char *url)
>>>  int64_t new_start_pos;
>>>  char line[1024];
>>>  const char *ptr;
>>> +const char *end;
>>>
>>>  if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
>>> &s->interrupt_callback, NULL,
>>> @@ -842,6 +843,29 @@ static int parse_playlist(AVFormatContext *s, const
>>> char *url)
>>>  } else if (av_strstart(line, "#EXTINF:", &ptr)) {
>>>  is_segment = 1;
>>>  hls->duration = atof(ptr);
>>> +} else if (av_stristart(line, "#EXT-X-KEY:", &ptr)) {
>>> +ptr = av_stristr(line, "URI=\"");
>>> +if (ptr) {
>>> +ptr += strlen("URI=\"");
>>> +end = av_stristr(ptr, ",");
>>> +if (end) {
>>> +av_strlcpy(hls->key_uri, ptr, end - ptr);
>>> +} else {
>>> +av_strlcpy(hls->key_uri, ptr, sizeof(hls->key_uri));
>>>
>>
> I know that this patch has already been applied (although it didn't get
> any reviews on the ML),

applied after ticket submiter check ok, and after 2 days.


> but I think that there are some issues with it. First, it seems that both
> av_strlcpy() cases above will copy the terminating '\"' character into
> hls->key_uri.  Perhaps that won't cause an issue in practice, but it is
> likely not the intended result.  Second, with both av_strlcpy() calls that
> use a length of end - ptr, this could in theory result in a buffer overrun
> depending on how long the URI is, since the destination buffers have a
> fixed size.  This issue is prevented in the second call to av_strlcpy(),
> since it uses sizeof(hls->key_uri), but it is a potential issue with the
> first calls (note that this comment applies to the IV=0x code below).  If
> you want to use av_strlcpy(), either make sure that end - ptr is less than
> or equal to sizeof(hls->key_uri) or do something like *end = 0 first and
> then use av_strlcpy(hls->key_uri, ptr, sizeof(hls->key_uri)).
>
> In addition, based on the EXT-X-KEY example at
> https://developer.apple.com/library/content/technotes/tn2288/_index.html
> , it would appear that an EXT-X-KEY declaration may span multiple lines.
> Your solution will not work properly in this case.
>
i will fix it.


Thanks.

>
> Aaron Levinson
>
> +}
>>> +}
>>> +
>>> +ptr = av_stristr(line, "IV=0x");
>>> +if (ptr) {
>>> +ptr += strlen("IV=0x");
>>> +end = av_stristr(ptr, ",");
>>> +if (end) {
>>> +av_strlcpy(hls->iv_string, ptr, end - ptr);
>>> +} else {
>>> +av_strlcpy(hls->iv_string, ptr,
>>> sizeof(hls->iv_string));
>>> +}
>>> +}
>>> +
>>>  } else if (av_strstart(line, "#", NULL)) {
>>>  continue;
>>>  } else if (line[0]) {
>>> --
>>> 2.11.0 (Apple Git-81)
>>>
>>>
>>> Applied!
>>
>>
>> Thanks
>>
> ___
> 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] avformat/concatdec: port to the new bitstream filter API

[Aaron Levinson]

I don't seem to have the original e-mail in my inbox anymore, so I'll 
respond to wm4's response.  Overall, the new code is a lot cleaner and 
easier to understand than the existing code.


See below for more.

Aaron Levinson

On 5/2/2017 5:04 PM, wm4 wrote:

On Fri, 28 Apr 2017 21:27:56 -0300
James Almer  wrote:


Signed-off-by: James Almer 
---
 libavformat/concatdec.c | 94 -
 1 file changed, 30 insertions(+), 64 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index dd52e4d366..fa9443ff78 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -34,8 +34,7 @@ typedef enum ConcatMatchMode {
 } ConcatMatchMode;

 typedef struct ConcatStream {
-AVBitStreamFilterContext *bsf;
-AVCodecContext *avctx;
+AVBSFContext *bsf;
 int out_stream_index;
 } ConcatStream;

@@ -196,7 +195,8 @@ static int detect_stream_specific(AVFormatContext *avf, int 
idx)
 ConcatContext *cat = avf->priv_data;
 AVStream *st = cat->avf->streams[idx];
 ConcatStream *cs = &cat->cur_file->streams[idx];
-AVBitStreamFilterContext *bsf;
+const AVBitStreamFilter *filter;
+AVBSFContext *bsf;
 int ret;

 if (cat->auto_convert && st->codecpar->codec_id == AV_CODEC_ID_H264) {
@@ -206,29 +206,28 @@ static int detect_stream_specific(AVFormatContext *avf, 
int idx)
 return 0;
 av_log(cat->avf, AV_LOG_INFO,
"Auto-inserting h264_mp4toannexb bitstream filter\n");
-if (!(bsf = av_bitstream_filter_init("h264_mp4toannexb"))) {
+filter = av_bsf_get_by_name("h264_mp4toannexb");
+if (!filter) {
 av_log(avf, AV_LOG_ERROR, "h264_mp4toannexb bitstream filter "
"required for H.264 streams\n");
 return AVERROR_BSF_NOT_FOUND;
 }
+ret = av_bsf_alloc(filter, &bsf);
+if (ret < 0)
+return ret;
 cs->bsf = bsf;

-cs->avctx = avcodec_alloc_context3(NULL);
-if (!cs->avctx)
-return AVERROR(ENOMEM);
-
-/* This really should be part of the bsf work.
-   Note: input bitstream filtering will not work with bsf that
-   create extradata from the first packet. */
-av_freep(&st->codecpar->extradata);
-st->codecpar->extradata_size = 0;
+ret = avcodec_parameters_copy(bsf->par_in, st->codecpar);
+if (ret < 0)
+   return ret;

-ret = avcodec_parameters_to_context(cs->avctx, st->codecpar);
-if (ret < 0) {
-avcodec_free_context(&cs->avctx);
+ret = av_bsf_init(bsf);
+if (ret < 0)
 return ret;
-}

+ret = avcodec_parameters_copy(st->codecpar, bsf->par_out);
+if (ret < 0)
+return ret;
 }
 return 0;
 }



@@ -291,8 +290,11 @@ static int match_streams(AVFormatContext *avf)
 memset(map + cat->cur_file->nb_streams, 0,
(cat->avf->nb_streams - cat->cur_file->nb_streams) * sizeof(*map));

-for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++)
+for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++) {
 map[i].out_stream_index = -1;
+if ((ret = detect_stream_specific(avf, i)) < 0)
+return ret;
+}
 switch (cat->stream_match_mode) {
 case MATCH_ONE_TO_ONE:
 ret = match_streams_one_to_one(avf);
@@ -305,9 +307,6 @@ static int match_streams(AVFormatContext *avf)
 }
 if (ret < 0)
 return ret;
-for (i = cat->cur_file->nb_streams; i < cat->avf->nb_streams; i++)
-if ((ret = detect_stream_specific(avf, i)) < 0)
-return ret;
 cat->cur_file->nb_streams = cat->avf->nb_streams;
 return 0;
 }


This just moves already existing code around.  While it is unclear to me 
why this is being done (a comment and/or log message would help), I 
would suspect that this particular change is unrelated to the purpose of 
this patch:  "port to the new bitstream filter API".



@@ -370,10 +369,8 @@ static int concat_read_close(AVFormatContext *avf)
 for (i = 0; i < cat->nb_files; i++) {
 av_freep(&cat->files[i].url);
 for (j = 0; j < cat->files[i].nb_streams; j++) {
-if (cat->files[i].streams[j].avctx)
-avcodec_free_context(&cat->files[i].streams[j].avctx);
 if (cat->files[i].streams[j].bsf)
-av_bitstream_filter_close(cat->files[i].streams[j].bsf);
+av_bsf_free(&cat->files[i].streams[j].bsf);
 }
 av_freep(&cat->files[i].streams);
 av_dict_free(&cat->files[i].metadata);
@@ -524,56 +521,25 @@ static int open_next_file(AVFormatContext *avf)

 static int filter_packet(AVFormatContext *avf, ConcatStream *cs, AVPacket *pkt)
 {
-AVStream *st = avf->streams[cs->out_stream_index];
-AVBitStreamFilterContext *bsf;
-AVPacket pkt2;
 int ret;

 av_assert0(cs->out_stream_index >= 0);


I wonder if it is