Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: fix directly setting channel layout

[Paul B Mahol]

On 2/21/17, Rostislav Pehlivanov  wrote:
> When setting the channel layout directly using AVBufferSrcParameters
> the channel layout was correctly set however the init function still
> expected the old string format to set the number of channels (when it
> hadn't already been specified).
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavfilter/buffersrc.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> index 77fd174219..37d1992b50 100644
> --- a/libavfilter/buffersrc.c
> +++ b/libavfilter/buffersrc.c
> @@ -341,14 +341,16 @@ static av_cold int init_audio(AVFilterContext *ctx)
>  return AVERROR(EINVAL);
>  }
>
> -if (s->channel_layout_str) {
> +if (s->channel_layout_str || s->channel_layout) {
>  int n;
>
> -s->channel_layout = av_get_channel_layout(s->channel_layout_str);
> -if (!s->channel_layout) {
> -av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
> -   s->channel_layout_str);
> -return AVERROR(EINVAL);
> +if (s->channel_layout_str) {
> +s->channel_layout =
> av_get_channel_layout(s->channel_layout_str);
> +if (!s->channel_layout) {
> +av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
> +   s->channel_layout_str);
> +return AVERROR(EINVAL);
> +}
>  }
>  n = av_get_channel_layout_nb_channels(s->channel_layout);
>  if (s->channels) {
> --
> 2.12.0.rc1.440.g5b76565f74
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH v6] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

> OK I guess. Could be further beautified, but I'm ok with the current state.

This is very good news. We have recently circulated a new version of the patch 
which fixed some indentation issues.
Thanks a lot for the time spent to review our patch.

All the best,

Saverio Blasi, PhD
Senior Research Engineer 
BBC Research & Development
Centre House|56 Wood Lane|London|W12 7SB



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

[FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Paul B Mahol]

Fixes #1849.

Signed-off-by: Paul B Mahol 
---
 libavcodec/amrnbdec.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
index ea299ac..e75df23 100644
--- a/libavcodec/amrnbdec.c
+++ b/libavcodec/amrnbdec.c
@@ -101,6 +101,7 @@ typedef struct AMRContext {
 AMRNBFrameframe; ///< decoded AMR parameters (lsf 
coefficients, codebook indexes, etc)
 uint8_t bad_frame_indicator; ///< bad frame ? 1 : 0
 enum Modecur_frame_mode;
+enum Mode   prev_frame_mode;
 
 int16_t prev_lsf_r[LP_FILTER_ORDER]; ///< residual LSF vector from 
previous subframe
 double  lsp[4][LP_FILTER_ORDER]; ///< lsp vectors from current 
frame
@@ -188,6 +189,7 @@ static av_cold int amrnb_decode_init(AVCodecContext *avctx)
 ff_acelp_vectors_init(>acelpv_ctx);
 ff_celp_filter_init(>celpf_ctx);
 ff_celp_math_init(>celpm_ctx);
+p->prev_frame_mode = NO_DATA;
 
 return 0;
 }
@@ -960,6 +962,7 @@ static int amrnb_decode_frame(AVCodecContext *avctx, void 
*data,
 float spare_vector[AMR_SUBFRAME_SIZE];   // extra stack space to hold 
result from anti-sparseness processing
 float synth_fixed_gain;  // the fixed gain that synthesis 
should use
 const float *synth_fixed_vector; // pointer to the fixed vector 
that synthesis should use
+int consumed;
 
 /* get output buffer */
 frame->nb_samples = AMR_BLOCK_SIZE;
@@ -969,8 +972,14 @@ static int amrnb_decode_frame(AVCodecContext *avctx, void 
*data,
 
 p->cur_frame_mode = unpack_bitstream(p, buf, buf_size);
 if (p->cur_frame_mode == NO_DATA) {
-av_log(avctx, AV_LOG_ERROR, "Corrupt bitstream\n");
-return AVERROR_INVALIDDATA;
+p->cur_frame_mode = p->prev_frame_mode;
+if (p->cur_frame_mode == NO_DATA) {
+av_log(avctx, AV_LOG_ERROR, "Corrupt bitstream\n");
+return AVERROR_INVALIDDATA;
+}
+consumed = 1;
+} else {
+consumed = frame_sizes_nb[p->cur_frame_mode] + 1; // +7 for rounding 
and +8 for TOC
 }
 if (p->cur_frame_mode == MODE_DTX) {
 avpriv_report_missing_feature(avctx, "dtx mode");
@@ -1075,8 +1084,10 @@ static int amrnb_decode_frame(AVCodecContext *avctx, 
void *data,
 
 *got_frame_ptr = 1;
 
+p->prev_frame_mode = p->cur_frame_mode;
+
 /* return the amount of bytes consumed if everything was OK */
-return frame_sizes_nb[p->cur_frame_mode] + 1; // +7 for rounding and +8 
for TOC
+return consumed;
 }
 
 
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Carl Eugen Hoyos]

2017-02-21 12:21 GMT+01:00 Paul B Mahol :
> On 2/21/17, Carl Eugen Hoyos  wrote:
>> 2017-02-21 12:07 GMT+01:00 Paul B Mahol :
>>> On 2/21/17, Carl Eugen Hoyos  wrote:
 2017-02-21 10:59 GMT+01:00 Paul B Mahol :
> Fixes #1849.

 The patch changes output for the sample from ticket #1848, is
 this intended?
>>>
>>> Yes.
>>
>> Reference decoder output sounds very different here - more
>> similar without the patch applied.
>
> Similar is not good enough.

I don't disagree I just thought that worse isn't better.

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

Re: [FFmpeg-devel] [PATCH v6] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

 > Vertical indentation please.

Thanks for this feedback. We have recently circulated a new version of the 
patch (v7) which fixes these indentation issues.

All the best,

Saverio Blasi, PhD
Senior Research Engineer 
BBC Research & Development
Centre House|56 Wood Lane|London|W12 7SB





-
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless 
specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Paul B Mahol]

On 2/21/17, Carl Eugen Hoyos  wrote:
> 2017-02-21 10:59 GMT+01:00 Paul B Mahol :
>> Fixes #1849.
>
> The patch changes output for the sample from ticket #1848, is
> this intended?

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Carl Eugen Hoyos]

2017-02-21 12:07 GMT+01:00 Paul B Mahol :
> On 2/21/17, Carl Eugen Hoyos  wrote:
>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol :
>>> Fixes #1849.
>>
>> The patch changes output for the sample from ticket #1848, is
>> this intended?
>
> Yes.

Reference decoder output sounds very different here - more
similar without the patch applied.

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

Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: fix directly setting channel layout

[wm4]

On Tue, 21 Feb 2017 10:08:45 +0100
Paul B Mahol  wrote:

> On 2/21/17, Rostislav Pehlivanov  wrote:
> > When setting the channel layout directly using AVBufferSrcParameters
> > the channel layout was correctly set however the init function still
> > expected the old string format to set the number of channels (when it
> > hadn't already been specified).
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavfilter/buffersrc.c | 14 --
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> > index 77fd174219..37d1992b50 100644
> > --- a/libavfilter/buffersrc.c
> > +++ b/libavfilter/buffersrc.c
> > @@ -341,14 +341,16 @@ static av_cold int init_audio(AVFilterContext *ctx)
> >  return AVERROR(EINVAL);
> >  }
> >
> > -if (s->channel_layout_str) {
> > +if (s->channel_layout_str || s->channel_layout) {
> >  int n;
> >
> > -s->channel_layout = av_get_channel_layout(s->channel_layout_str);
> > -if (!s->channel_layout) {
> > -av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
> > -   s->channel_layout_str);
> > -return AVERROR(EINVAL);
> > +if (s->channel_layout_str) {
> > +s->channel_layout =
> > av_get_channel_layout(s->channel_layout_str);
> > +if (!s->channel_layout) {
> > +av_log(ctx, AV_LOG_ERROR, "Invalid channel layout %s.\n",
> > +   s->channel_layout_str);
> > +return AVERROR(EINVAL);
> > +}
> >  }
> >  n = av_get_channel_layout_nb_channels(s->channel_layout);
> >  if (s->channels) {
> > --
> > 2.12.0.rc1.440.g5b76565f74
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> lgtm

Should probably go into stable as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] avcodec/utils: do not reallocate packet buffer for AV_CODEC_ID_WRAPPED_AVFRAME

[wm4]

On Mon, 20 Feb 2017 21:11:50 +0100 (CET)
Marton Balint  wrote:

> On Sun, 19 Feb 2017, Hendrik Leppkes wrote:
> 
> > On Sun, Feb 19, 2017 at 2:41 PM, wm4  wrote:  
> >> On Sun, 19 Feb 2017 14:35:42 +0100
> >> Marton Balint  wrote:
> >>  
> >>> Reallocating a wrapped avframe invalidates internal pointers, such as 
> >>> extended
> >>> data.
> >>>
> >>> FFmpeg has another way of passing AVFrames to muxers, but it seems the API
> >>> (av_write_uncoded_frame) is not implemented in the ffmpeg CLI yet.
> >>>
> >>> Signed-off-by: Marton Balint 
> >>> ---
> >>>  libavcodec/utils.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >>> index f4085bf..184821a 100644
> >>> --- a/libavcodec/utils.c
> >>> +++ b/libavcodec/utils.c
> >>> @@ -1820,7 +1820,7 @@ int attribute_align_arg 
> >>> avcodec_encode_audio2(AVCodecContext *avctx,
> >>>  AVFrame *padded_frame = NULL;
> >>>  int ret;
> >>>  AVPacket user_pkt = *avpkt;
> >>> -int needs_realloc = !user_pkt.data;
> >>> +int needs_realloc = !user_pkt.data && avctx->codec_id != 
> >>> AV_CODEC_ID_WRAPPED_AVFRAME;
> >>>
> >>>  *got_packet_ptr = 0;
> >>>
> >>> @@ -1964,7 +1964,7 @@ int attribute_align_arg 
> >>> avcodec_encode_video2(AVCodecContext *avctx,
> >>>  {
> >>>  int ret;
> >>>  AVPacket user_pkt = *avpkt;
> >>> -int needs_realloc = !user_pkt.data;
> >>> +int needs_realloc = !user_pkt.data && avctx->codec_id != 
> >>> AV_CODEC_ID_WRAPPED_AVFRAME;
> >>>
> >>>  *got_packet_ptr = 0;
> >>>  
> >>
> >> I don't understand this logic in the first place. If nothing was
> >> encoded (!ret), and avpkt->data is set (why is it set?), then the
> >> AVPacket.buf is realllocated (why?) to the packet size (why???) - how
> >> does it make sense?  
> >
> > ret = 0 indicates successfull encode, ie. not an error code. What
> > result code did you expect?
> > AFAIK the realloc is performed to shrink over-sized pre-allocated
> > packets down and save memory.
> >  
> 
> So is it OK to apply the patch?

My suggestion doesn't work? (Would probably imply adding the padding in
wrapped_avframe.c.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

On 2/18/17, Nicolas Roy-Renaud  wrote:
> 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
>

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Carl Eugen Hoyos]

2017-02-21 10:59 GMT+01:00 Paul B Mahol :
> Fixes #1849.

The patch changes output for the sample from ticket #1848, is
this intended?

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Paul B Mahol]

On 2/21/17, Carl Eugen Hoyos  wrote:
> 2017-02-21 12:07 GMT+01:00 Paul B Mahol :
>> On 2/21/17, Carl Eugen Hoyos  wrote:
>>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol :
 Fixes #1849.
>>>
>>> The patch changes output for the sample from ticket #1848, is
>>> this intended?
>>
>> Yes.
>
> Reference decoder output sounds very different here - more
> similar without the patch applied.

Similar is not good enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: fix hls_flags temp_file bug

[Steven Liu]

refer to ticket id: #6170

rename file from temp to origin name after complete current segment

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

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e673f59..712a01b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -691,6 +691,17 @@ static void write_m3u8_head_block(HLSContext *hls, 
AVIOContext *out, int version
 av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
 }
 
+static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
+{
+size_t len = strlen(oc->filename);
+char final_filename[sizeof(oc->filename)];
+
+av_strlcpy(final_filename, oc->filename, len);
+final_filename[len-4] = '\0';
+ff_rename(oc->filename, final_filename, s);
+oc->filename[len-4] = '\0';
+}
+
 static int hls_window(AVFormatContext *s, int last)
 {
 HLSContext *hls = s->priv_data;
@@ -833,15 +844,6 @@ static int hls_start(AVFormatContext *s)
 char *filename, iv_string[KEYSIZE*2 + 1];
 int err = 0;
 
-if ((c->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
-size_t len = strlen(oc->filename);
-char final_filename[sizeof(oc->filename)];
-av_strlcpy(final_filename, oc->filename, len);
-final_filename[len-4] = '\0';
-ff_rename(oc->filename, final_filename, s);
-oc->filename[len-4] = '\0';
-}
-
 if (c->flags & HLS_SINGLE_FILE) {
 av_strlcpy(oc->filename, c->basename,
sizeof(oc->filename));
@@ -962,6 +964,7 @@ static int hls_start(AVFormatContext *s)
 av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
 }
 
+
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1325,6 +1328,11 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 new_start_pos = avio_tell(hls->avf->pb);
 hls->size = new_start_pos - hls->start_pos;
+
+if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
+hls_rename_temp_file(s, oc);
+}
+
 ret = hls_append_segment(s, hls, hls->duration, hls->start_pos, 
hls->size);
 hls->start_pos = new_start_pos;
 if (ret < 0) {
@@ -1402,6 +1410,11 @@ static int hls_write_trailer(struct AVFormatContext *s)
 if (oc->pb) {
 hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
 ff_format_io_close(s, >pb);
+
+if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
+hls_rename_temp_file(s, oc);
+}
+
 /* after av_write_trailer, then duration + 1 duration per packet */
 hls_append_segment(s, hls, hls->duration + hls->dpp, hls->start_pos, 
hls->size);
 }
@@ -1411,15 +1424,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
  ff_rename(old_filename, hls->avf->filename, hls);
 }
 
-if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
-size_t len = strlen(oc->filename);
-char final_filename[sizeof(oc->filename)];
-av_strlcpy(final_filename, oc->filename, len);
-final_filename[len-4] = '\0';
-ff_rename(oc->filename, final_filename, s);
-oc->filename[len-4] = '\0';
-}
-
 if (vtt_oc) {
 if (vtt_oc->pb)
 av_write_trailer(vtt_oc);
-- 
2.10.1.382.ga23ca1b.dirty



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

Re: [FFmpeg-devel] [PATCH] hlsenc: don't use %s for strftime on msvc

[Steven Liu]

2017-02-21 15:26 GMT+08:00 Hendrik Leppkes :

> On Tue, Feb 21, 2017 at 8:24 AM, Hendrik Leppkes 
> wrote:
> > MSVC doesn't support the %s time format, and instead of returning an
> > error the invalid parameter handler is invoked which (by default)
> > terminates the process.
> > ---
> >  libavformat/hlsenc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index e673f59710..cf2e3381c4 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -1025,7 +1025,8 @@ static const char * get_default_pattern_localtime_
> fmt(void)
> >  struct tm *p, tmbuf;
> >  p = localtime_r(, );
> >  // no %s support when strftime returned error or left format string
> unchanged
> > -return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ?
> "-%Y%m%d%H%M%S.ts" : "-%s.ts";
> > +// also no %s support on MSVC, which invokes the invalid parameter
> handler on unsupported format strings, instead of returning an error
> > +return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) ||
> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts";
> >  }
> >
> >  static int hls_write_header(AVFormatContext *s)
> > --
> > 2.11.0.windows.1
> >
>
> An alternative would be testing for %s support in configure somehow
> and setting a config variable for that, instead of probing at runtime
> here.
>
> Yes, Agreed!

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


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

[FFmpeg-devel] [PATCH]Makefile: Clean compat subdirectory

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5546 here.

Please comment, Carl Eugen
From 175f3ba7b6034670965e62beef26294efdbc858f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 21 Feb 2017 14:36:15 +0100
Subject: [PATCH] Makefile: Clean compat subdirectory.

Fixes ticket #5546.
---
 Makefile |2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 8aa72fd..ddc7f0c 100644
--- a/Makefile
+++ b/Makefile
@@ -179,6 +179,8 @@ clean::
$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G)
$(RM) $(CLEANSUFFIXES)
$(RM) $(CLEANSUFFIXES:%=tools/%)
+   $(RM) $(CLEANSUFFIXES:%=compat/msvcrt/%)
+   $(RM) $(CLEANSUFFIXES:%=compat/%)
$(RM) -r coverage-html
$(RM) -rf coverage.info coverage.info.in lcov
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Ronald S. Bultje]

Hi,

On Tue, Feb 21, 2017 at 6:22 AM, Carl Eugen Hoyos 
wrote:

> 2017-02-21 12:21 GMT+01:00 Paul B Mahol :
> > On 2/21/17, Carl Eugen Hoyos  wrote:
> >> 2017-02-21 12:07 GMT+01:00 Paul B Mahol :
> >>> On 2/21/17, Carl Eugen Hoyos  wrote:
>  2017-02-21 10:59 GMT+01:00 Paul B Mahol :
> > Fixes #1849.
> 
>  The patch changes output for the sample from ticket #1848, is
>  this intended?
> >>>
> >>> Yes.
> >>
> >> Reference decoder output sounds very different here - more
> >> similar without the patch applied.
> >
> > Similar is not good enough.
>
> I don't disagree I just thought that worse isn't better.


For the rest of us, this isn't helpful. What differences are you seeing?
Can you send a before/after sine wave diagram to showcase relevant
differences? Or something else that isn't just "it's better!" vs. "it's
worse" without any relevant explanation of what you're talking about.

(This is a reply to both, not just Carl.)

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Carl Eugen Hoyos]

2017-02-21 13:47 GMT+01:00 Ronald S. Bultje :

> For the rest of us, this isn't helpful. What differences are you seeing?

I don't see a difference, I hear a difference.
Since this isn't mentioned in the commit message, I was wondering
if the difference is intended.

My English language capabilities are not sufficient to explain "worse"
better but please test yourself and explain.

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

[FFmpeg-devel] enabling sse2

[James Darnley]

 libavcodec/x86/h264_deblock.asm |  1 +
 libavcodec/x86/h264dsp_init.c   | 10 ++
 2 files changed, 11 insertions(+)

Okay, enabling sse2 gets me the results below.  It turns out I should allow sse2
despite some previous testing.  Should I leave avx?  Sometimes it is a few
percentage points faster.

I should really see how this fares on an sse2slow system.

Yorkfield:
deblock_v_chroma:
sse2: 1.02x faster (729±8.6 vs. 714±8.5 decicycles) compared with mmxext
deblock_h_chroma:
sse2: 1.08x faster (1087±8.3 vs. 1010±8.4 decicycles) compared with 
mmxext
deblock_h_chroma422:
sse2: 1.16x faster (1492±12.7 vs. 1291±12.8 decicycles) compared with 
mmxext
deblock_v_chroma_intra:
sse2: 1.00x faster (731±8.2 vs. 731±9.3 decicycles) compared with mmxext
deblock_h_chroma_intra:
sse2: 1.07x faster (1325±9.8 vs. 1238±9.7 decicycles) compared with 
mmxext
deblock_h_chroma422_intra:
sse2: 1.09x faster (1953±19.9 vs. 1795±18.9 decicycles) compared with 
mmxext

Lynnfield (on Windows with no SSD, should probably ignore this result):
deblock_v_chroma:
sse2: 0.98x faster (539±6.3 vs. 550±6.2 decicycles) compared with mmxext
deblock_h_chroma:
sse2: 0.97x faster (730±5.7 vs. 752±5.7 decicycles) compared with mmxext
deblock_h_chroma422:
sse2: 0.99x faster (1090±17.9 vs. 1104±22.1 decicycles) compared with 
mmxext
deblock_v_chroma_intra:
sse2: 0.97x faster (534±8.6 vs. 551±10.0 decicycles) compared with 
mmxext
deblock_h_chroma_intra:
sse2: 0.96x faster (795±9.0 vs. 828±9.7 decicycles) compared with mmxext
deblock_h_chroma422_intra:
sse2: 1.02x faster (1200±18.7 vs. 1180±16.6 decicycles) compared with 
mmxext

Haswell:
deblock_v_chroma:
sse2: 1.15x faster (559±5.8 vs. 484±4.9 decicycles) compared with mmxext
avx:  1.19x faster (559±5.8 vs. 468±4.9 decicycles) compared with mmxext
deblock_h_chroma:
sse2: 1.13x faster (752±4.6 vs. 663±4.6 decicycles) compared with mmxext
avx:  1.14x faster (752±4.6 vs. 659±4.6 decicycles) compared with mmxext
deblock_h_chroma422:
sse2: 1.11x faster (1095±10.4 vs. 984±1.1 decicycles) compared with 
mmxext
avx:  1.14x faster (1095±10.4 vs. 961±0.5 decicycles) compared with 
mmxext
deblock_v_chroma_intra:
sse2: 1.05x faster (491±4.9 vs. 468±5.2 decicycles) compared with mmxext
avx:  1.09x faster (491±4.9 vs. 452±5.3 decicycles) compared with mmxext
deblock_h_chroma_intra:
sse2: 1.16x faster (730±4.2 vs. 629±4.2 decicycles) compared with mmxext
avx:  1.13x faster (730±4.2 vs. 645±4.1 decicycles) compared with mmxext
deblock_h_chroma422_intra:
sse2: 1.17x faster (1128±2.7 vs. 968±3.1 decicycles) compared with 
mmxext
avx:  1.17x faster (1128±2.7 vs. 962±1.4 decicycles) compared with 
mmxext

Skylake:
deblock_v_chroma:
sse2: 1.24x faster (681±4.5 vs. 547±4.9 decicycles) compared with mmxext
avx:  1.27x faster (681±4.5 vs. 534±5.5 decicycles) compared with mmxext
deblock_h_chroma:
sse2: 1.31x faster (876±4.7 vs. 668±5.4 decicycles) compared with mmxext
avx:  1.31x faster (876±4.7 vs. 671±5.4 decicycles) compared with mmxext
deblock_h_chroma422:
sse2: 1.39x faster (1322±3.7 vs. 953±5.3 decicycles) compared with 
mmxext
avx:  1.40x faster (1322±3.7 vs. 946±6.1 decicycles) compared with 
mmxext
deblock_v_chroma_intra:
sse2: 1.12x faster (586±5.6 vs. 522±6.2 decicycles) compared with mmxext
avx:  1.15x faster (586±5.6 vs. 510±6.1 decicycles) compared with mmxext
deblock_h_chroma_intra:
sse2: 1.26x faster (842±4.4 vs. 668±11.7 decicycles) compared with 
mmxext
avx:  1.27x faster (842±4.4 vs. 663±5.1 decicycles) compared with mmxext
deblock_h_chroma422_intra:
sse2: 1.38x faster (1328±3.3 vs. 964±3.2 decicycles) compared with 
mmxext
avx:  1.38x faster (1328±3.3 vs. 960±4.4 decicycles) compared with 
mmxext

Skylake-U:
deblock_v_chroma:
sse2: 1.21x faster (720±7.2 vs. 594±7.9 decicycles) compared with mmxext
avx:  1.25x faster (720±7.2 vs. 575±7.7 decicycles) compared with mmxext
deblock_h_chroma:
sse2: 1.23x faster (941±6.5 vs. 763±8.1 decicycles) compared with mmxext
avx:  1.26x faster (941±6.5 vs. 748±7.5 decicycles) compared with mmxext
deblock_h_chroma422:
sse2: 1.30x faster (1486±17.3 vs. 1145±7.6 decicycles) compared with 
mmxext
avx:  1.38x faster (1486±17.3 vs. 1077±5.4 decicycles) compared with 
mmxext
deblock_v_chroma_intra:
sse2: 1.04x faster (642±7.4 vs. 616±10.5 decicycles) compared with 
mmxext
avx:  1.12x faster (642±7.4 vs. 575±8.9 decicycles) compared with mmxext
deblock_h_chroma_intra:
sse2: 1.18x faster (931±6.8 vs. 789±8.6 decicycles) compared with mmxext
avx:  1.27x faster (931±6.8 vs. 733±10.6 decicycles) 

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

[Thomas Turner]

On 02/17/2017 02:15 PM, Michael Niedermayer wrote:
> 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

What if we force gcc compiler to use IEEE 754 floating-point semantics...Will 
adding the following gcc compilation flags to ffmpeg configuration allow the 
test to pass? : -msse2 -mfpmath=sse
> 
> --- 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...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/h264: enable sse2 chroma deblock/loop filter functions

[James Darnley]

---
 libavcodec/x86/h264_deblock.asm |  1 +
 libavcodec/x86/h264dsp_init.c   | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index 32aa3d3..6702ae9 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -1252,6 +1252,7 @@ RET
 
 %endmacro ; DEBLOCK_CHROMA_XMM
 
+DEBLOCK_CHROMA_XMM sse2
 DEBLOCK_CHROMA_XMM avx
 
 ;-
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 51082e8..0643b37 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -304,6 +304,16 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 #if ARCH_X86_64
 c->h264_h_loop_filter_luma_mbaff = ff_deblock_h_luma_mbaff_8_sse2;
 #endif
+
+c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_8_sse2;
+c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_8_sse2;
+if (chroma_format_idc <= 1) {
+c->h264_h_loop_filter_chroma   = 
ff_deblock_h_chroma_8_sse2;
+c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma_intra_8_sse2;
+} else {
+c->h264_h_loop_filter_chroma   = 
ff_deblock_h_chroma422_8_sse2;
+c->h264_h_loop_filter_chroma_intra = 
ff_deblock_h_chroma422_intra_8_sse2;
+}
 }
 if (EXTERNAL_SSSE3(cpu_flags)) {
 c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_ssse3;
-- 
2.8.3

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

Re: [FFmpeg-devel] [PATCH] doc: drawtext options update

[Lou Logan]

On Tue, Feb 21, 2017, at 07:53 PM, Mulvya V wrote:
> Hi Lou,
> 
> Did you mean the trailing whitespace throughout or only at the end of the
> patch file? In any case, I trimmed those from the attached patch.

I meant the trailing whitespace throughout.

The patch appears to be corrupt: 

  Applying: doc: update drawtext options
  error: corrupt patch at line 25
  Patch failed at 0001 doc: update drawtext options

This can occur if the patch itself is directly edited, but I can fix it
and apply within 24 hours.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: drawtext options update

[Mulvya V]

Hi Lou,

Did you mean the trailing whitespace throughout or only at the end of the
patch file? In any case, I trimmed those from the attached patch.

Regards,
mulvya

On Wed, Feb 22, 2017 at 1:35 AM, Lou Logan  wrote:

> On Tue, 21 Feb 2017 12:26:55 +0530, Mulvya V wrote:
>
> > Hi,
> >
> > Revised patch to include basetime option.
> >
> > Thanks,
> > mulvya
>
> Thanks for the update, but the patch contains trailing whitespaces which
> are to be avoided and are causing the patch to fail to be applied.
>
> Also, please break long lines. 70-80 character width is fine for
> documentation.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0003-doc-update-drawtext-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding

[wm4]

On Wed, 22 Feb 2017 00:14:32 +0100
Marton Balint  wrote:

> This ensures that the wrapped avframe will not get reallocated later, which
> would invalidate internal references such as extended data.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/wrapped_avframe.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
> index 13c8d8a..1436032 100644
> --- a/libavcodec/wrapped_avframe.c
> +++ b/libavcodec/wrapped_avframe.c
> @@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext *avctx, 
> AVPacket *pkt,
>   const AVFrame *frame, int *got_packet)
>  {
>  AVFrame *wrapped = av_frame_clone(frame);
> +uint8_t *data;
> +int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE;
>  
>  if (!wrapped)
>  return AVERROR(ENOMEM);
>  
> -pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped),
> +data = av_mallocz(size);
> +if (!data) {
> +av_frame_free();
> +return AVERROR(ENOMEM);
> +}
> +
> +pkt->buf = av_buffer_create(data, size,
>  wrapped_avframe_release_buffer, NULL,
>  AV_BUFFER_FLAG_READONLY);
>  if (!pkt->buf) {
>  av_frame_free();
> +av_freep();
>  return AVERROR(ENOMEM);
>  }
>  
> -pkt->data = (uint8_t *)wrapped;
> +av_frame_move_ref((AVFrame*)data, wrapped);
> +av_frame_free();

I think this could be done as just

  av_frame_ref((AVFrame*)data, frame);

without calling av_frame_clone(), but it doesn't hurt either. (Changing
it might be an optional, minor improvement.)

> +
> +pkt->data = data;
>  pkt->size = sizeof(*wrapped);
>  
>  pkt->flags |= AV_PKT_FLAG_KEY;

Patch looks good, and I like it better than checking the codec ID.

And now something in general:

wrapped_avframe is a special-case, because it stores a pointer in what
is supposed to be just a raw byte array. So it's always possible that
AVPacket use with it breaks in tricky ways that is fine with normal
codecs. To make wrapped_avframe absolutely safe, we could either
introduce a separate AVBuffer field just for wrapped_avframe, or we
could make side-data refcounted (like with AVFrame), and store the
AVFrame in side-data, which would probably be slightly more robust.
Maybe something to consider on the next ABI bump.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

[wm4]

On Tue, 21 Feb 2017 10:48:37 -0800
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
> API is not invoked until end_frame(), so alloc_frame() returns a dummy
> frame with a 1-byte buffer. When end_frame() is eventually called, the
> dummy buffer is replaced with the actual decoded data from
> VTDecompressionSessionDecodeFrame().
> 
> When the VT decoder fails, the frame returned to the h264 decoder from
> alloc_frame() remains invalid and should not be used. Before
> 9747219958060d8c4f697df62e7f172c2a77e6c7, it was accidentally being
> returned all the way up to the API user. After that commit, the dummy
> frame was unref'd so the user received an error.
> 
> However, since that commit, VT hwaccel failures started causing random
> segfaults in the h264 decoder. This happened more often on iOS where the
> VT implementation is more likely to throw errors on bitstream anomolies.
> A recent report of this issue can be see in
> http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
> 
> The issue here is that the dummy frame is still referenced internally by the
> h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
> frame causes assertions like this one to trip later on during decoding:
> 
>   Assertion h->cur_pic_ptr->f->buf[0] failed at 
> src/libavcodec/h264_slice.c:1340
> 
> With this commit, we leave the dummy 1-byte frame intact, but avoid returning 
> it
> to the user.
> 
> This reverts commit 9747219958060d8c4f697df62e7f172c2a77e6c7.
> ---
>  libavcodec/h264_refs.c| 3 +--
>  libavcodec/h264dec.c  | 7 ++-
>  libavcodec/videotoolbox.c | 2 --
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 97bf588b51..ad296753c3 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -571,8 +571,7 @@ void ff_h264_remove_all_refs(H264Context *h)
>  
>  if (h->short_ref_count && !h->last_pic_for_ec.f->data[0]) {
>  ff_h264_unref_picture(h, >last_pic_for_ec);
> -if (h->short_ref[0]->f->buf[0])
> -ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);
> +ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);

In case others don't realize, this just undoes an earlier VT-specific
hack, and should not affect software decoding in any way.

>  }
>  
>  for (i = 0; i < h->short_ref_count; i++) {
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 41c0964392..a0ae632fed 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame *dst, 
> H264Picture *srcp)
>  AVFrame *src = srcp->f;
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->format);
>  int i;
> -int ret = av_frame_ref(dst, src);
> +int ret;
> +
> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
> +return AVERROR_INVALIDDATA;

Kind of un-nice, but I guess we can live with it for now? And it's
probably much better than trying to make the h264 code deal with an
unset buffer (which was what I tried earlier, but which is imperfect).

I'd probably return AVERROR_EXTERNAL (or maybe we should introduce an
error code that signals that a hw decoder failed).

> +
> +ret = av_frame_ref(dst, src);
>  if (ret < 0)
>  return ret;
>  
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1288aa5087..d931dbd5f9 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -351,8 +351,6 @@ static int videotoolbox_common_end_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
>  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
>  
> -av_buffer_unref(>buf[0]);
> -
>  if (!videotoolbox->session || !vtctx->bitstream)
>  return AVERROR_INVALIDDATA;
>  

In theory, ff_videotoolbox_buffer_create() could still leave buf[0]
unset if av_buffer_create() fails. (Which is rare, but theoretically
possible.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix hls_flags temp_file bug

[Aman Gupta]

On Tue, Feb 21, 2017 at 7:13 AM, Steven Liu  wrote:

> refer to ticket id: #6170
>
> rename file from temp to origin name after complete current segment
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 40 ++--
>  1 file changed, 22 insertions(+), 18 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e673f59..712a01b 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -691,6 +691,17 @@ static void write_m3u8_head_block(HLSContext *hls,
> AVIOContext *out, int version
>  av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n",
> sequence);
>  }
>
> +static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
> +{
> +size_t len = strlen(oc->filename);
> +char final_filename[sizeof(oc->filename)];
> +
> +av_strlcpy(final_filename, oc->filename, len);
> +final_filename[len-4] = '\0';
> +ff_rename(oc->filename, final_filename, s);
> +oc->filename[len-4] = '\0';
> +}
> +
>

Thanks, I should have made a helper function in my original patch.


>  static int hls_window(AVFormatContext *s, int last)
>  {
>  HLSContext *hls = s->priv_data;
> @@ -833,15 +844,6 @@ static int hls_start(AVFormatContext *s)
>  char *filename, iv_string[KEYSIZE*2 + 1];
>  int err = 0;
>
> -if ((c->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
> -size_t len = strlen(oc->filename);
> -char final_filename[sizeof(oc->filename)];
> -av_strlcpy(final_filename, oc->filename, len);
> -final_filename[len-4] = '\0';
> -ff_rename(oc->filename, final_filename, s);
> -oc->filename[len-4] = '\0';
> -}
> -
>  if (c->flags & HLS_SINGLE_FILE) {
>  av_strlcpy(oc->filename, c->basename,
> sizeof(oc->filename));
> @@ -962,6 +964,7 @@ static int hls_start(AVFormatContext *s)
>  av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
>  }
>
> +
>

Unnecessary whitespace?


>  if (c->key_info_file) {
>  if ((err = hls_encryption_start(s)) < 0)
>  goto fail;
> @@ -1325,6 +1328,11 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
>  new_start_pos = avio_tell(hls->avf->pb);
>  hls->size = new_start_pos - hls->start_pos;
> +
> +if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
> +hls_rename_temp_file(s, oc);
> +}
> +
>

I think this will break on windows, because you cannot rename a file while
it is still open.


>  ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
> hls->size);
>  hls->start_pos = new_start_pos;
>  if (ret < 0) {
> @@ -1402,6 +1410,11 @@ static int hls_write_trailer(struct AVFormatContext
> *s)
>  if (oc->pb) {
>  hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
>  ff_format_io_close(s, >pb);
> +
> +if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
> +hls_rename_temp_file(s, oc);
> +}
> +
>  /* after av_write_trailer, then duration + 1 duration per packet
> */
>  hls_append_segment(s, hls, hls->duration + hls->dpp,
> hls->start_pos, hls->size);
>  }
> @@ -1411,15 +1424,6 @@ static int hls_write_trailer(struct AVFormatContext
> *s)
>   ff_rename(old_filename, hls->avf->filename, hls);
>  }
>
> -if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
> -size_t len = strlen(oc->filename);
> -char final_filename[sizeof(oc->filename)];
> -av_strlcpy(final_filename, oc->filename, len);
> -final_filename[len-4] = '\0';
> -ff_rename(oc->filename, final_filename, s);
> -oc->filename[len-4] = '\0';
> -}
> -
>  if (vtt_oc) {
>  if (vtt_oc->pb)
>  av_write_trailer(vtt_oc);
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> 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] doc: drawtext options update

[Lou Logan]

On Tue, 21 Feb 2017 12:26:55 +0530, Mulvya V wrote:

> Hi,
> 
> Revised patch to include basetime option.
> 
> Thanks,
> mulvya

Thanks for the update, but the patch contains trailing whitespaces which
are to be avoided and are causing the patch to fail to be applied.

Also, please break long lines. 70-80 character width is fine for
documentation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding

[Marton Balint]

This ensures that the wrapped avframe will not get reallocated later, which
would invalidate internal references such as extended data.

Signed-off-by: Marton Balint 
---
 libavcodec/wrapped_avframe.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
index 13c8d8a..1436032 100644
--- a/libavcodec/wrapped_avframe.c
+++ b/libavcodec/wrapped_avframe.c
@@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext *avctx, 
AVPacket *pkt,
  const AVFrame *frame, int *got_packet)
 {
 AVFrame *wrapped = av_frame_clone(frame);
+uint8_t *data;
+int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE;
 
 if (!wrapped)
 return AVERROR(ENOMEM);
 
-pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped),
+data = av_mallocz(size);
+if (!data) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+
+pkt->buf = av_buffer_create(data, size,
 wrapped_avframe_release_buffer, NULL,
 AV_BUFFER_FLAG_READONLY);
 if (!pkt->buf) {
 av_frame_free();
+av_freep();
 return AVERROR(ENOMEM);
 }
 
-pkt->data = (uint8_t *)wrapped;
+av_frame_move_ref((AVFrame*)data, wrapped);
+av_frame_free();
+
+pkt->data = data;
 pkt->size = sizeof(*wrapped);
 
 pkt->flags |= AV_PKT_FLAG_KEY;
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH]lavd/opengl: Support BGR48

[Carl Eugen Hoyos]

2017-02-21 2:07 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Will apply if I there are no objections.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Carl Eugen Hoyos]

2017-02-21 17:41 GMT+01:00 Ronald S. Bultje :

>> My English language capabilities are not sufficient to explain "worse"
>> better
>
> But you can decode the file before/after patch as well as with a reference
> decoder and open the decoded files in a wave editor and visualize the
> differences and show which is closer to reference, right?

Sorry for the misunderstanding (you may be faster testing yourself then
understanding my apparently badly written emails):
This isn't about a difference only reproducible with some metric - playing
the file without the patch sounds very similar (but not identical) to the
reference decoder (that produces silent output), with the patch white
noise can be heard.

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

[FFmpeg-devel] [PATCH v2] avformat/hlsenc: fix hls_flags temp_file bug

[Steven Liu]

refer to ticket id: #6170

rename file from temp to origin name after complete current segment

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

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 86a3b05..118aef2 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -691,6 +691,17 @@ static void write_m3u8_head_block(HLSContext *hls, 
AVIOContext *out, int version
 av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
 }
 
+static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
+{
+size_t len = strlen(oc->filename);
+char final_filename[sizeof(oc->filename)];
+
+av_strlcpy(final_filename, oc->filename, len);
+final_filename[len-4] = '\0';
+ff_rename(oc->filename, final_filename, s);
+oc->filename[len-4] = '\0';
+}
+
 static int hls_window(AVFormatContext *s, int last)
 {
 HLSContext *hls = s->priv_data;
@@ -833,15 +844,6 @@ static int hls_start(AVFormatContext *s)
 char *filename, iv_string[KEYSIZE*2 + 1];
 int err = 0;
 
-if ((c->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
-size_t len = strlen(oc->filename);
-char final_filename[sizeof(oc->filename)];
-av_strlcpy(final_filename, oc->filename, len);
-final_filename[len-4] = '\0';
-ff_rename(oc->filename, final_filename, s);
-oc->filename[len-4] = '\0';
-}
-
 if (c->flags & HLS_SINGLE_FILE) {
 av_strlcpy(oc->filename, c->basename,
sizeof(oc->filename));
@@ -1325,6 +1327,17 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 new_start_pos = avio_tell(hls->avf->pb);
 hls->size = new_start_pos - hls->start_pos;
+
+if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
+if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <= 0))
+if (hls->avf->oformat->priv_class && hls->avf->priv_data)
+av_opt_set(hls->avf->priv_data, "mpegts_flags", 
"resend_headers", 0);
+ff_format_io_close(s, >pb);
+if (hls->vtt_avf)
+ff_format_io_close(s, >vtt_avf->pb);
+hls_rename_temp_file(s, oc);
+}
+
 ret = hls_append_segment(s, hls, hls->duration, hls->start_pos, 
hls->size);
 hls->start_pos = new_start_pos;
 if (ret < 0) {
@@ -1336,21 +1349,14 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 hls->duration = 0;
 
 if (hls->flags & HLS_SINGLE_FILE) {
-if (hls->avf->oformat->priv_class && hls->avf->priv_data)
-av_opt_set(hls->avf->priv_data, "mpegts_flags", 
"resend_headers", 0);
 hls->number++;
 } else if (hls->max_seg_size > 0) {
-if (hls->avf->oformat->priv_class && hls->avf->priv_data)
-av_opt_set(hls->avf->priv_data, "mpegts_flags", 
"resend_headers", 0);
 if (hls->start_pos >= hls->max_seg_size) {
 hls->sequence++;
-ff_format_io_close(s, >pb);
 if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE | 
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
  strlen(hls->current_segment_final_filename_fmt)) {
 ff_rename(old_filename, hls->avf->filename, hls);
 }
-if (hls->vtt_avf)
-ff_format_io_close(s, >vtt_avf->pb);
 ret = hls_start(s);
 hls->start_pos = 0;
 /* When split segment by byte, the duration is short than 
hls_time,
@@ -1359,13 +1365,10 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 hls->number++;
 } else {
-ff_format_io_close(s, >pb);
 if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE | 
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
 strlen(hls->current_segment_final_filename_fmt)) {
 ff_rename(old_filename, hls->avf->filename, hls);
 }
-if (hls->vtt_avf)
-ff_format_io_close(s, >vtt_avf->pb);
 
 ret = hls_start(s);
 }
@@ -1402,6 +1405,11 @@ static int hls_write_trailer(struct AVFormatContext *s)
 if (oc->pb) {
 hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
 ff_format_io_close(s, >pb);
+
+if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
+hls_rename_temp_file(s, oc);
+}
+
 /* after av_write_trailer, then duration + 1 duration per packet */
 hls_append_segment(s, hls, hls->duration + hls->dpp, hls->start_pos, 
hls->size);
 }
@@ -1411,15 +1419,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
  ff_rename(old_filename, hls->avf->filename, hls);
 }
 
-if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
-

Re: [FFmpeg-devel] [PATCH v7] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

Hi all,

We have recently circulated this new iteration (see below) of our work towards 
integrating our HEVC Turing codec within FFMpeg. Assuming that there are no 
more requests for changes, we would like to understand what is the timeline for 
integration within the project.

Thanks a lot,

All the best,

Saverio Blasi, PhD
Senior Research Engineer 
BBC Research & Development
Centre House|56 Wood Lane|London|W12 7SB




-Original Message-
From: Saverio Blasi [mailto:saverio.bl...@bbc.co.uk] 
Sent: 13 February 2017 13:37
To: ffmpeg-devel@ffmpeg.org
Cc: Saverio Blasi 
Subject: [PATCH v7] - Added Turing codec interface for ffmpeg

- This patch contains the changes to interface the Turing codec 
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
comments in the review as follows:
  - Added a pkg-config file to list all dependencies required by libturing. 
This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
  - As per suggestions of wm4, two functions (add_option and finalise_options) 
have been created. The former appends new options while the latter sets up the 
argv array of pointers to char* accordingly. add_option re-allocates the buffer 
for options using av_realloc
  - Additionally, both these functions handle the errors in case the memory 
wasn't allocated correctly
  - malloc|free|realloc have been substituted with their corresponding 
av_{malloc|free|realloc} version
  - Check on bit-depth has been removed since the ffmpeg already casts the 
right pix_fmt and bit depth
  - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
  - Changed usage of av_free with av_freep and fixed calls to free arrays
  - Added brackets to all if and for statements
  - Avoid repetition of code to free arrays in case of failure to initialise 
the libturing encoder
  - Some fixes to address the review from wm4 and Mark Thompson received on Wed 
08/02/2017
  - Fixed indentation
---
 LICENSE.md |   1 +
 configure  |   5 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 320 +
 5 files changed, 328 insertions(+)
 create mode 100644 libavcodec/libturing.c

diff --git a/LICENSE.md b/LICENSE.md
index 640633c..86e5371 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -85,6 +85,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index 7154142..a27cb8b 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1562,6 +1563,7 @@ EXTERNAL_LIBRARY_LIST="
 libssh
 libtesseract
 libtheora
+libturing
 libtwolame
 libv4l2
 libvidstab
@@ -2858,6 +2860,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5131,6 +5134,7 @@ die_license_disabled gpl frei0r  die_license_disabled gpl 
libcdio  die_license_disabled gpl librubberband  die_license_disabled gpl 
libsmbclient
+die_license_disabled gpl libturing
 die_license_disabled gpl libvidstab
 die_license_disabled gpl libx264
 die_license_disabled gpl libx265
@@ -5789,6 +5793,7 @@ enabled libssh&& require_pkg_config libssh 
libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h 
turing_version
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; } diff --git a/libavcodec/Makefile 
b/libavcodec/Makefile index 43a6add..de5af1d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -883,6 +883,7 @@ OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 

Re: [FFmpeg-devel] [PATCH] avcodec/h264, videotoolbox: fix use-after-free of AVFrame buffer when VT decoder fails

[Aman Gupta]

On Mon, Feb 13, 2017 at 6:04 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> The videotoolbox hwaccel returns a dummy frame with a 1-byte buffer from
> alloc_frame(). In end_frame(), this buffer is replaced with the actual
> decoded data from VTDecompressionSessionDecodeFrame(). This is hacky,
> but works well enough, as long as the VT decoder returns a valid frame on
> every end_frame() call.
>
> In the case of errors, things get more interesting. Before
> 9747219958060d8c4f697df62e7f172c2a77e6c7, the dummy 1-byte frame would
> accidentally be returned all the way up to the user. After that commit,
> the dummy frame was properly unref'd so the user received an error.
>
> However, since that commit, VT hwaccel failures started causing random
> segfaults in the h264 decoder. This happened more often on iOS where the
> VT implementation is more likely to throw errors on bitstream anomolies.
> A recent report of this issue can be see in
> http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
>
> The root cause here is that between the calls to alloc_frame() and
> end_frame(), the h264 decoder will reference the dummy 1-byte frame in
> its ref_list. When the end_frame() call fails, the dummy frame is
> unref'd but still referenced in the h264 decoder. This eventually causes
> a NULL deference and segmentation fault.
>
> This patch fixes the issue by properly discarding references to the
> dummy frame in the H264Context after the frame has been unref'd.
> ---
>  libavcodec/h264_picture.c |  3 +++
>  libavcodec/h264_refs.c| 20 ++--
>  libavcodec/h264dec.h  |  1 +
>  3 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index f634d2a..702ca12 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -177,6 +177,9 @@ int ff_h264_field_end(H264Context *h, H264SliceContext
> *sl, int in_setup)
>  if (err < 0)
>  av_log(avctx, AV_LOG_ERROR,
> "hardware accelerator failed to decode picture\n");
> +
> +if (err < 0 && avctx->hwaccel->pix_fmt == AV_PIX_FMT_VIDEOTOOLBOX)
> +ff_h264_remove_cur_pic_ref(h);
>

This patch fixed the crash I was seeing pretty often, but now another
assert() can trip (albeit less frequently):

Assertion h->cur_pic_ptr->f->buf[0] failed at
src/libavcodec/h264_slice.c:1340

I will try wm4's suggestion of leaving the dummy 1-byte frame in-place, but
ignoring it when it's time to return a frame to the user.


>  }
>
>  #if FF_API_CAP_VDPAU
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 97bf588..9c77bc7 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -560,6 +560,23 @@ static H264Picture *remove_long(H264Context *h, int
> i, int ref_mask)
>  return pic;
>  }
>
> +void ff_h264_remove_cur_pic_ref(H264Context *h)
> +{
> +int j;
> +
> +if (h->short_ref[0] == h->cur_pic_ptr) {
> +remove_short_at_index(h, 0);
> +}
> +
> +if (h->cur_pic_ptr->long_ref) {
> +for (j = 0; j < FF_ARRAY_ELEMS(h->long_ref); j++) {
> +if (h->long_ref[j] == h->cur_pic_ptr) {
> +remove_long(h, j, 0);
> +}
> +}
> +}
> +}
> +
>  void ff_h264_remove_all_refs(H264Context *h)
>  {
>  int i;
> @@ -571,8 +588,7 @@ void ff_h264_remove_all_refs(H264Context *h)
>
>  if (h->short_ref_count && !h->last_pic_for_ec.f->data[0]) {
>  ff_h264_unref_picture(h, >last_pic_for_ec);
> -if (h->short_ref[0]->f->buf[0])
> -ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);
> +ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);
>  }
>
>  for (i = 0; i < h->short_ref_count; i++) {
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index 5f868b7..063afed 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -569,6 +569,7 @@ int ff_h264_alloc_tables(H264Context *h);
>  int ff_h264_decode_ref_pic_list_reordering(H264SliceContext *sl, void
> *logctx);
>  int ff_h264_build_ref_list(H264Context *h, H264SliceContext *sl);
>  void ff_h264_remove_all_refs(H264Context *h);
> +void ff_h264_remove_cur_pic_ref(H264Context *h);
>
>  /**
>   * Execute the reference picture marking (memory management control
> operations).
> --
> 2.10.1 (Apple Git-78)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/qdrw: add support for decoding rgb555

[Michael Niedermayer]

On Tue, Feb 21, 2017 at 12:22:06PM +0100, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol  | Tue Feb 21 
> 12:17:21 2017 +0100| [f4777d1b89c65166394a459399704fc034a782d6] | committer: 
> Paul B Mahol
> 
> avcodec/qdrw: add support for decoding rgb555
> 
> Signed-off-by: Paul B Mahol 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=f4777d1b89c65166394a459399704fc034a782d6
> ---
> 
>  libavcodec/qdrw.c | 65 
> +--
>  1 file changed, 63 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/qdrw.c b/libavcodec/qdrw.c
> index 65914fa..34b97dc 100644
> --- a/libavcodec/qdrw.c
> +++ b/libavcodec/qdrw.c
> @@ -68,6 +68,57 @@ static int parse_palette(AVCodecContext *avctx, 
> GetByteContext *gbc,
>  return 0;
>  }
>  
> +static int decode_rle16(AVCodecContext *avctx, AVFrame *p, GetByteContext 
> *gbc)
> +{
> +int offset = avctx->width * 2;
> +uint8_t *outdata = p->data[0];
> +int i, j;
> +
> +for (i = 0; i < avctx->height; i++) {
> +int size, left, code, pix;
> +uint16_t *out = (uint16_t *)outdata;
> +int pos = 0;
> +
> +/* size of packed line */
> +size = left = bytestream2_get_be16(gbc);
> +if (bytestream2_get_bytes_left(gbc) < size)
> +return AVERROR_INVALIDDATA;
> +
> +/* decode line */
> +while (left > 0) {
> +code = bytestream2_get_byte(gbc);
> +if (code & 0x80 ) { /* run */
> +pix = bytestream2_get_be16(gbc);
> +for (j = 0; j < 257 - code; j++) {
> +out[pos] = pix;
> +pos++;
> +if (pos >= offset) {
> +pos -= offset;
> +pos++;
> +}
> +if (pos >= offset)
> +return AVERROR_INVALIDDATA;
> +}
> +left  -= 3;
> +} else { /* copy */
> +for (j = 0; j < code + 1; j++) {
> +out[pos] = bytestream2_get_be16(gbc);
> +pos++;
> +if (pos >= offset) {
> +pos -= offset;
> +pos++;
> +}
> +if (pos >= offset)
> +return AVERROR_INVALIDDATA;

out[pos] can write outside the array, the check for offset does not
prevent that as its twice as many pixels as in a line

also as written the check cannot trigger as 2 is the smallest
offset. If this printed an error message this bug could have been
spotted by the absence of such error during testing.

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

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

[Michael Niedermayer]

On Tue, Feb 21, 2017 at 10:11:37AM +0100, Paul B Mahol wrote:
> On 2/18/17, Nicolas Roy-Renaud  wrote:
> > 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
> >
> 
> lgtm

applied

thx

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

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


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

[FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

[Aman Gupta]

From: Aman Gupta 

The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
API is not invoked until end_frame(), so alloc_frame() returns a dummy
frame with a 1-byte buffer. When end_frame() is eventually called, the
dummy buffer is replaced with the actual decoded data from
VTDecompressionSessionDecodeFrame().

When the VT decoder fails, the frame returned to the h264 decoder from
alloc_frame() remains invalid and should not be used. Before
9747219958060d8c4f697df62e7f172c2a77e6c7, it was accidentally being
returned all the way up to the API user. After that commit, the dummy
frame was unref'd so the user received an error.

However, since that commit, VT hwaccel failures started causing random
segfaults in the h264 decoder. This happened more often on iOS where the
VT implementation is more likely to throw errors on bitstream anomolies.
A recent report of this issue can be see in
http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html

The issue here is that the dummy frame is still referenced internally by the
h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
frame causes assertions like this one to trip later on during decoding:

  Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340

With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
to the user.

This reverts commit 9747219958060d8c4f697df62e7f172c2a77e6c7.
---
 libavcodec/h264_refs.c| 3 +--
 libavcodec/h264dec.c  | 7 ++-
 libavcodec/videotoolbox.c | 2 --
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 97bf588b51..ad296753c3 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -571,8 +571,7 @@ void ff_h264_remove_all_refs(H264Context *h)
 
 if (h->short_ref_count && !h->last_pic_for_ec.f->data[0]) {
 ff_h264_unref_picture(h, >last_pic_for_ec);
-if (h->short_ref[0]->f->buf[0])
-ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);
+ff_h264_ref_picture(h, >last_pic_for_ec, h->short_ref[0]);
 }
 
 for (i = 0; i < h->short_ref_count; i++) {
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 41c0964392..a0ae632fed 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame *dst, 
H264Picture *srcp)
 AVFrame *src = srcp->f;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->format);
 int i;
-int ret = av_frame_ref(dst, src);
+int ret;
+
+if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
+return AVERROR_INVALIDDATA;
+
+ret = av_frame_ref(dst, src);
 if (ret < 0)
 return ret;
 
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 1288aa5087..d931dbd5f9 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -351,8 +351,6 @@ static int videotoolbox_common_end_frame(AVCodecContext 
*avctx, AVFrame *frame)
 AVVideotoolboxContext *videotoolbox = avctx->hwaccel_context;
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 
-av_buffer_unref(>buf[0]);
-
 if (!videotoolbox->session || !vtctx->bitstream)
 return AVERROR_INVALIDDATA;
 
-- 
2.11.0 (Apple Git-80)

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

[FFmpeg-devel] [PATCHv3 2/3] mov: Export bounds and padding from spherical metadata

[Vittorio Giovara]

Update the fate test as needed.
---
 libavformat/mov.c | 28 +++-
 tests/ref/fate/mov-spherical-mono |  6 +-
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7b0bbcc..d798336 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4637,6 +4637,8 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 MOVStreamContext *sc;
 int size, version;
 int32_t yaw, pitch, roll;
+size_t l, t, r, b;
+size_t padding = 0;
 uint32_t tag;
 enum AVSphericalProjection projection;
 
@@ -4716,9 +4718,25 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 switch (tag) {
 case MKTAG('c','b','m','p'):
 projection = AV_SPHERICAL_CUBEMAP;
+padding = avio_rb32(pb);
 break;
 case MKTAG('e','q','u','i'):
-projection = AV_SPHERICAL_EQUIRECTANGULAR;
+t = avio_rb32(pb);
+b = avio_rb32(pb);
+l = avio_rb32(pb);
+r = avio_rb32(pb);
+
+if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
+av_log(c->fc, AV_LOG_ERROR,
+   "Invalid bounding rectangle coordinates "
+   "%zu,%zu,%zu,%zu\n", l, t, r, b);
+return AVERROR_INVALIDDATA;
+}
+
+if (l || t || r || b)
+projection = AV_SPHERICAL_EQUIRECTANGULAR_TILE;
+else
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
 break;
 default:
 av_log(c->fc, AV_LOG_ERROR, "Unknown projection type\n");
@@ -4735,6 +4753,14 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 sc->spherical->pitch = pitch;
 sc->spherical->roll  = roll;
 
+sc->spherical->padding = padding;
+
+if (projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE) {
+sc->spherical->bound_left   = l;
+sc->spherical->bound_top= t;
+sc->spherical->bound_right  = r;
+sc->spherical->bound_bottom = b;
+}
 return 0;
 }
 
diff --git a/tests/ref/fate/mov-spherical-mono 
b/tests/ref/fate/mov-spherical-mono
index 8048aff..a70d879 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -8,7 +8,11 @@ inverted=0
 [SIDE_DATA]
 side_data_type=Spherical Mapping
 side_data_size=56
-projection=equirectangular
+projection=tiled equirectangular
+bound_left=148
+bound_top=73
+bound_right=147
+bound_bottom=72
 yaw=45
 pitch=30
 roll=15
-- 
2.10.0

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

[FFmpeg-devel] [PATCHv3 1/3] spherical: Add tiled equirectangular type and projection-specific properties

[Vittorio Giovara]

Signed-off-by: Vittorio Giovara 
---
This leaves bounds unchanged, simplifying future muxing code.
Add a convenience function where human-readable values are needed.
Update mov and mkv in subsequent patches.
Vittorio

 doc/APIchanges |  5 +++
 ffprobe.c  | 19 +++--
 libavformat/dump.c | 15 ++-
 libavutil/spherical.c  | 18 +
 libavutil/spherical.h  | 74 ++
 libavutil/version.h|  2 +-
 tests/ref/fate/matroska-spherical-mono |  2 +-
 tests/ref/fate/mov-spherical-mono  |  2 +-
 8 files changed, 128 insertions(+), 9 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index d739895..569d457 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-02-10 - xxx - lavu 55.48.100 / 55.33.0 - spherical.h
+  Add AV_SPHERICAL_EQUIRECTANGULAR_TILE, av_spherical_tile_bounds(),
+  and projection-specific properties (bound_left, bound_top, bound_right,
+  bound_bottom, padding) to AVSphericalMapping.
+
 2017-02-13 - xxx - lavc 57.80.100 - avcodec.h
   Add AVCodecContext.hw_device_ctx.
 
diff --git a/ffprobe.c b/ffprobe.c
index 046f080..c85c3a1 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1762,6 +1762,7 @@ static inline int show_tags(WriterContext *w, 
AVDictionary *tags, int section_id
 }
 
 static void print_pkt_side_data(WriterContext *w,
+AVCodecParameters *par,
 const AVPacketSideData *side_data,
 int nb_side_data,
 SectionID id_data_list,
@@ -1788,9 +1789,19 @@ static void print_pkt_side_data(WriterContext *w,
 const AVSphericalMapping *spherical = (AVSphericalMapping 
*)sd->data;
 if (spherical->projection == AV_SPHERICAL_EQUIRECTANGULAR)
 print_str("projection", "equirectangular");
-else if (spherical->projection == AV_SPHERICAL_CUBEMAP)
+else if (spherical->projection == AV_SPHERICAL_CUBEMAP) {
 print_str("projection", "cubemap");
-else
+print_int("padding", spherical->padding);
+} else if (spherical->projection == 
AV_SPHERICAL_EQUIRECTANGULAR_TILE) {
+size_t l, t, r, b;
+av_spherical_tile_bounds(spherical, par->width, par->height,
+ , , , );
+print_str("projection", "tiled equirectangular");
+print_int("bound_left", l);
+print_int("bound_top", t);
+print_int("bound_right", r);
+print_int("bound_bottom", b);
+} else
 print_str("projection", "unknown");
 
 print_int("yaw", (double) spherical->yaw / (1 << 16));
@@ -1843,7 +1854,7 @@ static void show_packet(WriterContext *w, InputFile 
*ifile, AVPacket *pkt, int p
 av_dict_free();
 }
 
-print_pkt_side_data(w, pkt->side_data, pkt->side_data_elems,
+print_pkt_side_data(w, st->codecpar, pkt->side_data, 
pkt->side_data_elems,
 SECTION_ID_PACKET_SIDE_DATA_LIST,
 SECTION_ID_PACKET_SIDE_DATA);
 }
@@ -2404,7 +2415,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 ret = show_tags(w, stream->metadata, in_program ? 
SECTION_ID_PROGRAM_STREAM_TAGS : SECTION_ID_STREAM_TAGS);
 
 if (stream->nb_side_data) {
-print_pkt_side_data(w, stream->side_data, stream->nb_side_data,
+print_pkt_side_data(w, stream->codecpar, stream->side_data, 
stream->nb_side_data,
 SECTION_ID_STREAM_SIDE_DATA_LIST,
 SECTION_ID_STREAM_SIDE_DATA);
 }
diff --git a/libavformat/dump.c b/libavformat/dump.c
index d9aa3af..505d572 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -343,7 +343,7 @@ static void dump_mastering_display_metadata(void *ctx, 
AVPacketSideData* sd) {
av_q2d(metadata->min_luminance), av_q2d(metadata->max_luminance));
 }
 
-static void dump_spherical(void *ctx, AVPacketSideData *sd)
+static void dump_spherical(void *ctx, AVCodecParameters *par, AVPacketSideData 
*sd)
 {
 AVSphericalMapping *spherical = (AVSphericalMapping *)sd->data;
 double yaw, pitch, roll;
@@ -357,6 +357,8 @@ static void dump_spherical(void *ctx, AVPacketSideData *sd)
 av_log(ctx, AV_LOG_INFO, "equirectangular ");
 else if (spherical->projection == AV_SPHERICAL_CUBEMAP)
 av_log(ctx, AV_LOG_INFO, "cubemap ");
+else if (spherical->projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE)
+av_log(ctx, AV_LOG_INFO, "tiled equirectangular ");
 else {
 av_log(ctx, AV_LOG_WARNING, "unknown");
 return;
@@ -366,6 +368,15 

Re: [FFmpeg-devel] [PATCHv2] avcodec/utils: do not reallocate packet buffer for AV_CODEC_ID_WRAPPED_AVFRAME

[Marton Balint]

On Tue, 21 Feb 2017, wm4 wrote:


On Mon, 20 Feb 2017 21:11:50 +0100 (CET)
Marton Balint  wrote:


On Sun, 19 Feb 2017, Hendrik Leppkes wrote:

> On Sun, Feb 19, 2017 at 2:41 PM, wm4  wrote: 
>> On Sun, 19 Feb 2017 14:35:42 +0100

>> Marton Balint  wrote:
>> 
>>> Reallocating a wrapped avframe invalidates internal pointers, such as extended

>>> data.
>>>
>>> FFmpeg has another way of passing AVFrames to muxers, but it seems the API
>>> (av_write_uncoded_frame) is not implemented in the ffmpeg CLI yet.
>>>
>>> Signed-off-by: Marton Balint 
>>> ---
>>>  libavcodec/utils.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>


[...]



So is it OK to apply the patch?


My suggestion doesn't work? (Would probably imply adding the padding in
wrapped_avframe.c.)


Yes it does work, if I set the buffer size to sizeof(AVFrame) + 
AV_INPUT_BUFFER_PADDING_SIZE. av_buffer_realloc already checks the size of 
the buffer, and avoids the reallocation there is no size change.


In wrapped_avframe.c I can either lie about the buffer size in 
av_create_buffer and set it bigger than the actual allocated memory for 
the data (AVFrame). Or I can mallocz a buffer with the proper size with 
padding, and move a frame ref to that buffer. Maybe that is better.


I will post an updated patch.

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

[FFmpeg-devel] [PATCHv3 3/3] mkv: Export bounds and padding from spherical metadata

[Vittorio Giovara]

---
 libavformat/matroskadec.c  | 64 --
 tests/ref/fate/matroska-spherical-mono |  6 +++-
 2 files changed, 66 insertions(+), 4 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 7223e94..0a02237 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1913,16 +1913,65 @@ static int mkv_parse_video_projection(AVStream *st, 
const MatroskaTrack *track)
 AVSphericalMapping *spherical;
 enum AVSphericalProjection projection;
 size_t spherical_size;
+size_t l, t, r, b;
+size_t padding = 0;
 int ret;
+GetByteContext gb;
+
+bytestream2_init(, track->video.projection.private.data,
+ track->video.projection.private.size);
+
+if (bytestream2_get_byte() != 0) {
+av_log(NULL, AV_LOG_WARNING, "Unknown spherical metadata\n");
+return 0;
+}
+
+bytestream2_skip(, 3); // flags
 
 switch (track->video.projection.type) {
 case MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR:
-projection = AV_SPHERICAL_EQUIRECTANGULAR;
+if (track->video.projection.private.size == 0)
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+else if (track->video.projection.private.size == 20) {
+t = bytestream2_get_be32();
+b = bytestream2_get_be32();
+l = bytestream2_get_be32();
+r = bytestream2_get_be32();
+
+if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
+av_log(NULL, AV_LOG_ERROR,
+   "Invalid bounding rectangle coordinates "
+   "%zu,%zu,%zu,%zu\n", l, t, r, b);
+return AVERROR_INVALIDDATA;
+}
+
+if (l || t || r || b)
+projection = AV_SPHERICAL_EQUIRECTANGULAR_TILE;
+else
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+} else {
+av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n");
+return AVERROR_INVALIDDATA;
+}
 break;
 case MATROSKA_VIDEO_PROJECTION_TYPE_CUBEMAP:
-if (track->video.projection.private.size < 4)
+if (track->video.projection.private.size < 4) {
+av_log(NULL, AV_LOG_ERROR, "Missing projection private 
properties\n");
+return AVERROR_INVALIDDATA;
+} else if (track->video.projection.private.size == 12) {
+uint32_t layout = bytestream2_get_be32();
+if (layout == 0) {
+projection = AV_SPHERICAL_CUBEMAP;
+} else {
+av_log(NULL, AV_LOG_WARNING,
+   "Unknown spherical cubemap layout %"PRIu32"\n", layout);
+return 0;
+}
+padding = bytestream2_get_be32();
+} else {
+av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n");
 return AVERROR_INVALIDDATA;
-projection = AV_SPHERICAL_CUBEMAP;
+}
 break;
 default:
 return 0;
@@ -1937,6 +1986,15 @@ static int mkv_parse_video_projection(AVStream *st, 
const MatroskaTrack *track)
 spherical->pitch = (int32_t)(track->video.projection.pitch * (1 << 16));
 spherical->roll  = (int32_t)(track->video.projection.roll  * (1 << 16));
 
+spherical->padding = padding;
+
+if (spherical->projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE) {
+spherical->bound_left   = l;
+spherical->bound_top= t;
+spherical->bound_right  = r;
+spherical->bound_bottom = b;
+}
+
 ret = av_stream_add_side_data(st, AV_PKT_DATA_SPHERICAL, (uint8_t 
*)spherical,
   spherical_size);
 if (ret < 0) {
diff --git a/tests/ref/fate/matroska-spherical-mono 
b/tests/ref/fate/matroska-spherical-mono
index 8048aff..a70d879 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -8,7 +8,11 @@ inverted=0
 [SIDE_DATA]
 side_data_type=Spherical Mapping
 side_data_size=56
-projection=equirectangular
+projection=tiled equirectangular
+bound_left=148
+bound_top=73
+bound_right=147
+bound_bottom=72
 yaw=45
 pitch=30
 roll=15
-- 
2.10.0

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

[Ronald S. Bultje]

Hi,

On Tue, Feb 21, 2017 at 1:48 PM, Aman Gupta  wrote:

> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 41c0964392..a0ae632fed 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame *dst,
> H264Picture *srcp)
>  AVFrame *src = srcp->f;
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->format);
>  int i;
> -int ret = av_frame_ref(dst, src);
> +int ret;
> +
> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
> +return AVERROR_INVALIDDATA;
> +
> +ret = av_frame_ref(dst, src);
>  if (ret < 0)
>  return ret;


This is a total hack :) Is there a way to hide this into VT-specific code
outside h264*.[ch]?

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

Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties

[Vittorio Giovara]

On Thu, Feb 16, 2017 at 3:41 PM, Aaron Colwell  wrote:
> After sleeping on this, I think what you have will be fine. Resizing a
> cubemap w/ padding is just going to have to be handled in a special way
> because fractional pixel padding isn't going to work right on the GPU. You
> really only want to waste a few pixels on padding, not a constant fraction
> of the whole frame. Given that we have to handle cubemaps in a special way
> for resizing, then my thoughts about resizing equirect aren't really a big
> deal. I don't expect any spec changes will be needed for this.

Hey Aaron, thanks for the feedback, I actually had some time to think
about this (yay holidays), and I'm starting to agree with you: leaving
the values for the bounds unchanged is probably better. I think I'll
just add a convenience function to simplify conversion, and I'll send
an updated set soon.
Cheers
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

[Aman Gupta]

On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Tue, Feb 21, 2017 at 1:48 PM, Aman Gupta  wrote:
>
>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>> index 41c0964392..a0ae632fed 100644
>> --- a/libavcodec/h264dec.c
>> +++ b/libavcodec/h264dec.c
>> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame
>> *dst, H264Picture *srcp)
>>  AVFrame *src = srcp->f;
>>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->format);
>>  int i;
>> -int ret = av_frame_ref(dst, src);
>> +int ret;
>> +
>> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
>> +return AVERROR_INVALIDDATA;
>> +
>> +ret = av_frame_ref(dst, src);
>>  if (ret < 0)
>>  return ret;
>
>
> This is a total hack :) Is there a way to hide this into VT-specific code
> outside h264*.[ch]?
>

The way the VT hwaccel works is a total hack, as noted in my commit message.

AFAICT, given how the hwaccel APIs work, there's no way to do this outside
the h264 decoder. But I'm happy to try fixing this a different way if
anyone has a suggestion.


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

Re: [FFmpeg-devel] [PATCH v2 2/8] ffmpeg: do packet ts rescaling in write_packet()

[Michael Niedermayer]

On Wed, Feb 15, 2017 at 10:24:17AM +0100, wm4 wrote:
> From: Anton Khirnov 
> 
> This will be useful in the following commit, after which the muxer
> timebase is not always available when encoding.
> 
> This merges Libav commit 3e265ca. It was previously skipped.
> 
> There is a minor change with setting the mux_timebase field only after
> the muxer's write_header function has been called, because it can
> readjust the timebase.
> 
> Includes a minor merge fix by Mark Thompson, and
> 
> avconv: Move rescale to stream timebase before monotonisation
> 
> also by Mark Thompson .
> 
> Signed-off-by: wm4 
> ---
>  ffmpeg.c | 39 ++-
>  ffmpeg.h |  2 ++
>  2 files changed, 24 insertions(+), 17 deletions(-)

Tests run against master with
cb6f1be864c64cfa1d48a5d3eadbecbc771402e7
9148290d71648b0c4295485e59f6541892041a6b
(taken from your git)


This causes a difference in:
./ffmpeg -i ~/tickets/1242/sample.mkv -vcodec copy  -copyts -acodec copy -sn 
test.ts

Ive looked at the difference and it seems the first timestamp differs
0,  -3780,  0,0, 3056, 0x00f4902c, S=1,1, 
0x00e000e0
vs.
0,  -3754,  0,0, 3056, 0x00f4902c, S=1,1, 
0x00e000e0

3754 is closer to 9/24000/1001
3780 is closer to the first timestamp from the source file

i dont really know what is better

with
./ffmpeg -i ~/tickets/2143/input.mpg -vcodec copy -acodec copy  -ss 7 -t 7 
test.mpg

this causes larger timestamp differences and a shower of warnings like
Non-monotonous DTS in output stream 0:0; previous: 483483, current: 483483; 
changing to 483484. This may result in incorrect timestamps in the output file.

previously no such warnings where generated

with
./ffmpeg -i ~/tickets/2424/aspect_bug.mkv -vcodec copy -acodec copy -t 1 
test.mp4
Again the first timestamps change and here also the printed fps value
changes from 24 to 24.01

theres also a differene with Starship_Troopers.vob which i belive i reported
previously

and this also has different timestamps:
./ffmpeg -i ~/tickets/3547/sat_uplink_signalloss.ts -vcodec copy -acodec copy 
test.asf
interrestingly this is specific to asf output, other formats seem not
to show this

Thats all i could find for the 2 commits with some light analysis.
I Hope it helps

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

[FFmpeg-devel] Q: QSV filters (state of implementation)

[Haris Zukanovic]

Hi everyone,

The last record of an attempt to introduce QSV filters in the mailing list
would be the
thread titled lavf/vpp: Enable vpp filter, an Intel GPU accelerated scaler
from 8/25/16.
...but I understand the hwaccell sharing context was not at all ready at
that point...

Since now ffmpeg does implement api for hwaccell to enable zero-copy
pipeline between decoder and encoder, I wonder how far away it is from
being ready to accept implementation of some of the hw-accellerated filters
as well, like deinterlace and resize?

Would you say the QSV zero-copy filters implementation will be able to
support a scenario for multiple quality encoding where, for example, when
producing 3 qualities I would:
1. decode + deinterlace once + split into 3
2. resize 3 times (each split)
3. encode 3 times (once for each resized output)


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

Re: [FFmpeg-devel] [PATCH] avcodec/amrnbdec: fix handling of NO_DATA frames

[Ronald S. Bultje]

Hi,

On Tue, Feb 21, 2017 at 8:07 AM, Carl Eugen Hoyos 
wrote:

> 2017-02-21 13:47 GMT+01:00 Ronald S. Bultje :
> > For the rest of us, this isn't helpful. What differences are you seeing?
>
> I don't see a difference, I hear a difference.
>
[..]

> My English language capabilities are not sufficient to explain "worse"
> better


But you can decode the file before/after patch as well as with a reference
decoder and open the decoded files in a wave editor and visualize the
differences and show which is closer to reference, right?

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix cid 1401346 Dereferencing pointer error

[Steven Liu]

2017-02-20 17:03 GMT+08:00 Steven Liu :

> check if proto is null before av_strcasecmp
> CID:  1401346
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e673f59..fad6cae 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -668,7 +668,7 @@ static void hls_free_segments(HLSSegment *p)
>  static void set_http_options(AVFormatContext *s, AVDictionary **options,
> HLSContext *c)
>  {
>  const char *proto = avio_find_protocol_name(s->filename);
> -int http_base_proto = !av_strcasecmp(proto, "http") ||
> !av_strcasecmp(proto, "https");
> +int http_base_proto = proto ? (!av_strcasecmp(proto, "http") ||
> !av_strcasecmp(proto, "https")) : 0;
>
>  if (c->method) {
>  av_dict_set(options, "method", c->method, 0);
> --
> 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] [PATCHv3 2/3] mov: Export bounds and padding from spherical metadata

[James Almer]

On 2/21/2017 7:35 PM, Vittorio Giovara wrote:
> Update the fate test as needed.
> ---
>  libavformat/mov.c | 28 +++-
>  tests/ref/fate/mov-spherical-mono |  6 +-
>  2 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7b0bbcc..d798336 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4637,6 +4637,8 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  MOVStreamContext *sc;
>  int size, version;
>  int32_t yaw, pitch, roll;
> +size_t l, t, r, b;
> +size_t padding = 0;
>  uint32_t tag;
>  enum AVSphericalProjection projection;
>  
> @@ -4716,9 +4718,25 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  switch (tag) {
>  case MKTAG('c','b','m','p'):
>  projection = AV_SPHERICAL_CUBEMAP;
> +padding = avio_rb32(pb);

Doesn't layout come first?

>  break;
>  case MKTAG('e','q','u','i'):
> -projection = AV_SPHERICAL_EQUIRECTANGULAR;
> +t = avio_rb32(pb);
> +b = avio_rb32(pb);
> +l = avio_rb32(pb);
> +r = avio_rb32(pb);
> +
> +if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
> +av_log(c->fc, AV_LOG_ERROR,
> +   "Invalid bounding rectangle coordinates "
> +   "%zu,%zu,%zu,%zu\n", l, t, r, b);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (l || t || r || b)
> +projection = AV_SPHERICAL_EQUIRECTANGULAR_TILE;
> +else
> +projection = AV_SPHERICAL_EQUIRECTANGULAR;
>  break;
>  default:
>  av_log(c->fc, AV_LOG_ERROR, "Unknown projection type\n");
> @@ -4735,6 +4753,14 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  sc->spherical->pitch = pitch;
>  sc->spherical->roll  = roll;
>  
> +sc->spherical->padding = padding;
> +
> +if (projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE) {
> +sc->spherical->bound_left   = l;
> +sc->spherical->bound_top= t;
> +sc->spherical->bound_right  = r;
> +sc->spherical->bound_bottom = b;
> +}
>  return 0;
>  }
>  
> diff --git a/tests/ref/fate/mov-spherical-mono 
> b/tests/ref/fate/mov-spherical-mono
> index 8048aff..a70d879 100644
> --- a/tests/ref/fate/mov-spherical-mono
> +++ b/tests/ref/fate/mov-spherical-mono
> @@ -8,7 +8,11 @@ inverted=0
>  [SIDE_DATA]
>  side_data_type=Spherical Mapping
>  side_data_size=56
> -projection=equirectangular
> +projection=tiled equirectangular
> +bound_left=148
> +bound_top=73
> +bound_right=147
> +bound_bottom=72
>  yaw=45
>  pitch=30
>  roll=15
> 

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

Re: [FFmpeg-devel] [PATCH] aacdec: When ignoring a PCE restore the previous config

[Alex Converse]

On Thu, Feb 16, 2017 at 3:21 PM, Carl Eugen Hoyos  wrote:
> 2017-02-16 22:13 GMT+01:00 Alex Converse :
>> This is related to, but doesn't solve ticker 6152.
>> ---
>>  libavcodec/aacdec_template.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 4e0a9529e1..4367e74cf7 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -3036,6 +3036,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
>> void *data,
>>  if (pce_found) {
>>  av_log(avctx, AV_LOG_ERROR,
>> "Not evaluating a further program_config_element as 
>> this construct is dubious at best.\n");
>> +pop_output_configuration(ac);
>>  } else {
>>  err = output_configure(ac, layout_map, tags, OC_TRIAL_PCE, 
>> 1);
>>  if (!err)
>
> I thought ticket #6152 was related to the else tree...
>
> Anyway: Since this is your code, please wait a day or two
> and push.
>

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