date:20180329

On Thu, Mar 29, 2018 at 12:53:18AM +0300, Jan Ekström wrote:
> From: Jan Ekström 
> 
> With some streams multiple nullptr AVSubtitles can get pushed
> into sub2video_update() in a row.
> 
> This causes end_pts, and on the next round pts, to become
> INT64_MAX, latter of which signals EOF in framesync, leading to
> complete loss of subtitles from that point on.
> 
> Thus, utilize the previous sub2video.end_pts as both the pts and
> end_pts in case a nullptr AVSubtitle is received. This lets further
> incoming subtitle packets be properly processed, as EOF is not hit
> in framesync.
> 
> Signed-off-by: Jan Ekström 
> ---
>  fftools/ffmpeg.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

this breaks fate-sub2video

TESTsub2video
--- ./tests/ref/fate/sub2video  2018-03-29 02:30:48.095578219 +0200
+++ tests/data/fate/sub2video   2018-03-29 12:13:25.191428538 +0200
@@ -68,7 +68,8 @@
 0,258,258,1,   518400, 0x34cdddee
 0,269,269,1,   518400, 0xbab197ea
 1,   5391,   5391,  2696000, 2095, 0x61bb15ed, F=0x0
-0,270,270,1,   518400, 0x4db4ce51
+0,270,270,1,   518400, 0xbab197ea
+0,271,271,1,   518400, 0x4db4ce51
 0,283,283,1,   518400, 0xbab197ea
 1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7, F=0x0
 0,284,284,1,   518400, 0xe6bc0ea9
@@ -137,7 +138,7 @@
 1,  168049000,  168049000,  190, 1312, 0x0bf20e8d, F=0x0
 0,850,850,1,   518400, 0xbab197ea
 1,  170035000,  170035000,  1524000, 1279, 0xb6c2dafe, F=0x0
-0,851,851,1,   518400, 0x8780239e
+0,851,851,1,   518400, 0xbab197ea
 0,858,858,1,   518400, 0xbab197ea
 0,861,861,1,   518400, 0x6eb72347
 1,  172203000,  172203000,  1695000, 1826, 0x9a1ac769, F=0x0
@@ -161,7 +162,8 @@
 0,976,976,1,   518400, 0x923d1ce7
 0,981,981,1,   518400, 0xbab197ea
 1,  196361000,  196361000,  1524000, 1715, 0x695ca41e, F=0x0
-0,982,982,1,   518400, 0x6e652cd2
+0,982,982,1,   518400, 0xbab197ea
+0,983,983,1,   518400, 0x6e652cd2
 0,989,989,1,   518400, 0xbab197ea
 1,  197946000,  197946000,  116,  789, 0xc63a189e, F=0x0
 0,990,990,1,   518400, 0x25113966
Test sub2video failed. Look at tests/data/fate/sub2video.err for details.
make: *** [fate-sub2video] Error 1

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

On Thu, 29 Mar 2018 08:58:12 +0200
Tobias Rapp  wrote:

> On 28.03.2018 17:11, wm4 wrote:
> > On Wed, 28 Mar 2018 17:03:39 +0200
> > Tobias Rapp  wrote:
> >   
> >> Allows to set log level and flag values from string.
> >>
> >> Signed-off-by: Tobias Rapp 
> >> ---
> >>   doc/APIchanges  |  3 +++
> >>   libavutil/log.c | 76 
> >> +
> >>   libavutil/log.h | 16 +++
> >>   libavutil/version.h |  2 +-
> >>   4 files changed, 96 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index 83c7a40..2d14452 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >>   
> >>   API changes, most recent first:
> >>   
> >> +2018-03-xx - xxx - lavu 56.13.100 - log.h
> >> +  Add av_log_set_opts().
> >> +
> >>   2018-03-xx - xxx - lavc 58.16.100 - avcodec.h
> >> Add FF_SUB_CHARENC_MODE_IGNORE.
> >>   
> >> diff --git a/libavutil/log.c b/libavutil/log.c
> >> index 0a99d01..af32cd6 100644
> >> --- a/libavutil/log.c
> >> +++ b/libavutil/log.c
> >> @@ -34,6 +34,7 @@
> >>   #endif
> >>   #include 
> >>   #include 
> >> +#include "avassert.h"
> >>   #include "avutil.h"
> >>   #include "bprint.h"
> >>   #include "common.h"
> >> @@ -402,6 +403,81 @@ void av_log_set_callback(void (*callback)(void*, int, 
> >> const char*, va_list))
> >>   av_log_callback = callback;
> >>   }
> >>   
> >> +int av_log_set_opts(const char *arg)
> >> +{
> >> +const struct { const char *name; int level; } log_levels[] = {
> >> +{ "quiet"  , AV_LOG_QUIET   },
> >> +{ "panic"  , AV_LOG_PANIC   },
> >> +{ "fatal"  , AV_LOG_FATAL   },
> >> +{ "error"  , AV_LOG_ERROR   },
> >> +{ "warning", AV_LOG_WARNING },
> >> +{ "info"   , AV_LOG_INFO},
> >> +{ "verbose", AV_LOG_VERBOSE },
> >> +{ "debug"  , AV_LOG_DEBUG   },
> >> +{ "trace"  , AV_LOG_TRACE   },
> >> +};
> >> +const char *token;
> >> +char *tail;
> >> +int flags = av_log_get_flags();
> >> +int level = av_log_get_level();
> >> +int cmd, i = 0;
> >> +
> >> +av_assert0(arg);
> >> +while (*arg) {
> >> +token = arg;
> >> +if (*token == '+' || *token == '-') {
> >> +cmd = *token++;
> >> +} else {
> >> +cmd = 0;
> >> +}
> >> +if (!i && !cmd) {
> >> +flags = 0;  /* missing relative prefix, build absolute value 
> >> */
> >> +}
> >> +if (!strncmp(token, "repeat", 6)) {
> >> +if (cmd == '-') {
> >> +flags |= AV_LOG_SKIP_REPEATED;
> >> +} else {
> >> +flags &= ~AV_LOG_SKIP_REPEATED;
> >> +}
> >> +arg = token + 6;
> >> +} else if (!strncmp(token, "level", 5)) {
> >> +if (cmd == '-') {
> >> +flags &= ~AV_LOG_PRINT_LEVEL;
> >> +} else {
> >> +flags |= AV_LOG_PRINT_LEVEL;
> >> +}
> >> +arg = token + 5;
> >> +} else {
> >> +break;
> >> +}
> >> +i++;
> >> +}
> >> +if (!*arg) {
> >> +goto end;
> >> +} else if (*arg == '+') {
> >> +arg++;
> >> +} else if (!i) {
> >> +flags = av_log_get_flags();  /* level value without prefix, reset 
> >> flags */
> >> +}
> >> +
> >> +for (i = 0; i < FF_ARRAY_ELEMS(log_levels); i++) {
> >> +if (!strcmp(arg, log_levels[i].name)) {
> >> +level = log_levels[i].level;
> >> +goto end;
> >> +}
> >> +}
> >> +
> >> +level = strtol(arg, &tail, 10);
> >> +if (*tail) {
> >> +return -1;
> >> +}
> >> +
> >> +end:
> >> +av_log_set_flags(flags);
> >> +av_log_set_level(level);
> >> +return 0;
> >> +}
> >> +
> >>   static void missing_feature_sample(int sample, void *avc, const char 
> >> *msg,
> >>  va_list argument_list)
> >>   {
> >> diff --git a/libavutil/log.h b/libavutil/log.h
> >> index d9554e6..97010f7 100644
> >> --- a/libavutil/log.h
> >> +++ b/libavutil/log.h
> >> @@ -356,6 +356,22 @@ void av_log_set_flags(int arg);
> >>   int av_log_get_flags(void);
> >>   
> >>   /**
> >> + * Set log flags and level as an option string. Accepts "repeat" and 
> >> "level"
> >> + * flags mapped to AV_LOG_SKIP_REPEATED (inverted) and AV_LOG_PRINT_LEVEL,
> >> + * followed by the log level specified either by name ("warning", "info",
> >> + * "verbose", etc.) or by number.
> >> + *
> >> + * When flags are prefixed with "+" or "-" the change is relative to the
> >> + * current flags value. When both flags and level are present a "+" 
> >> separator
> >> + * is expected between last flag and before level.
> >> + *
> >> + * @param  arg  log option string
> >> + * @return Returns a negative value if parsing the option string failed,
> >> + * otherwise returns 0.
> >> + */
> >> +in

[FFmpeg-devel] [PATCH] avcodec/vaapi: do not parse MVMODE for VC-1 interlaced frame pictures

2018-03-29 Thread Jerome Borsboom

Interlaced frame pictures do not contain the MVMODE or MVMODE2 bitstream
element. Trying to parse this element and passing a nonzero value to the
hardware decoder results in small inaccuracies in the decoded picture.

Signed-off-by: Jerome Borsboom 
---
With this patch the Intel hardware decoded fate test for ilaced_twomv.vc1
perfectly matches the output from the Microsoft software decoder.

 libavcodec/vaapi_vc1.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index 74ba783141..bdb5e24cc5 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -138,8 +138,9 @@ static int vc1_get_FPTYPE(const VC1Context *v)
 /** Reconstruct bitstream MVMODE (7.1.1.32) */
 static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context *v)
 {
-if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
-(v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type))
+if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
+((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
+ (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type)))
 return get_VAMvModeVC1(v->mv_mode);
 return 0;
 }
@@ -147,7 +148,8 @@ static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context 
*v)
 /** Reconstruct bitstream MVMODE2 (7.1.1.33) */
 static inline VAMvModeVC1 vc1_get_MVMODE2(const VC1Context *v)
 {
-if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
+if ((v->fcm == PROGRESSIVE || v->fcm == ILACE_FIELD) &&
+(v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
 v->mv_mode == MV_PMODE_INTENSITY_COMP)
 return get_VAMvModeVC1(v->mv_mode2);
 return 0;
-- 
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

2018-03-29 Thread Tobias Rapp


On 29.03.2018 12:58, wm4 wrote:

On Thu, 29 Mar 2018 08:58:12 +0200
Tobias Rapp  wrote:


On 28.03.2018 17:11, wm4 wrote:

On Wed, 28 Mar 2018 17:03:39 +0200
Tobias Rapp  wrote:
   

Allows to set log level and flag values from string.

Signed-off-by: Tobias Rapp 
---
   doc/APIchanges  |  3 +++
   libavutil/log.c | 76 
+
   libavutil/log.h | 16 +++
   libavutil/version.h |  2 +-
   4 files changed, 96 insertions(+), 1 deletion(-)

[...]


Seems like a step backwards. Why can't it stay in the fftools thing?


When v2 of the patch was reviewed in
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227077.html it was
suggested to move the code into libavutil so that other applications can
make use of it. I agree that it can be useful for command-line apps that
interface with libav* to provide a loglevel option which accepts
info/verbose/etc. name strings without the need to do an own
string-to-level parsing.


That seems completely unnecessary. Applications will have their own
conventions and option parsers.


In case the function is placed into fftools applications are forced to 
do their own thing, when it's available inside avutil applications can 
either use it _or_ implement an own parser. Thus I see no benefit in not 
having it inside avutil.


Anyway: my goal still is to add support for setting AV_LOG_PRINT_LEVEL 
via some (ffmpeg) command-line option. If you're blocking addition to 
avutil and Michael accepts updating opt_loglevel() in fftools then 
that's also OK for me.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

On Thu, 29 Mar 2018 13:47:55 +0200
Tobias Rapp  wrote:

> On 29.03.2018 12:58, wm4 wrote:
> > On Thu, 29 Mar 2018 08:58:12 +0200
> > Tobias Rapp  wrote:
> >   
> >> On 28.03.2018 17:11, wm4 wrote:  
> >>> On Wed, 28 Mar 2018 17:03:39 +0200
> >>> Tobias Rapp  wrote:
> >>>  
>  Allows to set log level and flag values from string.
> 
>  Signed-off-by: Tobias Rapp 
>  ---
> doc/APIchanges  |  3 +++
> libavutil/log.c | 76 
>  +
> libavutil/log.h | 16 +++
> libavutil/version.h |  2 +-
> 4 files changed, 96 insertions(+), 1 deletion(-)
> 
>  [...]  
> >>>
> >>> Seems like a step backwards. Why can't it stay in the fftools thing?  
> >>
> >> When v2 of the patch was reviewed in
> >> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227077.html it was
> >> suggested to move the code into libavutil so that other applications can
> >> make use of it. I agree that it can be useful for command-line apps that
> >> interface with libav* to provide a loglevel option which accepts
> >> info/verbose/etc. name strings without the need to do an own
> >> string-to-level parsing.  
> > 
> > That seems completely unnecessary. Applications will have their own
> > conventions and option parsers.  
> 
> In case the function is placed into fftools applications are forced to 
> do their own thing, when it's available inside avutil applications can 
> either use it _or_ implement an own parser. Thus I see no benefit in not 
> having it inside avutil.
> 
> Anyway: my goal still is to add support for setting AV_LOG_PRINT_LEVEL 
> via some (ffmpeg) command-line option. If you're blocking addition to 
> avutil and Michael accepts updating opt_loglevel() in fftools then 
> that's also OK for me.

I'd like to block it, because I don't see it as a good thing that more
fftools specific stuff is leaking into the generic libs. Sorry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

2018-03-29 Thread Steve Lhomme

Le 27/03/2018 à 22:45, Dave Rice a écrit :

On Mar 27, 2018, at 4:33 PM, wm4 wrote:

On Tue, 27 Mar 2018 16:11:11 -0400
Dave Rice wrote:

On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis
wrote:

On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:

I think we should drop the internal crap if the tools and the API support
it. Would also solve a lot of issues like ffmpeg.c not trimming the start
frame (so people complain all the time about longer files).

I personally agree, but I thought I'd be diplomatic about it, since it would
technically be losing a 'feature', since it would no longer Just Work(ish)
and require user applications to apply timelines themselves - and I figured
some would argue that point.

+1 I’m willing to contribute what information or samples would be needed to
help with Matroska support with virtual timelines. IMO, this would be a
valuable feature to have in ffmpeg.
Dave Rice

Some explanations how this interacts with editions would be good.

I put an example with two editions at
https://archive.org/download/chapters_test/chapters_test.mkv which mimics a
digitized video tape. One edition depicts the stored video encoding in its
entire presentation and the other default edition plays from the video encoding
selectively. When the file is played in VLC, the default edition is used to
show a shortened presentation, but the other editions may be selected within
the Program menu option. In the proposal there should be an option to mimic the
current behavior and ignore the editions (equivalent of -ignore_editlist in
mov), to use the first default edition, or to select a specific edition.

For the record, the ordered chapters with segment linking in VLC have
been fixed recently with this issue
https://trac.videolan.org/vlc/ticket/19101

There is a lengthy set of sample files with ordered chapters and
multiple segments. That's basically the most complex case that can exist.

I don't think the API covers segment linking, nor how libavformat would
look around in the file system if there are available segments
(something we do in VLC). So not sure an API for some case not covered
would make sense.

Or documenting ordered chapters and segment linking in the mkv "spec"
at all.

This document, http://mod16.org/hurfdurf/?p=8 ,
is unofficially a good resource on that.

More officially the Cellar working group has this section on Linked Segments:
https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-23
, and this one on Ordered
Editions: https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-10.1.2.3
. This
documentation is a work in progress so comments/reviews/suggestions are welcome (issues can be filed at
https://github.com/Matroska-Org/matroska-specification
or via
https://www.ietf.org/mailman/listinfo/cellar ).

Dave Rice

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

[FFmpeg-devel] [PATCH] avfilter/af_amix: add weights option

2018-03-29 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  3 +++
 libavfilter/af_amix.c | 32 +++-
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 5c119c0151..6cbb7255f4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1350,6 +1350,9 @@ The duration of the first input.
 The transition time, in seconds, for volume renormalization when an input
 stream ends. The default value is 2 seconds.
 
+@item weights
+Specify weight of each input audio stream as sequence.
+Each weight is separated by space. By default all inputs have same weight.
 @end table
 
 @section anequalizer
diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
index ec764375c0..9fa504765f 100644
--- a/libavfilter/af_amix.c
+++ b/libavfilter/af_amix.c
@@ -162,6 +162,7 @@ typedef struct MixContext {
 int active_inputs;  /**< number of input currently active */
 int duration_mode;  /**< mode for determining duration */
 float dropout_transition;   /**< transition time when an input drops out */
+char *weights_str;  /**< string for custom weights for every input 
*/
 
 int nb_channels;/**< number of channels */
 int sample_rate;/**< sample rate */
@@ -169,6 +170,7 @@ typedef struct MixContext {
 AVAudioFifo **fifos;/**< audio fifo for each input */
 uint8_t *input_state;   /**< current state of each input */
 float *input_scale; /**< mixing scale factor for each input */
+float *weights; /**< custom weights for every input */
 float scale_norm;   /**< normalization factor for all inputs */
 int64_t next_pts;   /**< calculated pts for next output frame */
 FrameList *frame_list;  /**< list of frame info for the first input */
@@ -188,6 +190,8 @@ static const AVOption amix_options[] = {
 { "dropout_transition", "Transition time, in seconds, for volume "
 "renormalization when an input stream ends.",
 OFFSET(dropout_transition), AV_OPT_TYPE_FLOAT, { .dbl = 2.0 }, 0, 
INT_MAX, A|F },
+{ "weights", "Set weight for each input.",
+OFFSET(weights_str), AV_OPT_TYPE_STRING, {.str="1 1"}, 0, 0, A|F },
 { NULL }
 };
 
@@ -202,6 +206,7 @@ AVFILTER_DEFINE_CLASS(amix);
  */
 static void calculate_scales(MixContext *s, int nb_samples)
 {
+float weight_sum = 0.f;
 int i;
 
 if (s->scale_norm > s->active_inputs) {
@@ -209,9 +214,13 @@ static void calculate_scales(MixContext *s, int nb_samples)
 s->scale_norm = FFMAX(s->scale_norm, s->active_inputs);
 }
 
+for (i = 0; i < s->nb_inputs; i++)
+if (s->input_state[i] & INPUT_ON)
+weight_sum += s->weights[i];
+
 for (i = 0; i < s->nb_inputs; i++) {
 if (s->input_state[i] & INPUT_ON)
-s->input_scale[i] = 1.0f / s->scale_norm;
+s->input_scale[i] = s->weights[i] / weight_sum * s->active_inputs 
/ s->scale_norm;
 else
 s->input_scale[i] = 0.0f;
 }
@@ -487,6 +496,8 @@ static int activate(AVFilterContext *ctx)
 static av_cold int init(AVFilterContext *ctx)
 {
 MixContext *s = ctx->priv;
+char *p, *arg, *saveptr = NULL;
+float last_weight = 1.f;
 int i, ret;
 
 for (i = 0; i < s->nb_inputs; i++) {
@@ -507,6 +518,24 @@ static av_cold int init(AVFilterContext *ctx)
 if (!s->fdsp)
 return AVERROR(ENOMEM);
 
+s->weights = av_mallocz_array(s->nb_inputs, sizeof(*s->weights));
+if (!s->weights)
+return AVERROR(ENOMEM);
+
+p = s->weights_str;
+for (i = 0; i < s->nb_inputs; i++) {
+if (!(arg = av_strtok(p, " ", &saveptr)))
+break;
+
+p = NULL;
+sscanf(arg, "%f", &last_weight);
+s->weights[i] = last_weight;
+}
+
+for (; i < s->nb_inputs; i++) {
+s->weights[i] = last_weight;
+}
+
 return 0;
 }
 
@@ -524,6 +553,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(&s->frame_list);
 av_freep(&s->input_state);
 av_freep(&s->input_scale);
+av_freep(&s->weights);
 av_freep(&s->fdsp);
 
 for (i = 0; i < ctx->nb_inputs; i++)
-- 
2.11.0

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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

On Thu, 29 Mar 2018 14:00:03 +0200
Steve Lhomme  wrote:

> Le 27/03/2018 à 22:45, Dave Rice a écrit :
> >> On Mar 27, 2018, at 4:33 PM, wm4  wrote:
> >>
> >> On Tue, 27 Mar 2018 16:11:11 -0400
> >> Dave Rice  wrote:
> >>  
>  On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis 
>   wrote:
> 
>  On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:  
> > I think we should drop the internal crap if the tools and the API 
> > support
> > it. Would also solve a lot of issues like ffmpeg.c not trimming the 
> > start
> > frame (so people complain all the time about longer files).  
>  I personally agree, but I thought I'd be diplomatic about it, since it 
>  would
>  technically be losing a 'feature', since it would no longer Just 
>  Work(ish)
>  and require user applications to apply timelines themselves - and I 
>  figured
>  some would argue that point.  
> >>> +1 I’m willing to contribute what information or samples would be needed 
> >>> to help with Matroska support with virtual timelines. IMO, this would be 
> >>> a valuable feature to have in ffmpeg.
> >>> Dave Rice  
> >> Some explanations how this interacts with editions would be good.  
> > I put an example with two editions at 
> > https://archive.org/download/chapters_test/chapters_test.mkv which mimics a 
> > digitized video tape. One edition depicts the stored video encoding in its 
> > entire presentation and the other default edition plays from the video 
> > encoding selectively. When the file is played in VLC, the default edition 
> > is used to show a shortened presentation, but the other editions may be 
> > selected within the Program menu option. In the proposal there should be an 
> > option to mimic the current behavior and ignore the editions (equivalent of 
> > -ignore_editlist in mov), to use the first default edition, or to select a 
> > specific edition.  
> 
> For the record, the ordered chapters with segment  linking in VLC have 
> been fixed recently with this issue 
> https://trac.videolan.org/vlc/ticket/19101
> 
> There is a lengthy set of sample files with ordered chapters and 
> multiple segments. That's basically the most complex case that can exist.

Samples are good, but don't replace exhaustive documentation.

> I don't think the API covers segment linking, nor how libavformat would 
> look around in the file system if there are available segments 
> (something we do in VLC). So not sure an API for some case not covered 
> would make sense.

The idea is that the proposed API can be extended to export segment
UUIDs. Then the mkv demuxer could export the ordered chapter metadata.
How an application knows how to find segment references is another
story. Since Matroska has such a special mechanism (finding references
by opening _all_ files and checking their UUID), it's unlikely that
there can be a generic API for this. I think mov files at least use a
filename/URL for external references, which actually could be handled
in generic files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] avcodec/avpacket: add av_packet_make_ref()

On Sun, Mar 25, 2018 at 03:17:19PM -0300, James Almer wrote:
> On 3/25/2018 2:54 PM, Mark Thompson wrote:
> > On 25/03/18 05:03, James Almer wrote:
> >> It works as a drop in replacement for the deprecated av_dup_packet(),
> >> to ensure a packet is reference counted.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> Better name welcome.
> >>
> >>  libavcodec/avcodec.h  | 18 +-
> >>  libavcodec/avpacket.c | 18 ++
> >>  2 files changed, 35 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> index 495242faf0..eb3fe4e428 100644
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >> @@ -4360,7 +4360,7 @@ int av_packet_from_data(AVPacket *pkt, uint8_t 
> >> *data, int size);
> >>   * @warning This is a hack - the packet memory allocation stuff is 
> >> broken. The
> >>   * packet is allocated if it was not really allocated.
> >>   *
> >> - * @deprecated Use av_packet_ref
> >> + * @deprecated Use av_packet_ref or av_packet_make_ref
> >>   */
> >>  attribute_deprecated
> >>  int av_dup_packet(AVPacket *pkt);
> >> @@ -4531,6 +4531,22 @@ void av_packet_move_ref(AVPacket *dst, AVPacket 
> >> *src);
> >>   */
> >>  int av_packet_copy_props(AVPacket *dst, const AVPacket *src);
> >>  
> >> +/**
> >> + * Ensure the data described by a given packet is reference counted.
> >> + *
> >> + * @note This function does no ensure that the reference will be writable.
> > 
> > "does not ensure"
> 
> Fixed.
> 
> > 
> >> + *   Use av_packet_make_writable instead for that purpose.
> >> + *
> >> + * @see av_packet_ref
> >> + * @see av_packet_make_writable
> >> + *
> >> + * @param pkt packet whose data should be made reference counted.
> >> + *
> >> + * @return 0 on success, a negative AVERROR on error. On failure, the
> >> + * packet is unchanged.
> >> + */
> >> +int av_packet_make_ref(AVPacket *pkt);
> > 
> > "make_ref" seems pretty confusing as a name - it sounds like it will always 
> > make a new reference somehow.
> > 
> > Given the first line of the description, "ensure_refcounted"?
> 
> av_packet_ensure_refcounted() seems a tad too long, IMO, especially for
> a function doing something as simple as this one as replacement for one
> called av_dup_packet().
> 
> But if others agree I'll go with it.

maybe av_packet_make_refcounted() would be better than 
av_packet_ensure_refcounted()
as it is more similar to av_packet_make_writable()

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

[FFmpeg-devel] [PATCH] avformat/mov: parse multiple iTunes cover images

2018-03-29 Thread Timo Teräs

Multiple cover images are supported by having multiple data atoms
inside the covr atom. AtomicParsley and mutagen amongst others
support and document this construct.

Signed-off-by: Timo Teräs 
---
 libavformat/mov.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index cb6f3a45de..e7c32e6148 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -412,7 +412,11 @@ retry:
 int ret = mov_read_covr(c, pb, data_type, str_size);
 if (ret < 0) {
 av_log(c->fc, AV_LOG_ERROR, "Error parsing cover art.\n");
+return ret;
 }
+atom.size -= str_size;
+if (atom.size > 8)
+goto retry;
 return ret;
 } else if (!key && c->found_hdlr_mdta && c->meta_keys) {
 uint32_t index = AV_RB32(&atom.type);
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 1/2] xwdenc: do not rely on AV_PIX_FMT_FLAG_PSEUDOPAL palettes

This is the only code I found within FFmpeg that still inherently
requires AV_PIX_FMT_FLAG_PSEUDOPAL. It's easily changed not to require
it.

Preparation for the next patch.
---
 libavcodec/xwdenc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavcodec/xwdenc.c b/libavcodec/xwdenc.c
index 43bca89033..81cca6c963 100644
--- a/libavcodec/xwdenc.c
+++ b/libavcodec/xwdenc.c
@@ -41,6 +41,7 @@ static int xwd_encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 int i, out_size, ret;
 uint8_t *ptr, *buf;
 AVFrame * const p = (AVFrame *)pict;
+uint32_t pal[256];
 
 pixdepth = av_get_bits_per_pixel(desc);
 if (desc->flags & AV_PIX_FMT_FLAG_BE)
@@ -180,11 +181,17 @@ static int xwd_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 bytestream_put_be32(&buf, 0); // window border width
 bytestream_put_buffer(&buf, WINDOW_NAME, WINDOW_NAME_SIZE);
 
+if (pix_fmt == AV_PIX_FMT_PAL8) {
+memcpy(pal, p->data[1], sizeof(pal));
+} else {
+avpriv_set_systematic_pal2(pal, pix_fmt);
+}
+
 for (i = 0; i < ncolors; i++) {
 uint32_t val;
 uint8_t red, green, blue;
 
-val   = AV_RN32A(p->data[1] + i * 4);
+val   = pal[i];
 red   = (val >> 16) & 0xFF;
 green = (val >>  8) & 0xFF;
 blue  =  val& 0xFF;
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

PSEUDOPAL pixel formats are not paletted, but carried a palette with the
intention of allowing code to treat unpaletted formats as paletted. The
palette simply mapped the byte values to the resulting RGB values,
making it some sort of LUT for RGB conversion.

It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
formats. The last one, GRAY8, is more common, but its treatment is
grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
from typical Y video planes was not mapped to the correct RGB values.
Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
All other code had to treat it as a special case, just to ignore or
propagate palette data.

In conclusion, this was just a very strange old hack that has no real
justification to exist. It's negatively useful, because API users who
allocate their own pixel data have to be aware that they need to
allocate the palette, or FFmpeg will crash on them in _some_ situations.
On top of this, there was no API to allocate the pseuo palette outside
of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
which is good, because GRAY8 treatment is broken.)

This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
the pseudo palette optional. Nothing accesses it anymore, though if it's
set, it's propagated. It's still allocated and initialized for
compatibility with API users that rely on this feature. But new API
users do not need to allocate it. This was an explicit goal of this
patch.

Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.

Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
functions manually changed to not allocating a palette.
---
 fftools/ffprobe.c  |  2 ++
 libavcodec/decode.c|  5 +
 libavcodec/ffv1dec.c   |  2 +-
 libavcodec/rawdec.c|  6 --
 libavcodec/smvjpegdec.c|  2 +-
 libavfilter/drawutils.c|  2 +-
 libavfilter/framepool.c|  4 ++--
 libavfilter/vf_crop.c  |  2 +-
 libavfilter/vf_pixdesctest.c   |  2 +-
 libavfilter/vf_scale.c |  5 ++---
 libavfilter/vf_shuffleplanes.c |  2 +-
 libavutil/frame.c  |  4 ++--
 libavutil/imgutils.c   | 13 +++--
 libavutil/internal.h   |  9 +
 libavutil/pixdesc.c| 10 +-
 libavutil/pixdesc.h|  8 
 libavutil/version.h|  3 +++
 libswscale/swscale_internal.h  | 14 +++---
 18 files changed, 62 insertions(+), 33 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a4ac6972a2..6965b9f679 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3118,7 +3118,9 @@ static void ffprobe_show_pixel_formats(WriterContext *w)
 PRINT_PIX_FMT_FLAG(HWACCEL,   "hwaccel");
 PRINT_PIX_FMT_FLAG(PLANAR,"planar");
 PRINT_PIX_FMT_FLAG(RGB,   "rgb");
+#if FF_API_PSEUDOPAL
 PRINT_PIX_FMT_FLAG(PSEUDOPAL, "pseudopal");
+#endif
 PRINT_PIX_FMT_FLAG(ALPHA, "alpha");
 writer_print_section_footer(w);
 }
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 40c8a8855c..d883a5f9fc 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1614,7 +1614,7 @@ static int video_get_buffer(AVCodecContext *s, AVFrame 
*pic)
 pic->linesize[i] = 0;
 }
 if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
-desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
+((desc->flags & FF_PSEUDOPAL) && pic->data[1]))
 avpriv_set_systematic_pal2((uint32_t *)pic->data[1], pic->format);
 
 if (s->debug & FF_DEBUG_BUFFERS)
@@ -1782,9 +1782,6 @@ static void validate_avframe_allocation(AVCodecContext 
*avctx, AVFrame *frame)
 for (i = 0; i < num_planes; i++) {
 av_assert0(frame->data[i]);
 }
-// For now do not enforce anything for palette of pseudopal formats
-if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL))
-num_planes = 2;
 // For formats without data like hwaccel allow unused pointers to be 
non-NULL.
 for (i = num_planes; num_planes > 0 && i < 
FF_ARRAY_ELEMS(frame->data); i++) {
 if (frame->data[i])
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index b4a183c5b7..7658a51685 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -950,7 +950,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame, AVPac
 
 }
 if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
-desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) {
+desc->flags & FF_PSEUDOPAL) {
 dst[1] = p->data[1];

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

On 3/29/2018 2:06 AM, Michael Niedermayer wrote:
> Its how AVStreams are living in AVFormatContext too
> so to me it seems thats the obvious and consistent way to go.
> i do not know if there are any unforseen issues with that ...

Sounds like the best way to go about it then.

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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

On 3/29/2018 1:06 PM, wm4 wrote:
> I think mov files at least use a
> filename/URL for external references, which actually could be handled
> in generic files.

The dref box is for the whole track, FWIW, and not for edit list entries.

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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

2018-03-29 Thread Vasile Toncu




On 14.03.2018 18:56, Thomas Mundt wrote:

2018-03-13 16:10 GMT+01:00 Vasile Toncu :



On 06.03.2018 20:38, Thomas Mundt wrote:


Hi,

2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :

2018-03-05 12:37 GMT+01:00, Paul B Mahol :

On 3/5/18, Vasile Toncu  wrote:


Hello,

Thanks for the review. I've made changes according to your guidance.

It would be great to know if the community will go on with our
intention
of adding reinterlace as a alternative for tinterlace.

That being said, here is the new patch.


As already said, this is not acceptable.

There is no point in having 2 filters with near same funcionality.


If you consider the new filter ok, the existing filter will be removed
in the same push. I believe sending only the new filter makes
reviewing easier.

For me reviewing would be easier when Vasile sends a patchset that

includes
the replacement of tinterlace filter.
That way existing fate tests could be used which are fortunately pretty
extensive in this case.
Also it would be helpful when you and/or other experienced ffmpeg
developers would clarify first which parts of tinterlace have to be
rewritten for proper relicensing.
Being left in the dark makes working on patches frustrating.

Another question is how to deal with vf_interlace? IMHO for the user there
should be no difference in output, speed and license.
Two options:
1. Relicensing and slice threading will also be ported to vf_interlace
2. The commands from vf_interlace will be included in the new tinterlace
filter. vf_interlace will be deleted together with old tinterlace filter

I would prefer the second option, but maybe there are even better options
that don´t come to my mind.

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


Hello everyone,

sorry for a delayed response.

 From what has been discussed in here, I think the reinterlace will exist
with tinterlace for a period of time, just after that the tinterlace can be
removed.

To have the reinterlace added, what is needed to be done from my side?

Thanks,
Vasile Toncu


Two filters with almost the same functionality won´t be accepted, as Paul
stated in this thread.
Also there is vf_interlace filter, which is a subset of vf_tinterlace and
should not differ in speed, output and license. As already said, I would
prefer to include vf_interlace options into vf_tinterlace and remove
vf_interlace.
Also you want several changes: Making tinterlace filter LGPL, adding new
options and adding slice threading.
This should be done in a patch set:

Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
remove vf_interlace


Hello,

Further research I've made showed that vf_tinterlace already contains all
the functionality from vf_interlace. I am ready to start the patches.

Please confirm.

Regards,
Vasile Toncu

Patch 2/5: Your new LGPL vf_reinterlace filter without the new options,
fixes and slice threading
Patch 3/5: Rename vf_reinterlace and replace vf_tinterlace by it
Patch 4/5: Add slice threading
Patch 5/5: Add the new options and fate tests for them

Please run fate. All tests should pass.
As already said, I don´t have the skills to suggest what has to be done
making the relicensing legal. So I can do a technical review only.
These are just my suggestions to the best of my knowledge! There might be
better ideas from more experienced developers.
Please comment.

Regards,
Thomas
___
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][RFC] avcodec/avutil: Add timeline side data

On 3/29/2018 2:13 AM, Michael Niedermayer wrote:
> Well, no unless we want a single unified API that represents information
> about timespans.
> We can use completely unrelated systems to handle the virtual timeline,
> the codec and related changes, chapters, ...

Personal opinion time: From design and use perspective, an single unified
API to handle all of those things an their edge cases sounds like a
nightmare to use and write.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

On 3/27/2018 8:44 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/avcodec.h |   8 +++
>  libavutil/timeline.h | 160 
> +++
>  2 files changed, 168 insertions(+)
>  create mode 100644 libavutil/timeline.h

A few notes from Steve on IRC:

* The ID should be 64bit, or Matroska UUIDs cannot be cleanly mapped 1:1.
* There should be a field to indicate which timeline is the default 'on'
  timeline (e.g. the default/on edition in Matroska).

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: prevent premature EOF in sub2video with nullptr AVSubtitles

2018-03-29 Thread Jan Ekström

On Thu, Mar 29, 2018 at 1:14 PM, Michael Niedermayer
 wrote:
>
> this breaks fate-sub2video
>
> TESTsub2video
> --- ./tests/ref/fate/sub2video  2018-03-29 02:30:48.095578219 +0200
> +++ tests/data/fate/sub2video   2018-03-29 12:13:25.191428538 +0200
> @@ -68,7 +68,8 @@
>  0,258,258,1,   518400, 0x34cdddee
>  0,269,269,1,   518400, 0xbab197ea
>  1,   5391,   5391,  2696000, 2095, 0x61bb15ed, F=0x0
> -0,270,270,1,   518400, 0x4db4ce51
> +0,270,270,1,   518400, 0xbab197ea
> +0,271,271,1,   518400, 0x4db4ce51
>  0,283,283,1,   518400, 0xbab197ea
>  1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7, F=0x0
>  0,284,284,1,   518400, 0xe6bc0ea9
> @@ -137,7 +138,7 @@
>  1,  168049000,  168049000,  190, 1312, 0x0bf20e8d, F=0x0
>  0,850,850,1,   518400, 0xbab197ea
>  1,  170035000,  170035000,  1524000, 1279, 0xb6c2dafe, F=0x0
> -0,851,851,1,   518400, 0x8780239e
> +0,851,851,1,   518400, 0xbab197ea
>  0,858,858,1,   518400, 0xbab197ea
>  0,861,861,1,   518400, 0x6eb72347
>  1,  172203000,  172203000,  1695000, 1826, 0x9a1ac769, F=0x0
> @@ -161,7 +162,8 @@
>  0,976,976,1,   518400, 0x923d1ce7
>  0,981,981,1,   518400, 0xbab197ea
>  1,  196361000,  196361000,  1524000, 1715, 0x695ca41e, F=0x0
> -0,982,982,1,   518400, 0x6e652cd2
> +0,982,982,1,   518400, 0xbab197ea
> +0,983,983,1,   518400, 0x6e652cd2
>  0,989,989,1,   518400, 0xbab197ea
>  1,  197946000,  197946000,  116,  789, 0xc63a189e, F=0x0
>  0,990,990,1,   518400, 0x25113966
> Test sub2video failed. Look at tests/data/fate/sub2video.err for details.
> make: *** [fate-sub2video] Error 1

Thanks. I tried running this last night but it required some of the
samples in FATE so I decided to re-run it today. Will check if the
change is correct. For the reference, this change has now been running
in a testing setup for at least 24h with the subtitles still being
overlayed correctly, so the change seems alright by the general
metrics (that I can gather).

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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

2018-03-29 Thread Thomas Mundt

2018-03-29 15:44 GMT+02:00 Vasile Toncu :

>
>
> On 14.03.2018 18:56, Thomas Mundt wrote:
>
>> 2018-03-13 16:10 GMT+01:00 Vasile Toncu :
>>
>>
>>> On 06.03.2018 20:38, Thomas Mundt wrote:
>>>
>>> Hi,

 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :

 2018-03-05 12:37 GMT+01:00, Paul B Mahol :

> On 3/5/18, Vasile Toncu  wrote:
>>
>> Hello,
>>>
>>> Thanks for the review. I've made changes according to your guidance.
>>>
>>> It would be great to know if the community will go on with our
>>> intention
>>> of adding reinterlace as a alternative for tinterlace.
>>>
>>> That being said, here is the new patch.
>>>
>>> As already said, this is not acceptable.
>>
>> There is no point in having 2 filters with near same funcionality.
>>
>> If you consider the new filter ok, the existing filter will be removed
> in the same push. I believe sending only the new filter makes
> reviewing easier.
>
> For me reviewing would be easier when Vasile sends a patchset that
>
 includes
 the replacement of tinterlace filter.
 That way existing fate tests could be used which are fortunately pretty
 extensive in this case.
 Also it would be helpful when you and/or other experienced ffmpeg
 developers would clarify first which parts of tinterlace have to be
 rewritten for proper relicensing.
 Being left in the dark makes working on patches frustrating.

 Another question is how to deal with vf_interlace? IMHO for the user
 there
 should be no difference in output, speed and license.
 Two options:
 1. Relicensing and slice threading will also be ported to vf_interlace
 2. The commands from vf_interlace will be included in the new tinterlace
 filter. vf_interlace will be deleted together with old tinterlace filter

 I would prefer the second option, but maybe there are even better
 options
 that don´t come to my mind.

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

 Hello everyone,
>>>
>>> sorry for a delayed response.
>>>
>>>  From what has been discussed in here, I think the reinterlace will exist
>>> with tinterlace for a period of time, just after that the tinterlace can
>>> be
>>> removed.
>>>
>>> To have the reinterlace added, what is needed to be done from my side?
>>>
>>> Thanks,
>>> Vasile Toncu
>>>
>>> Two filters with almost the same functionality won´t be accepted, as Paul
>> stated in this thread.
>> Also there is vf_interlace filter, which is a subset of vf_tinterlace and
>> should not differ in speed, output and license. As already said, I would
>> prefer to include vf_interlace options into vf_tinterlace and remove
>> vf_interlace.
>> Also you want several changes: Making tinterlace filter LGPL, adding new
>> options and adding slice threading.
>> This should be done in a patch set:
>>
>> Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
>> remove vf_interlace
>>
>
> Hello,
>
> Further research I've made showed that vf_tinterlace already contains all
> the functionality from vf_interlace. I am ready to start the patches.
>
> Please confirm.
>

The functionality is not the point. The options must not be removed.
"ffmpeg -i input vf interlace output" must remain for the user.


> Regards,
> Vasile Toncu
>
>> Patch 2/5: Your new LGPL vf_reinterlace filter without the new options,
>> fixes and slice threading
>> Patch 3/5: Rename vf_reinterlace and replace vf_tinterlace by it
>> Patch 4/5: Add slice threading
>> Patch 5/5: Add the new options and fate tests for them
>>
>> Please run fate. All tests should pass.
>> As already said, I don´t have the skills to suggest what has to be done
>> making the relicensing legal. So I can do a technical review only.
>> These are just my suggestions to the best of my knowledge! There might be
>> better ideas from more experienced developers.
>> Please comment.
>>
>> Regards,
>> Thomas
>> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

On Wed, Mar 28, 2018 at 07:02:48PM +0300, Timo Teräs wrote:
> iTunes currently uses the 'cprt' atom to store the copyright notice
> and this patch fixes compatibility with majority of software that
> supports the 'ilst' atom. Other software and documentation using this:
>  - AtomicParseley encodes and parses only 'cprt'
>  - Most players recognize only 'cprt'
>  - https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html
>documents both tag types
>  - http://mutagen.readthedocs.io/en/latest/api/mp4.html documents
>only 'cprt'
> 
> ffmpeg mov reader properly parses the 'cprt' tag inside 'ilst' tag
> and functions correctly with streams produced with this commit.
> 
> Since 'cprt' seems to be the current correct atom, it is used by
> default. "-movflags legacy_copyright" option is added to revert
> back to the old atom type in case that is needed.
> 
> Signed-off-by: Timo Teräs 
> ---
> If the legacy option is not needed, I'm happy to resend patch just
> changing the atom types.

why dont you store both ?
the old should do no harm or am i missing something ?
and it avoids the need for the user parameter (which few will find if
they run in a file that doesnt work)

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH v3 3/3] fftools/cmdutils: replace loglevel option parsing with av_log_set_opts

On Wed, Mar 28, 2018 at 05:03:40PM +0200, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  fftools/cmdutils.c | 48 +++-
>  1 file changed, 7 insertions(+), 41 deletions(-)

LGTM

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH v3 1/3] avutil/log: rename and initialize global log flags variable

On Wed, Mar 28, 2018 at 05:03:38PM +0200, Tobias Rapp wrote:
> Rename global variable for symmetry with av_log_level.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  libavutil/log.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libavutil/log.c b/libavutil/log.c
> index 9b7d484..0a99d01 100644
> --- a/libavutil/log.c
> +++ b/libavutil/log.c
> @@ -52,7 +52,7 @@ static AVMutex mutex = AV_MUTEX_INITIALIZER;
>  #endif
>  
>  static int av_log_level = AV_LOG_INFO;
> -static int flags;
> +static int av_log_flags = 0;

This prefix is confusing as the av prefix is intended for 
exported public symbols which a static symbol cannot be

[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:
> On 3/29/2018 2:13 AM, Michael Niedermayer wrote:
> > Well, no unless we want a single unified API that represents information
> > about timespans.
> > We can use completely unrelated systems to handle the virtual timeline,
> > the codec and related changes, chapters, ...
> 
> Personal opinion time: From design and use perspective, an single unified
> API to handle all of those things an their edge cases sounds like a
> nightmare to use and write.

That is not what i meant

what i meant is to align the APIs that handle timespan related information
and not have totally different interfaces for each.
For example they might share the same struct in some cases to deliver data
They do have in common that they all in/export data for a sequence of timespans

Also the function interfaces could be aligned to each other

They also may have in common that some formats store the data interleaved
at the time and some store it in a main header.
If this is so the case of collecting all this info from the whole
duration of a file to store it in the output file header at the start
may be a situation common to multiple of these.
A similar API may allow simplifying whichever way we handle this

Iam sure there are more advantages of having APIs which deal with
similar types of data to be similar ...

thx

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

On Thu, Mar 29, 2018 at 08:49:21PM +0200, Michael Niedermayer wrote:
> On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:
> > On 3/29/2018 2:13 AM, Michael Niedermayer wrote:
> > > Well, no unless we want a single unified API that represents information
> > > about timespans.
> > > We can use completely unrelated systems to handle the virtual timeline,
> > > the codec and related changes, chapters, ...
> > 
> > Personal opinion time: From design and use perspective, an single unified
> > API to handle all of those things an their edge cases sounds like a
> > nightmare to use and write.
> 
> That is not what i meant
> 
> what i meant is to align the APIs that handle timespan related information
> and not have totally different interfaces for each.
> For example they might share the same struct in some cases to deliver data
> They do have in common that they all in/export data for a sequence of 
> timespans
> 
> Also the function interfaces could be aligned to each other
> 
> They also may have in common that some formats store the data interleaved
> at the time and some store it in a main header.
> If this is so the case of collecting all this info from the whole
> duration of a file to store it in the output file header at the start
> may be a situation common to multiple of these.
> A similar API may allow simplifying whichever way we handle this
> 
> Iam sure there are more advantages of having APIs which deal with
> similar types of data to be similar ...

an example of an API that serves a similar kind of information but is
differnt is AVChapter
I think we should minimize the amount of different public structs that 
describe timespans when that is easily and cleanly possible

thx


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] avcodec/wmalosslessdec: Fix null pointer dereference in decode_frame()

On Sun, Mar 25, 2018 at 03:32:38AM +0200, Michael Niedermayer wrote:
> Fixes: 2018_03_23_poc.wav
> Found-by: GwanYeong Kim 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wmalosslessdec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

will apply

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

On Thu, 29 Mar 2018 20:55:52 +0200
Michael Niedermayer  wrote:

> On Thu, Mar 29, 2018 at 08:49:21PM +0200, Michael Niedermayer wrote:
> > On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:  
> > > On 3/29/2018 2:13 AM, Michael Niedermayer wrote:  
> > > > Well, no unless we want a single unified API that represents information
> > > > about timespans.
> > > > We can use completely unrelated systems to handle the virtual timeline,
> > > > the codec and related changes, chapters, ...  
> > > 
> > > Personal opinion time: From design and use perspective, an single unified
> > > API to handle all of those things an their edge cases sounds like a
> > > nightmare to use and write.  
> > 
> > That is not what i meant
> > 
> > what i meant is to align the APIs that handle timespan related information
> > and not have totally different interfaces for each.
> > For example they might share the same struct in some cases to deliver data
> > They do have in common that they all in/export data for a sequence of 
> > timespans
> > 
> > Also the function interfaces could be aligned to each other
> > 
> > They also may have in common that some formats store the data interleaved
> > at the time and some store it in a main header.
> > If this is so the case of collecting all this info from the whole
> > duration of a file to store it in the output file header at the start
> > may be a situation common to multiple of these.
> > A similar API may allow simplifying whichever way we handle this
> > 
> > Iam sure there are more advantages of having APIs which deal with
> > similar types of data to be similar ...  
> 
> an example of an API that serves a similar kind of information but is
> differnt is AVChapter
> I think we should minimize the amount of different public structs that 
> describe timespans when that is easily and cleanly possible

Like how?

This sounds like a bikeshed smoke bomb to stop all progress again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

2018-03-29 Thread Timo Teras

On Thu, 29 Mar 2018 20:29:44 +0200
Michael Niedermayer  wrote:

> On Wed, Mar 28, 2018 at 07:02:48PM +0300, Timo Teräs wrote:
> > iTunes currently uses the 'cprt' atom to store the copyright notice
> > and this patch fixes compatibility with majority of software that
> > supports the 'ilst' atom. Other software and documentation using
> > this:
> >  - AtomicParseley encodes and parses only 'cprt'
> >  - Most players recognize only 'cprt'
> >  - https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html
> >documents both tag types
> >  - http://mutagen.readthedocs.io/en/latest/api/mp4.html documents
> >only 'cprt'
> > 
> > ffmpeg mov reader properly parses the 'cprt' tag inside 'ilst' tag
> > and functions correctly with streams produced with this commit.
> > 
> > Since 'cprt' seems to be the current correct atom, it is used by
> > default. "-movflags legacy_copyright" option is added to revert
> > back to the old atom type in case that is needed.
> > 
> > Signed-off-by: Timo Teräs 
> > ---
> > If the legacy option is not needed, I'm happy to resend patch just
> > changing the atom types.  
> 
> why dont you store both ?
> the old should do no harm or am i missing something ?
> and it avoids the need for the user parameter (which few will find if
> they run in a file that doesnt work)

AFAIK, 'cprt' is the canonical tag and always has been for iTunes list.
I tried to look where the current ffmpeg atom came from, but did not
find anything conclusive. It might be copy paste error on ffmpeg from
other container variants, and others who supports it in iTunes list is
to support ffmpeg generated .movs.

While it would do no harm, I'd rather not encode the same data multiple
times. And at least for the files I am generating, I would like to not
generate the incorrect tag.

If the preferred choice is to generate both tags, how about adding
option "{skip,disable,omit,no}_itls_cpy" or similar to inhibit it?

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

[FFmpeg-devel] [PATCH] avcodec/libaomenc: add support for AQ-mode setting

2018-03-29 Thread James Almer

Ported and adapted from the libvpx encoder wrapper.

Signed-off-by: James Almer 
---
 libavcodec/libaomenc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index f075bf4de7..67c9d5678c 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -66,6 +66,7 @@ typedef struct AOMEncoderContext {
 int static_thresh;
 int drop_threshold;
 int noise_sensitivity;
+int aq_mode;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -73,6 +74,7 @@ static const char *const ctlidstr[] = {
 [AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
 [AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
 [AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
+[AV1E_SET_AQ_MODE]  = "AV1E_SET_AQ_MODE",
 [AV1E_SET_COLOR_RANGE]  = "AV1E_SET_COLOR_RANGE",
 [AV1E_SET_COLOR_PRIMARIES]  = "AV1E_SET_COLOR_PRIMARIES",
 [AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
@@ -449,6 +451,8 @@ static av_cold int aom_init(AVCodecContext *avctx,
 codecctl_int(avctx, AOME_SET_STATIC_THRESHOLD, ctx->static_thresh);
 if (ctx->crf >= 0)
 codecctl_int(avctx, AOME_SET_CQ_LEVEL,  ctx->crf);
+if (ctx->aq_mode >= 0)
+codecctl_int(avctx, AV1E_SET_AQ_MODE, ctx->aq_mode);
 
 codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
 codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
@@ -708,6 +712,11 @@ static const AVOption options[] = {
  "by the bool decoder, meaning that partitions can be 
decoded even "
  "though earlier partitions have been lost. Note that 
intra predicition"
  " is still done over the partition boundary.",   
0, AV_OPT_TYPE_CONST, {.i64 = AOM_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE, "er"},
+{ "aq-mode", "adaptive quantization mode", OFFSET(aq_mode),
  AV_OPT_TYPE_INT, {.i64 = -1}, -1, 3, VE, "aq_mode"},
+{ "none","Aq not used", 0, AV_OPT_TYPE_CONST, {.i64 = 
0}, 0, 0, VE, "aq_mode" },
+{ "variance","Variance based Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
1}, 0, 0, VE, "aq_mode" },
+{ "complexity",  "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 = 
2}, 0, 0, VE, "aq_mode" },
+{ "cyclic",  "Cyclic Refresh Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
3}, 0, 0, VE, "aq_mode" },
 { "crf",  "Select the quality for constant quality mode", 
offsetof(AOMContext, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE },
 { "static-thresh","A change threshold on blocks below which they will 
be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { .i64 = 0 
}, 0, INT_MAX, VE },
 { "drop-threshold",   "Frame drop threshold", offsetof(AOMContext, 
drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
-- 
2.16.2

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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

2018-03-29 Thread Sasi Inguva

If we can support ffmpeg to parse and display a timeline with multiple
edits correctly, I am ok with deleting that code.

On Thu, Mar 29, 2018 at 6:43 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 3/29/2018 1:06 PM, wm4 wrote:
> > I think mov files at least use a
> > filename/URL for external references, which actually could be handled
> > in generic files.
>
> The dref box is for the whole track, FWIW, and not for edit list entries.
>
> - Derek
> ___
> 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] avcodec/dcaenc: Use aac psychoacoustic model for dcaenc

2018-03-29 Thread Даниил Чередник

Actually this test does not make a sense since encoder now use floating
point math. I should have noticed it before.
Both patches have been updated. Checked on arm.

On Thu, Mar 29, 2018 at 1:52 AM, Michael Niedermayer  wrote:

> On Tue, Mar 27, 2018 at 02:26:45AM +0300, Даниил Чередник wrote:
> > Now it should be fine. Second patch has been fixed.
> >
> > On Mon, Mar 26, 2018 at 3:59 PM, Даниил Чередник <
> dan.chered...@gmail.com>
> > wrote:
> >
> > > Hi.
> > > Yes, I reproduced it on mac. A bit strange, I run fate with valgrind
> > > during patch preparation, it was ok.
> > > I will fix it, and send updated patch.
> > >
> > > Thank you!
> > >
> > > On Sun, Mar 25, 2018 at 5:57 PM, Michael Niedermayer <
> > > mich...@niedermayer.cc> wrote:
> > >
> > >> On Sun, Mar 25, 2018 at 01:55:42PM +0300, Даниил Чередник wrote:
> > >> [...]
> > >>
> > >> >  libavcodec/dcaenc.c   |  369 --
> > >> 
> > >> >  libavcodec/psymodel.c |1
> > >> >  tests/fate/acodec.mak |4
> > >> >  3 files changed, 156 insertions(+), 218 deletions(-)
> > >> > fd146632a7f29530a59d35abd63149c81b4dfcc6
> > >> 0002-avcodec-dcaenc-Use-aac-psychoacoustic-model-for-DCA-.patch
> > >> > From 99d937a0828bbd60aef52d7979c75f8c21989145 Mon Sep 17 00:00:00
> 2001
> > >> > From: Daniil Cherednik 
> > >> > Date: Sun, 4 Mar 2018 13:14:17 +
> > >> > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model
> for
> > >> DCA
> > >> >  encoder
> > >> >
> > >> > There are several reasons to replace dca psychoacoustic to common
> model:
> > >> >  - dca psychoacoustic has some quality problems especially at high
> > >> frequency bands
> > >> >  - unclear implementation
> > >> >  - aac implementation allows to use tonality measurement for future
> > >> improvements
> > >> >  - a bit faster
> > >>
> > >> This breaks
> > >> make -j12 fate-acodec-dca
> > >> (segfaults)
> > >>
> > >> tell me if you can reproduce? If not ill rebuild with debug symbols
> and
> > >> get a
> > >> backtrace
> > >>
> > >> [...]
> > >> --
> > >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >>
> > >> If you drop bombs on a foreign country and kill a hundred thousand
> > >> innocent people, expect your government to call the consequence
> > >> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> > >> more bombs and killing more people. The technology changed, the idea
> is
> > >> old.
> > >>
> > >> ___
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >>
> > >
> > >
> > > --
> > > Daniil Cherednik
> > >
> >
> >
> >
> > --
> > Daniil Cherednik
>
> [...]
>
> > 57b2e6d001a856c9434fe6ad1856cb3f24443a83  0002-avcodec-dcaenc-Use-aac-
> psychoacoustic-model-for-DCA-.patch
> > From 49b4f2a966719c24f54c026c438680557c35e96b Mon Sep 17 00:00:00 2001
> > From: Daniil Cherednik 
> > Date: Sun, 4 Mar 2018 13:14:17 +
> > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model for DCA
> >  encoder
> >
> > There are several reasons to replace dca psychoacoustic to common model:
> >  - dca psychoacoustic has some quality problems especially at high
> frequency bands
> >  - unclear implementation
> >  - aac implementation allows to use tonality measurement for future
> improvements
> >  - a bit faster
> >
> > Signed-off-by: Daniil Cherednik 
> > ---
> >  libavcodec/dcaenc.c   | 369 +-
> 
> >  libavcodec/psymodel.c |   1 +
> >  tests/fate/acodec.mak |   4 +-
> >  3 files changed, 156 insertions(+), 218 deletions(-)
>
> breaks fate on arm qemu
>
> TESTacodec-dca
> --- -   2018-03-29 00:37:01.286083392 +0200
> +++ tests/data/fate/acodec-dca  2018-03-29 00:37:01.283607451 +0200
> @@ -1 +1 @@
> -c610f911aa74656132abb650be6b548a
> +503d8eac7238d87aae6f92808231e0c0
> Test acodec-dca failed. Look at tests/data/fate/acodec-dca.err for details.
> make: *** [fate-acodec-dca] Error 1
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No human being will ever know the Truth, for even if they happen to say it
> by chance, they would not even known they had done so. -- Xenophanes
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


-- 
Daniil Cherednik


0001-avcodec-dcaenc-Use-planar-float-frame-format.patch
Description: Binary data


0002-avcodec-dcaenc-Use-aac-psychoacoustic-model-for-DCA-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix timestamps to be strictly monotonic for video also.

2018-03-29 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index cb6f3a45de..6b13742e4d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3568,7 +3568,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 flags |= AVINDEX_DISCARD_FRAME;
 av_log(mov->fc, AV_LOG_DEBUG, "drop a frame at curr_cts: 
%"PRId64" @ %"PRId64"\n", curr_cts, index);
 
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO && 
edit_list_start_encountered == 0) {
+if (edit_list_start_encountered == 0) {
 num_discarded_begin++;
 frame_duration_buffer = 
av_realloc(frame_duration_buffer,
num_discarded_begin 
* sizeof(int64_t));
@@ -3579,7 +3579,8 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 frame_duration_buffer[num_discarded_begin - 1] = 
frame_duration;
 
 // Increment skip_samples for the first non-zero audio 
edit list
-if (first_non_zero_audio_edit > 0 && 
st->codecpar->codec_id != AV_CODEC_ID_VORBIS) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+first_non_zero_audio_edit > 0 && 
st->codecpar->codec_id != AV_CODEC_ID_VORBIS) {
 st->skip_samples += frame_duration;
 }
 }
@@ -3594,7 +3595,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 edit_list_start_encountered = 1;
 // Make timestamps strictly monotonically increasing for 
audio, by rewriting timestamps for
 // discarded packets.
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO && 
frame_duration_buffer) {
+if (frame_duration_buffer) {
 fix_index_entry_timestamps(st, st->nb_index_entries, 
edit_list_dts_counter,
frame_duration_buffer, 
num_discarded_begin);
 av_freep(&frame_duration_buffer);
-- 
2.17.0.rc1.321.gba9d0f2565-goog

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

Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Use aac psychoacoustic model for dcaenc

On 30 March 2018 at 00:12, Даниил Чередник  wrote:

> Actually this test does not make a sense since encoder now use floating
> point math. I should have noticed it before.
> Both patches have been updated. Checked on arm.
>
> On Thu, Mar 29, 2018 at 1:52 AM, Michael Niedermayer
>  > wrote:
>
> > On Tue, Mar 27, 2018 at 02:26:45AM +0300, Даниил Чередник wrote:
> > > Now it should be fine. Second patch has been fixed.
> > >
> > > On Mon, Mar 26, 2018 at 3:59 PM, Даниил Чередник <
> > dan.chered...@gmail.com>
> > > wrote:
> > >
> > > > Hi.
> > > > Yes, I reproduced it on mac. A bit strange, I run fate with valgrind
> > > > during patch preparation, it was ok.
> > > > I will fix it, and send updated patch.
> > > >
> > > > Thank you!
> > > >
> > > > On Sun, Mar 25, 2018 at 5:57 PM, Michael Niedermayer <
> > > > mich...@niedermayer.cc> wrote:
> > > >
> > > >> On Sun, Mar 25, 2018 at 01:55:42PM +0300, Даниил Чередник wrote:
> > > >> [...]
> > > >>
> > > >> >  libavcodec/dcaenc.c   |  369 --
> > > >> 
> > > >> >  libavcodec/psymodel.c |1
> > > >> >  tests/fate/acodec.mak |4
> > > >> >  3 files changed, 156 insertions(+), 218 deletions(-)
> > > >> > fd146632a7f29530a59d35abd63149c81b4dfcc6
> > > >> 0002-avcodec-dcaenc-Use-aac-psychoacoustic-model-for-DCA-.patch
> > > >> > From 99d937a0828bbd60aef52d7979c75f8c21989145 Mon Sep 17 00:00:00
> > 2001
> > > >> > From: Daniil Cherednik 
> > > >> > Date: Sun, 4 Mar 2018 13:14:17 +
> > > >> > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model
> > for
> > > >> DCA
> > > >> >  encoder
> > > >> >
> > > >> > There are several reasons to replace dca psychoacoustic to common
> > model:
> > > >> >  - dca psychoacoustic has some quality problems especially at high
> > > >> frequency bands
> > > >> >  - unclear implementation
> > > >> >  - aac implementation allows to use tonality measurement for
> future
> > > >> improvements
> > > >> >  - a bit faster
> > > >>
> > > >> This breaks
> > > >> make -j12 fate-acodec-dca
> > > >> (segfaults)
> > > >>
> > > >> tell me if you can reproduce? If not ill rebuild with debug symbols
> > and
> > > >> get a
> > > >> backtrace
> > > >>
> > > >> [...]
> > > >> --
> > > >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > 87040B0FAB
> > > >>
> > > >> If you drop bombs on a foreign country and kill a hundred thousand
> > > >> innocent people, expect your government to call the consequence
> > > >> "unprovoked inhuman terrorist attacks" and use it to justify
> dropping
> > > >> more bombs and killing more people. The technology changed, the idea
> > is
> > > >> old.
> > > >>
> > > >> ___
> > > >> ffmpeg-devel mailing list
> > > >> ffmpeg-devel@ffmpeg.org
> > > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Daniil Cherednik
> > > >
> > >
> > >
> > >
> > > --
> > > Daniil Cherednik
> >
> > [...]
> >
> > > 57b2e6d001a856c9434fe6ad1856cb3f24443a83  0002-avcodec-dcaenc-Use-aac-
> > psychoacoustic-model-for-DCA-.patch
> > > From 49b4f2a966719c24f54c026c438680557c35e96b Mon Sep 17 00:00:00 2001
> > > From: Daniil Cherednik 
> > > Date: Sun, 4 Mar 2018 13:14:17 +
> > > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model for
> DCA
> > >  encoder
> > >
> > > There are several reasons to replace dca psychoacoustic to common
> model:
> > >  - dca psychoacoustic has some quality problems especially at high
> > frequency bands
> > >  - unclear implementation
> > >  - aac implementation allows to use tonality measurement for future
> > improvements
> > >  - a bit faster
> > >
> > > Signed-off-by: Daniil Cherednik 
> > > ---
> > >  libavcodec/dcaenc.c   | 369 +-
> > 
> > >  libavcodec/psymodel.c |   1 +
> > >  tests/fate/acodec.mak |   4 +-
> > >  3 files changed, 156 insertions(+), 218 deletions(-)
> >
> > breaks fate on arm qemu
> >
> > TESTacodec-dca
> > --- -   2018-03-29 00:37:01.286083392 +0200
> > +++ tests/data/fate/acodec-dca  2018-03-29 00:37:01.283607451 +0200
> > @@ -1 +1 @@
> > -c610f911aa74656132abb650be6b548a
> > +503d8eac7238d87aae6f92808231e0c0
> > Test acodec-dca failed. Look at tests/data/fate/acodec-dca.err for
> details.
> > make: *** [fate-acodec-dca] Error 1
> >
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > No human being will ever know the Truth, for even if they happen to say
> it
> > by chance, they would not even known they had done so. -- Xenophanes
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
>
>
> --
> Daniil Cherednik
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I'll take a lo

[FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

2018-03-29 Thread Drew Allen

Hello all,

My name is Andrew Allen and I'm a contributor to Opus, supporting new
channel mappings 2 and 3 for ambisonics compression. I've attached a patch
to support the new OpusProjectionEncoder and OpusProjectionDecoder APIs for
handling the new channel mapping 3 in OPUS.

Please let me know of any changes I should make or if there are any
questions I can help answer.

Cheers,
Drew
From a897b4d9b1ebe9031b98a9e507c28355ef9a44ba Mon Sep 17 00:00:00 2001
From: Andrew Allen 
Date: Wed, 28 Mar 2018 14:48:46 -0700
Subject: [PATCH] Support for Ambisonics and OpusProjection* API.

---
 libavcodec/libopusdec.c | 160 -
 libavcodec/libopusenc.c | 257 ++--
 libavcodec/opus.c   |  18 ++-
 3 files changed, 358 insertions(+), 77 deletions(-)

diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index 3d2ee5b61b..d4b5a459b9 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@ -21,6 +21,9 @@
 
 #include 
 #include 
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+#include 
+#endif
 
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
@@ -33,9 +36,93 @@
 #include "mathops.h"
 #include "libopus.h"
 
+typedef struct OpusGenericDecoder {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+OpusProjectionDecoder *pr;
+#endif
+OpusMSDecoder *ms;
+} OpusGenericDecoder;
+
+static int libopus_generic_decoder_init(OpusGenericDecoder *st, int Fs,
+int channels, int nb_streams,
+int nb_coupled, uint8_t *mapping,
+uint8_t *dmatrix) {
+int err;
+if (dmatrix != NULL) {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+opus_int32 size;
+size = 2 * channels * (nb_streams + nb_coupled);
+st->pr = opus_projection_decoder_create(Fs, channels, nb_streams,
+nb_coupled, dmatrix, size, &err);
+#else
+err = OPUS_UNIMPLEMENTED;
+#endif
+st->ms = NULL;
+return err;
+}
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+st->pr = NULL;
+#endif
+st->ms = opus_multistream_decoder_create(Fs, channels, nb_streams,
+nb_coupled, mapping, &err);
+return err;
+}
+
+static void libopus_generic_decoder_cleanup(OpusGenericDecoder *st)
+{
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (st->pr) opus_projection_decoder_destroy(st->pr);
+#endif
+if (st->ms) opus_multistream_decoder_destroy(st->ms);
+}
+
+static int libopus_generic_decode(OpusGenericDecoder *st,
+const unsigned char *data, opus_int32 len, opus_int16 *pcm,
+int frame_size, int decode_fec) {
+int ret;
+
+#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
+if (st->pr){
+ret=opus_projection_decode(st->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode(st->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+static int libopus_generic_decode_float(OpusGenericDecoder *st,
+const unsigned char *data, opus_int32 len, float *pcm, int frame_size,
+int decode_fec) {
+int ret;
+
+#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
+if (st->pr){
+ret=opus_projection_decode_float(st->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode_float(st->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define libopus_generic_decoder_ctl(st, request) \
+((st)->pr != NULL ? \
+opus_projection_decoder_ctl((st)->pr, request) : \
+opus_multistream_decoder_ctl((st)->ms, request))
+#else
+# define libopus_generic_decoder_ctl(st, request) \
+opus_multistream_decoder_ctl((st)->ms, request)
+#endif
+
 struct libopus_context {
 AVClass *class;
-OpusMSDecoder *dec;
+OpusGenericDecoder dec;
 int pre_skip;
 #ifndef OPUS_SET_GAIN
 union { int i; double d; } gain;
@@ -46,12 +133,17 @@ struct libopus_context {
 };
 
 #define OPUS_HEAD_SIZE 19
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define OPUS_MAX_CHANNELS 18
+#else
+# define OPUS_MAX_CHANNELS 8
+#endif
 
 static av_cold int libopus_decode_init(AVCodecContext *avc)
 {
 struct libopus_context *opus = avc->priv_data;
 int ret, channel_map = 0, gain_db = 0, nb_streams, nb_coupled;
-uint8_t mapping_arr[8] = { 0, 1 }, *mapping;
+uint8_t mapping_arr[OPUS_MAX_CHANNELS] = { 0, 1 }, *mapping, *dmatrix = NULL;
 
 avc->channels = avc->extradata_size >= 10 ? avc->extradata[9] : (avc->channels == 1) ? 1 : 2;
 if (avc->channels <= 0) {
@@ -74,7 +166,21 @@ static av_cold int libopus_decode_init(AVCodecContext *avc)
 nb_coupled = avc->extradata[OPUS_HEAD_SIZE + 1];
 if (nb_streams + nb_coupled != avc->channels)
 av_log(avc, AV_LOG_WARNING, "Inconsistent channel mapping.\n");
-mapping = avc->extradata + OPUS_HEAD_SIZE + 2;
+if (channel_map == 3) {
+

[FFmpeg-devel] ffmpeg_opt.c wrong parameter for Filter

2018-03-29 Thread sebastian-doerf...@t-online.de

 
 
use the ost->enc_ctx->channel_layout for f->channel_layout
 
not 
 
f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
 
 
ffmpeg_opt.c
 
static int open_output_file(OptionsContext *o, const char *filename)
 
Old:
 
if (ost->enc_ctx->channels) {
f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
} else if (ost->enc->channel_layouts) {
count = 0;
while (ost->enc->channel_layouts[count])
count++;
f->channel_layouts = av_mallocz_array(count + 1, 
sizeof(*f->channel_layouts));
if (!f->channel_layouts)
exit_program(1);
memcpy(f->channel_layouts, ost->enc->channel_layouts,
(count + 1) * sizeof(*f->channel_layouts));
}
 
 
new:
 
if (ost->enc_ctx->channel_layout) {
f->channel_layout = ost->enc_ctx->channel_layout;
}
else if (ost->enc_ctx->channels) {
f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
}
else if (ost->enc->channel_layouts) {
count = 0;
while (ost->enc->channel_layouts[count])
count++;
f->channel_layouts = av_mallocz_array(count + 1, 
sizeof(*f->channel_layouts));
if (!f->channel_layouts)
exit_program(1);
memcpy(f->channel_layouts, ost->enc->channel_layouts,
(count + 1) * sizeof(*f->channel_layouts));
}

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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

On Thu, Mar 29, 2018 at 10:12:50PM +0300, Timo Teras wrote:
> On Thu, 29 Mar 2018 20:29:44 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 28, 2018 at 07:02:48PM +0300, Timo Teräs wrote:
> > > iTunes currently uses the 'cprt' atom to store the copyright notice
> > > and this patch fixes compatibility with majority of software that
> > > supports the 'ilst' atom. Other software and documentation using
> > > this:
> > >  - AtomicParseley encodes and parses only 'cprt'
> > >  - Most players recognize only 'cprt'
> > >  - https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html
> > >documents both tag types
> > >  - http://mutagen.readthedocs.io/en/latest/api/mp4.html documents
> > >only 'cprt'
> > > 
> > > ffmpeg mov reader properly parses the 'cprt' tag inside 'ilst' tag
> > > and functions correctly with streams produced with this commit.
> > > 
> > > Since 'cprt' seems to be the current correct atom, it is used by
> > > default. "-movflags legacy_copyright" option is added to revert
> > > back to the old atom type in case that is needed.
> > > 
> > > Signed-off-by: Timo Teräs 
> > > ---
> > > If the legacy option is not needed, I'm happy to resend patch just
> > > changing the atom types.  
> > 
> > why dont you store both ?
> > the old should do no harm or am i missing something ?
> > and it avoids the need for the user parameter (which few will find if
> > they run in a file that doesnt work)
> 
> AFAIK, 'cprt' is the canonical tag and always has been for iTunes list.
> I tried to look where the current ffmpeg atom came from, but did not
> find anything conclusive. It might be copy paste error on ffmpeg from
> other container variants, and others who supports it in iTunes list is
> to support ffmpeg generated .movs.

git log points to
bed4fc54c947b9e36d2103b400d438bfb4dd80dd

This commit added both cpy and cprt, that makes your hypothesis not
fit very well

did you ask the author, who added this ? Maybe he remembers where it
came from. 
It would be better to understand where it came from before its changed

If it was a typo or something like that, i agree that it should be
removed/replaced. I was assuming it come from some official
reference/software ...

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

2018-03-29 Thread Jan Ekström

On Fri, Mar 30, 2018 at 3:39 AM, Michael Niedermayer
 wrote:
>
> If it was a typo or something like that, i agree that it should be
> removed/replaced. I was assuming it come from some official
> reference/software ...
>

For the record, the current QTFF (aka MOV) specification still lists
'©cpy' as the copyright statement international text field. The
copyright sign at the beginning of the identifier is defined as:
"All user data list entries whose type begins with the © character
(ASCII 169) are defined to be international text. These list entries
must contain a list of text strings with associated language codes. By
storing multiple versions of the same text, a single user data text
item can contain translations for different languages."
Official ref: 
https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-BBCCFFGD

'cprt' is not mentioned in QTFF.

Meanwhile, in ISOBMFF (aka MP4 aka 14496-12, available for free from
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html )
'cprt' is defined.

So with a quick look it seems like when writing in MOV mode one should
still utilize '©cpy' while with MP4 one should utilize 'cprt'
according to ISOBMFF.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

2018-03-29 Thread Timo Teras

On Fri, 30 Mar 2018 02:39:13 +0200
Michael Niedermayer  wrote:

> On Thu, Mar 29, 2018 at 10:12:50PM +0300, Timo Teras wrote:
> > On Thu, 29 Mar 2018 20:29:44 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 28, 2018 at 07:02:48PM +0300, Timo Teräs wrote:  
> > > > iTunes currently uses the 'cprt' atom to store the copyright
> > > > notice and this patch fixes compatibility with majority of
> > > > software that supports the 'ilst' atom. Other software and
> > > > documentation using this:
> > > >  - AtomicParseley encodes and parses only 'cprt'
> > > >  - Most players recognize only 'cprt'
> > > >  -
> > > > https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html
> > > > documents both tag types
> > > >  - http://mutagen.readthedocs.io/en/latest/api/mp4.html
> > > > documents only 'cprt'
> > > > 
> > > > ffmpeg mov reader properly parses the 'cprt' tag inside 'ilst'
> > > > tag and functions correctly with streams produced with this
> > > > commit.
> > > > 
> > > > Since 'cprt' seems to be the current correct atom, it is used by
> > > > default. "-movflags legacy_copyright" option is added to revert
> > > > back to the old atom type in case that is needed.
> > > > 
> > > > Signed-off-by: Timo Teräs 
> > > > ---
> > > > If the legacy option is not needed, I'm happy to resend patch
> > > > just changing the atom types.
> > > 
> > > why dont you store both ?
> > > the old should do no harm or am i missing something ?
> > > and it avoids the need for the user parameter (which few will
> > > find if they run in a file that doesnt work)  
> > 
> > AFAIK, 'cprt' is the canonical tag and always has been for iTunes
> > list. I tried to look where the current ffmpeg atom came from, but
> > did not find anything conclusive. It might be copy paste error on
> > ffmpeg from other container variants, and others who supports it in
> > iTunes list is to support ffmpeg generated .movs.  
> 
> git log points to
> bed4fc54c947b9e36d2103b400d438bfb4dd80dd
> 
> This commit added both cpy and cprt, that makes your hypothesis not
> fit very well

That commit adds it to three places:
 - MOV mode which is basically in mov_write_udta_tag() using '\251cpy'
   which published in Apple docs
 - 3GP mode using 'cprt' which is in ISO standard
 - mov_write_ilst_tag() is iTunes which is non-documented

The commit adds exactly one tag to each variant. To me my hyptothesis
still looks correct.

> did you ask the author, who added this ? Maybe he remembers where it
> came from. 
> It would be better to understand where it came from before its changed

@Baptiste: Any comment why \251cpy tag was used for iTunes list and not
cprt?

> If it was a typo or something like that, i agree that it should be
> removed/replaced. I was assuming it come from some official
> reference/software ...

iTunes list format is unfortunately not documented. MOV and 3GP modes
are standardized.

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

Re: [FFmpeg-devel] ffmpeg_opt.c wrong parameter for Filter

2018-03-29 Thread pkv.stream


Le 29/03/2018 à 2:53 PM, sebastian-doerf...@t-online.de a écrit :
  
  
use the ost->enc_ctx->channel_layout for f->channel_layout
  
not
  
f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
  
  
ffmpeg_opt.c
  
static int open_output_file(OptionsContext *o, const char *filename)
  
Old:
  
if (ost->enc_ctx->channels) {

f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
} else if (ost->enc->channel_layouts) {
count = 0;
while (ost->enc->channel_layouts[count])
count++;
f->channel_layouts = av_mallocz_array(count + 1,
sizeof(*f->channel_layouts));
if (!f->channel_layouts)
exit_program(1);
memcpy(f->channel_layouts, ost->enc->channel_layouts,
(count + 1) * sizeof(*f->channel_layouts));
}
  
  
new:
  
if (ost->enc_ctx->channel_layout) {

f->channel_layout = ost->enc_ctx->channel_layout;
}
else if (ost->enc_ctx->channels) {
f->channel_layout = av_get_default_channel_layout(ost->enc_ctx->channels);
}
else if (ost->enc->channel_layouts) {
count = 0;
while (ost->enc->channel_layouts[count])
count++;
f->channel_layouts = av_mallocz_array(count + 1,
sizeof(*f->channel_layouts));
if (!f->channel_layouts)
exit_program(1);
memcpy(f->channel_layouts, ost->enc->channel_layouts,
(count + 1) * sizeof(*f->channel_layouts));
}

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


Hi

the fix required is more involved than that.

Check the two solutions I ended up with:

http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225769.html

and the original ticket :

https://trac.ffmpeg.org/ticket/6706

The patch reviewing seems in limbo though and has been for several months.

best

pkv

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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/movenc: use modern iTunes copyright atom

2018-03-29 Thread Timo Teras

On Fri, 30 Mar 2018 03:54:59 +0300
Jan Ekström  wrote:

> On Fri, Mar 30, 2018 at 3:39 AM, Michael Niedermayer
>  wrote:
> >
> > If it was a typo or something like that, i agree that it should be
> > removed/replaced. I was assuming it come from some official
> > reference/software ...
> >  
> 
> For the record, the current QTFF (aka MOV) specification still lists
> '©cpy' as the copyright statement international text field. The
> copyright sign at the beginning of the identifier is defined as:
> "All user data list entries whose type begins with the © character
> (ASCII 169) are defined to be international text. These list entries
> must contain a list of text strings with associated language codes. By
> storing multiple versions of the same text, a single user data text
> item can contain translations for different languages."
> Official ref:
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-BBCCFFGD
> 
> 'cprt' is not mentioned in QTFF.
> 
> Meanwhile, in ISOBMFF (aka MP4 aka 14496-12, available for free from
> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html )
> 'cprt' is defined.
> 
> So with a quick look it seems like when writing in MOV mode one should
> still utilize '©cpy' while with MP4 one should utilize 'cprt'
> according to ISOBMFF.

Correct. And these modes are not touched in the patch, it changes
iTunes list writing which is not covered by any standard.

Do note that iTunes list is is not MOV format. It's Apple extension to
MP4. The MOV mode tag is written in mov_write_udta_tag() in the if
mov->mode == MODE_MOV block.

The commit bed4fc54c947b9e36d2103b400d438bfb4dd80dd pointed by Michael
shows the three code paths writing copyright tag in the different
modes/variants.

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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
> PSEUDOPAL pixel formats are not paletted, but carried a palette with the
> intention of allowing code to treat unpaletted formats as paletted. The
> palette simply mapped the byte values to the resulting RGB values,
> making it some sort of LUT for RGB conversion.
> 
> It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
> GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
> formats. The last one, GRAY8, is more common, but its treatment is
> grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
> from typical Y video planes was not mapped to the correct RGB values.
> Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
> All other code had to treat it as a special case, just to ignore or
> propagate palette data.
> 
> In conclusion, this was just a very strange old hack that has no real
> justification to exist. It's negatively useful, because API users who
> allocate their own pixel data have to be aware that they need to
> allocate the palette, or FFmpeg will crash on them in _some_ situations.
> On top of this, there was no API to allocate the pseuo palette outside
> of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
> which is good, because GRAY8 treatment is broken.)
> 
> This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
> the pseudo palette optional. Nothing accesses it anymore, though if it's
> set, it's propagated. It's still allocated and initialized for
> compatibility with API users that rely on this feature. But new API
> users do not need to allocate it. This was an explicit goal of this
> patch.
> 
> Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
> first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
> macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
> 
> Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
> FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
> functions manually changed to not allocating a palette.
> ---

iam not sure if your rants / political views belong in a commit message.
I think they should be removed. 

about the patch, ive not tested it yet or looked deeper but
please seperate the identifer renaming out into its own patch, that way
it will be much more readable.


thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] lavc/hevc: Don't parse NAL unit for a dummy buffer

2018-03-29 Thread Xiang, Haihao


> > On 27 Mar 2018, at 15:57, Haihao Xiang  wrote:
> > 
> > hevc parser mistakenly reports the following message if a dummy buffer
> > is padded for EOF
> > 
> >   [hevc @ 0x559b63848610] missing picture in access unit
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> > libavcodec/hevc_parser.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > index a468682ed33..228784e946f 100644
> > --- a/libavcodec/hevc_parser.c
> > +++ b/libavcodec/hevc_parser.c
> > @@ -294,6 +294,8 @@ static int hevc_parse(AVCodecParserContext *s,
> > AVCodecContext *avctx,
> > int next;
> > HEVCParserContext *ctx = s->priv_data;
> > ParseContext *pc = &ctx->pc;
> > +int is_dummy_buf = (buf_size == 0);
> 
> What about use !buf_size

Thanks, I will update the patch to use !buf_size.

> > +const uint8_t *dummy_buf = buf;
> > 
> > if (avctx->extradata && !ctx->parsed_extradata) {
> > ff_hevc_decode_extradata(avctx->extradata, avctx->extradata_size,
> > &ctx->ps, &ctx->sei,
> > @@ -313,7 +315,10 @@ static int hevc_parse(AVCodecParserContext *s,
> > AVCodecContext *avctx,
> > }
> > }
> > 
> > -parse_nal_units(s, buf, buf_size, avctx);
> > +is_dummy_buf = (is_dummy_buf && (dummy_buf == buf));
> > +
> > +if (!is_dummy_buf)
> > +parse_nal_units(s, buf, buf_size, avctx);
> > 
> > *poutbuf  = buf;
> > *poutbuf_size = buf_size;
> > -- 
> > 2.14.1
> > 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Thanks
> Steven
> 
> 
> 
> 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

On Fri, 30 Mar 2018 03:13:07 +0200
Michael Niedermayer  wrote:

> On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
> > PSEUDOPAL pixel formats are not paletted, but carried a palette with the
> > intention of allowing code to treat unpaletted formats as paletted. The
> > palette simply mapped the byte values to the resulting RGB values,
> > making it some sort of LUT for RGB conversion.
> > 
> > It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
> > GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
> > formats. The last one, GRAY8, is more common, but its treatment is
> > grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
> > from typical Y video planes was not mapped to the correct RGB values.
> > Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
> > All other code had to treat it as a special case, just to ignore or
> > propagate palette data.
> > 
> > In conclusion, this was just a very strange old hack that has no real
> > justification to exist. It's negatively useful, because API users who
> > allocate their own pixel data have to be aware that they need to
> > allocate the palette, or FFmpeg will crash on them in _some_ situations.
> > On top of this, there was no API to allocate the pseuo palette outside
> > of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
> > which is good, because GRAY8 treatment is broken.)
> > 
> > This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
> > the pseudo palette optional. Nothing accesses it anymore, though if it's
> > set, it's propagated. It's still allocated and initialized for
> > compatibility with API users that rely on this feature. But new API
> > users do not need to allocate it. This was an explicit goal of this
> > patch.
> > 
> > Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
> > first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
> > macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
> > 
> > Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
> > FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
> > functions manually changed to not allocating a palette.
> > ---  
> 
> iam not sure if your rants / political views belong in a commit message.
> I think they should be removed. 

There are no "political" views. Please point out which parts you think
are political, and why they supposedly are political.

There are no rants either. In fact, calling them rants is disrespectful
and implies there is no logic behind whatever parts you think are rants.

> about the patch, ive not tested it yet or looked deeper but
> please seperate the identifer renaming out into its own patch, that way
> it will be much more readable.

There's nothing being renamed. This is the deprecation. Do you prefer if
I litter the code with ifdefs instead? Did you read the commit message?

> 
> thx

If you meant it you'd do a proper review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_signature: use av_strlcpy()

Fixes: out of array access

Found-by: Kira 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_signature.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
index f0078ba1a6..d07b213f31 100644
--- a/libavfilter/vf_signature.c
+++ b/libavfilter/vf_signature.c
@@ -576,7 +576,8 @@ static int export(AVFilterContext *ctx, StreamContext *sc, 
int input)
 /* error already handled */
 av_assert0(av_get_frame_filename(filename, sizeof(filename), 
sic->filename, input) == 0);
 } else {
-strcpy(filename, sic->filename);
+if (av_strlcpy(filename, sic->filename, sizeof(filename)) >= 
sizeof(filename))
+return AVERROR(EINVAL);
 }
 if (sic->format == FORMAT_XML) {
 return xml_export(ctx, sc, filename);
-- 
2.16.2

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

[FFmpeg-devel] [PATCH v2] lavc/hevc: Don't parse NAL unit for a dummy buffer

2018-03-29 Thread Haihao Xiang

hevc parser mistakenly reports the following message if a dummy buffer
is padded for EOF

   [hevc @ 0x559b63848610] missing picture in access unit

v2: use the preferred code style and rebase the patch

Signed-off-by: Haihao Xiang 
---
 libavcodec/hevc_parser.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a468682ed3..01418b276d 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -294,6 +294,8 @@ static int hevc_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 int next;
 HEVCParserContext *ctx = s->priv_data;
 ParseContext *pc = &ctx->pc;
+int is_dummy_buf = !buf_size;
+const uint8_t *dummy_buf = buf;
 
 if (avctx->extradata && !ctx->parsed_extradata) {
 ff_hevc_decode_extradata(avctx->extradata, avctx->extradata_size, 
&ctx->ps, &ctx->sei,
@@ -313,7 +315,10 @@ static int hevc_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 }
 }
 
-parse_nal_units(s, buf, buf_size, avctx);
+is_dummy_buf = (is_dummy_buf && (dummy_buf == buf));
+
+if (!is_dummy_buf)
+parse_nal_units(s, buf, buf_size, avctx);
 
 *poutbuf  = buf;
 *poutbuf_size = buf_size;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/eac3: add support for dependent stream

2018-03-29 Thread James Almer

On 3/28/2018 3:59 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/aac_ac3_parser.c |   9 ++-
>  libavcodec/ac3_parser.c |   2 +-
>  libavcodec/ac3dec.c | 177 
> +++-
>  libavcodec/ac3dec.h |  10 ++-
>  libavcodec/eac3dec.c|  11 +--
>  tests/ref/fate/ts-demux |   2 +-
>  tests/ref/seek/lavf-rm  |   6 +-
>  7 files changed, 164 insertions(+), 53 deletions(-)
> 

> @@ -1463,14 +1483,17 @@ static int ac3_decode_frame(AVCodecContext * avctx, 
> void *data,
>  {
>  AVFrame *frame = data;
>  const uint8_t *buf = avpkt->data;
> -int buf_size = avpkt->size;
> +int buf_size, full_buf_size = avpkt->size;
>  AC3DecodeContext *s = avctx->priv_data;
> -int blk, ch, err, ret;
> +int blk, ch, err, offset, ret;
> +int got_independent_frame = 0;
>  const uint8_t *channel_map;
> +uint8_t extended_channel_map[AC3_MAX_CHANNELS * 2];

AC3_MAX_CHANNELS is 7

[...]

> +for (ch = 0; ch < 16; ch++)
> +extended_channel_map[ch] = ch;

Which means an out of array access takes place here.

This is making all ac3 and eac3 tests crash with SIGABRT on Linux GCC
when -fstack-protector is enabled (which is on by default).

http://fate.ffmpeg.org/report.cgi?time=20180329202433&slot=x86_64-archlinux-gcc-threads-auto

[...]

> @@ -239,11 +242,12 @@ typedef struct AC3DecodeContext {
>  ///@name Aligned arrays
>  DECLARE_ALIGNED(16, int,   
> fixed_coeffs)[AC3_MAX_CHANNELS][AC3_MAX_COEFS];   ///< fixed-point 
> transform coefficients
>  DECLARE_ALIGNED(32, INTFLOAT, 
> transform_coeffs)[AC3_MAX_CHANNELS][AC3_MAX_COEFS];   ///< transform 
> coefficients
> -DECLARE_ALIGNED(32, INTFLOAT, delay)[AC3_MAX_CHANNELS][AC3_BLOCK_SIZE];  
>///< delay - added to the next block
> +DECLARE_ALIGNED(32, INTFLOAT, delay)[2 * 
> AC3_MAX_CHANNELS][AC3_BLOCK_SIZE]; ///< delay - added to the next 
> block
>  DECLARE_ALIGNED(32, INTFLOAT, window)[AC3_BLOCK_SIZE];   
>///< window coefficients
>  DECLARE_ALIGNED(32, INTFLOAT, tmp_output)[AC3_BLOCK_SIZE];   
>///< temporary storage for output before windowing
> -DECLARE_ALIGNED(32, SHORTFLOAT, 
> output)[AC3_MAX_CHANNELS][AC3_BLOCK_SIZE];///< output after imdct 
> transform and windowing
> +DECLARE_ALIGNED(32, SHORTFLOAT, output)[2 * 
> AC3_MAX_CHANNELS][AC3_BLOCK_SIZE];///< output after imdct 
> transform and windowing
>  DECLARE_ALIGNED(32, uint8_t, input_buffer)[AC3_FRAME_BUFFER_SIZE + 
> AV_INPUT_BUFFER_PADDING_SIZE]; ///< temp buffer to prevent overread
> +DECLARE_ALIGNED(32, SHORTFLOAT, output_buffer)[2 * 
> AC3_MAX_CHANNELS][AC3_BLOCK_SIZE * 6];  ///< final output buffer

Not sure if the same happens with these, but better make sure.

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

Re: [FFmpeg-devel] [PATCH] fate: add eac3_core bitstream filter test

2018-03-29 Thread James Almer

On 3/29/2018 6:12 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  tests/fate/ac3.mak | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak
> index 76be2e869a..26d2bf3e1c 100644
> --- a/tests/fate/ac3.mak
> +++ b/tests/fate/ac3.mak
> @@ -88,6 +88,11 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c ac3_fixed 
> -ab 128k -f ac3 -flags +
>  fate-ac3-fixed-encode: CMP = oneline
>  fate-ac3-fixed-encode: REF = a1d1fc116463b771abf5aef7ed37d7b1
>  
> +FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += 
> fate-eac3-core-bsf
> +fate-eac3-core-bsf: CMD = md5pipe -i 
> $(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core 
> -fflags +bitexact -f eac3
> +fate-eac3-core-bsf: CMP = oneline
> +fate-eac3-core-bsf: REF = b704bf851e99b7442e9bed368b60e6ca
> +
>  FATE_SAMPLES_AVCONV += $(FATE_AC3-yes) $(FATE_EAC3-yes)
>  
>  fate-ac3: $(FATE_AC3-yes) $(FATE_EAC3-yes)

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

[FFmpeg-devel] [PATCH 1/3] lavu: add a Vulkan hwcontext

This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
VAAPI frames but additional functionality can be added later to support
importing of D3D11 surfaces as well as exporting to various other APIs.

This context requires the newest stable version of the Vulkan API,
and once the new extension for DRM surfaces makes it in will also require
it (in order to properly and fully import them).

It makes use of every part of the Vulkan spec in order to ensure fastest
possible uploading, downloading and mapping of frames. On AMD, it will
also make use of mapping host memory frames in order to upload
very efficiently and with minimal CPU to hardware.

To be useful for non-RGB images an implementation with the YUV images
extension is needed. All current implementations support that with the
exception of AMD, though support is coming soon for Mesa.

This is RFC-only, its not meant for merging as is. In particular, I'd
like to know whether the exposed hwcontext API is fine.

Signed-off-by: Rostislav Pehlivanov 
---
 configure  |7 +-
 doc/APIchanges |3 +
 libavutil/Makefile |3 +
 libavutil/hwcontext.c  |4 +
 libavutil/hwcontext.h  |1 +
 libavutil/hwcontext_internal.h |1 +
 libavutil/hwcontext_vulkan.c   | 1952 
 libavutil/hwcontext_vulkan.h   |  116 +++
 libavutil/pixdesc.c|4 +
 libavutil/pixfmt.h |4 +
 libavutil/version.h|2 +-
 11 files changed, 2095 insertions(+), 2 deletions(-)
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

diff --git a/configure b/configure
index 99570a1415..2213f0452d 100755
--- a/configure
+++ b/configure
@@ -297,6 +297,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls or libtls is not used [no]
+  --enable-vulkan  enable Vulkan code [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1761,6 +1762,7 @@ HWACCEL_LIBRARY_LIST="
 mmal
 omx
 opencl
+vulkan
 "
 
 DOCUMENT_LIST="
@@ -3442,7 +3444,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl vulkan 
user32 vaapi videotoolbox corefoundation corevideo coremedia wincrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -6314,6 +6316,9 @@ enabled vdpau &&
 
 enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
 
+enabled vulkan &&
+check_lib vulkan "vulkan/vulkan.h" vkCreateInstance -lvulkan
+
 if enabled x86; then
 case $target_os in
 mingw32*|mingw64*|win32|win64|linux|cygwin*)
diff --git a/doc/APIchanges b/doc/APIchanges
index 83c7a40a55..cd38dee916 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-03-xx - xx - lavu 56.13.100 - hwcontext.h
+  Add AV_HWDEVICE_TYPE_VULKAN and implementation.
+
 2018-03-xx - xxx - lavc 58.16.100 - avcodec.h
   Add FF_SUB_CHARENC_MODE_IGNORE.
 
diff --git a/libavutil/Makefile b/libavutil/Makefile
index a63ba523c9..aa641d78ed 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -42,6 +42,7 @@ HEADERS = adler32.h   
  \
   hwcontext_vaapi.h \
   hwcontext_videotoolbox.h  \
   hwcontext_vdpau.h \
+  hwcontext_vulkan.h\
   imgutils.h\
   intfloat.h\
   intreadwrite.h\
@@ -168,6 +169,7 @@ OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
 OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
+OBJS-$(CONFIG_VULKAN)   += hwcontext_vulkan.o
 
 OBJS += $(COMPAT_OBJS:%=../compat/%)
 
@@ -183,6 +185,7 @@ SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwconte

[FFmpeg-devel] [PATCH 0/3] RFC: Add a Vulkan filtering infrastructure and a filter

This is an RFC version of the patchset, put here to discuss any issues
that it might have, and its not ready for merging as-is.

Rostislav Pehlivanov (3):
  lavu: add a Vulkan hwcontext
  lavfi: add common Vulkan filtering code
  lavfi: add a Vulkan avgblur filter

 configure   |   11 +-
 doc/APIchanges  |3 +
 libavfilter/Makefile|1 +
 libavfilter/allfilters.c|1 +
 libavfilter/vf_avgblur_vulkan.c |  353 +++
 libavfilter/vulkan.c| 1101 ++
 libavfilter/vulkan.h|  179 
 libavutil/Makefile  |3 +
 libavutil/hwcontext.c   |4 +
 libavutil/hwcontext.h   |1 +
 libavutil/hwcontext_internal.h  |1 +
 libavutil/hwcontext_vulkan.c| 1952 +++
 libavutil/hwcontext_vulkan.h|  116 +++
 libavutil/pixdesc.c |4 +
 libavutil/pixfmt.h  |4 +
 libavutil/version.h |2 +-
 16 files changed, 3734 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

-- 
2.16.3

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

[FFmpeg-devel] [PATCH 2/3] lavfi: add common Vulkan filtering code

This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.

It supports both compute and graphic pipelines and manages to abstract
the API to such a level there's no need to call any Vulkan functions
inside the init path of the code. Handling shader descriptors is probably
the bulk of the code, and despite the abstraction, it loses none of the
features for describing shader IO.

In order to produce linkable shaders, it depends on the libshaderc
library (and depends on the latest stable version of it). This allows
for greater performance and flexibility than static built-in shaders
and also eliminates the cumbersome process of interfacing with glslang
to compile GLSL to SPIR-V.

It's based off of the common opencl and provides similar interfaces for
filter pad init and config, with the addition that it also supports
in-place filtering.

Signed-off-by: Rostislav Pehlivanov 
---
 configure|3 +
 libavfilter/vulkan.c | 1101 ++
 libavfilter/vulkan.h |  179 
 3 files changed, 1283 insertions(+)
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h

diff --git a/configure b/configure
index 2213f0452d..3621b5cdeb 100755
--- a/configure
+++ b/configure
@@ -252,6 +252,7 @@ External library support:
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
+  --enable-libshaderc  enable GLSL->SPIRV compilation via libshaderc [no]
   --enable-libshineenable fixed-point MP3 encoding via libshine [no]
   --enable-libsmbclientenable Samba protocol via libsmbclient [no]
   --enable-libsnappy   enable Snappy compression, needed for hap encoding 
[no]
@@ -1702,6 +1703,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librsvg
 librtmp
+libshaderc
 libshine
 libsmbclient
 libsnappy
@@ -6020,6 +6022,7 @@ enabled libpulse  && require_pkg_config libpulse 
libpulse pulse/pulseaud
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
+enabled libshaderc&& require libshaderc shaderc/shaderc.h 
shaderc_compiler_initialize -lshaderc_shared
 enabled libshine  && require_pkg_config libshine shine shine/layer3.h 
shine_encode_buffer
 enabled libsmbclient  && { check_pkg_config libsmbclient smbclient 
libsmbclient.h smbc_init ||
require libsmbclient libsmbclient.h smbc_init 
-lsmbclient; }
diff --git a/libavfilter/vulkan.c b/libavfilter/vulkan.c
new file mode 100644
index 00..c2e02f5d0a
--- /dev/null
+++ b/libavfilter/vulkan.c
@@ -0,0 +1,1101 @@
+/*
+ * Vulkan utilities
+ * Copyright (c) 2018 Rostislav Pehlivanov 
+ *
+ * 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 "formats.h"
+#include "vulkan.h"
+
+int ff_vk_filter_query_formats(AVFilterContext *avctx)
+{
+static const enum AVPixelFormat pixel_formats[] = {
+AV_PIX_FMT_VULKAN, AV_PIX_FMT_NONE,
+};
+AVFilterFormats *pix_fmts = ff_make_format_list(pixel_formats);
+if (!pix_fmts)
+return AVERROR(ENOMEM);
+
+return ff_set_common_formats(avctx, pix_fmts);
+}
+
+static int vulkan_filter_set_device(AVFilterContext *avctx,
+AVBufferRef *device)
+{
+VulkanFilterContext *s = avctx->priv;
+
+av_buffer_unref(&s->device_ref);
+
+s->device_ref = av_buffer_ref(device);
+if (!s->device_ref)
+return AVERROR(ENOMEM);
+
+s->device = (AVHWDeviceContext*)s->device_ref->data;
+s->hwctx  = s->device->hwctx;
+
+return 0;
+}
+
+static int vulkan_filter_set_frames(AVFilterContext *avctx,
+AVBufferRef *fr

[FFmpeg-devel] [PATCH 3/3] lavfi: add a Vulkan avgblur filter

This commit adds an average blur Vulkan filter which functions
exactly the same as avgblur but on Vulkan surfaces.

Currently contains a workaround that will be removed for the actual,
non-RFC version.

It implements a clever way of minimizing texel fetches by storing
all texels needed to filter and entire wavefront's worth of
workgroups in a shared cache, and then averaging over the area needed.

Currently, it lacks the ability to avoid edges of images and will mix
0s around the edges of planes. This will be fixed for the non-RFC
version.

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_avgblur_vulkan.c | 353 
 4 files changed, 356 insertions(+)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c

diff --git a/configure b/configure
index 3621b5cdeb..388e45fed1 100755
--- a/configure
+++ b/configure
@@ -3293,6 +3293,7 @@ ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
 avgblur_opencl_filter_deps="opencl"
+avgblur_vulkan_filter_deps="vulkan libshaderc"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30ad7..f0a47320c8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -141,6 +141,7 @@ OBJS-$(CONFIG_ATADENOISE_FILTER) += 
vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
 OBJS-$(CONFIG_AVGBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
 opencl/avgblur.o
+OBJS-$(CONFIG_AVGBLUR_VULKAN_FILTER) += vf_avgblur_vulkan.o vulkan.o
 OBJS-$(CONFIG_BBOX_FILTER)   += bbox.o vf_bbox.o
 OBJS-$(CONFIG_BENCH_FILTER)  += f_bench.o
 OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += vf_bitplanenoise.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf13409ca..3cbaecd726 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -150,6 +150,7 @@ static void register_all(void)
 REGISTER_FILTER(ATADENOISE, atadenoise, vf);
 REGISTER_FILTER(AVGBLUR,avgblur,vf);
 REGISTER_FILTER(AVGBLUR_OPENCL, avgblur_opencl, vf);
+REGISTER_FILTER(AVGBLUR_VULKAN, avgblur_vulkan, vf);
 REGISTER_FILTER(BBOX,   bbox,   vf);
 REGISTER_FILTER(BENCH,  bench,  vf);
 REGISTER_FILTER(BITPLANENOISE,  bitplanenoise,  vf);
diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
new file mode 100644
index 00..a2c0fddd98
--- /dev/null
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -0,0 +1,353 @@
+/*
+ * 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 "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct AvgBlurVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+AVVkExecContext exec;
+AVVkBuffer shader_buf;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+int size_x;
+int size_y;
+int planes;
+} AvgBlurVulkanContext;
+
+#define RET(x) \
+do { \
+if ((err = (x)) < 0) \
+goto fail; \
+} while (0)
+
+static const char blur_kernel[] = {
+C(0, #define CACHE_SIZE (ivec2(gl_WorkGroupSize) + FILTER_RADIUS*2)
)
+C(0, shared vec4 cache[AREA(CACHE_SIZE)];  
)
+C(0,   
)
+C(0, void blur_kernel(int idx, ivec2 pos)  
)
+C(0, { 
)
+C(1, ivec2 d;  
)
+C(1, const ivec2 s = CACHE_SIZE;   
)
+C(1, const ivec2 w = ivec2(gl_WorkGroupSize);  
)
+C(1, const ivec2 l = ivec2(gl_LocalInvocationID.xy);   
)
+C(1,

[FFmpeg-devel] [PATCH 0/8] HLS/DASH live streaming stability updates

From: Vishwanath Dixit 

This patch series contains minor bug fixes and error handling functionalities
for uninterrupted long duration HLS/DASH live streaming use cases. During live
streaming, it was observed that ingest network fluctuations are common which
were causing application to exit or crash. Network error handling functionality
added in HLS/DASH muxers provides configurability to ignore any non-fatal
network errors, so that the muxer can continue streaming when ingest network
recovers.

Vishwanath Dixit (8):
  avformat/avio: check for null context to avoid uninitialized pointer
access
  avformat/dashenc: check for null context to avoid uninitialized
pointer access
  avformat/dashenc: handling errors for dashenc_io_open and
dashenc_io_close
  avformat/utils: function to check and ignore non fatal network errors
  avformat/dashenc: usage of error handling utility function
  avformat/hlsenc: handling errors in hlsenc_io_open and hlsenc_io_close
  avformat/hlsenc: check for null context to avoid uninitialized pointer
access
  avformat/hlsenc: usage of error handling utility function

 doc/muxers.texi| 17 +
 libavformat/avio.c |  2 +-
 libavformat/dashenc.c  | 34 ++
 libavformat/hlsenc.c   | 23 +++
 libavformat/internal.h | 11 +++
 libavformat/utils.c| 10 ++
 6 files changed, 80 insertions(+), 17 deletions(-)

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

[FFmpeg-devel] [PATCH 3/8] avformat/dashenc: handling errors for dashenc_io_open and dashenc_io_close

From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index c0fe0a5..4c8fc6f 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -143,6 +143,8 @@ static int dashenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 URLContext *http_url_context = ffio_geturlcontext(*pb);
 av_assert0(http_url_context);
 err = ff_http_do_new_request(http_url_context, filename);
+if (err < 0)
+ff_format_io_close(s, pb);
 #endif
 }
 return err;
@@ -152,6 +154,11 @@ static void dashenc_io_close(AVFormatContext *s, 
AVIOContext **pb, char *filenam
 DASHContext *c = s->priv_data;
 int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
 
+if (!*pb) {
+av_log(s, AV_LOG_WARNING, "NULL AVIOContext\n");
+return;
+}
+
 if (!http_base_proto || !c->http_persistent) {
 ff_format_io_close(s, pb);
 #if CONFIG_HTTP_PROTOCOL
@@ -411,7 +418,12 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, AVFormatCont
 snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
 
 set_http_options(&http_opts, c);
-dashenc_io_open(s, &c->m3u8_out, temp_filename_hls, &http_opts);
+ret = dashenc_io_open(s, &c->m3u8_out, temp_filename_hls, &http_opts);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Unable to open %s for writing %d\n",
+   temp_filename_hls, ret);
+return;
+}
 av_dict_free(&http_opts);
 for (i = start_index; i < os->nb_segments; i++) {
 Segment *seg = os->segments[i];
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 4/8] avformat/utils: function to check and ignore non fatal network errors

From: Vishwanath Dixit 

For live HLS/DASH output usecases, currently ffmpeg application exits
for any network error during muxing. However, some of the errors like
EPIPE, ECONNREFUSED and ECONNRESET are non-fatal. They might cause
temporary disruption. However, muxer can recover and continue further
processing.
---
 libavformat/internal.h | 11 +++
 libavformat/utils.c| 10 ++
 2 files changed, 21 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index a020b1b..e56f867 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -731,6 +731,17 @@ int ff_unlock_avformat(void);
  */
 void ff_format_set_url(AVFormatContext *s, char *url);
 
+/**
+ * Handle error.
+ * Ignores network errors EPIPE, ECONNREFUSED and ECONNRESET
+ *
+ * @param s AVFormatContext
+ * @param err error code
+ * @param ignore_nw_err flag to ignore network errors
+ * @return 0 if error is ignored, else err
+ */
+int av_handle_error(AVFormatContext *s, int err, int ignore_nw_err);
+
 #if FF_API_NEXT
 /**
   * Register devices in deprecated format linked list.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f13c820..a942ad0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5658,3 +5658,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
+
+int av_handle_error(AVFormatContext *s, int err, int ignore_nw_err) {
+if (err && ff_is_http_proto(s->url) && ignore_nw_err &&
+(err == AVERROR(EPIPE) || err == AVERROR(ECONNREFUSED) ||
+ err == AVERROR(ECONNRESET))) {
+av_log(s, AV_LOG_WARNING, "Ignored network error %d\n", err);
+return 0;
+}
+return err;
+}
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/8] avformat/dashenc: check for null context to avoid uninitialized pointer access

From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index bdf8c8d..c0fe0a5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -254,7 +254,9 @@ static int flush_dynbuf(OutputStream *os, int *range_length)
 // write out to file
 *range_length = avio_close_dyn_buf(os->ctx->pb, &buffer);
 os->ctx->pb = NULL;
-avio_write(os->out, buffer + os->written_len, *range_length - 
os->written_len);
+if (os->out)
+avio_write(os->out, buffer + os->written_len,
+   *range_length - os->written_len);
 os->written_len = 0;
 av_free(buffer);
 
@@ -1358,9 +1360,11 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 write_styp(os->ctx->pb);
 avio_flush(os->ctx->pb);
 len = avio_get_dyn_buf (os->ctx->pb, &buf);
-avio_write(os->out, buf + os->written_len, len - os->written_len);
+if (os->out) {
+avio_write(os->out, buf + os->written_len, len - os->written_len);
+avio_flush(os->out);
+}
 os->written_len = len;
-avio_flush(os->out);
 }
 
 return ret;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 1/8] avformat/avio: check for null context to avoid uninitialized pointer access

From: Vishwanath Dixit 

---
 libavformat/avio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 63e8287..18e58ae 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -420,7 +420,7 @@ int ffurl_read_complete(URLContext *h, unsigned char *buf, 
int size)
 
 int ffurl_write(URLContext *h, const unsigned char *buf, int size)
 {
-if (!(h->flags & AVIO_FLAG_WRITE))
+if (!h || !(h->flags & AVIO_FLAG_WRITE))
 return AVERROR(EIO);
 /* avoid sending too big packets */
 if (h->max_packet_size && size > h->max_packet_size)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 5/8] avformat/dashenc: usage of error handling utility function

From: Vishwanath Dixit 

---
 doc/muxers.texi   |  8 
 libavformat/dashenc.c | 10 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c26..0d9ecef 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -266,6 +266,14 @@ To map all video (or audio) streams to an AdaptationSet, 
"v" (or "a") can be use
 When no assignment is defined, this defaults to an AdaptationSet for each 
stream.
 @item -timeout @var{timeout}
 Set timeout for socket I/O operations. Applicable only for HTTP output.
+@item -ignore_nw_error @var{ignore_nw_error}
+Enable (1) or disable (0) ignoring the following non-fatal network errors 
during
+muxing. Applicable only for HTTP output.
+@example
+EPIPE- Broken pipe
+ECONNREFUSED - Connection refused
+ECONNRESET   - Connection reset by peer
+@end example
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4c8fc6f..05ebd6b 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -118,6 +118,7 @@ typedef struct DASHContext {
 AVIOContext *m3u8_out;
 int streaming;
 int64_t timeout;
+int ignore_nw_err;
 } DASHContext;
 
 static struct codec_string {
@@ -1321,7 +1322,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 
 if ((ret = dash_flush(s, 0, pkt->stream_index)) < 0)
-return ret;
+return av_handle_error(s, ret, c->ignore_nw_err);
 }
 
 if (!os->packets_written) {
@@ -1339,7 +1340,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 os->max_pts = FFMAX(os->max_pts, pkt->pts + pkt->duration);
 os->packets_written++;
 if ((ret = ff_write_chained(os->ctx, 0, pkt, s, 0)) < 0)
-return ret;
+return av_handle_error(s, ret, c->ignore_nw_err);
 
 if (!os->init_range_length)
 flush_init_segment(s, os);
@@ -1360,7 +1361,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 set_http_options(&opts, c);
 ret = dashenc_io_open(s, &os->out, os->temp_path, &opts);
 if (ret < 0)
-return ret;
+return av_handle_error(s, ret, c->ignore_nw_err);
 av_dict_free(&opts);
 }
 
@@ -1379,7 +1380,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 os->written_len = len;
 }
 
-return ret;
+return av_handle_error(s, ret, c->ignore_nw_err);
 }
 
 static int dash_write_trailer(AVFormatContext *s)
@@ -1458,6 +1459,7 @@ static const AVOption options[] = {
 { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
},
 { "streaming", "Enable/Disable streaming mode of output. Each frame will 
be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
 { "timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
+{ "ignore_nw_error", "Ignores any non-fatal network errors during muxing", 
OFFSET(ignore_nw_err), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 { NULL },
 };
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 8/8] avformat/hlsenc: usage of error handling utility function

From: Vishwanath Dixit 

---
 doc/muxers.texi  |  9 +
 libavformat/hlsenc.c | 16 +---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 0d9ecef..a651a49 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -977,6 +977,15 @@ Use persistent HTTP connections. Applicable only for HTTP 
output.
 @item timeout
 Set timeout for socket I/O operations. Applicable only for HTTP output.
 
+@item -ignore_nw_error @var{ignore_nw_error}
+Enable (1) or disable (0) ignoring the following non-fatal network errors 
during
+muxing. Applicable only for HTTP output.
+@example
+EPIPE- Broken pipe
+ECONNREFUSED - Connection refused
+ECONNRESET   - Connection reset by peer
+@end example
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 334720f..f6de326 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -225,6 +225,7 @@ typedef struct HLSContext {
 AVIOContext *m3u8_out;
 AVIOContext *sub_m3u8_out;
 int64_t timeout;
+int ignore_nw_err;
 } HLSContext;
 
 static int mkdir_p(const char *path) {
@@ -2247,7 +2248,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 ret = flush_dynbuf(vs, &range_length);
 if (ret < 0) {
 av_free(old_filename);
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 vs->size = range_length;
 } else {
@@ -2255,12 +2256,12 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
vs->avf->url);
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 write_styp(vs->out);
 ret = flush_dynbuf(vs, &range_length);
 if (ret < 0) {
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 ff_format_io_close(s, &vs->out);
 }
@@ -2277,7 +2278,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 vs->duration = 0;
 if (ret < 0) {
 av_free(old_filename);
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 }
 
@@ -2308,12 +2309,12 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 av_free(old_filename);
 
 if (ret < 0) {
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 
 if (!vs->fmp4_init_mode || byterange_mode)
 if ((ret = hls_window(s, 0, vs)) < 0) {
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 }
 
@@ -2321,7 +2322,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (oc->pb)
 ret = ff_write_chained(oc, stream_index, pkt, s, 0);
 
-return ret;
+return av_handle_error(s, ret, hls->ignore_nw_err);
 }
 
 static int hls_write_trailer(struct AVFormatContext *s)
@@ -2835,6 +2836,7 @@ static const AVOption options[] = {
 {"master_pl_publish_rate", "Publish master play list every after this many 
segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 = 0}, 
0, UINT_MAX, E},
 {"http_persistent", "Use persistent HTTP connections", 
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
+{ "ignore_nw_error", "Ignores any non-fatal network errors during muxing", 
OFFSET(ignore_nw_err), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 { NULL },
 };
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 6/8] avformat/hlsenc: handling errors in hlsenc_io_open and hlsenc_io_close

From: Vishwanath Dixit 

---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a54b43..1dd196f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -272,6 +272,8 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 URLContext *http_url_context = ffio_geturlcontext(*pb);
 av_assert0(http_url_context);
 err = ff_http_do_new_request(http_url_context, filename);
+if (err < 0)
+ff_format_io_close(s, pb);
 #endif
 }
 return err;
@@ -280,6 +282,8 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
 static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
 HLSContext *hls = s->priv_data;
 int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
+if (!*pb)
+return;
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
 #if CONFIG_HTTP_PROTOCOL
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 7/8] avformat/hlsenc: check for null context to avoid uninitialized pointer access