[FFmpeg-devel] GSoC 2017 MPEG-4 ALS codec project

[George Panagopoulos]

Hi all,

My name is George and I am a PhD student at Stanford. I am interested in 
the MPEG-4 ALS codec project for this year's GSoC program.


Should I go straight into attempting to fix a bug of ALS on the tracker 
as a qualification task and if so do you have a specific one to recommend?


George

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix sound shake when change speed

[Steven Liu]

2017-02-18 10:28 GMT+08:00 Pavel Koshevoy :

> On Fri, Feb 17, 2017 at 1:55 AM, Steven Liu  wrote:
> > commandline:
> > ./ffmpeg -i ~/Downloads/test.wav -af atempo=1.5 -acodec aac -y
> > output.aac
> >
> > play the output.aac, the sound is very shake, terrible.
> > after this patch，
> > play the sound is smooth
> >
> > Signed-off-by: Steven Liu 
> > ---
> >  libavfilter/af_atempo.c | 17 +++--
> >  1 file changed, 7 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> > index a487882..db2f981 100644
> > --- a/libavfilter/af_atempo.c
> > +++ b/libavfilter/af_atempo.c
> > @@ -123,6 +123,8 @@ typedef struct {
> >  // tempo scaling factor:
> >  double tempo;
> >
> > +int drift;
> > +
> >  // a snapshot of previous fragment input and output position values
> >  // captured when the tempo scale factor was set most recently:
> >  int64_t origin[2];
> > @@ -179,6 +181,7 @@ static void yae_clear(ATempoContext *atempo)
> >  atempo->head = 0;
> >  atempo->tail = 0;
> >
> > +atempo->drift = 0;
> >  atempo->nfrag = 0;
> >  atempo->state = YAE_LOAD_FRAGMENT;
> >
> > @@ -696,21 +699,12 @@ static int yae_adjust_position(ATempoContext
> *atempo)
> >  const AudioFragment *prev = yae_prev_frag(atempo);
> >  AudioFragment   *frag = yae_curr_frag(atempo);
> >
> > -const double prev_output_position =
> > -(double)(prev->position[1] - atempo->origin[1] + atempo->window
> / 2);
> > -
> > -const double ideal_output_position =
> > -(double)(prev->position[0] - atempo->origin[0] + atempo->window
> / 2) /
> > -atempo->tempo;
> > -
> > -const int drift = (int)(prev_output_position -
> ideal_output_position);
> > -
> >  const int delta_max  = atempo->window / 2;
> >  const int correction = yae_align(frag,
> >   prev,
> >   atempo->window,
> >   delta_max,
> > - drift,
> > + atempo->drift,
> >   atempo->correlation,
> >   atempo->complex_to_real);
> >
> > @@ -722,6 +716,9 @@ static int yae_adjust_position(ATempoContext
> *atempo)
> >  frag->nsamples = 0;
> >  }
> >
> > +// update cumulative correction drift counter:
> > +atempo->drift += correction;
> > +
> >  return correction;
> >  }
> >
>
>
> Essentially, what you are doing here is reverting
> 0c77cdb491de7a178e4142cb6a24538eec6b4f64
>
> libavfilter/af_atempo: Avoid round-off error build-up, ticket #2484
>
> Current method for constraining fragment position drift suffers from
> round-off error build up.
>
> Instead of calculating cumulative drift as a sum of input fragment
> position corrections, it is more accurate to calculate drift as the
> difference between current fragment position and the ideal position
> specified by the tempo scale factor.
>
>
> Can you open another ticket and attach your sample file to it so I can
> see how terrible it really sounds, and attempt a less destructive
> solution perhaps?  Please attach your output file as well.
>
> Thank you,
> Pavel.




Ok, tickets has been create;
https://trac.ffmpeg.org/ticket/6157
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/sierravmd: Support for Shivers 2 stereo tracks

[Nicolas Roy-Renaud]

Signed-off-by: Nicolas Roy-Renaud 
---
 libavformat/sierravmd.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/libavformat/sierravmd.c b/libavformat/sierravmd.c
index 734a3f2c1e..6960c2868f 100644
--- a/libavformat/sierravmd.c
+++ b/libavformat/sierravmd.c
@@ -142,13 +142,6 @@ static int vmd_read_header(AVFormatContext *s)
 st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
 st->codecpar->codec_id   = AV_CODEC_ID_VMDAUDIO;
 st->codecpar->codec_tag  = 0;  /* no fourcc */
-if (vmd->vmd_header[811] & 0x80) {
-st->codecpar->channels   = 2;
-st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
-} else {
-st->codecpar->channels   = 1;
-st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
-}
 st->codecpar->sample_rate = vmd->sample_rate;
 st->codecpar->block_align = AV_RL16(>vmd_header[806]);
 if (st->codecpar->block_align & 0x8000) {
@@ -157,6 +150,19 @@ static int vmd_read_header(AVFormatContext *s)
 } else {
 st->codecpar->bits_per_coded_sample = 8;
 }
+if (vmd->vmd_header[811] & 0x80) {
+st->codecpar->channels   = 2;
+st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
+} else if (vmd->vmd_header[811] & 0x2) {
+/* Shivers 2 stereo audio */
+/* Frame length is for 1 channel */
+st->codecpar->channels   = 2;
+st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
+st->codecpar->block_align = st->codecpar->block_align << 1;
+} else {
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+}
 st->codecpar->bit_rate = st->codecpar->sample_rate *
 st->codecpar->bits_per_coded_sample * st->codecpar->channels;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] tiff: fix leaking yuv_line

[Michael Niedermayer]

On Fri, Feb 17, 2017 at 02:05:06AM +0100, Andreas Cadhalpun wrote:
> On 16.02.2017 03:15, Michael Niedermayer wrote:
> > On Thu, Feb 16, 2017 at 12:23:28AM +0100, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/tiff.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> >> index efbd9791a5..474ea90015 100644
> >> --- a/libavcodec/tiff.c
> >> +++ b/libavcodec/tiff.c
> >> @@ -1386,6 +1386,7 @@ static av_cold int tiff_end(AVCodecContext *avctx)
> >>  
> >>  ff_lzw_decode_close(>lzw);
> >>  av_freep(>deinvert_buf);
> >> +av_freep(>yuv_line);
> >>  return 0;
> > 
> > I assume we are missing a test in fate for the yuv case
> > adding such test would be usefull
> 
> Indeed, I'll send a patch adding one.
> 
> > yuv_line_size should be reset to 0, not sure its ever needed but it
> > feels more proper
> 
> It's in the close function, so it's unlikely to be needed, but I added
> it now anyway. Updated patch is attached. 
> 
> Best regards,
> Andreas

>  tiff.c |2 ++
>  1 file changed, 2 insertions(+)
> e3de2fb1a9c5034573fe4690bb71231bece1  0001-tiff-fix-leaking-yuv_line.patch
> From c9a5c531c1d0434c989998eab6cb1ac352200695 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Thu, 16 Feb 2017 00:07:24 +0100
> Subject: [PATCH] tiff: fix leaking yuv_line
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/tiff.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index efbd9791a5..650a9d89ef 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -1386,6 +1386,8 @@ static av_cold int tiff_end(AVCodecContext *avctx)
>  
>  ff_lzw_decode_close(>lzw);
>  av_freep(>deinvert_buf);
> +av_freep(>yuv_line);
> +s->yuv_line_size = 0;

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] lavc/libzvbi: base support for multiple levels

[Josh de Kock]

On 18/02/2017 00:51, Marton Balint wrote:
> 
> On Fri, 17 Feb 2017, Josh de Kock wrote:
> 
>> Also add support for level 1.0 explicitly.
>>
> 
> What is the use case for this? Reducing the number of colors?
> 

Pretty much.

> I don't think you can reduce the number of colors based on teletext
> level, because libzvbi uses high (>32) colors for navigation, which is
> also part of level 1.0.
> 
> Also, I don't think you can skip fix_transparency.
> 

Does level 1.0 support transparency?

> And by reducing to level 1.0, you are excluding a lot of users, many
> countries use the extra international characters level 1.5 provides.
> 

1.5 could be done instead.

> If you only want to reduce the number of colors, then I prefer an option
> which makes the code go through every pixel, find the minimum color
> value, and sets nb_colors to that.  Still a hack, but IMHO small enough
> to be acceptable, until subtitle filters are implemented, and you can do
> this with a filter.
> 

Not entirely sure what you mean by this, shouldn't the nb_colors be set
based on the CLUT?

>
> [...]
>

-- 
Josh

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix sound shake when change speed

[Pavel Koshevoy]

On Fri, Feb 17, 2017 at 1:55 AM, Steven Liu  wrote:
> commandline:
> ./ffmpeg -i ~/Downloads/test.wav -af atempo=1.5 -acodec aac -y
> output.aac
>
> play the output.aac, the sound is very shake, terrible.
> after this patch，
> play the sound is smooth
>
> Signed-off-by: Steven Liu 
> ---
>  libavfilter/af_atempo.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index a487882..db2f981 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilter/af_atempo.c
> @@ -123,6 +123,8 @@ typedef struct {
>  // tempo scaling factor:
>  double tempo;
>
> +int drift;
> +
>  // a snapshot of previous fragment input and output position values
>  // captured when the tempo scale factor was set most recently:
>  int64_t origin[2];
> @@ -179,6 +181,7 @@ static void yae_clear(ATempoContext *atempo)
>  atempo->head = 0;
>  atempo->tail = 0;
>
> +atempo->drift = 0;
>  atempo->nfrag = 0;
>  atempo->state = YAE_LOAD_FRAGMENT;
>
> @@ -696,21 +699,12 @@ static int yae_adjust_position(ATempoContext *atempo)
>  const AudioFragment *prev = yae_prev_frag(atempo);
>  AudioFragment   *frag = yae_curr_frag(atempo);
>
> -const double prev_output_position =
> -(double)(prev->position[1] - atempo->origin[1] + atempo->window / 2);
> -
> -const double ideal_output_position =
> -(double)(prev->position[0] - atempo->origin[0] + atempo->window / 2) 
> /
> -atempo->tempo;
> -
> -const int drift = (int)(prev_output_position - ideal_output_position);
> -
>  const int delta_max  = atempo->window / 2;
>  const int correction = yae_align(frag,
>   prev,
>   atempo->window,
>   delta_max,
> - drift,
> + atempo->drift,
>   atempo->correlation,
>   atempo->complex_to_real);
>
> @@ -722,6 +716,9 @@ static int yae_adjust_position(ATempoContext *atempo)
>  frag->nsamples = 0;
>  }
>
> +// update cumulative correction drift counter:
> +atempo->drift += correction;
> +
>  return correction;
>  }
>


Essentially, what you are doing here is reverting
0c77cdb491de7a178e4142cb6a24538eec6b4f64

libavfilter/af_atempo: Avoid round-off error build-up, ticket #2484

Current method for constraining fragment position drift suffers from
round-off error build up.

Instead of calculating cumulative drift as a sum of input fragment
position corrections, it is more accurate to calculate drift as the
difference between current fragment position and the ideal position
specified by the tempo scale factor.


Can you open another ticket and attach your sample file to it so I can
see how terrible it really sounds, and attempt a less destructive
solution perhaps?  Please attach your output file as well.

Thank you,
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: set default http method to PUT when method is null

[Steven Liu]

2017-02-16 8:34 GMT+08:00 Steven Liu :

> When the http method is not set, the method will use POST for ts,
> PUT for m3u8, it is not unify, now set it unify.
> This ticket id: 5315
>
> Reviewed-by: Moritz Barsnick 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 930e94b..c8401ec 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -242,7 +242,7 @@ fail:
>  return -1;
>  }
>
> -static int hls_delete_old_segments(HLSContext *hls) {
> +static int hls_delete_old_segments(AVFormatContext *s, HLSContext *hls) {
>
>  HLSSegment *segment, *previous_segment = NULL;
>  float playlist_duration = 0.0f;
> @@ -251,6 +251,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
>  char *path = NULL;
>  AVDictionary *options = NULL;
>  AVIOContext *out = NULL;
> +const char *proto = NULL;
>
>  segment = hls->segments;
>  while (segment) {
> @@ -300,7 +301,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
>  av_strlcat(path, segment->filename, path_size);
>  }
>
> -if (hls->method) {
> +proto = avio_find_protocol_name(s->filename);
> +if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
>  av_dict_set(, "method", "DELETE", 0);
>  if ((ret = hls->avf->io_open(hls->avf, , path,
> AVIO_FLAG_WRITE, )) < 0)
>  goto fail;
> @@ -321,7 +323,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
>  av_strlcpy(sub_path, dirname, sub_path_size);
>  av_strlcat(sub_path, segment->sub_filename, sub_path_size);
>
> -if (hls->method) {
> +if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
>  av_dict_set(, "method", "DELETE", 0);
>  if ((ret = hls->avf->io_open(hls->avf, , sub_path,
> AVIO_FLAG_WRITE, )) < 0) {
>  av_free(sub_path);
> @@ -576,7 +578,7 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls, double
>  #endif
>  en->next = hls->old_segments;
>  hls->old_segments = en;
> -if ((ret = hls_delete_old_segments(hls)) < 0)
> +if ((ret = hls_delete_old_segments(s, hls)) < 0)
>  return ret;
>  } else
>  av_free(en);
> @@ -663,10 +665,17 @@ static void hls_free_segments(HLSSegment *p)
>  }
>  }
>
> -static void set_http_options(AVDictionary **options, HLSContext *c)
> +static void set_http_options(AVFormatContext *s, AVDictionary **options,
> HLSContext *c)
>  {
> -if (c->method)
> +const char *proto = avio_find_protocol_name(s->filename);
> +int http_base_proto = !av_strcasecmp(proto, "http") ||
> !av_strcasecmp(proto, "https");
> +
> +if (c->method) {
>  av_dict_set(options, "method", c->method, 0);
> +} else if (proto && http_base_proto) {
> +av_log(c, AV_LOG_WARNING, "No HTTP method set, hls muxer
> defaulting to method PUT.\n");
> +av_dict_set(options, "method", "PUT", 0);
> +}
>  }
>
>  static void write_m3u8_head_block(HLSContext *hls, AVIOContext *out, int
> version,
> @@ -710,7 +719,7 @@ static int hls_window(AVFormatContext *s, int last)
>  if (!use_rename && !warned_non_file++)
>  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> this may lead to races and temporary partial files\n");
>
> -set_http_options(, hls);
> +set_http_options(s, , hls);
>  snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp"
> : "%s", s->filename);
>  if ((ret = s->io_open(s, , temp_filename, AVIO_FLAG_WRITE,
> )) < 0)
>  goto fail;
> @@ -947,7 +956,7 @@ static int hls_start(AVFormatContext *s)
>  }
>  c->number++;
>
> -set_http_options(, c);
> +set_http_options(s, , c);
>
>  if (c->flags & HLS_TEMP_FILE) {
>  av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
> @@ -979,7 +988,7 @@ static int hls_start(AVFormatContext *s)
>  if ((err = s->io_open(s, >pb, oc->filename, AVIO_FLAG_WRITE,
> )) < 0)
>  goto fail;
>  if (c->vtt_basename) {
> -set_http_options(, c);
> +set_http_options(s, , c);
>  if ((err = s->io_open(s, _oc->pb, vtt_oc->filename,
> AVIO_FLAG_WRITE, )) < 0)
>  goto fail;
>  }
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


pushed!


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

Re: [FFmpeg-devel] [PATCH] lavc/libzvbi: base support for multiple levels

[Marton Balint]

On Fri, 17 Feb 2017, Josh de Kock wrote:


Also add support for level 1.0 explicitly.



What is the use case for this? Reducing the number of colors?

I don't think you can reduce the number of colors based on teletext level, 
because libzvbi uses high (>32) colors for navigation, which is also part 
of level 1.0.


Also, I don't think you can skip fix_transparency.

And by reducing to level 1.0, you are excluding a lot of users, many 
countries use the extra international characters level 1.5 provides.


If you only want to reduce the number of colors, then I prefer an option 
which makes the code go through every pixel, find the minimum color 
value, and sets nb_colors to that.  Still a hack, but IMHO small enough to 
be acceptable, until subtitle filters are implemented, and you can do this 
with a filter.


Regards,
Marton




Signed-off-by: Josh de Kock 
---
libavcodec/libzvbi-teletextdec.c | 60 
1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index 687b6af..b4316f4 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -76,6 +76,7 @@ typedef struct TeletextContext
vbi_sliced  sliced[MAX_SLICES];

int readorder;
+int wst_level;
} TeletextContext;

static int chop_spaces_utf8(const unsigned char* t, int len)
@@ -248,32 +249,51 @@ static int gen_sub_bitmap(TeletextContext *ctx, 
AVSubtitleRect *sub_rect, vbi_pa
sub_rect->data[0], sub_rect->linesize[0],
0, chop_top, page->columns, page->rows - chop_top,
/*reveal*/ 1, /*flash*/ 1);
-
-fix_transparency(ctx, sub_rect, page, chop_top, resx, resy);
+if (ctx->opacity != -1)
+fix_transparency(ctx, sub_rect, page, chop_top, resx, resy);
sub_rect->x = ctx->x_offset;
sub_rect->y = ctx->y_offset + chop_top * BITMAP_CHAR_HEIGHT;
sub_rect->w = resx;
sub_rect->h = resy;
-sub_rect->nb_colors = ctx->opacity > 0 && ctx->opacity < 255 ? 2 * 
VBI_NB_COLORS : VBI_NB_COLORS;
+sub_rect->type = SUBTITLE_BITMAP;
+
sub_rect->data[1] = av_mallocz(AVPALETTE_SIZE);
if (!sub_rect->data[1]) {
av_freep(_rect->data[0]);
return AVERROR(ENOMEM);
}
-for (ci = 0; ci < VBI_NB_COLORS; ci++) {
-int r, g, b, a;
-
-r = VBI_R(page->color_map[ci]);
-g = VBI_G(page->color_map[ci]);
-b = VBI_B(page->color_map[ci]);
-a = VBI_A(page->color_map[ci]);
-((uint32_t *)sub_rect->data[1])[ci] = RGBA(r, g, b, a);
-((uint32_t *)sub_rect->data[1])[ci + VBI_NB_COLORS] = RGBA(r, g, b, 
ctx->opacity);
-ff_dlog(ctx, "palette %0x\n", ((uint32_t *)sub_rect->data[1])[ci]);
+
+switch (ctx->wst_level) {
+case VBI_WST_LEVEL_1:
+sub_rect->nb_colors = 16;
+for (ci = 0; ci < VBI_NB_COLORS; ci ++)
+((uint32_t *)sub_rect->data[1])[ci] = ci < 16 ? 
RGBA(VBI_R(page->color_map[ci]), VBI_G(page->color_map[ci]),
+ 
VBI_B(page->color_map[ci]), VBI_A(page->color_map[ci])) :
+RGBA(0, 0, 0, 0);
+break;
+case VBI_WST_LEVEL_1p5:
+case VBI_WST_LEVEL_2p5:
+return AVERROR_PATCHWELCOME;
+break;
+case VBI_WST_LEVEL_3p5:
+sub_rect->nb_colors = ctx->opacity > 0 && ctx->opacity < 255 ? 2 * 
VBI_NB_COLORS : VBI_NB_COLORS;
+for (ci = 0; ci < VBI_NB_COLORS; ci++) {
+int r, g, b, a;
+
+r = VBI_R(page->color_map[ci]);
+g = VBI_G(page->color_map[ci]);
+b = VBI_B(page->color_map[ci]);
+a = VBI_A(page->color_map[ci]);
+((uint32_t *)sub_rect->data[1])[ci] = RGBA(r, g, b, a);
+((uint32_t *)sub_rect->data[1])[ci + VBI_NB_COLORS] = RGBA(r, g, b, 
ctx->opacity);
+av_log(ctx, AV_LOG_DEBUG, "palette %08x pallete opacity %08x\n",
+((uint32_t *)sub_rect->data[1])[ci], ((uint32_t 
*)sub_rect->data[1])[ci + VBI_NB_COLORS]);
+}
}
+
((uint32_t *)sub_rect->data[1])[VBI_TRANSPARENT_BLACK] = RGBA(0, 0, 0, 0);
((uint32_t *)sub_rect->data[1])[VBI_TRANSPARENT_BLACK + VBI_NB_COLORS] = 
RGBA(0, 0, 0, 0);
-sub_rect->type = SUBTITLE_BITMAP;
+
return 0;
}

@@ -301,7 +321,7 @@ static void handler(vbi_event *ev, void *user_data)
res = vbi_fetch_vt_page(ctx->vbi, ,
ev->ev.ttx_page.pgno,
ev->ev.ttx_page.subno,
-VBI_WST_LEVEL_3p5, 25, TRUE);
+ctx->wst_level, 25, TRUE);

if (!res)
return;
@@ -549,9 +569,13 @@ static const AVOption options[] = {
{"txt_top", "y offset of generated bitmaps", 
OFFSET(y_offset),   AV_OPT_TYPE_INT,{.i64 = 0}, 

Re: [FFmpeg-devel] [PATCH] lavf/mpegts: document DVB teletext PMT fields

[Marton Balint]

On Fri, 17 Feb 2017, Josh de Kock wrote:


Signed-off-by: Josh de Kock 
---
libavformat/mpegts.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 590abb0..bcf2118 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1718,6 +1718,11 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
case 0x56: /* DVB teletext descriptor */
{
uint8_t *extradata = NULL;
+/* 5 bytes per DVB teletext substream data:
+ * ISO_639_language_code (3 bytes),
+ * teletext_type (5 bits),
+ * teletext_magazine_number (3 bits),
+ * teletext_page_number (1 byte) */


ok.


int language_count = desc_len / 5;

if (desc_len > 0 && desc_len % 5 != 0)
@@ -1745,6 +1750,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
language[i * 4 + 3] = ',';

memcpy(extradata, *pp, 2);
+/* The page number which libzvbi will output is extradata[0] 
& 7 * 256 + extradata[1] */


I am not sure this is useful, because it is irrelevant here, also not 
entirely true, e.g. magazine 0 means 8xx page.




extradata += 2;

*pp += 2;


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

Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

[Michael Niedermayer]

On Thu, Feb 16, 2017 at 08:29:38PM -0800, Thomas Turner wrote:
> The Chen-Shapiro(CS) test was used to test normality for
> Lagged Fibonacci PRNG.
> 
> Normality Hypothesis Test:
> 
> The null hypothesis formally tests if the population
> the sample represents is normally-distributed. For
> CS, when the normality hypothesis is True, the
> distribution of QH will have a mean close to 1.
> 
> Information on CS can be found here:
> 
> http://www.stata-journal.com/sjpdf.html?articlenum=st0264
> http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm
> 
> Signed-off-by: Thomas Turner 
> ---
>  libavutil/tests/lfg.c|  170 ++--
>  tests/fate/libavutil.mak |4 +
>  tests/ref/fate/lfg   | 1007 
> ++
>  3 files changed, 1157 insertions(+), 24 deletions(-)
>  create mode 100644 tests/ref/fate/lfg

works on x86_64 linux but fails on x86_32

--- ffmpeg/tests/ref/fate/lfg  2017-02-17 22:27:05.394644315 +0100
+++ tests/data/fate/lfg 2017-02-17 22:53:34.978677803 +0100
@@ -1004,4 +1004,4 @@
 true stddev  : 53.00
 z-score  : 0.181279
 p-value  : 0.428600
-QH[normality]: 1.015347
+QH[normality]: 
-274309382319023864748424681468621758678576399865310792059887853269490762262076171214661036349063168.00
Test lfg failed. Look at tests/data/fate/lfg.err for details.
make: *** [fate-lfg] Error 1


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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

[FFmpeg-devel] [PATCH] lavc/libzvbi: base support for multiple levels

[Josh de Kock]

Also add support for level 1.0 explicitly.

Signed-off-by: Josh de Kock 
---
 libavcodec/libzvbi-teletextdec.c | 60 
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index 687b6af..b4316f4 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -76,6 +76,7 @@ typedef struct TeletextContext
 vbi_sliced  sliced[MAX_SLICES];
 
 int readorder;
+int wst_level;
 } TeletextContext;
 
 static int chop_spaces_utf8(const unsigned char* t, int len)
@@ -248,32 +249,51 @@ static int gen_sub_bitmap(TeletextContext *ctx, 
AVSubtitleRect *sub_rect, vbi_pa
 sub_rect->data[0], sub_rect->linesize[0],
 0, chop_top, page->columns, page->rows - chop_top,
 /*reveal*/ 1, /*flash*/ 1);
-
-fix_transparency(ctx, sub_rect, page, chop_top, resx, resy);
+if (ctx->opacity != -1)
+fix_transparency(ctx, sub_rect, page, chop_top, resx, resy);
 sub_rect->x = ctx->x_offset;
 sub_rect->y = ctx->y_offset + chop_top * BITMAP_CHAR_HEIGHT;
 sub_rect->w = resx;
 sub_rect->h = resy;
-sub_rect->nb_colors = ctx->opacity > 0 && ctx->opacity < 255 ? 2 * 
VBI_NB_COLORS : VBI_NB_COLORS;
+sub_rect->type = SUBTITLE_BITMAP;
+
 sub_rect->data[1] = av_mallocz(AVPALETTE_SIZE);
 if (!sub_rect->data[1]) {
 av_freep(_rect->data[0]);
 return AVERROR(ENOMEM);
 }
-for (ci = 0; ci < VBI_NB_COLORS; ci++) {
-int r, g, b, a;
-
-r = VBI_R(page->color_map[ci]);
-g = VBI_G(page->color_map[ci]);
-b = VBI_B(page->color_map[ci]);
-a = VBI_A(page->color_map[ci]);
-((uint32_t *)sub_rect->data[1])[ci] = RGBA(r, g, b, a);
-((uint32_t *)sub_rect->data[1])[ci + VBI_NB_COLORS] = RGBA(r, g, b, 
ctx->opacity);
-ff_dlog(ctx, "palette %0x\n", ((uint32_t *)sub_rect->data[1])[ci]);
+
+switch (ctx->wst_level) {
+case VBI_WST_LEVEL_1:
+sub_rect->nb_colors = 16;
+for (ci = 0; ci < VBI_NB_COLORS; ci ++)
+((uint32_t *)sub_rect->data[1])[ci] = ci < 16 ? 
RGBA(VBI_R(page->color_map[ci]), VBI_G(page->color_map[ci]),
+ 
VBI_B(page->color_map[ci]), VBI_A(page->color_map[ci])) :
+RGBA(0, 0, 0, 0);
+break;
+case VBI_WST_LEVEL_1p5:
+case VBI_WST_LEVEL_2p5:
+return AVERROR_PATCHWELCOME;
+break;
+case VBI_WST_LEVEL_3p5:
+sub_rect->nb_colors = ctx->opacity > 0 && ctx->opacity < 255 ? 2 * 
VBI_NB_COLORS : VBI_NB_COLORS;
+for (ci = 0; ci < VBI_NB_COLORS; ci++) {
+int r, g, b, a;
+
+r = VBI_R(page->color_map[ci]);
+g = VBI_G(page->color_map[ci]);
+b = VBI_B(page->color_map[ci]);
+a = VBI_A(page->color_map[ci]);
+((uint32_t *)sub_rect->data[1])[ci] = RGBA(r, g, b, a);
+((uint32_t *)sub_rect->data[1])[ci + VBI_NB_COLORS] = RGBA(r, g, 
b, ctx->opacity);
+av_log(ctx, AV_LOG_DEBUG, "palette %08x pallete opacity %08x\n",
+((uint32_t *)sub_rect->data[1])[ci], ((uint32_t 
*)sub_rect->data[1])[ci + VBI_NB_COLORS]);
+}
 }
+
 ((uint32_t *)sub_rect->data[1])[VBI_TRANSPARENT_BLACK] = RGBA(0, 0, 0, 0);
 ((uint32_t *)sub_rect->data[1])[VBI_TRANSPARENT_BLACK + VBI_NB_COLORS] = 
RGBA(0, 0, 0, 0);
-sub_rect->type = SUBTITLE_BITMAP;
+
 return 0;
 }
 
@@ -301,7 +321,7 @@ static void handler(vbi_event *ev, void *user_data)
 res = vbi_fetch_vt_page(ctx->vbi, ,
 ev->ev.ttx_page.pgno,
 ev->ev.ttx_page.subno,
-VBI_WST_LEVEL_3p5, 25, TRUE);
+ctx->wst_level, 25, TRUE);
 
 if (!res)
 return;
@@ -549,9 +569,13 @@ static const AVOption options[] = {
 {"txt_top", "y offset of generated bitmaps", 
OFFSET(y_offset),   AV_OPT_TYPE_INT,{.i64 = 0},0, 65535,SD},
 {"txt_chop_spaces", "chops leading and trailing spaces from text",   
OFFSET(chop_spaces),AV_OPT_TYPE_INT,{.i64 = 1},0, 1,SD},
 {"txt_duration","display duration of teletext pages in msecs",   
OFFSET(sub_duration),   AV_OPT_TYPE_INT,{.i64 = 3},0, 8640, SD},
-{"txt_transparent", "force transparent background of the teletext",  
OFFSET(transparent_bg), AV_OPT_TYPE_INT,{.i64 = 0},0, 1,SD},
-{"txt_opacity", "set opacity of the transparent background", 
OFFSET(opacity),AV_OPT_TYPE_INT,{.i64 = -1},  -1, 255,  SD},
-{ NULL },
+{"txt_transparent", "force transparent background of the teletext (doesn't 
work with 

[FFmpeg-devel] [PATCH] lavf/mpegts: document DVB teletext PMT fields

[Josh de Kock]

Signed-off-by: Josh de Kock 
---
 libavformat/mpegts.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 590abb0..bcf2118 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1718,6 +1718,11 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 case 0x56: /* DVB teletext descriptor */
 {
 uint8_t *extradata = NULL;
+/* 5 bytes per DVB teletext substream data:
+ * ISO_639_language_code (3 bytes),
+ * teletext_type (5 bits),
+ * teletext_magazine_number (3 bits),
+ * teletext_page_number (1 byte) */
 int language_count = desc_len / 5;
 
 if (desc_len > 0 && desc_len % 5 != 0)
@@ -1745,6 +1750,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 language[i * 4 + 3] = ',';
 
 memcpy(extradata, *pp, 2);
+/* The page number which libzvbi will output is 
extradata[0] & 7 * 256 + extradata[1] */
 extradata += 2;
 
 *pp += 2;
-- 
2.10.1 (Apple Git-78)

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

Re: [FFmpeg-devel] [PATCH] fate: add yuv420p tiff en-/decoding test

[Michael Niedermayer]

On Fri, Feb 17, 2017 at 02:06:26AM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  tests/lavf-regression.sh | 1 +
>  tests/ref/lavf/tiff  | 3 +++
>  2 files changed, 4 insertions(+)

this breaks fate-seek-lavf-tiff

--- ./tests/ref/seek/lavf-tiff  2017-02-09 01:23:54.666561361 +0100
+++ tests/data/fate/seek-lavf-tiff  2017-02-17 22:16:13.174630574 +0100
@@ -1,4 +1,4 @@
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: -1 
size:307124
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: -1 
size:153758
 ret:-EINVALst:-1 flags:0  ts:-1.00
 ret:-EINVALst:-1 flags:1  ts: 1.894167
 ret:-EINVALst: 0 flags:0  ts: 0.80
@@ -6,7 +6,7 @@
 ret:-EINVALst:-1 flags:0  ts: 2.576668
 ret:-EINVALst:-1 flags:1  ts: 1.470835
 ret: 0 st: 0 flags:0  ts: 0.36
-ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos: -1 
size:307150
+ret: 0 st: 0 flags:1 dts: 0.36 pts: 0.36 pos: -1 
size:153764
 ret:-EINVALst: 0 flags:1  ts:-0.76
 ret:-EINVALst:-1 flags:0  ts: 2.153336
 ret:-EINVALst:-1 flags:1  ts: 1.047503
@@ -18,7 +18,7 @@
 ret:-EINVALst: 0 flags:1  ts: 2.40
 ret:-EINVALst:-1 flags:0  ts: 1.306672
 ret: 0 st:-1 flags:1  ts: 0.200839
-ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos: -1 
size:307140
+ret: 0 st: 0 flags:1 dts: 0.20 pts: 0.20 pos: -1 
size:153764
 ret:-EINVALst: 0 flags:0  ts:-0.92
 ret:-EINVALst: 0 flags:1  ts: 2.00
 ret:-EINVALst:-1 flags:0  ts: 0.883340
@@ -26,5 +26,5 @@
 ret:-EINVALst: 0 flags:0  ts: 2.68
 ret:-EINVALst: 0 flags:1  ts: 1.56
 ret: 0 st:-1 flags:0  ts: 0.460008
-ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos: -1 
size:307140
+ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos: -1 
size:153754
 ret:-EINVALst:-1 flags:1  ts:-0.645825
Test seek-lavf-tiff failed. Look at tests/data/fate/seek-lavf-tiff.err for 
details.
make: *** [fate-seek-lavf-tiff] Error 1



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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264, videotoolbox: pass SPS changes into the VT decoder

[Michael Niedermayer]

On Fri, Feb 17, 2017 at 07:02:10AM +0100, wm4 wrote:
> On Thu, 16 Feb 2017 10:29:36 -0800
> Aman Gupta  wrote:
> 
> > From: Aman Gupta 
> > 
> > This fixes playback of h264 streams with SPS changes. One such sample
> > is available at http://tmm1.s3.amazonaws.com/videotoolbox/spschange.ts.
> > It switches mid-stream from level 4.0 to level 3.2.
> > 
> > Previously, playing this sample with the VT hwaccel on iOS would crash.
> > After this patch, it plays back as expected.
> > 
> > On macOS however, feeding in new SPS into an existing decompression
> > session does not always work, so this patch is only a partial fix.
> > ---
> >  libavcodec/h264dec.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index 41c0964..e521c52 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
> > @@ -740,6 +740,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  break;
> >  case H264_NAL_SPS: {
> >  GetBitContext tmp_gb = nal->gb;
> > +if (avctx->hwaccel && avctx->hwaccel->pix_fmt == 
> > AV_PIX_FMT_VIDEOTOOLBOX) {
> > +ret = avctx->hwaccel->decode_slice(avctx,
> > +   nal->data,
> > +   nal->size);
> > +if (ret < 0)
> > +goto end;
> > +}
> >  if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 
> > 0) >= 0)
> >  break;
> >  av_log(h->avctx, AV_LOG_DEBUG,
> 
> A bit ugly but ok IMHO. Maybe it would be better to add a new hwaccel
> callback here, even if it's used by VT only.
> 
> You should probably wait for approval by michaelni.

i dont really have an oppinion on hwaccel, thats not so much my
area
though i find special cases for specific hwaccel a bit ugly, i dont
object to it, just saying i would be in favor of not having special
cases if that is possible

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

[Damien Riegel]

Hi,

On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote:
> >
> > No, do this in libavfilter and do not introduce another useless pseudo
> > codec
> >
> 
> *libavformat, sorry

The advantage of using a pseudo codec just to depack the stream is that
the input and the codec are in separate threads in ffmpeg, so it can
handle a heavier workload.

Is there any way to do the depacking in the RTP handler without that
performance penalty?

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

Re: [FFmpeg-devel] [PATCH]lavc/avpacket: Initialize a variable in error path

[Michael Niedermayer]

On Fri, Feb 17, 2017 at 10:53:26AM +0100, Carl Eugen Hoyos wrote:
> 2017-02-17 1:42 GMT+01:00 Michael Niedermayer :
> > On Fri, Feb 17, 2017 at 12:49:05AM +0100, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch is said to fix undefined behaviour, see ticket #6153,
> >> I cannot reproduce.
> >>
> >> Please comment, Carl Eugen
> >
> > patch is ok
> 
> Patch pushed and backported.
> 

> > the issue described is real but a bit hypothetical and probably has
> > no real world effect
> 
> I don't understand how the issue can be triggered...

a compiler can optimize it out, i would expect it to need -O0
also iam not sure what ubsan exactly considers an issue, depending on
that it may be random if it can be reproduced
didnt try or see the exact ubsan error


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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH] Consistent use of user_agent in hls.c

[Steven Liu]

2017-02-17 23:16 GMT+08:00 Jan Berkel :

>
> > 2017-02-17 12:00 GMT+01:00 Jan Berkel :
> > > This came up while debugging a problem with mpv:
> > > https://github.com/mpv-player/mpv/issues/4155
> > > ---
> > >  libavformat/hls.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > index 3ae3c7cc5c..e1163a7927 100644
> > > --- a/libavformat/hls.c
> > > +++ b/libavformat/hls.c
> > > @@ -670,7 +670,7 @@ static int parse_playlist(HLSContext *c, const
> char *url,
> > >  av_dict_set(, "seekable", "0", 0);
> > >
> > >  // broker prior HTTP options that should be consistent across
> requests
> > > -av_dict_set(, "user-agent", c->user_agent, 0);
> > > +av_dict_set(, "user_agent", c->user_agent, 0);
> >
> > Why is the code in http.c line 1048 not triggered that
> > should use the "user-agent" in case it was defined?.
>
> In my case the user_agent_* properties on HTTPContext never got set.
>
> The problem is that there is some client  code (mpv in this case)
> which uses "user_agent":
>
> https://github.com/mpv-player/mpv/blob/master/stream/stream_lavf.c#L205
>  av_dict_set(dict, "user_agent", opts->useragent, 0);
>
> This value should then be read from hls.c:1626
>
> update_options(>user_agent, "user-agent", u);
>
> I'm new to both mpv and ffmeg development so not exactly sure
> how this should be fixed. The result of the discussion on the mpv
> github issue was that ffmpeg needs to be changed, since user-agent
> is deprecated.
>
>  Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Yes, the user-agent will deprecated.

And I think this can test with ticket #1291
https://trac.ffmpeg.org/ticket/1291
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Consistent use of user_agent in hls.c

[Jan Berkel]

> 2017-02-17 12:00 GMT+01:00 Jan Berkel :
> > This came up while debugging a problem with mpv:
> > https://github.com/mpv-player/mpv/issues/4155
> > ---
> >  libavformat/hls.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 3ae3c7cc5c..e1163a7927 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -670,7 +670,7 @@ static int parse_playlist(HLSContext *c, const char 
> > *url,
> >  av_dict_set(, "seekable", "0", 0);
> >
> >  // broker prior HTTP options that should be consistent across 
> > requests
> > -av_dict_set(, "user-agent", c->user_agent, 0);
> > +av_dict_set(, "user_agent", c->user_agent, 0);
> 
> Why is the code in http.c line 1048 not triggered that
> should use the "user-agent" in case it was defined?. 

In my case the user_agent_* properties on HTTPContext never got set.

The problem is that there is some client  code (mpv in this case) 
which uses "user_agent":

https://github.com/mpv-player/mpv/blob/master/stream/stream_lavf.c#L205
 av_dict_set(dict, "user_agent", opts->useragent, 0);

This value should then be read from hls.c:1626

update_options(>user_agent, "user-agent", u);

I'm new to both mpv and ffmeg development so not exactly sure 
how this should be fixed. The result of the discussion on the mpv
github issue was that ffmpeg needs to be changed, since user-agent
is deprecated. 

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

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support decoding files with broken mediasubtype base guid

[Carl Eugen Hoyos]

2017-02-17 11:04 GMT+01:00 Michael Niedermayer :
> On Thu, Feb 16, 2017 at 02:16:21PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch by Thierry fixes ticket #6100, the broken
>> software writing such files was fixed according to the
>> reporter, no effect on written files.
>>
>> Please comment, Carl Eugen
>
>>  riff.h|2 ++
>>  riffdec.c |2 ++
>>  2 files changed, 4 insertions(+)
>> 9c34902b6f0c10778b90b4d67cca39319e340a27  
>> 0001-lavf-riff-Support-decoding-files-with-broken-mediasu.patch
>> From 3c409a0c633fcee5093f026b0ff786a87d9a7989 Mon Sep 17 00:00:00 2001
>> From: Thierry Foucu 
>> Date: Thu, 16 Feb 2017 14:03:38 +0100
>> Subject: [PATCH] lavf/riff: Support decoding files with broken mediasubtype
>>  base guid.
>>
>> Fixes ticket #6100.
>
> should be ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix sound shake when change speed

[Pavel Koshevoy]

On Feb 17, 2017 01:56, "Steven Liu"  wrote:

commandline:
./ffmpeg -i ~/Downloads/test.wav -af atempo=1.5 -acodec aac -y
output.aac

play the output.aac, the sound is very shake, terrible.
after this patch，
play the sound is smooth

Signed-off-by: Steven Liu 
---
 libavfilter/af_atempo.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index a487882..db2f981 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -123,6 +123,8 @@ typedef struct {
 // tempo scaling factor:
 double tempo;

+int drift;
+
 // a snapshot of previous fragment input and output position values
 // captured when the tempo scale factor was set most recently:
 int64_t origin[2];
@@ -179,6 +181,7 @@ static void yae_clear(ATempoContext *atempo)
 atempo->head = 0;
 atempo->tail = 0;

+atempo->drift = 0;
 atempo->nfrag = 0;
 atempo->state = YAE_LOAD_FRAGMENT;

@@ -696,21 +699,12 @@ static int yae_adjust_position(ATempoContext *atempo)
 const AudioFragment *prev = yae_prev_frag(atempo);
 AudioFragment   *frag = yae_curr_frag(atempo);

-const double prev_output_position =
-(double)(prev->position[1] - atempo->origin[1] + atempo->window /
2);
-
-const double ideal_output_position =
-(double)(prev->position[0] - atempo->origin[0] + atempo->window /
2) /
-atempo->tempo;
-
-const int drift = (int)(prev_output_position - ideal_output_position);
-
 const int delta_max  = atempo->window / 2;
 const int correction = yae_align(frag,
  prev,
  atempo->window,
  delta_max,
- drift,
+ atempo->drift,
  atempo->correlation,
  atempo->complex_to_real);

@@ -722,6 +716,9 @@ static int yae_adjust_position(ATempoContext *atempo)
 frag->nsamples = 0;
 }

+// update cumulative correction drift counter:
+atempo->drift += correction;
+
 return correction;
 }

--
2.10.1.382.ga23ca1b.dirty



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




I'll need some time to verify the problem and confirm that your solution
doesn't introduce lipsync issues.

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

Re: [FFmpeg-devel] [PATCH] rv34dsp: Exclude mmx for x86_64 at build time

[Hendrik Leppkes]

On Fri, Feb 17, 2017 at 11:56 AM, Hugo Beauzée-Luyssen  wrote:
> On Fri, Feb 17, 2017, at 11:50 AM, Carl Eugen Hoyos wrote:
>> 2017-02-17 11:24 GMT+01:00 Hugo Beauzée-Luyssen :
>> > The function is not defined when building for x86_64
>>
>> But it is declared unconditionally.
>>
>> How can the issue you are trying to fix be reproduced?
>> Why is this the only occurrence?
>>
>> Carl Eugen
>
> Hi,
>
> This problem arose while building VLC for Android-x86_64.
> I'm quite convinced there is a similar issue for VP8, but we don't use
> that module in our builds.
> It could be a good idea to conditionally declare the function as well
> indeed.

There is already a condition that will exclude actually using the
function on x86_64, and all our regular builds pass just fine.

Note that FFmpeg currently relies on DCE (Dead Code Eliminiation) to
strip references to unused functions, like in this case, so if your
build system doesn't provide DCE, then FFmpeg build can and will fail.

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/x86: deduplicate PASS8ROWS macro

[James Darnley]

On 2017-02-16 14:11, James Darnley wrote:
> Four patches

Does anyone else have any more comments about this patch series?
Yea or nay from anyone?

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

Re: [FFmpeg-devel] [PATCH v2 0/8] Merge lazy filter initialization in ffmpeg CLI

[Michael Niedermayer]

On Wed, Feb 15, 2017 at 07:57:17PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 15, 2017 at 03:22:33PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 15, 2017 at 10:24:15AM +0100, wm4 wrote:
> > > These patches merge the previously skipped Libav commits, which made
> > > avconv lazily initialize libavfilter graphs. This means the filters
> > > are initialized with the actual output format, instead of whatever
> > > libavformat reports.
> > > 
> > > It's a prerequisite to making hardware decoding support saner, as
> > > hardware decoders will output a different pixfmt than the software
> > > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > > half of the code is removed.
> > > 
> > > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > > changes were required.
> > > 
> > > I plan to push this tomorrow, except if critical errors are found.
> > > 
> > > Anton Khirnov (4):
> > >   ffmpeg: do packet ts rescaling in write_packet()
> > >   ffmpeg: init filtergraphs only after we have a frame on each input
> > >   ffmpeg: move flushing the queued frames to configure_filtergraph()
> > >   ffmpeg: restructure sending EOF to filters
> > > 
> > > Timo Rothenpieler (2):
> > >   ffmpeg_cuvid: adapt for recent filter graph initialization changes
> > >   avcodec/cuvid: update hw_frames_ctx reference after get_format call
> > > 
> > > wm4 (2):
> > >   ffmpeg: make sure packets put into the muxing FIFO are refcounted
> > >   ffmpeg: fix printing of filter input/output names
> > 
> > breaks: (Application provided invalid, non monotonically increasing dts to 
> > muxer in stream 1: 1824120 >= 70020)
> > 
> > ./ffmpeg -skip_frame nokey -ss 20  -i ~/tickets/2024/dvbsubtest.ts -qscale 
> > 2  -scodec dvbsub -t 6   -an file.ts
> 
> heres another issue:
> 
> ./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar 
> 22050 -shortest file.flv
> 
> the output files looses a audio stream

also it seems this patchset does not fix all the previously reported
isssues, tickets/1726/Mono.thd is still broken

and the patchset causes crashes, sadly it seems not with any public
files i could find but heres a backtrace
==11848== Invalid read of size 8
==11848==at 0x4714B1: av_buffersink_get_frame_rate (buffersink.c:193)
==11848==by 0x435ADB: init_output_stream_encode (ffmpeg.c:3207)
==11848==by 0x43641C: init_output_stream (ffmpeg.c:3339)
==11848==by 0x42E4DB: reap_filters (ffmpeg.c:1428)
==11848==by 0x43A9CC: transcode_step (ffmpeg.c:4442)
==11848==by 0x43AAB0: transcode (ffmpeg.c:4486)
==11848==by 0x43B285: main (ffmpeg.c:4691)
==11848==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

If this backtrace is not sufficient i can share the file privatly
with someone who wants to work on fixing this

It also may make sense to test this patchset with a fuzzer, i did not
try that.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] Consistent use of user_agent in hls.c

[Carl Eugen Hoyos]

2017-02-17 12:00 GMT+01:00 Jan Berkel :
> This came up while debugging a problem with mpv:
> https://github.com/mpv-player/mpv/issues/4155
> ---
>  libavformat/hls.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3ae3c7cc5c..e1163a7927 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -670,7 +670,7 @@ static int parse_playlist(HLSContext *c, const char *url,
>  av_dict_set(, "seekable", "0", 0);
>
>  // broker prior HTTP options that should be consistent across 
> requests
> -av_dict_set(, "user-agent", c->user_agent, 0);
> +av_dict_set(, "user_agent", c->user_agent, 0);

Why is the code in http.c line 1048 not triggered that
should use the "user-agent" in case it was defined?

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

Re: [FFmpeg-devel] [PATCH] rv34dsp: Exclude mmx for x86_64 at build time

[Carl Eugen Hoyos]

2017-02-17 11:56 GMT+01:00 Hugo Beauzée-Luyssen :
> On Fri, Feb 17, 2017, at 11:50 AM, Carl Eugen Hoyos wrote:
>> 2017-02-17 11:24 GMT+01:00 Hugo Beauzée-Luyssen :
>> > The function is not defined when building for x86_64
>>
>> But it is declared unconditionally.
>>
>> How can the issue you are trying to fix be reproduced?
>> Why is this the only occurrence?
>>
>> Carl Eugen
>
> Hi,
>
> This problem arose while building VLC for Android-x86_64.

How can we reproduce the issue?

> I'm quite convinced there is a similar issue for VP8, but we don't use
> that module in our builds.

You also disable huffyuv?

> It could be a good idea to conditionally declare the function as well
> indeed.

I would prefer not to add more conditionals to the files and I wonder
why this issue triggers only in this file for you - dead code elimination
is needed in many places when compiling FFmpeg.

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

[FFmpeg-devel] [PATCH] Consistent use of user_agent in hls.c

[Jan Berkel]

This came up while debugging a problem with mpv:
https://github.com/mpv-player/mpv/issues/4155
---
 libavformat/hls.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3ae3c7cc5c..e1163a7927 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -670,7 +670,7 @@ static int parse_playlist(HLSContext *c, const char *url,
 av_dict_set(, "seekable", "0", 0);
 
 // broker prior HTTP options that should be consistent across requests
-av_dict_set(, "user-agent", c->user_agent, 0);
+av_dict_set(, "user_agent", c->user_agent, 0);
 av_dict_set(, "cookies", c->cookies, 0);
 av_dict_set(, "headers", c->headers, 0);
 av_dict_set(, "http_proxy", c->http_proxy, 0);
@@ -1084,7 +1084,7 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg)
 int is_http = 0;
 
 // broker prior HTTP options that should be consistent across requests
-av_dict_set(, "user-agent", c->user_agent, 0);
+av_dict_set(, "user_agent", c->user_agent, 0);
 av_dict_set(, "cookies", c->cookies, 0);
 av_dict_set(, "headers", c->headers, 0);
 av_dict_set(, "http_proxy", c->http_proxy, 0);
@@ -1623,7 +1623,7 @@ static int hls_read_header(AVFormatContext *s)
 
 if (u) {
 // get the previous user agent & set back to null if string size is 
zero
-update_options(>user_agent, "user-agent", u);
+update_options(>user_agent, "user_agent", u);
 
 // get the previous cookies & set back to null if string size is zero
 update_options(>cookies, "cookies", u);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] rv34dsp: Exclude mmx for x86_64 at build time

[Hugo Beauzée-Luyssen]

On Fri, Feb 17, 2017, at 11:50 AM, Carl Eugen Hoyos wrote:
> 2017-02-17 11:24 GMT+01:00 Hugo Beauzée-Luyssen :
> > The function is not defined when building for x86_64
> 
> But it is declared unconditionally.
> 
> How can the issue you are trying to fix be reproduced?
> Why is this the only occurrence?
> 
> Carl Eugen

Hi,

This problem arose while building VLC for Android-x86_64.
I'm quite convinced there is a similar issue for VP8, but we don't use
that module in our builds.
It could be a good idea to conditionally declare the function as well
indeed.

Regards,

-- 
  Hugo Beauzée-Luyssen
  h...@beauzee.fr
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rv34dsp: Exclude mmx for x86_64 at build time

[Carl Eugen Hoyos]

2017-02-17 11:24 GMT+01:00 Hugo Beauzée-Luyssen :
> The function is not defined when building for x86_64

But it is declared unconditionally.

How can the issue you are trying to fix be reproduced?
Why is this the only occurrence?

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

[FFmpeg-devel] [PATCH] rv34dsp: Exclude mmx for x86_64 at build time

[Hugo Beauzée-Luyssen]

The function is not defined when building for x86_64
---
 libavcodec/x86/rv34dsp_init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/x86/rv34dsp_init.c b/libavcodec/x86/rv34dsp_init.c
index 7310122458..116beb31fc 100644
--- a/libavcodec/x86/rv34dsp_init.c
+++ b/libavcodec/x86/rv34dsp_init.c
@@ -35,8 +35,10 @@ av_cold void ff_rv34dsp_init_x86(RV34DSPContext* c)
 {
 int cpu_flags = av_get_cpu_flags();
 
-if (ARCH_X86_32 && EXTERNAL_MMX(cpu_flags))
+#if ARCH_X86_32
+if (EXTERNAL_MMX(cpu_flags))
 c->rv34_idct_dc_add = ff_rv34_idct_dc_add_mmx;
+#endif
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 c->rv34_inv_transform_dc = ff_rv34_idct_dc_noround_mmxext;
 c->rv34_idct_add = ff_rv34_idct_add_mmxext;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] libopus: decode ambisonics with non-diegetic sources

[Michael Niedermayer]

On Fri, Feb 10, 2017 at 06:42:55PM +, Felicia Lim wrote:
> Hi all,
> 
> The attached patch allows libavcodec/opus to decode ambisonics with
> non-diegetic stereo stream in an ogg/opus container, as is being added in
> this IETF standards draft [1].
> 
> Please let me know if there are any concerns.
> 
> Thanks,
> Felicia
> 
> [1] https://tools.ietf.org/html/draft-ietf-codec-ambisonics-01#section-3.1

>  opus.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 118751c3eaf7bf909eda8abe6aa9737fd36286b7  
> 0001-libopus-decode-ambisonics-with-non-diegetic-sources.patch
> From 0798655323605d44d4f75e48fbfc940be0ba7423 Mon Sep 17 00:00:00 2001
> From: Felicia 
> Date: Mon, 6 Feb 2017 15:49:36 -0800
> Subject: [PATCH] libopus: decode ambisonics with non-diegetic sources
> 
> Channel mapping 2 additionally supports a non-diegetic stereo track
> appended to the end of a full-order ambisonics signal, such that the
> total channel count is either
>   (n + 1) ^ 2, or
>   (n + 1) ^ 2 + 2
> where n is the ambisonics order

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH]lavf/riff: Support decoding files with broken mediasubtype base guid

[Michael Niedermayer]

On Thu, Feb 16, 2017 at 02:16:21PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch by Thierry fixes ticket #6100, the broken 
> software writing such files was fixed according to the 
> reporter, no effect on written files.
> 
> Please comment, Carl Eugen

>  riff.h|2 ++
>  riffdec.c |2 ++
>  2 files changed, 4 insertions(+)
> 9c34902b6f0c10778b90b4d67cca39319e340a27  
> 0001-lavf-riff-Support-decoding-files-with-broken-mediasu.patch
> From 3c409a0c633fcee5093f026b0ff786a87d9a7989 Mon Sep 17 00:00:00 2001
> From: Thierry Foucu 
> Date: Thu, 16 Feb 2017 14:03:38 +0100
> Subject: [PATCH] lavf/riff: Support decoding files with broken mediasubtype
>  base guid.
> 
> Fixes ticket #6100.

should be ok

[...]

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH]lavc/avpacket: Initialize a variable in error path

[Carl Eugen Hoyos]

2017-02-17 1:42 GMT+01:00 Michael Niedermayer :
> On Fri, Feb 17, 2017 at 12:49:05AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch is said to fix undefined behaviour, see ticket #6153,
>> I cannot reproduce.
>>
>> Please comment, Carl Eugen
>
> patch is ok

Patch pushed and backported.

> the issue described is real but a bit hypothetical and probably has
> no real world effect

I don't understand how the issue can be triggered...

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

[FFmpeg-devel] [PATCH] avfilter/af_atempo: fix sound shake when change speed

[Steven Liu]

commandline:
./ffmpeg -i ~/Downloads/test.wav -af atempo=1.5 -acodec aac -y
output.aac

play the output.aac, the sound is very shake, terrible.
after this patch，
play the sound is smooth

Signed-off-by: Steven Liu 
---
 libavfilter/af_atempo.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index a487882..db2f981 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -123,6 +123,8 @@ typedef struct {
 // tempo scaling factor:
 double tempo;
 
+int drift;
+
 // a snapshot of previous fragment input and output position values
 // captured when the tempo scale factor was set most recently:
 int64_t origin[2];
@@ -179,6 +181,7 @@ static void yae_clear(ATempoContext *atempo)
 atempo->head = 0;
 atempo->tail = 0;
 
+atempo->drift = 0;
 atempo->nfrag = 0;
 atempo->state = YAE_LOAD_FRAGMENT;
 
@@ -696,21 +699,12 @@ static int yae_adjust_position(ATempoContext *atempo)
 const AudioFragment *prev = yae_prev_frag(atempo);
 AudioFragment   *frag = yae_curr_frag(atempo);
 
-const double prev_output_position =
-(double)(prev->position[1] - atempo->origin[1] + atempo->window / 2);
-
-const double ideal_output_position =
-(double)(prev->position[0] - atempo->origin[0] + atempo->window / 2) /
-atempo->tempo;
-
-const int drift = (int)(prev_output_position - ideal_output_position);
-
 const int delta_max  = atempo->window / 2;
 const int correction = yae_align(frag,
  prev,
  atempo->window,
  delta_max,
- drift,
+ atempo->drift,
  atempo->correlation,
  atempo->complex_to_real);
 
@@ -722,6 +716,9 @@ static int yae_adjust_position(ATempoContext *atempo)
 frag->nsamples = 0;
 }
 
+// update cumulative correction drift counter:
+atempo->drift += correction;
+
 return correction;
 }
 
-- 
2.10.1.382.ga23ca1b.dirty



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