Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

On Mon, Jul 25, 2016 at 11:08 PM, Chao Liu  wrote:

>
>
> On Mon, Jul 25, 2016 at 11:04 PM, Chao Liu  wrote:
>
>> Hi,
>>
>> (Ivan, I am sending this mail to you directly because you said you are
>> the maintainer of QSV related code in a recent mail. Apologize if this is
>> inappropriate.. )
>>
>> I am trying to use h264_qsv to transcode a MP4 file. This is my command:
>> ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
>> -maxrate 1600k -preset fast output.mp4
>> It always stucks in this loop
>> .
>>
>> It works if I change the command to
>> ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
>> -preset fast output.mp4
>> (not using qsv for decoding).
>>
>> Looks like the decoding and encoding were contending for the resources
>> and there is a deadlock or sth. like that..
>>
>> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
>> There is sth. I don't understand. Not sure whether it's related..
>> In ffmpeg, we decode the frame in a loop
>> ,
>> it sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns
>> busy.
>> In intel media SDK sample_decode, it calls SyncOperation when
>> MFXVideoDECODE_DecodeFrameAsync returns busy.
>>
> Sorry, forgot to paste the link to the code
> https://github.com/Intel-Media-SDK/samples/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L1631
>
>

>> Could this be the cause?
>>
>
I think this is red herring. I could repro the deadlock w/o qsv decoding,
just the chance is pretty low.
And looks like this is a known issue: https://trac.ffmpeg.org/ticket/4832
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

On Mon, Jul 25, 2016 at 11:04 PM, Chao Liu  wrote:

> Hi,
>
> (Ivan, I am sending this mail to you directly because you said you are the
> maintainer of QSV related code in a recent mail. Apologize if this is
> inappropriate.. )
>
> I am trying to use h264_qsv to transcode a MP4 file. This is my command:
> ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
> -maxrate 1600k -preset fast output.mp4
> It always stucks in this loop
> .
>
> It works if I change the command to
> ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
> -preset fast output.mp4
> (not using qsv for decoding).
>
> Looks like the decoding and encoding were contending for the resources and
> there is a deadlock or sth. like that..
>
> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
> There is sth. I don't understand. Not sure whether it's related..
> In ffmpeg, we decode the frame in a loop
> ,
> it sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns
> busy.
> In intel media SDK sample_decode, it calls SyncOperation when
> MFXVideoDECODE_DecodeFrameAsync returns busy.
>
Sorry, forgot to paste the link to the code
https://github.com/Intel-Media-SDK/samples/blob/master/samples/sample_decode/src/pipeline_decode.cpp#L1631


>
> Could this be the cause?
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

[Chao Liu]

Hi,

(Ivan, I am sending this mail to you directly because you said you are the
maintainer of QSV related code in a recent mail. Apologize if this is
inappropriate.. )

I am trying to use h264_qsv to transcode a MP4 file. This is my command:
ffmpeg -c:v h264_qsv -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k
-maxrate 1600k -preset fast output.mp4
It always stucks in this loop
.

It works if I change the command to
ffmpeg -i input.mp4 -look_ahead 0 -c:v h264_qsv -b:v 800k -maxrate 1600k
-preset fast output.mp4
(not using qsv for decoding).

Looks like the decoding and encoding were contending for the resources and
there is a deadlock or sth. like that..

I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
There is sth. I don't understand. Not sure whether it's related..
In ffmpeg, we decode the frame in a loop
, it
sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns busy.
In intel media SDK sample_decode, it calls SyncOperation when
MFXVideoDECODE_DecodeFrameAsync returns busy.

Could this be the cause?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] v2 SCTE-35 support in hlsenc

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 12:25:17PM -0700, Carlos Fernandez Sanz wrote:
> From: carlos 
> 

[...]

> diff --git a/libavformat/scte_35.h b/libavformat/scte_35.h
> new file mode 100644
> index 000..733736a
> --- /dev/null
> +++ b/libavformat/scte_35.h
> @@ -0,0 +1,76 @@
> +/*
> + * SCTE-35 parser
> + * Copyright (c) 2016 Carlos Fernandez
> + *
> + * 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
> + */

> +#ifndef SCTE_35_H
> +#define SCTE_35_H

the include guards should start with the lib name AVFORMAT
see other headers
that preempts odd issues if a similarly named file is added to
another lib

thx

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

Those who are best at talking, realize last or never when they are wrong.


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] v2 SCTE extraction from mpegts

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 12:25:16PM -0700, Carlos Fernandez Sanz wrote:
> From: Carlos 
> 
> Signed-off-by: carlos 
> ---
>  libavcodec/avcodec.h|  1 +
>  libavcodec/codec_desc.c |  6 ++
>  libavformat/mpegts.c| 46 --
>  3 files changed, 47 insertions(+), 6 deletions(-)

This breaks 
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1827/vc1_dts_mplayerAudioProblem_sb41_cut.m2ts
which after the patch has a stream that seems dts detected as
SCTE_35 resultig in lack of audio
the sample is sadly a bit short

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc: don't define OPJ_STATIC with openjpeg 2.1.1

[James Almer]

On 7/25/2016 2:09 AM, Kia wrote:
> This fixes bug #5694 and builds with libopenjpeg 2.1.1.
> 
> openjpeg commit 3ed5858902055d3500a6ab183f1395686921d026 hides all
> symbols with __attribute__ ((visibility ("hidden"))) if OPJ_STATIC is
> defined

Does this affect libopenjpeg 2.1.0 in any way? And should the
configure check for 2.1 be updated as well? It defines OPJ_STATIC
to detect libopenjpeg by trying to compile a test program calling
opj_version().

> 
> Signed-off-by: Kia 
> ---
>  libavcodec/libopenjpegdec.c | 1 +
>  libavcodec/libopenjpegenc.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 65167e6..efc0648 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -37,6 +37,7 @@
>  #include "thread.h"
>  
>  #if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#undef  OPJ_STATIC
>  #  include 
>  #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
>  #  include 
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 1443551..2bc75e2 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -35,6 +35,7 @@
>  #include "internal.h"
>  
>  #if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#undef  OPJ_STATIC
>  #  include 
>  #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
>  #  include 
> 

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 10:13:38PM +0530, Umair Khan wrote:
> On Sun, Jul 24, 2016 at 1:47 AM, Umair Khan  wrote:
> >
> > HI,
> >
> > On Fri, Jul 22, 2016 at 9:19 PM, Michael Niedermayer
> >  wrote:
> > > On Fri, Jul 22, 2016 at 06:22:30PM +0530, Umair Khan wrote:
> > >> On Thu, Jul 21, 2016 at 6:18 PM, Michael Niedermayer
> > >>  wrote:
> > >> > On Sun, Jul 17, 2016 at 12:06:03AM +0530, Umair Khan wrote:
> > > [...]
> > >> >> +static int decode_string(MLZDict *dict, unsigned char *buff, int 
> > >> >> string_code, int *first_char_code, unsigned long bufsize) {
> > >> >> +unsigned long count, offset;
> > >> >> +int current_code, parent_code, tmp_code;
> > >> >> +
> > >> >> +count= 0;
> > >> >> +current_code = string_code;
> > >> >> +*first_char_code = CODE_UNSET;
> > >> >> +
> > >> >> +while (count < bufsize) {
> > >> >> +switch (current_code) {
> > >> >> +case CODE_UNSET:
> > >> >> +return count;
> > >> >> +break;
> > >> >> +default:
> > >> >> +if (current_code < FIRST_CODE) {
> > >> >> +*first_char_code = current_code;
> > >> >> +buff[0] = current_code;
> > >> >> +count++;
> > >> >> +return count;
> > >> >> +} else {
> > >> >> +offset  = dict[current_code].match_len - 1;
> > >> >> +tmp_code = dict[current_code].char_code;
> > >> >> +buff[offset] = tmp_code;
> > >> >> +count++;
> > >> >> +}
> > >> >> +current_code = dict[current_code].parent_code;
> > >> >> +if ((current_code < 0) || (current_code > (DIC_INDEX_MAX 
> > >> >> - 1))) {
> > >> >
> > >> >> +av_log(NULL, AV_LOG_ERROR, "MLZ dic index error.\n");
> > >> >
> > >> > it would be ideal if all av_log() would have a context instead of NULL
> > >>
> > >> How to go ahead with this? Should I create MLZContext or something? If
> > >> yes, could you please tell how?
> > >
> > > possible or you pass a void *context
> >
> > Updated patch.
> 
> Another revision. Fixes some things I had overlooked.
> 
> - Umair

>  Changelog |3 
>  libavcodec/Makefile   |2 
>  libavcodec/alsdec.c   |  286 
> +-
>  libavcodec/mlz.c  |  173 +
>  libavcodec/mlz.h  |   70 ++
>  libavutil/softfloat_ieee754.h |  115 
>  6 files changed, 646 insertions(+), 3 deletions(-)
> 66dd916fe5b2e98b30aed21f4cf656b66c51ce1f  
> 0001-avcodec-alsdec-implement-floating-point-decoding.patch
> From 44567b208cf0b697a4403420bc3f7ba0cebabbc1 Mon Sep 17 00:00:00 2001
> From: Umair Khan 
> Date: Sun, 24 Jul 2016 00:28:55 +0530
> Subject: [PATCH 1/1] avcodec/alsdec: implement floating point decoding
> 
> It conforms to RM22 version of the reference codec.

gcc generates these warnings:

libavcodec/mlz.c: In function ‘ff_mlz_decompression’:
libavcodec/mlz.c:152:25: warning: passing argument 1 of ‘decode_string’ from 
incompatible pointer type [enabled by default]
libavcodec/mlz.c:61:12: note: expected ‘struct MLZ *’ but argument is of type 
‘struct MLZDict *’
libavcodec/mlz.c:153:25: warning: passing argument 1 of ‘decode_string’ from 
incompatible pointer type [enabled by default]
libavcodec/mlz.c:61:12: note: expected ‘struct MLZ *’ but argument is of type 
‘struct MLZDict *’
libavcodec/mlz.c:157:25: warning: passing argument 1 of ‘decode_string’ from 
incompatible pointer type [enabled by default]


[...]
> +
> +/** Read and decode the floating point sample data
> + */
> +static int read_diff_float_data(ALSDecContext *ctx, unsigned int ra_frame) {
> +AVCodecContext *avctx   = ctx->avctx;
> +GetBitContext *gb   = &ctx->gb;
> +SoftFloat_IEEE754 *acf  = ctx->acf;
> +int *shift_value= ctx->shift_value;
> +int *last_shift_value   = ctx->last_shift_value;
> +int *last_acf_mantissa  = ctx->last_acf_mantissa;
> +int **raw_mantissa  = ctx->raw_mantissa;
> +int *nbits  = ctx->nbits;
> +unsigned char *larray   = ctx->larray;
> +int frame_length= ctx->cur_frame_length;
> +SoftFloat_IEEE754 scale = av_int2sf_ieee754(0x1u, 23);
> +unsigned int partA_flag;
> +unsigned int highest_byte;
> +unsigned int shift_amp;
> +uint32_t tmp_32;
> +int use_acf;
> +int nchars;
> +int i;
> +int c;
> +long k;
> +long nbits_aligned;
> +unsigned long acc;
> +unsigned long j;
> +uint32_t sign;
> +uint32_t e;
> +uint32_t mantissa;
> +
> +skip_bits_long(gb, 32); //num_bytes_diff_float
> +use_acf = get_bits1(gb);
> +
> +if (ra_frame) {

> +memset(last_acf_mantissa, 0, sizeof(last_acf_mantissa));
> +memset(last_shift_value,  0, sizeof(last_shift_value) );

the sizeof look a bit strange, these are not the allocated array sizes



[...]
> 

Re: [FFmpeg-devel] [PATCH] avutil/frame: access avframe fields directly in get_frame_defaults()

[James Almer]

On 7/25/2016 5:11 PM, Michael Niedermayer wrote:
> On Mon, Jul 25, 2016 at 04:01:40PM -0300, James Almer wrote:
>> The accessors are needed only from outside libavutil.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/frame.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> LGTM
> 
> thanks

Pushed.

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

Re: [FFmpeg-devel] [PATCH] avformat/fivdec: cached keyframes before video or audio stream was created

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 05:34:58PM +0800, XinZheng Zhang wrote:
> On Mon, Jul 25, 2016 at 4:41 PM, Michael Niedermayer
>  wrote:
> > On Thu, Jul 21, 2016 at 10:36:20AM +0800, Xinzheng Zhang wrote:
> >> ---
> >>  libavformat/flvdec.c | 51 
> >> ---
> >>  1 file changed, 44 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> >> index 2bf1e05..b4fb4e2 100644
> >> --- a/libavformat/flvdec.c
> >> +++ b/libavformat/flvdec.c
> >> @@ -30,6 +30,7 @@
> >>  #include "libavutil/opt.h"
> >>  #include "libavutil/intfloat.h"
> >>  #include "libavutil/mathematics.h"
> >> +#include "libavutil/mem.h"
> >>  #include "libavcodec/bytestream.h"
> >>  #include "libavcodec/mpeg4audio.h"
> >>  #include "avformat.h"
> >> @@ -41,6 +42,11 @@
> >>
> >>  #define RESYNC_BUFFER_SIZE (1<<20)
> >>
> >> +typedef struct FLVKeyFrame {
> >> +int64_t pos;
> >> +int64_t timestamp;
> >> +} FLVKeyFrame;
> >
> > instead of adding a 3rd array the local arrays from parse_keyframes_index()
> > could be moved into the context. That would reduce the memory needed
> >
> 
> ok
> 

> > It also may be needed to keep 2 sets that is one per stream
> > and the arrays should be freed after their use
> >
> >
> 
> Is that mean we need to call av_add_index_entry() for both stream?

no, but i am not sure if its guranteed that we never read both

when it first looks like theres just an audio stream the audio
index is loaded but when then a video index is found that is loaded
i think

maybe you could free the previous one in that case if you prefer
to have only single set of arrays


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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: access avframe fields directly in get_frame_defaults()

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 04:01:40PM -0300, James Almer wrote:
> The accessors are needed only from outside libavutil.
> 
> Signed-off-by: James Almer 
> ---
>  libavutil/frame.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

LGTM

thanks

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

[FFmpeg-devel] [PATCH 2/2] v2 SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

From: carlos 

Signed-off-by: carlos 
---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 110 +---
 libavformat/scte_35.c | 482 ++
 libavformat/scte_35.h |  76 
 4 files changed, 646 insertions(+), 24 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c3f38b4..93635bc 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -204,7 +204,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
-OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
+OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o scte_35.o
 OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
 OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
 OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5dc518d..94e058e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -38,6 +38,7 @@
 #include "avio_internal.h"
 #include "internal.h"
 #include "os_support.h"
+#include "scte_35.h"
 
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
@@ -48,6 +49,10 @@ typedef struct HLSSegment {
 double duration; /* in seconds */
 int64_t pos;
 int64_t size;
+struct scte_35_event *event;
+int out;
+int adv_count;
+int64_t start_pts;
 
 char key_uri[LINE_BUFFER_SIZE + 1];
 char iv_string[KEYSIZE*2 + 1];
@@ -89,6 +94,8 @@ typedef struct HLSContext {
 uint32_t flags;// enum HLSFlags
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
+char *adv_filename;
+char *adv_subfilename;
 
 int use_localtime;  ///< flag to expand filename with localtime
 int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
@@ -104,6 +111,7 @@ typedef struct HLSContext {
 int nb_entries;
 int discontinuity_set;
 
+struct scte_35_interface *scte_iface;
 HLSSegment *segments;
 HLSSegment *last_segment;
 HLSSegment *old_segments;
@@ -203,6 +211,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
 av_freep(&path);
 previous_segment = segment;
 segment = previous_segment->next;
+if (hls->scte_iface)
+hls->scte_iface->unref_scte35_event(&previous_segment->event);
 av_free(previous_segment);
 }
 
@@ -314,8 +324,8 @@ static int hls_mux_init(AVFormatContext *s)
 }
 
 /* Create a new segment and append it to the segment list */
-static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration,
-  int64_t pos, int64_t size)
+static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration, int64_t pos,
+  int64_t start_pts, struct scte_35_event *event, 
int64_t size)
 {
 HLSSegment *en = av_malloc(sizeof(*en));
 char *tmp, *p;
@@ -349,11 +359,25 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 else
 en->sub_filename[0] = '\0';
 
-en->duration = duration;
-en->pos  = pos;
-en->size = size;
+en->duration   = duration;
+en->pos= pos;
+en->event  = event;
+en->size   = size;
+en->start_pts  = start_pts;
 en->next = NULL;
 
+if (hls->scte_iface) {
+if (hls->scte_iface->event_out == EVENT_OUT_CONT) {
+en->adv_count = hls->scte_iface->adv_count;
+hls->scte_iface->adv_count++;
+en->out = hls->scte_iface->event_out;
+} else {
+hls->scte_iface->adv_count = 0;
+en->out = hls->scte_iface->event_out;
+}
+}
+
+
 if (hls->key_info_file) {
 av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
 av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
@@ -475,9 +499,23 @@ static int hls_window(AVFormatContext *s, int last)
 if (hls->flags & HLS_SINGLE_FILE)
  avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
  en->size, en->pos);
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
+if (hls->scte_iface && (en->event || en->out) ) {
+char *str;
+char fname[1024] = "";
+if (hls->adv_filename) {
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, hls->adv_filename, en->out, en->adv_count, en->start_pts);
+} else {
+if (hls->baseurl)
+strncat(fname, hls->baseurl, 1024);
+strncat(fname, en->filename, 1024);
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, 

[FFmpeg-devel] [PATCH 1/2] v2 SCTE extraction from mpegts

[Carlos Fernandez Sanz]

From: Carlos 

Signed-off-by: carlos 
---
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  6 ++
 libavformat/mpegts.c| 46 --
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ca8dba8..df8e2f3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -628,6 +628,7 @@ enum AVCodecID {
 /* other specific kind of codecs (generally used for attachments) */
 AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing at 
the start of various fake codecs.
 AV_CODEC_ID_TTF = 0x18000,
+AV_CODEC_ID_SCTE_35,
 
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index dea17c9..5c00be0 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2950,6 +2950,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("binary data"),
 .mime_types= MT("application/octet-stream"),
 },
+{
+.id= AV_CODEC_ID_SCTE_35,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_35",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
+},
 
 /* deprecated codec ids */
 };
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..99631b1 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -57,6 +57,7 @@ enum MpegTSFilterType {
 MPEGTS_PES,
 MPEGTS_SECTION,
 MPEGTS_PCR,
+MPEGTS_DATA,
 };
 
 typedef struct MpegTSFilter MpegTSFilter;
@@ -510,6 +511,11 @@ static MpegTSFilter *mpegts_open_pcr_filter(MpegTSContext 
*ts, unsigned int pid)
 return mpegts_open_filter(ts, pid, MPEGTS_PCR);
 }
 
+static MpegTSFilter *mpegts_open_data_filter(MpegTSContext *ts, unsigned int 
pid)
+{
+return mpegts_open_filter(ts, pid, MPEGTS_DATA);
+}
+
 static void mpegts_close_filter(MpegTSContext *ts, MpegTSFilter *filter)
 {
 int pid;
@@ -705,6 +711,7 @@ static const StreamType ISO_types[] = {
 { 0x21, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_JPEG2000   },
 { 0x24, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC   },
 { 0x42, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_CAVS   },
+{ 0x86, AVMEDIA_TYPE_DATA,  AV_CODEC_ID_SCTE_35},
 { 0xd1, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_DIRAC  },
 { 0xea, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1},
 { 0 },
@@ -872,6 +879,13 @@ static void reset_pes_packet_state(PESContext *pes)
 av_buffer_unref(&pes->buffer);
 }
 
+static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
+{
+av_init_packet(pkt);
+pkt->data = buffer;
+pkt->size = len;
+}
+
 static int new_pes_packet(PESContext *pes, AVPacket *pkt)
 {
 char *sd;
@@ -1975,6 +1989,19 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 pes->st->id = pes->pid;
 }
 st = pes->st;
+} else if (stream_type == 0x86 && prog_reg_desc ==  AV_RL32("CUEI")) {
+int idx = ff_find_stream_index(ts->stream, pid);
+if (idx >= 0) {
+st = ts->stream->streams[idx];
+} else {
+st = avformat_new_stream(ts->stream, NULL);
+if (!st)
+goto out;
+st->id = pid;
+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
+mpegts_find_stream_type(st, stream_type, ISO_types);
+mpegts_open_data_filter(ts, pid);
+}
 } else if (stream_type != 0x13) {
 if (ts->pids[pid])
 mpegts_close_filter(ts, ts->pids[pid]); // wrongly added sdt 
filter probably
@@ -2317,15 +2344,20 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 }
-
-} else {
+} else if (tss->type == MPEGTS_DATA) {
+int idx = ff_find_stream_index(ts->stream, pid);
+p++;
+new_data_packet(p,p_end - p, ts->pkt);
+if (idx >= 0) {
+ts->pkt->stream_index = idx;
+}
+ts->stop_parse = 1;
+} else if (tss->type == MPEGTS_PES) {
 int ret;
 // Note: The position here points actually behind the current packet.
-if (tss->type == MPEGTS_PES) {
-if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
+if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
 pos - ts->raw_packet_size)) < 
0)
-return ret;
-}
+return ret;
 }
 
 return 0;
@@ -2730,6 +2762,8 @@ static int mpegts_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 ret = 0;
 break;
 }
+} else if (ts->pids[i] && ts->pids[i]->type == MPEGTS_DATA) {
+return ret;
 }
 }
 
-- 
2.7.4

___

[FFmpeg-devel] [PATCH 0/2] v2 - SCTE-35 support

[Carlos Fernandez Sanz]

These two patches add support for SCTE-35. First, parse it correct from MPEG,
then segment appropiately.

All things reported about v1 addressed:

- Removed commented out code
- Spaces where there was a tab
- Should build on mingw64 (removed probable cause of error)
- Made it a hls muxer dependency instead of libavformat  


Carlos (1):
  SCTE extraction from mpegts

carlos (1):
  SCTE-35 support in hlsenc

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavformat/Makefile|   2 +-
 libavformat/hlsenc.c| 110 ---
 libavformat/mpegts.c|  46 -
 libavformat/scte_35.c   | 482 
 libavformat/scte_35.h   |  76 
 7 files changed, 693 insertions(+), 30 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

-- 
2.7.4

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

[FFmpeg-devel] avio starting offset and hls regression in 3.1

[Anssi Hannula]

Hi all,

Commit d0fc5de3a643fe7f974ed14e410c2ac2f4147d7e [1] merged in
commit 81306fd4bdeb5c17d4db771e4fec684773b5790f "hls: eliminate ffurl_*
usage" from libav, which changed the hls demuxer to use AVIOContext
instead of URLContext for its HTTP requests.

HLS demuxer uses the "offset" option for the http demuxer, requesting
the initial file offset for the I/O (http URLProtocol uses the "Range:"
HTTP header to try to accommodate that).

However, the code in libavformat/aviobuf.c seems to be doing its own
accounting for the current file offset (AVIOContext.pos), with the
assumption that the initial offset is always zero.

HLS demuxer does an explicit seek after open_url to account for cases
where the "offset" was not effective (due to the URL being a local file
or the HTTP server not obeying it), which should be a no-op in case the
file offset is already at that position.

However, since aviobuf.c code thinks the starting offset is 0, this
doesn't work properly.

E.g. this command, which worked fine in FFmpeg 3.0, now fails after
approx. 10 seconds of playback:
ffplay
https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8


Now, what should be done to fix this regression?

I guess there are at least these options:

1. Make aviobuf.c call seek() to check the offset after open:

--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -913,6 +913,14 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
 (*s)->read_pause = io_read_pause;
 (*s)->read_seek  = io_read_seek;
 }
+
+/* get initial buffer position (may be non-zero with e.g. offset
option for http) */
+if ((*s)->seek) {
+int64_t pos = (*s)->seek((*s)->opaque, 0, SEEK_CUR);
+if (pos >= 0)
+(*s)->pos = pos;
+}
+
 (*s)->av_class = &ff_avio_class;
 return 0;
 fail:

I guess that has a high chance of further regressions (*if* it is even
correct), though, as I guess there may be seek() handlers that don't
have SEEK_CUR = 0 as a no-op.

2. Revert the commit. I'm not familiar enough (or I've just forgotten
that stuff) with avio/ffurl to know how big the benefit of using avio_
instead of ffurl_ is, though...

3. Drop the seek call from HLS demuxer in case protocol is http*, and
assume the HTTP server obeyed the ranged request.


Any other ideas / opinions for the course of action?


[1] https://github.com/FFmpeg/FFmpeg/commit/d0fc5de3a643fe7f974ed14

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

[FFmpeg-devel] [PATCH] af_hdcd: Process stereo channels together, fix #5727

[Burt P]

Issue #5727: gain adjustment should only be applied if matching
gain value from a valid packet in both channels. The existing functions process
each channel separately, so it was not possible.

* New versions of hdcd_process(), hdcd_scan(), hdcd_integrate() named
  hdcd_*_stereo() that process both channels together.
* target_gain applied will be the last matching target_gain.
* The old single channel functions remain as an option. They can be used
  by filter option: -af hdcd=process_stereo=0.
* Some code common to both sets has been moved into own functions:
  hdcd_code(), hdcd_control(), hdcd_sustain_reset().
* This is against master, so it also includes the changes in an earlier
  patch set for HDCD detection, PE mode, cdt counter, and code comments.

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 463 +-
 1 file changed, 386 insertions(+), 77 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 6f0db71..725b697 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -23,12 +23,12 @@
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-*/
+ */
 
 /*
   Original code reverse engineered from HDCD decoder library by Christopher 
Key,
   which was likely reverse engineered from Windows Media Player.
-*/
+ */
 
 /*
   HDCD is High Definition Compatible Digital
@@ -818,44 +818,88 @@ static const int32_t gaintab[] = {
 
 typedef struct {
 uint64_t window;
-unsigned char readahead, arg, control;
-int running_gain;
-unsigned sustain, sustain_reset;
-int code_counterA;
-int code_counterA_almost; /* looks like an A code, but a bit expected to 
be 0 is 1 */
-int code_counterB;
+unsigned char readahead;
+
+/* arg is set when a packet prefix is found.
+ * control is the active control code, where
+ * bit 0-3: target_gain, 4-bit (3.1) fixed-point value
+ * bit 4  : peak_extend
+ * bit 5  : transient_filter
+ * bit 6,7: always zero */
+unsigned char arg, control;
+unsigned sustain, sustain_reset; /* code detect timer */
+
+int running_gain; /* 11-bit (3.8) fixed point, extended from target_gain */
+
+/* counters */
+int code_counterA;/* 8-bit format packet */
+int code_counterA_almost; /* looks like an A code, but a bit expected 
to be 0 is 1 */
+int code_counterB;/* 16-bit format packet, 8-bit code, 8-bit 
XOR of code */
 int code_counterB_checkfails; /* looks like a B code, but doesn't pass the 
XOR check */
-int code_counterC;
-int code_counterC_unmatched; /* told to look for a code, but didn't find 
one */
-
-/* For user information/stats, pulled up into HDCDContext
- * by filter_frame() */
-int count_peak_extend;
-int count_transient_filter;
+int code_counterC;/* packet prefix was found, expect a code */
+int code_counterC_unmatched;  /* told to look for a code, but didn't find 
one */
+int count_peak_extend;/* valid packets where peak_extend was 
enabled */
+int count_transient_filter;   /* valid packets where filter was detected */
 /* target_gain is a 4-bit (3.1) fixed-point value, always
  * negative, but stored positive.
  * The 16 possible values range from -7.5 to 0.0 dB in
  * steps of 0.5, but no value below -6.0 dB should appear. */
 int gain_counts[16]; /* for cursiosity, mostly */
 int max_gain;
-
-AVFilterContext *fctx; /* filter context for logging errors */
+/* occurences of code detect timer expiring without detecting
+ * a code. -1 for timer never set. */
+int count_sustain_expired;
 } hdcd_state_t;
 
+typedef enum {
+HDCD_PE_NEVER=0,
+HDCD_PE_INTERMITTENT =1,
+HDCD_PE_PERMANENT=2
+} hdcd_pe_t;
+
+const char* pe_str[] = {
+"never enabled",
+"enabled intermittently",
+"enabled permanently"
+};
+
+#define HDCD_PROCESS_STEREO_DEFAULT 1
+#define HDCD_MAX_CHANNELS 2
+
 typedef struct HDCDContext {
 const AVClass *class;
-hdcd_state_t state[2];
+hdcd_state_t state[HDCD_MAX_CHANNELS];
+
+/* use hdcd_*_stereo() functions to process both channels together.
+ * -af hdcd=process_stereo=0 for off
+ * -af hdcd=process_stereo=1 for on
+ * default is HDCD_PROCESS_STEREO_DEFAULT */
+int process_stereo;
+/* always extend peaks above -3dBFS even if PE isn't signaled
+ * -af hdcd=force_pe=0 for off
+ * -af hdcd=force_pe=1 for on
+ * default is off */
+int force_pe;
+
+AVFilterContext *fctx; /* filter context for logging errors */
+int sample_count;  /* used in error logging */
+int val_target_gain;   /* last matching target_gain in both channels */
 
 /* User information/stats */
 int hdcd_detected;
 int det_errors;/* detectable erro

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 12:25:07PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer  > wrote:
> 
> > On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > > https://github.com/dsmudhar/FFmpeg/commits/dev
> 
> 
> So, correct me if I'm wrong, but it seems the complete ME code currently
> lives inside the filter. I wonder if that is the best way forward. I
> thought the idea was to split out the ME code into its own module and share
> it between various filters and the relevant encoders without a strict
> dependency on avfilter/avcodec, or more specifically, AVCodecContext or
> anything like that?

there is little overlap between ME used in encoders and ME used
for finding true motion
These are different problems unless one considers just some
initial motion estimation pass that just serves as a start point
(that initial start pass code could be shared in principle ...)

For encoding you want to minimize the distortion after the decoder
and the bitrate, and you are restricted by the structure of the
codec like 4x4, 8x8 and 16x16 blocks with 1/4 translational motion
for example


For finding true motion for the purpose of filtering there is no
bitrate, there is no restrictions on the segmentation, precission,
type of motion or the number of motion vectors per pixel. distortion
does not even matter all that much, the vectors must match the
true motion of the objects and if you cant achive that making the
vector field smooth temporally and spatially is much more important
because having all vectors wrong in a smooth way looks much better
than having a tiny number of vectors wrong even if these match very
well the pixels
simple frame duplication is basically all (0,0) vectors from the
past frame and that looks ok


just think about what happens if you interpolate with all prefectly
optimal vectors per pixel but one single 16x16 block being entirely
wrong. Such a frame would have a randomly displaced 16x16 block in each
frame thats much worse than all (0,0) vectors
also that bad block could be 100% matching pixel wise between
frame 1 and 3 and still be totally wrong at the interpolated
position in frame 2 (which we create)
this is the big issue i had with mcfps, it all looks good except the
occasional vectors which match ok pixel wise but are just really
not right vector wise, like someones finger moving to his nose
because that matches well pixel wise ...
(it wasnt finger and nose but random blocks moving around very
 differntly from the actual motion which looks really bad)

Also another issue with code sharing ATM is that it would make
tuning the code harder, the ME code used for the encoders is quite
restricted in what it supports and its optimized for that.
IIUC for the filtering Davinder is still testing and tuning things,
i think thats much easier without draging
"shared with encoders and highly optimized for that" code along

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

[FFmpeg-devel] [PATCH] avutil/frame: access avframe fields directly in get_frame_defaults()

[James Almer]

The accessors are needed only from outside libavutil.

Signed-off-by: James Almer 
---
 libavutil/frame.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index d5c7c9f..662c20d 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -101,10 +101,10 @@ static void get_frame_defaults(AVFrame *frame)
 frame->pts   =
 frame->pkt_dts   =
 frame->pkt_pts   = AV_NOPTS_VALUE;
-av_frame_set_best_effort_timestamp(frame, AV_NOPTS_VALUE);
-av_frame_set_pkt_duration (frame, 0);
-av_frame_set_pkt_pos  (frame, -1);
-av_frame_set_pkt_size (frame, -1);
+frame->best_effort_timestamp = AV_NOPTS_VALUE;
+frame->pkt_duration= 0;
+frame->pkt_pos = -1;
+frame->pkt_size= -1;
 frame->key_frame   = 1;
 frame->sample_aspect_ratio = (AVRational){ 0, 1 };
 frame->format  = -1; /* unknown */
-- 
2.9.1

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

[FFmpeg-devel] [PATCH 0/1] af_hdcd: Process stereo channels together, fix #5727

[Burt P]

For review, a fix for #5727. Please test and comment.

I've made new versions of the processing functions that process
stereo channels together so that the rule regarding target_gain can
be implemented. The target_gain used for both channels will now be
the last valid target_gain that matched between channels.

The old single-channel functions are still there, so that testing
is possible, and for compatibility with the original fb2k code.
They can be used by: -af hdcd=process_stereo=0

I've tested several HDCD flac and the majority come out exactly the
same using either path, but there have been a few differences where
control codes do not appear at exactly the same sample, so there is
a few samples of delay before they match up.

One strange case is John Mellencamp - [1994] Mr. Happy Go Lucky
06. Emotional Love, where there is one extra HDCD packet in one
channel, and that target_gain value ends up being ignored.

This patch is against master, so it also includes the changes in an
earlier (not yet applied) patch set for HDCD detection, PE mode,
cdt counter, and code comments.

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

[FFmpeg-devel] [PATCH] avfilter: Add new format for PSNR stats log

[Lucas Cooper]

Add an AVOption stats_version with a new header for V2 stats, which
specifies the stats log version and lists the fields that will be
present in the log (to ease parsing).

The primary motivation is to facilitate the addition of optional fields
to the log without breaking backwards compatibility, while making the
logs easier to parse.
---
 libavfilter/vf_psnr.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index 89acd3c..999f14d 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -43,6 +43,8 @@ typedef struct PSNRContext {
 uint64_t nb_frames;
 FILE *stats_file;
 char *stats_file_str;
+int stats_version;
+int stats_header_written;
 int max[4], average_max;
 int is_rgb;
 uint8_t rgba_map[4];
@@ -60,6 +62,7 @@ typedef struct PSNRContext {
 static const AVOption psnr_options[] = {
 {"stats_file", "Set file where to store per-frame difference information", 
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
 {"f",  "Set file where to store per-frame difference information", 
OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
+{"stats_version", "Set the format version for the stats file.",
   OFFSET(stats_version),  AV_OPT_TYPE_INT,{.i64=1},1, 2, FLAGS },
 { NULL }
 };
 
@@ -169,6 +172,19 @@ static AVFrame *do_psnr(AVFilterContext *ctx, AVFrame 
*main,
 set_meta(metadata, "lavfi.psnr.psnr_avg", 0, get_psnr(mse, 1, 
s->average_max));
 
 if (s->stats_file) {
+if (s->stats_version == 2 && !s->stats_header_written) {
+fprintf(s->stats_file, "psnr_log_version:2 fields:n");
+fprintf(s->stats_file, ",mse_avg");
+for (j = 0; j < s->nb_components; j++) {
+fprintf(s->stats_file, ",mse_%c", s->comps[j]);
+}
+fprintf(s->stats_file, ",psnr_avg");
+for (j = 0; j < s->nb_components; j++) {
+fprintf(s->stats_file, ",psnr_%c", s->comps[j]);
+}
+fprintf(s->stats_file, "\n");
+s->stats_header_written = 1;
+}
 fprintf(s->stats_file, "n:%"PRId64" mse_avg:%0.2f ", s->nb_frames, 
mse);
 for (j = 0; j < s->nb_components; j++) {
 c = s->is_rgb ? s->rgba_map[j] : j;
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] avdev/libdc1394: distinguish between enumeration errors, and no cameras found

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 12:21:12PM +0100, Josh de Kock wrote:
> On Mon, Jul 25, 2016, at 10:23 AM, Michael Niedermayer wrote:
> > 
> > applied
> > 
> > will push once git.videolan.org is up again
> > 
> > thx
> 
> if you haven't pushed already, could you change the following: 
> 
> if (dc1394_camera_enumerate(dc1394->d, &list) != DC1394_SUCCESS ||
> !list){
> 
> should be:
> 
> if (dc1394_camera_enumerate(dc1394->d, &list) != DC1394_SUCCESS ||
> !list) {
> 
> and 'lavd/libdc1394: distinguish between enumeration errors and no
> cameras found'
> is probably a better commit message (fits in with the other commit
> messages more)

fixed

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH] libavformat/rtpdec_asf: zero initialize the AVIOContext struct

[Michael Niedermayer]

On Sat, Jul 23, 2016 at 11:47:39PM +0200, Kacper Michajłow wrote:
> This fixes crash in avformat_open_input() when accessing
> protocol_whitelist field.
> ---
>  libavformat/rtpdec_asf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

[...]
-- 
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] avcodec/alsdec: implement floating point decoding

[Umair Khan]

On Sun, Jul 24, 2016 at 1:47 AM, Umair Khan  wrote:
>
> HI,
>
> On Fri, Jul 22, 2016 at 9:19 PM, Michael Niedermayer
>  wrote:
> > On Fri, Jul 22, 2016 at 06:22:30PM +0530, Umair Khan wrote:
> >> On Thu, Jul 21, 2016 at 6:18 PM, Michael Niedermayer
> >>  wrote:
> >> > On Sun, Jul 17, 2016 at 12:06:03AM +0530, Umair Khan wrote:
> > [...]
> >> >> +static int decode_string(MLZDict *dict, unsigned char *buff, int 
> >> >> string_code, int *first_char_code, unsigned long bufsize) {
> >> >> +unsigned long count, offset;
> >> >> +int current_code, parent_code, tmp_code;
> >> >> +
> >> >> +count= 0;
> >> >> +current_code = string_code;
> >> >> +*first_char_code = CODE_UNSET;
> >> >> +
> >> >> +while (count < bufsize) {
> >> >> +switch (current_code) {
> >> >> +case CODE_UNSET:
> >> >> +return count;
> >> >> +break;
> >> >> +default:
> >> >> +if (current_code < FIRST_CODE) {
> >> >> +*first_char_code = current_code;
> >> >> +buff[0] = current_code;
> >> >> +count++;
> >> >> +return count;
> >> >> +} else {
> >> >> +offset  = dict[current_code].match_len - 1;
> >> >> +tmp_code = dict[current_code].char_code;
> >> >> +buff[offset] = tmp_code;
> >> >> +count++;
> >> >> +}
> >> >> +current_code = dict[current_code].parent_code;
> >> >> +if ((current_code < 0) || (current_code > (DIC_INDEX_MAX - 
> >> >> 1))) {
> >> >
> >> >> +av_log(NULL, AV_LOG_ERROR, "MLZ dic index error.\n");
> >> >
> >> > it would be ideal if all av_log() would have a context instead of NULL
> >>
> >> How to go ahead with this? Should I create MLZContext or something? If
> >> yes, could you please tell how?
> >
> > possible or you pass a void *context
>
> Updated patch.

Another revision. Fixes some things I had overlooked.

- Umair


0001-avcodec-alsdec-implement-floating-point-decoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Ronald S. Bultje]

Hi,

On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer  wrote:

> On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > https://github.com/dsmudhar/FFmpeg/commits/dev


So, correct me if I'm wrong, but it seems the complete ME code currently
lives inside the filter. I wonder if that is the best way forward. I
thought the idea was to split out the ME code into its own module and share
it between various filters and the relevant encoders without a strict
dependency on avfilter/avcodec, or more specifically, AVCodecContext or
anything like that?

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

[FFmpeg-devel] [PATCH 2/2] MAINTAINERS: Add myself as maintainer of fifo muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d4c9f9..0e66170 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -164,6 +164,7 @@ Codecs:
   exif.c, exif.hThilo Borgmann
   ffv1* Michael Niedermayer
   ffwavesynth.c Nicolas George
+  fifo.cJan Sebechlebsky
   flicvideo.c   Mike Melanson
   g722.cMartin Storsjo
   g726.cRoman Shaposhnik
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v3 1/2] libavformat: Add fifo pseudo-muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

The fifo pseudo-muxer allows to separate encoder from the
actual output by using a first-in-first-out queue and
running actual muxer asynchronously in separate thread.

It can be configured to attempt transparent recovery
of output on failure.

Signed-off-by: Jan Sebechlebsky 
---
 Changelog|   1 +
 configure|   1 +
 doc/muxers.texi  |  90 +++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/fifo.c   | 666 +++
 libavformat/version.h|   2 +-
 7 files changed, 761 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/fifo.c

diff --git a/Changelog b/Changelog
index 479f164..d7d0056 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - curves filter doesn't automatically insert points at x=0 and x=1 anymore
 - 16-bit support in curves filter
 - 16-bit support in selectivecolor filter
+- fifo muxer
 
 
 version 3.1:
diff --git a/configure b/configure
index 1b41303..903205b 100755
--- a/configure
+++ b/configure
@@ -2832,6 +2832,7 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
+fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 5873269..e2bc290 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1436,6 +1436,96 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@section fifo
+
+The fifo pseudo-muxer allows to separate encoding from any other muxer by using
+first-in-first-out queue and running the actual muxer in a separate thread. 
This
+is especially useful in combination with the @ref{tee} muxer and output to
+several destinations with different reliability/writing speed/latency.
+
+The behavior of fifo muxer in case of failure can be configured:
+@itemize @bullet
+
+@item
+output can be transparently restarted with configurable delay between retries
+based on real time or time of the processed stream.
+
+@item
+encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case fifo queue fills up.
+
+@end itemize
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets). Default value is 60.
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to 1 (true), in case the fifo queue fills up, packets will be dropped
+rather than blocking the encoder. This allows to continue streaming without
+delaying the output, at the cost of ommiting part of the stream. By default
+this option is set to 0 (false), so in such cases the encoder will be blocked
+until the muxer processes some of the packets and none of them is lost.
+
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option set to 0 (false).
+
+@item max_recovery_attempts
+Sets maximum number of successive unsucessful recovery attempts after which
+the output fails permanently. Unlimited if set to zero. Default value is 16.
+
+@item recovery_wait_time @var{duration}
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt. Default value is 5 seconds.
+
+s@item recovery_wait_streamtime @var{bool}
+If set to 0 (false), the real time is used when waiting for the recovery
+attempt (i.e. the recovery will be attempted after at least
+recovery_wait_time seconds).
+If set to 1 (true), the time of the processed stream is taken into account
+instead (i.e. the recovery will be attempted after at least recovery_wait_time
+seconds of the stream is omitted).
+By default, this option is set to 0 (false).
+
+@item recover_any_error @var{bool}
+If set to 1 (true), recovery will be attempted regardless of type of the error
+causing the failure. By default this option is set to 0 (false) and in case of
+certain errors the recovery is not attempted even when @ref{attempt_recovery}
+is set to 1.
+
+@item restart_with_keyframe @var{bool}
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure. This option is set to 0 (false) by default.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Stream something to rtmp server, continue processing the stream at real-time
+rate even in case of temporary failure (network outage) and attempt to recover
+streaming every second indefinitely.
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a mp2 -f fifo -fifo_format flv -map 0:v -map 
0:a
+  -block_on_overflow 0 -attemp

[FFmpeg-devel] [PATCH 0/2][GSoC] Add fifo pseudo-muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

Hello,
I am sending next version of fifo pseudo-muxer.

I will send patchset adding AVFMT_FLAG_NONBLOCK support requested 
by Nicolas later - it turned out that there are some more things
to solve (av_write_frame does not support repeated calls in current state)
and test.

Regards,
Jan

Jan Sebechlebsky (2):
  libavformat: Add fifo pseudo-muxer
  MAINTAINERS: Add myself as maintainer of fifo muxer

 Changelog|   1 +
 MAINTAINERS  |   1 +
 configure|   1 +
 doc/muxers.texi  |  90 +++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/fifo.c   | 666 +++
 libavformat/version.h|   2 +-
 8 files changed, 762 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/fifo.c

-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc: add missing dependency on dnxhddata

[James Almer]

On 7/24/2016 6:45 PM, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> Fixes a missing symbol error in lavc/movenc if the dnxhd encoder is not
> enabled.
> ---
> 
> New patch attached. If it's accepted, I'll revert the previous one and push 
> the
> new one.

Just reverted the previous patch and pushed a better solution.

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

Re: [FFmpeg-devel] [PATCH] lavc: always build dnxhddata

[James Almer]

On 7/25/2016 4:36 AM, Michael Niedermayer wrote:
> On Sun, Jul 24, 2016 at 11:43:41PM -0300, James Almer wrote:
>> On 7/24/2016 8:13 PM, Michael Niedermayer wrote:
> [...]
>>>

 Looking at this function closely now, it could have been added
 to dnxhddata.h instead. No need for avpriv_ prefix and to
 forcefully build an object file full of data tables that it
 doesn't need.
>>>
>>> agree, this would be best in this case
>>
>> Are you ok with me reverting this commit and moving the function
>> to the header? The symbol will of course not be removed until next
>> major bump since it's already in a release.
>> Alternatively apply "[PATCH] lavf/movenc: add missing dependency
>> on dnxhddata" but IMO it's better to just move the thing to the
>> header.
> 
> yes, moving to the header is better
> 
> thx

Moved then.

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/bsf: Set EOF flag only if pkt == NULL

[Nicolas George]

Le septidi 7 thermidor, an CCXXIV, Jan Sebechlebsky a écrit :
> I gave this a second thought, wouldn't it be better to simply ignore pkt
> without payload? So after caller would send empty packet using
> av_bsf_send_packet, he would get AVERROR(EAGAIN) from the next
> av_bsf_receive_packet call (from the definition in documentation
> AVERROR(EAGAIN) means "more data needed" when returned by
> av_bsf_receive_packet).
> However, if you think it is better to reserve packet without payload for
> some future use, I won't object.

Both are possible, it is a matter of balance between convenience for us and
convenience for the applications.

If at some point someone finds a way to use that kind of packet. If they
used to be ignored, it makes an incompatible API change. If they used to be
forbidden, it works.

The same logic applies for functions that return 0 for success or an AVERROR
code: the documentation usually states ">= 0 for success", that allows to
extend their return value later.

In this particular case, I do not see how an application can accidentally
send a completely empty packet, and therefore I think forbidding them is
better.

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] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 01:55:18PM +0300, Ivan Uskov wrote:
> Hello Michael,
> 
> Sunday, July 24, 2016, 11:25:29 PM, you wrote:
> 
> MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
> >> Hello Michael,
> >> 
> >> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
> >> 
> >> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
> >> >> Hello All,
> >> >> 
> >> >> I have discovered the following issue:
> >> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* 
> >> >> qsv-based h264 decoder uses.
> >> >> The crash does appear inside the
> >> >> 
> >> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
> >> >> {
> >> >> H264Context *h = avctx->priv_data;
> >> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
> >> >> }
> >> >> 
> >> >> It is obvious, that casting to H264Context cannot be used for qsv 
> >> >> decoder
> >> >> because there is QSVH2645Context. Similar issue will appear for CUVID
> >> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
> >> >> (MediaCodecH264DecContext uses), possible another cases existing.
> >> >> 
> >> >> The caller function is
> >> >> 
> >> >> static int has_decode_delay_been_guessed(AVStream *st)
> >> >> {
> >> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
> >> >> if (!st->info) // if we have left find_stream_info then 
> >> >> nb_decoded_frames won't increase anymore for stream copy
> >> >> return 1;
> >> >> #if CONFIG_H264_DECODER
> >> >> if (st->internal->avctx->has_b_frames &&
> >> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
> >> >> st->internal->avctx->has_b_frames)
> >> >> return 1;
> >> >> #endif
> >> >> if (st->internal->avctx->has_b_frames<3)
> >> >> return st->nb_decoded_frames >= 7;
> >> >> else if (st->internal->avctx->has_b_frames<4)
> >> >> return st->nb_decoded_frames >= 18;
> >> >> else
> >> >> return st->nb_decoded_frames >= 20;
> >> >> }
> >> >> ...which called by update_initial_timestamps()
> >> >> 
> >> >> Have anybody the idea how it can be correctly fixed?
> >> >> Looks like has_decode_delay_been_guessed() should be corrected.
> >> 
> >> MN> this code is not new, this is in git since 4 years
> >> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
> >> MN> Date:   Mon Jul 2 23:16:59 2012 +020
> >> 
> >> MN> why does it cause a problem now ?
> >> 
> >> MN> why does libavformat use hw h264 decoding ?
> >> I do not know that is reason why I'm asking.
> >> I just run ffmpeg like
> >> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
> >> -vcodec h264_qsv -y ./result.mp4
> >> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
> >> *avctx)
> >> 
> >> When I replace
> >> #if CONFIG_H264_DECODER
> >> to
> >> #if 0
> >> ...all working fine.
> >> 
> >> I can not say when exactly the issue appeared, about several weeks ago all
> >> worked correct. But current build is broken at this place.
> 
> MN> can you use git bisect to figure out when this issue appeared?
> The problem commit is
> Sun Jun 12 13:24:27 2016 +0200| [1534ef87c74cc66a117bf61c467641c2129bc964] | 
> committer: Clément Bœsch
> 
> There are lot changes but this modification made the issue visible:
> ==
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index c011527..0de6d91 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
>  -60,7 +60,7  const uint16_t ff_h264_mb_sizes[4] = { 
> 256, 384, 512, 768 };
>  int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>  {
>  H264Context *h = avctx->priv_data;
> -return h ? h->sps.num_reorder_frames : 0;
> +return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>  }
> ==
> I.e. _before_it_worked_wrong_too_ but silently. After the H264Context was
> modified and new construction h->ps.sps-> was added it has become critical.

hmm ok

so possible solutions are
A. make find_decoder() in libavformat/utils.c never return a hardware
   decoder, its a recipe for problems with races of thread unsafe
   drivers anyway
B. Improve the h264 AVParser in libavcodec so it can find the
   num_reorder_frames as well as the decoder and use that instead of
   avpriv_h264_has_num_reorder_frames()
C. disable avpriv_h264_has_num_reorder_frames() when the decoder isnt
   the sw decoder

C will cause errors for some usecases

[...]

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

Re: [FFmpeg-devel] [PATCH] avdev/libdc1394: distinguish between enumeration errors, and no cameras found

[Josh de Kock]

On Mon, Jul 25, 2016, at 10:23 AM, Michael Niedermayer wrote:
> 
> applied
> 
> will push once git.videolan.org is up again
> 
> thx

if you haven't pushed already, could you change the following: 

if (dc1394_camera_enumerate(dc1394->d, &list) != DC1394_SUCCESS ||
!list){

should be:

if (dc1394_camera_enumerate(dc1394->d, &list) != DC1394_SUCCESS ||
!list) {

and 'lavd/libdc1394: distinguish between enumeration errors and no
cameras found'
is probably a better commit message (fits in with the other commit
messages more)

Thanks,

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

Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

[Ivan Uskov]

Hello Michael,

Sunday, July 24, 2016, 11:25:29 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>> 
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> >> Hello All,
>> >> 
>> >> I have discovered the following issue:
>> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> >> h264 decoder uses.
>> >> The crash does appear inside the
>> >> 
>> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> >> {
>> >> H264Context *h = avctx->priv_data;
>> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> >> }
>> >> 
>> >> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> >> because there is QSVH2645Context. Similar issue will appear for CUVID
>> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> >> (MediaCodecH264DecContext uses), possible another cases existing.
>> >> 
>> >> The caller function is
>> >> 
>> >> static int has_decode_delay_been_guessed(AVStream *st)
>> >> {
>> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> >> if (!st->info) // if we have left find_stream_info then 
>> >> nb_decoded_frames won't increase anymore for stream copy
>> >> return 1;
>> >> #if CONFIG_H264_DECODER
>> >> if (st->internal->avctx->has_b_frames &&
>> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> >> st->internal->avctx->has_b_frames)
>> >> return 1;
>> >> #endif
>> >> if (st->internal->avctx->has_b_frames<3)
>> >> return st->nb_decoded_frames >= 7;
>> >> else if (st->internal->avctx->has_b_frames<4)
>> >> return st->nb_decoded_frames >= 18;
>> >> else
>> >> return st->nb_decoded_frames >= 20;
>> >> }
>> >> ...which called by update_initial_timestamps()
>> >> 
>> >> Have anybody the idea how it can be correctly fixed?
>> >> Looks like has_decode_delay_been_guessed() should be corrected.
>> 
>> MN> this code is not new, this is in git since 4 years
>> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
>> MN> Date:   Mon Jul 2 23:16:59 2012 +020
>> 
>> MN> why does it cause a problem now ?
>> 
>> MN> why does libavformat use hw h264 decoding ?
>> I do not know that is reason why I'm asking.
>> I just run ffmpeg like
>> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
>> -vcodec h264_qsv -y ./result.mp4
>> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
>> *avctx)
>> 
>> When I replace
>> #if CONFIG_H264_DECODER
>> to
>> #if 0
>> ...all working fine.
>> 
>> I can not say when exactly the issue appeared, about several weeks ago all
>> worked correct. But current build is broken at this place.

MN> can you use git bisect to figure out when this issue appeared?
The problem commit is
Sun Jun 12 13:24:27 2016 +0200| [1534ef87c74cc66a117bf61c467641c2129bc964] | 
committer: Clément Bœsch

There are lot changes but this modification made the issue visible:
==
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index c011527..0de6d91 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
 -60,7 +60,7  const uint16_t ff_h264_mb_sizes[4] = { 
256, 384, 512, 768 };
 int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
 {
 H264Context *h = avctx->priv_data;
-return h ? h->sps.num_reorder_frames : 0;
+return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
 }
==
I.e. _before_it_worked_wrong_too_ but silently. After the H264Context was
modified and new construction h->ps.sps-> was added it has become critical.


MN> was the decoder used in libavformat previously also the hw instead of
MN> sw decoder ?


MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] [PATCH] avformat/fivdec: cached keyframes before video or audio stream was created

[XinZheng Zhang]

On Mon, Jul 25, 2016 at 4:41 PM, Michael Niedermayer
 wrote:
> On Thu, Jul 21, 2016 at 10:36:20AM +0800, Xinzheng Zhang wrote:
>> ---
>>  libavformat/flvdec.c | 51 
>> ---
>>  1 file changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>> index 2bf1e05..b4fb4e2 100644
>> --- a/libavformat/flvdec.c
>> +++ b/libavformat/flvdec.c
>> @@ -30,6 +30,7 @@
>>  #include "libavutil/opt.h"
>>  #include "libavutil/intfloat.h"
>>  #include "libavutil/mathematics.h"
>> +#include "libavutil/mem.h"
>>  #include "libavcodec/bytestream.h"
>>  #include "libavcodec/mpeg4audio.h"
>>  #include "avformat.h"
>> @@ -41,6 +42,11 @@
>>
>>  #define RESYNC_BUFFER_SIZE (1<<20)
>>
>> +typedef struct FLVKeyFrame {
>> +int64_t pos;
>> +int64_t timestamp;
>> +} FLVKeyFrame;
>
> instead of adding a 3rd array the local arrays from parse_keyframes_index()
> could be moved into the context. That would reduce the memory needed
>

ok

> It also may be needed to keep 2 sets that is one per stream
> and the arrays should be freed after their use
>
>

Is that mean we need to call av_add_index_entry() for both stream?

>> +
>>  typedef struct FLVContext {
>>  const AVClass *class; ///< Class for private options.
>>  int trust_metadata;   ///< configure streams according onMetaData
>> @@ -61,6 +67,10 @@ typedef struct FLVContext {
>>
>>  int broken_sizes;
>>  int sum_flv_tag_size;
>> +
>> +int head_flags; //r8
>> +FLVKeyFrame *keyframes;
>> +int keyframe_count;
>>  } FLVContext;
>>
>>  static int probe(AVProbeData *p, int live)
>> @@ -95,6 +105,9 @@ static int live_flv_probe(AVProbeData *p)
>>  static AVStream *create_stream(AVFormatContext *s, int codec_type)
>>  {
>>  AVStream *st = avformat_new_stream(s, NULL);
>> +FLVContext *flv = s->priv_data;
>> +int flags = flv->head_flags;
>> +int i = 0;
>>  if (!st)
>>  return NULL;
>>  st->codecpar->codec_type = codec_type;
>> @@ -104,6 +117,17 @@ static AVStream *create_stream(AVFormatContext *s, int 
>> codec_type)
>>  s->ctx_flags &= ~AVFMTCTX_NOHEADER;
>>
>>  avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
>> +if ((!(flags & FLV_HEADER_FLAG_HASVIDEO) && codec_type == 
>> AVMEDIA_TYPE_AUDIO) ||
>> +(codec_type == AVMEDIA_TYPE_VIDEO)
>> +) {
>> +for (; i < flv->keyframe_count; i++) {
>> +FLVKeyFrame *keyframe = &flv->keyframes[i];
>> +av_add_index_entry(st, keyframe->pos, keyframe->timestamp,
>> +   0, 0, AVINDEX_KEYFRAME);
>> +}
>> +flv->keyframe_count = 0;
>> +av_freep(&flv->keyframes);
>> +}
>>  return st;
>>  }
>>
>> @@ -306,7 +330,7 @@ static int amf_get_string(AVIOContext *ioc, char 
>> *buffer, int buffsize)
>>  }
>>
>>  static int parse_keyframes_index(AVFormatContext *s, AVIOContext *ioc,
>> - AVStream *vstream, int64_t max_pos)
>> + AVStream *vstream, AVStream *astream, 
>> int64_t max_pos)
>>  {
>>  FLVContext *flv   = s->priv_data;
>>  unsigned int timeslen = 0, fileposlen = 0, i;
>> @@ -315,8 +339,12 @@ static int parse_keyframes_index(AVFormatContext *s, 
>> AVIOContext *ioc,
>>  int64_t *filepositions = NULL;
>>  int ret= AVERROR(ENOSYS);
>>  int64_t initial_pos= avio_tell(ioc);
>> +int head_flags = flv->head_flags;
>> +AVStream *kf_stream= vstream;
>> +if (!kf_stream && astream && (!(head_flags & FLV_HEADER_FLAG_HASVIDEO) 
>> && (head_flags & FLV_HEADER_FLAG_HASAUDIO)))
>> +kf_stream = astream;
>>
>> -if (vstream->nb_index_entries>0) {
>> +if (kf_stream && kf_stream->nb_index_entries > 0) {
>>  av_log(s, AV_LOG_WARNING, "Skipping duplicate index\n");
>>  return 0;
>>  }
>
>> @@ -369,8 +397,16 @@ static int parse_keyframes_index(AVFormatContext *s, 
>> AVIOContext *ioc,
>>
>>  if (timeslen == fileposlen && fileposlen>1 && max_pos <= 
>> filepositions[0]) {
>>  for (i = 0; i < fileposlen; i++) {
>> -av_add_index_entry(vstream, filepositions[i], times[i] * 1000,
>> -   0, 0, AVINDEX_KEYFRAME);
>> +if (kf_stream) {
>> +av_add_index_entry(kf_stream, filepositions[i], times[i] * 
>> 1000,
>> +   0, 0, AVINDEX_KEYFRAME);
>> +} else {
>> +FLVKeyFrame frame = {0};
>> +frame.pos = filepositions[i];
>> +frame.timestamp = times[i] * 1000;
>> +av_dynarray2_add((void **)&flv->keyframes, 
>> &flv->keyframe_count,sizeof(FLVKeyFrame), (const uint8_t *)&frame);
>> +}
>> +
>>  if (i < 2) {
>>  flv->validate_index[i].pos = filepositions[i];
>>  flv->validate_index[i].dts = times[i] * 1000;
>> @@ -418,10 +4

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Michael Niedermayer]

On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> https://github.com/dsmudhar/FFmpeg/commits/dev
> 
> The Paper 2 algorithm is complete. It seems good. If I compare Paper 2
> (which uses bilateral motion estimation) v/s motion vectors exported by

good!


> mEstimate filter:
> 
> $ tiny_psnr 60_source_2.yuv 60_mest-esa+obmc.yuv
> stddev:1.43 PSNR: 45.02 MAXDIFF:  174 bytes:476928000/474163200
> 
> $ tiny_psnr 60_source_2.yuv 60_paper2_aobmc+cls.yuv
> stddev:1.25 PSNR: 46.18 MAXDIFF:  187 bytes:476928000/474163200

how does this compare to vf_mcfps ?


> 
> Frame comparison: http://www.mediafire.com/?qe7sc4o0s4hgug5
> 
> Compared to simple OBMC which over-smooth edges, Objects clustering and
> Adaptive OBMC makes the edges crisp but also introduce blocking artifacts
> where MVs are bad (with default search window = 7). But I think it’s ESA’s
> fault. The paper doesn’t specify which motion estimation method they used;
> I have been using ESA. I think quality can be further improved with EPZS,
> which I'm going to implement.

agree, good idea, also do you use some "smoothness" term ?
i mean in video encoding the difference between the predicted MV and
the actual one needs to be stored, the number of bits is scaled by
some constant and added in when testing MVs that resuslts in MVs being
closer together.
Something similar should help any motion estiation be that ESA or EPZS
i didnt check if you already use something like that but if not then
its probably a good idea to try, also as its quite simple

thanks!

[...]

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

Re: [FFmpeg-devel] [PATCH] avdev/libdc1394: distinguish between enumeration errors, and no cameras found

[Michael Niedermayer]

On Sun, Jul 24, 2016 at 07:49:40PM +0100, Josh de Kock wrote:
> ---
>  libavdevice/libdc1394.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

applied

will push once git.videolan.org is up again

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] avformat/fivdec: cached keyframes before video or audio stream was created

[Michael Niedermayer]

On Thu, Jul 21, 2016 at 10:36:20AM +0800, Xinzheng Zhang wrote:
> ---
>  libavformat/flvdec.c | 51 ---
>  1 file changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 2bf1e05..b4fb4e2 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -30,6 +30,7 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/intfloat.h"
>  #include "libavutil/mathematics.h"
> +#include "libavutil/mem.h"
>  #include "libavcodec/bytestream.h"
>  #include "libavcodec/mpeg4audio.h"
>  #include "avformat.h"
> @@ -41,6 +42,11 @@
>  
>  #define RESYNC_BUFFER_SIZE (1<<20)
>  
> +typedef struct FLVKeyFrame {
> +int64_t pos;
> +int64_t timestamp;
> +} FLVKeyFrame;

instead of adding a 3rd array the local arrays from parse_keyframes_index()
could be moved into the context. That would reduce the memory needed

It also may be needed to keep 2 sets that is one per stream
and the arrays should be freed after their use


> +
>  typedef struct FLVContext {
>  const AVClass *class; ///< Class for private options.
>  int trust_metadata;   ///< configure streams according onMetaData
> @@ -61,6 +67,10 @@ typedef struct FLVContext {
>  
>  int broken_sizes;
>  int sum_flv_tag_size;
> +
> +int head_flags; //r8
> +FLVKeyFrame *keyframes;
> +int keyframe_count;
>  } FLVContext;
>  
>  static int probe(AVProbeData *p, int live)
> @@ -95,6 +105,9 @@ static int live_flv_probe(AVProbeData *p)
>  static AVStream *create_stream(AVFormatContext *s, int codec_type)
>  {
>  AVStream *st = avformat_new_stream(s, NULL);
> +FLVContext *flv = s->priv_data;
> +int flags = flv->head_flags;
> +int i = 0;
>  if (!st)
>  return NULL;
>  st->codecpar->codec_type = codec_type;
> @@ -104,6 +117,17 @@ static AVStream *create_stream(AVFormatContext *s, int 
> codec_type)
>  s->ctx_flags &= ~AVFMTCTX_NOHEADER;
>  
>  avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
> +if ((!(flags & FLV_HEADER_FLAG_HASVIDEO) && codec_type == 
> AVMEDIA_TYPE_AUDIO) ||
> +(codec_type == AVMEDIA_TYPE_VIDEO)
> +) {
> +for (; i < flv->keyframe_count; i++) {
> +FLVKeyFrame *keyframe = &flv->keyframes[i];
> +av_add_index_entry(st, keyframe->pos, keyframe->timestamp,
> +   0, 0, AVINDEX_KEYFRAME);
> +}
> +flv->keyframe_count = 0;
> +av_freep(&flv->keyframes);
> +}
>  return st;
>  }
>  
> @@ -306,7 +330,7 @@ static int amf_get_string(AVIOContext *ioc, char *buffer, 
> int buffsize)
>  }
>  
>  static int parse_keyframes_index(AVFormatContext *s, AVIOContext *ioc,
> - AVStream *vstream, int64_t max_pos)
> + AVStream *vstream, AVStream *astream, 
> int64_t max_pos)
>  {
>  FLVContext *flv   = s->priv_data;
>  unsigned int timeslen = 0, fileposlen = 0, i;
> @@ -315,8 +339,12 @@ static int parse_keyframes_index(AVFormatContext *s, 
> AVIOContext *ioc,
>  int64_t *filepositions = NULL;
>  int ret= AVERROR(ENOSYS);
>  int64_t initial_pos= avio_tell(ioc);
> +int head_flags = flv->head_flags;
> +AVStream *kf_stream= vstream;
> +if (!kf_stream && astream && (!(head_flags & FLV_HEADER_FLAG_HASVIDEO) 
> && (head_flags & FLV_HEADER_FLAG_HASAUDIO)))
> +kf_stream = astream;
>  
> -if (vstream->nb_index_entries>0) {
> +if (kf_stream && kf_stream->nb_index_entries > 0) {
>  av_log(s, AV_LOG_WARNING, "Skipping duplicate index\n");
>  return 0;
>  }

> @@ -369,8 +397,16 @@ static int parse_keyframes_index(AVFormatContext *s, 
> AVIOContext *ioc,
>  
>  if (timeslen == fileposlen && fileposlen>1 && max_pos <= 
> filepositions[0]) {
>  for (i = 0; i < fileposlen; i++) {
> -av_add_index_entry(vstream, filepositions[i], times[i] * 1000,
> -   0, 0, AVINDEX_KEYFRAME);
> +if (kf_stream) {
> +av_add_index_entry(kf_stream, filepositions[i], times[i] * 
> 1000,
> +   0, 0, AVINDEX_KEYFRAME);
> +} else {
> +FLVKeyFrame frame = {0};
> +frame.pos = filepositions[i];
> +frame.timestamp = times[i] * 1000;
> +av_dynarray2_add((void **)&flv->keyframes, 
> &flv->keyframe_count,sizeof(FLVKeyFrame), (const uint8_t *)&frame);
> +}
> +
>  if (i < 2) {
>  flv->validate_index[i].pos = filepositions[i];
>  flv->validate_index[i].dts = times[i] * 1000;
> @@ -418,10 +454,10 @@ static int amf_parse_object(AVFormatContext *s, 
> AVStream *astream,

maybe the filepositions/times -> av_add_index_entry() code can be
split out of parse_keyframes_index() in a seperate patch

that way parse_keyframes_index() would always do th

Re: [FFmpeg-devel] Outreachy 2016 december

[Stefano Sabatini]

In date Friday 2016-07-22 19:18:13 +0200, Michael Niedermayer wrote:
> On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer wrote:
> > Hi all
> > 
> > The next Outreachy round starts soon
> > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/)
> > to express interrest to participate.
> > 
> > We need an admin and backup admins.
> 
> ping!
> 
> 
> > They need to create the wiki page(s) for this round, and make sure
> > the pages are in shape by the time applicants start pouring in.
> > make sure applicants questions (like "[FFmpeg-devel] need guidance")
> > get awnsered
> > recruite mentors,
> 
> > secure funding (as in confirming with the community and stefano that
> > SPI/FFIS funding can be used for one slot or find another sponsor)
> 

> @stefano, do we have funding for a slot in the next outreachy round?

From the last published SPI report (2016-01-31), this is the available
fund amount (in USD):

   FFmpeg 6,008.31
   FFmpeg (Outreachy)   169.17

Considering that we provided a few refunds and received several
donations you can expect the FFmpeg fund to have more or less the same
amount at the present time.

While the ffis.de fund still contains 9129.56 (EUR).

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

Re: [FFmpeg-devel] libavcodec : add psd image file decoder

[Martin Vignali]

2016-07-25 2:46 GMT+02:00 Michael Niedermayer :

> On Sun, Jul 24, 2016 at 03:21:00PM +0200, Martin Vignali wrote:
> > > breaks fate
> > >
> > > make: *** [fate-filter-metadata-ebur128] Error 1
> > > --- -   2016-07-23 18:50:11.633752058 +0200
> > > +++ tests/data/fate/probe-format-roundup14142016-07-23
> > > 18:50:10.913635588 +0200
> > > @@ -1 +1 @@
> > > -mpeg
> > > +psd_pipe
> > > Test probe-format-roundup1414 failed. Look at
> > > tests/data/fate/probe-format-roundup1414.err for details.
> > > make: *** [fate-probe-format-roundup1414] Error 1
> > > --- -   2016-07-23 18:50:11.657384876 +0200
> > > +++ tests/data/fate/probe-format-roundup997 2016-07-23
> > > 18:50:10.917635588 +0200
> > > @@ -1 +1 @@
> > > -mpeg
> > > +psd_pipe
> > > Test probe-format-roundup997 failed. Look at
> > > tests/data/fate/probe-format-roundup997.err for details.
> > > make: *** [fate-probe-format-roundup997] Error 1
> > > --- -   2016-07-23 18:50:11.667958765 +0200
> > > +++ tests/data/fate/probe-format-roundup13832016-07-23
> > > 18:50:10.917635588 +0200
> > > @@ -1 +1 @@
> > > -mp3
> > > +psd_pipe
> > > Test probe-format-roundup1383 failed. Look at
> > > tests/data/fate/probe-format-roundup1383.err for details.
> > > make: *** [fate-probe-format-roundup1383] Error 1
> > > make: Target `fate' not remade because of errors.
> > >
> > >
> > Hello,
> >
> > Corrected patch in attach who fix the psd_probe function.
> >
> > Comments welcome
> >
> > Martin
>
> >  Changelog|1
> >  doc/general.texi |2
> >  libavcodec/Makefile  |1
> >  libavcodec/allcodecs.c   |1
> >  libavcodec/avcodec.h |1
> >  libavcodec/codec_desc.c  |7
> >  libavcodec/psd.c |  395
> +++
> >  libavformat/Makefile |1
> >  libavformat/allformats.c |1
> >  libavformat/img2.c   |1
> >  libavformat/img2dec.c|   35 
> >  11 files changed, 446 insertions(+)
>
> this should be split into 2 patches one for libavcodec and libavformat
>
>
> [...]
> > +static int decode_rle(PSDContext * s){
> > +unsigned int scanline_count;
> > +unsigned int sl, count;
> > +unsigned long target_index = 0;
> > +
> > +scanline_count = s->height * s->channel_count;
> > +
> > +/* scanline table */
> > +if (bytestream2_get_bytes_left(&s->gb) < scanline_count * 2) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Not enough data for rle
> scanline table.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +bytestream2_skip(&s->gb, scanline_count * 2);/* size of each
> scanline */
> > +
> > +/* decode rle data scanline by scanline */
> > +for (sl = 0; sl < scanline_count; sl++) {
> > +count = 0;
> > +
> > +while (count < s->line_size) {
>
> > +char rle_char = bytestream2_get_byte(&s->gb);
>
> please use intXY_t or int, char can be unsigned
>
>
> > +
> > +if (rle_char <= 0) {/* byte repeat */
>
> > +rle_char *= -1;
>
> this is not safe
> rle_char is just 8 bit -128 cannot be represented as positive value
>
>
> > +
> > +if (bytestream2_get_bytes_left(&s->gb) < 1) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Not enough data for
> rle scanline.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +if (target_index + rle_char > s->uncompressed_size) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Invalid rle
> char.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
>
> > +uint8_t v = bytestream2_get_byte(&s->gb);
>
> mixed declarations and code, please move the uint8_t v up
>
>
> > +for (unsigned char p = 0; p <= rle_char; p++) {
> > +s->tmp[target_index++] = v;
> > +}
> > +} else {
> > +if (bytestream2_get_bytes_left(&s->gb) < rle_char) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Not enough data for
> rle scanline.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
>
> > +if (target_index + rle_char > s->uncompressed_size) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Invalid rle
> char.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
>
> isnt this off by 1?
> rle_char = 0
> target_index == uncompressed_size would pass but write at
> uncompressed_size whch would be after the array if iam not mistaken
>
>
> > +
> > +for (int p = 0; p <= rle_char; p++) {
> > +uint8_t v = bytestream2_get_byte(&s->gb);
> > +s->tmp[target_index++] = v;
> > +}
> > +}
> > +count += rle_char + 1;
> > +}
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static int decode_frame(AVCodecContext *avctx, void *data,
> > +int *go

Re: [FFmpeg-devel] [PATCH] lavc/ffjni: replace ff_jni_{attach, detach} with ff_jni_get_env

[Benoit Fouet]

Hi,

On 24/07/2016 23:05, Matthieu Bouron wrote:

From: Matthieu Bouron

If a JNI environment is not already attached to the thread where the
MediaCodec calls are made the current implementation will attach /
detach an environment for each MediaCodec call wasting some CPU time.

ff_jni_get_env replaces ff_jni_{attach,detach} by permanently attaching
an environment (if it is not already the case) to the current thread.
The environment will be automatically detached at the thread destruction
using a pthread_key callback.

Saves around 5% of CPU time (out of 20%) while decoding a stream with
MediaCodec.
---
  libavcodec/ffjni.c  |  43 +
  libavcodec/ffjni.h  |  15 +--


LGTM


  libavcodec/mediacodec.c |  14 +--
  libavcodec/mediacodec_surface.c |  14 +--
  libavcodec/mediacodec_wrapper.c | 200 
  5 files changed, 74 insertions(+), 212 deletions(-)


Just had a quick look at those ones.

Cheers,
--
Ben

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

Re: [FFmpeg-devel] [PATCH] lavc: always build dnxhddata

[Michael Niedermayer]

On Sun, Jul 24, 2016 at 11:43:41PM -0300, James Almer wrote:
> On 7/24/2016 8:13 PM, Michael Niedermayer wrote:
[...]
> > 
> >>
> >> Looking at this function closely now, it could have been added
> >> to dnxhddata.h instead. No need for avpriv_ prefix and to
> >> forcefully build an object file full of data tables that it
> >> doesn't need.
> > 
> > agree, this would be best in this case
> 
> Are you ok with me reverting this commit and moving the function
> to the header? The symbol will of course not be removed until next
> major bump since it's already in a release.
> Alternatively apply "[PATCH] lavf/movenc: add missing dependency
> on dnxhddata" but IMO it's better to just move the thing to the
> header.

yes, moving to the header is better

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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