Re: [FFmpeg-devel] [PATCH 5/6] opus_celt: rename structures to better names and reorganize them

2017-02-01 Thread Michael Niedermayer
On Wed, Feb 01, 2017 at 01:03:23PM +, Rostislav Pehlivanov wrote:
> On 1 February 2017 at 11:51, Michael Niedermayer  wrote:
> 
> > On Wed, Feb 01, 2017 at 03:13:08AM +, Rostislav Pehlivanov wrote:
> > > This is meant to be applied on top of my previous patch which
> > > split PVQ into celt_pvq.c and made opus_celt.h
> > >
> > > Essentially nothing has been changed other than renaming CeltFrame
> > > to CeltBlock (CeltFrame had absolutely nothing at all to do with
> > > a frame) and CeltContext to CeltFrame.
> > > 3 variables have been put in CeltFrame as they make more sense
> > > there rather than being passed around as arguments.
> > > The coefficients have been moved to the CeltBlock structure
> > > (why the hell were they in CeltContext and not in CeltFrame??).
> > >
> > > Now the encoder would be able to use the exact context the decoder
> > > uses (plus a couple of extra fields in there).
> > >
> > > FATE passes, no slowdowns, etc.
> >
> > This doesnt build on arm-linux-gnueabi-gcc-4.5
> > (i think arm is unrelated here)
> >
> > In file included from src/libavcodec/opus_celt.c:28:0:
> > src/libavcodec/opus_celt.h:134:3: error: redefinition of typedef
> > ‘CeltFrame’
> > src/libavcodec/opus.h:82:26: note: previous declaration of ‘CeltFrame’ was
> > here
> > make: *** [libavcodec/opus_celt.o] Error 1
> >
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > No great genius has ever existed without some touch of madness. --
> > Aristotle
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> Seems older GCC versions are unhappy.
> Removed the typedef from the struct definition in opus_celt.h and attached
> new patch


this fixes it:


diff --git a/libavcodec/opus_celt.h b/libavcodec/opus_celt.h
index 9d144f2f52..681b028d9c 100644
--- a/libavcodec/opus_celt.h
+++ b/libavcodec/opus_celt.h
@@ -59,7 +59,7 @@ enum CeltBlockSize {
 CELT_BLOCK_NB
 };

-struct CeltBlock {
+typedef struct CeltBlock {
 float energy[CELT_MAX_BANDS];
 float lin_energy[CELT_MAX_BANDS];
 float error_energy[CELT_MAX_BANDS];
@@ -87,9 +87,9 @@ struct CeltBlock {
 float pf_gains_old[3];

 float emph_coeff;
-};
+} CeltBlock;

-typedef struct CeltFrame {
+struct CeltFrame {
 // constant values that do not change during context lifetime
 AVCodecContext  *avctx;
 MDCT15Context   *imdct[4];
@@ -131,7 +131,7 @@ typedef struct CeltFrame {
 int tf_change[CELT_MAX_BANDS];

 DECLARE_ALIGNED(32, float, scratch)[22 * 8]; // MAX(ff_celt_freq_range) * 
1<

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


Re: [FFmpeg-devel] [PATCH v3] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Mark Thompson
On 02/02/17 00:30, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Implements support for height/width expressions in vf_scale_vaapi,
> by refactoring common code into a new libavfilter/scale.c
> ---
>  libavfilter/Makefile |   8 +--
>  libavfilter/scale.c  | 152 
> +++
>  libavfilter/scale.h  |  28 
>  libavfilter/vf_scale.c   | 109 +++
>  libavfilter/vf_scale_npp.c   |  93 +++---
>  libavfilter/vf_scale_vaapi.c |  19 --
>  6 files changed, 216 insertions(+), 193 deletions(-)
>  create mode 100644 libavfilter/scale.c
>  create mode 100644 libavfilter/scale.h

LGTM.  Michael is listed as the maintainer of vf_scale, though, so we should 
wait for him to look at it before applying.

Thanks,

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


[FFmpeg-devel] [PATCH v3] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Aman Gupta
From: Aman Gupta 

Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
---
 libavfilter/Makefile |   8 +--
 libavfilter/scale.c  | 152 +++
 libavfilter/scale.h  |  28 
 libavfilter/vf_scale.c   | 109 +++
 libavfilter/vf_scale_npp.c   |  93 +++---
 libavfilter/vf_scale_vaapi.c |  19 --
 6 files changed, 216 insertions(+), 193 deletions(-)
 create mode 100644 libavfilter/scale.c
 create mode 100644 libavfilter/scale.h

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 68a94be..3231f08 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -257,10 +257,10 @@ OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += 
vf_repeatfields.o
 OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
-OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
-OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o
-OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
-OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
+OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
+OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
 OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
new file mode 100644
index 000..50cd442
--- /dev/null
+++ b/libavfilter/scale.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (c) 2007 Bobby Bingham
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "scale.h"
+#include "libavutil/eval.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/pixdesc.h"
+
+static const char *const var_names[] = {
+"PI",
+"PHI",
+"E",
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow",
+"out_h",  "oh",
+"a",
+"sar",
+"dar",
+"hsub",
+"vsub",
+"ohsub",
+"ovsub",
+NULL
+};
+
+enum var_name {
+VAR_PI,
+VAR_PHI,
+VAR_E,
+VAR_IN_W,   VAR_IW,
+VAR_IN_H,   VAR_IH,
+VAR_OUT_W,  VAR_OW,
+VAR_OUT_H,  VAR_OH,
+VAR_A,
+VAR_SAR,
+VAR_DAR,
+VAR_HSUB,
+VAR_VSUB,
+VAR_OHSUB,
+VAR_OVSUB,
+VARS_NB
+};
+
+int ff_scale_eval_dimensions(void *log_ctx,
+const char *w_expr, const char *h_expr,
+AVFilterLink *inlink, AVFilterLink *outlink,
+int *ret_w, int *ret_h)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format);
+const char *expr;
+int w, h;
+int factor_w, factor_h;
+int eval_w, eval_h;
+int ret;
+double var_values[VARS_NB], res;
+
+var_values[VAR_PI]= M_PI;
+var_values[VAR_PHI]   = M_PHI;
+var_values[VAR_E] = M_E;
+var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
+var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
+var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
+var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
+var_values[VAR_A] = (double) inlink->w / inlink->h;
+var_values[VAR_SAR]   = inlink->sample_aspect_ratio.num ?
+(double) inlink->sample_aspect_ratio.num / 
inlink->sample_aspect_ratio.den : 1;
+var_values[VAR_DAR]   = var_values[VAR_A] * var_values[VAR_SAR];
+var_values[VAR_HSUB]  = 1 << desc->log2_chroma_w;
+var_values[VAR_VSUB]  = 1 << desc->log2_chroma_h;
+var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
+var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
+
+/* evaluate width and height */
+av_expr_parse_and_eval(, (expr = w_expr),
+   var_names, var_values,
+   NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
+eval_w = var_values[VAR_OUT_W] = 

[FFmpeg-devel] [PATCH v2] avformat/hlsenc: add hls_flag option to write segments to temporary file until complete

2017-02-01 Thread Aman Gupta
From: Aman Gupta 

Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete.

This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
---
 libavformat/hlsenc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..17d4fe4 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -76,6 +76,7 @@ typedef enum HLSFlags {
 HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in 
segment filenames when use_localtime  e.g.: %%03d
 HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
 HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
+HLS_TEMP_FILE = (1 << 11),
 } HLSFlags;
 
 typedef enum {
@@ -416,6 +417,7 @@ static int hls_mux_init(AVFormatContext *s)
 return ret;
 oc = hls->avf;
 
+oc->filename[0]= '\0';
 oc->oformat= hls->oformat;
 oc->interrupt_callback = s->interrupt_callback;
 oc->max_delay  = s->max_delay;
@@ -815,6 +817,15 @@ 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));
@@ -915,6 +926,10 @@ static int hls_start(AVFormatContext *s)
 
 set_http_options(, c);
 
+if (c->flags & HLS_TEMP_FILE) {
+av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
+}
+
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1364,6 +1379,15 @@ 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);
@@ -1406,6 +1430,7 @@ static const AVOption options[] = {
 {"hls_subtitle_path", "set path of hls subtitles", 
OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
 {"hls_flags", "set flags affecting HLS playlist and media file 
generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E, 
"flags"},
 {"single_file",   "generate a single media file indexed with byte ranges", 
0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E, "flags"},
+{"temp_file", "write segment to temporary file and rename when complete", 
0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E, "flags"},
 {"delete_segments", "delete segment files that are no longer part of the 
playlist", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0, UINT_MAX,   
E, "flags"},
 {"round_durations", "round durations in m3u8 to whole numbers", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E, "flags"},
 {"discont_start", "start the playlist with a discontinuity tag", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
-- 
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] speedhq: make sure the block index is not negative

2017-02-01 Thread Andreas Cadhalpun
On 01.02.2017 17:25, Steinar H. Gunderson wrote:
> On Wed, Feb 01, 2017 at 02:17:05AM +0100, Andreas Cadhalpun wrote:
>>> Would you mind sharing an input where this actually triggers? None of the
>>> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
>>> input.
>> Indeed it is. I've sent you a sample.
> 
> Could you please try the attached patch?

It works fine, thanks! I've applied it.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls_flag option to create segments atomically

2017-02-01 Thread Aman Gupta
On Tue, Jan 31, 2017 at 12:29 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> Adds a `-hls_flags +temp_file` which will write segment data to
> filename.tmp, and then rename to filename when the segment is complete
> and before the file is added to the m3u8 playlist.
>
> This patch is similar in spirit to one used in Plex's ffmpeg fork, and
> allows a transcoding webserver to ensure incomplete segment files are
> never served up accidentally.
> ---
>  libavformat/hlsenc.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bd1e684..23b9011 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -76,6 +76,7 @@ typedef enum HLSFlags {
>  HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index
> in segment filenames when use_localtime  e.g.: %%03d
>  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment
> duration (microsec) in segment filenames when use_localtime  e.g.: %%09t
>  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size
> (bytes) in segment filenames when use_localtime  e.g.: %%014s
> +HLS_TEMP_FILE = (1 << 11),
>  } HLSFlags;
>
>  typedef enum {
> @@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
>
>  set_http_options(, c);
>
> +if (c->flags & HLS_TEMP_FILE) {
> +av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
> +}
> +
>  if (c->key_info_file) {
>  if ((err = hls_encryption_start(s)) < 0)
>  goto fail;
> @@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
>  av_write_frame(oc, NULL); /* Flush any buffered data */
>
> +if (hls->flags & HLS_TEMP_FILE) {
> +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);
>

This doesn't work on windows, since you cannot rename the file while it is
still open. Strangely ff_rename is not logging any errors in this case.


> +oc->filename[len-4] = '\0';
> +}
> +
>  new_start_pos = avio_tell(hls->avf->pb);
>  hls->size = new_start_pos - hls->start_pos;
>  ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
> hls->size);
> @@ -1406,6 +1420,7 @@ static const AVOption options[] = {
>  {"hls_subtitle_path", "set path of hls subtitles",
> OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
>  {"hls_flags", "set flags affecting HLS playlist and media file
> generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E,
> "flags"},
>  {"single_file",   "generate a single media file indexed with byte
> ranges", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E,
> "flags"},
> +{"temp_file", "write segment to temporary file and rename when
> complete", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E,
> "flags"},
>  {"delete_segments", "delete segment files that are no longer part of
> the playlist", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0,
> UINT_MAX,   E, "flags"},
>  {"round_durations", "round durations in m3u8 to whole numbers", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E,
> "flags"},
>  {"discont_start", "start the playlist with a discontinuity tag", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
> --
> 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 v2] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Mark Thompson
On 01/02/17 23:12, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Implements support for height/width expressions in vf_scale_vaapi,
> by refactoring common code into a new libavfilter/scale.c

Some more minor points:

> ---
>  libavfilter/Makefile |   8 +--
>  libavfilter/scale.c  | 152 
> +++
>  libavfilter/scale.h  |  28 
>  libavfilter/vf_scale.c   | 109 +++
>  libavfilter/vf_scale_npp.c   |  94 +++---
>  libavfilter/vf_scale_vaapi.c |  19 --
>  6 files changed, 217 insertions(+), 193 deletions(-)
>  create mode 100644 libavfilter/scale.c
>  create mode 100644 libavfilter/scale.h
> 
> ...
> +int ff_scale_eval_dimensions(void *log_ctx,
> +const char *w_expr, const char *h_expr,
> +AVFilterLink *inlink, AVFilterLink *outlink,
> +int *ret_w, int *ret_h)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> +const AVPixFmtDescriptor *out_desc = 
> av_pix_fmt_desc_get(outlink->format);
> +const char *expr;
> +int w, h;
> +int factor_w, factor_h;
> +int eval_w, eval_h;
> +int ret;
> +double var_values[VARS_NB], res;
> +
> +var_values[VAR_PI]= M_PI;
> +var_values[VAR_PHI]   = M_PHI;
> +var_values[VAR_E] = M_E;
> +var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
> +var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
> +var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
> +var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
> +var_values[VAR_A] = (double) inlink->w / inlink->h;
> +var_values[VAR_SAR]   = inlink->sample_aspect_ratio.num ?
> +(double) inlink->sample_aspect_ratio.num / 
> inlink->sample_aspect_ratio.den : 1;
> +var_values[VAR_DAR]   = var_values[VAR_A] * var_values[VAR_SAR];
> +var_values[VAR_HSUB]  = 1 << desc->log2_chroma_w;
> +var_values[VAR_VSUB]  = 1 << desc->log2_chroma_h;
> +var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
> +var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
> +
> +/* evaluate width and height */
> +av_expr_parse_and_eval(, (expr = w_expr),
> +   var_names, var_values,
> +   NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
> +eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
> +
> +if ((ret = av_expr_parse_and_eval(, (expr = h_expr),
> +  var_names, var_values,
> +  NULL, NULL, NULL, NULL, NULL, 0, 
> log_ctx)) < 0)
> +goto fail;
> +eval_h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
> +/* evaluate again the width, as it may depend on the output height */
> +if ((ret = av_expr_parse_and_eval(, (expr = w_expr),
> +  var_names, var_values,
> +  NULL, NULL, NULL, NULL, NULL, 0, 
> log_ctx)) < 0)
> +goto fail;
> +eval_w = res;
> +
> +w = eval_w;
> +h = eval_h;
> +
> +/* Check if it is requested that the result has to be divisible by a some
> + * factor (w or h = -n with n being the factor). */
> +factor_w = 1;
> +factor_h = 1;
> +if (w < -1) {
> +factor_w = -w;
> +}
> +if (h < -1) {
> +factor_h = -h;
> +}
> +
> +if (w < 0 && h < 0)
> +eval_w = eval_h = 0;
> +
> +if (!(w = eval_w))
> +w = inlink->w;
> +if (!(h = eval_h))
> +h = inlink->h;
> +
> +/* Make sure that the result is divisible by the factor we determined
> + * earlier. If no factor was set, it is nothing will happen as the 
> default
> + * factor is 1 */
> +if (w < 0)
> +w = av_rescale(h, inlink->w, inlink->h * factor_w) * factor_w;
> +if (h < 0)
> +h = av_rescale(w, inlink->h, inlink->w * factor_h) * factor_h;
> +
> +*ret_w = w;
> +*ret_h = h;
> +
> +return 0;
> +
> +fail:
> +av_log(NULL, AV_LOG_ERROR,

Having passed the logging context, you should use it here.

> +   "Error when evaluating the expression '%s'.\n"
> +   "Maybe the expression for out_w:'%s' or for out_h:'%s' is 
> self-referencing.\n",
> +   expr, w_expr, h_expr);
> +return ret;
> +}
> ...
> @@ -359,64 +332,19 @@ static int nppscale_config_props(AVFilterLink *outlink)
>  {
>  AVFilterContext *ctx = outlink->src;
>  AVFilterLink *inlink = outlink->src->inputs[0];
> -NPPScaleContext  *s = ctx->priv;
> -int64_t w, h;
> -double var_values[VARS_NB], res;
> -char *expr;
> +NPPScaleContext *s = ctx->priv;
> +int w, h;
>  int ret;
>  
> -var_values[VAR_PI]= M_PI;
> -var_values[VAR_PHI]   = M_PHI;
> -var_values[VAR_E] = M_E;
> -var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
> -var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
> -var_values[VAR_OUT_W] = 

[FFmpeg-devel] [PATCH v2] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Aman Gupta
From: Aman Gupta 

Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
---
 libavfilter/Makefile |   8 +--
 libavfilter/scale.c  | 152 +++
 libavfilter/scale.h  |  28 
 libavfilter/vf_scale.c   | 109 +++
 libavfilter/vf_scale_npp.c   |  94 +++---
 libavfilter/vf_scale_vaapi.c |  19 --
 6 files changed, 217 insertions(+), 193 deletions(-)
 create mode 100644 libavfilter/scale.c
 create mode 100644 libavfilter/scale.h

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 68a94be..3231f08 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -257,10 +257,10 @@ OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += 
vf_repeatfields.o
 OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
-OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
-OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o
-OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
-OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
+OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
+OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
 OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
new file mode 100644
index 000..caa4680
--- /dev/null
+++ b/libavfilter/scale.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (c) 2007 Bobby Bingham
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "scale.h"
+#include "libavutil/eval.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/pixdesc.h"
+
+static const char *const var_names[] = {
+"PI",
+"PHI",
+"E",
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow",
+"out_h",  "oh",
+"a",
+"sar",
+"dar",
+"hsub",
+"vsub",
+"ohsub",
+"ovsub",
+NULL
+};
+
+enum var_name {
+VAR_PI,
+VAR_PHI,
+VAR_E,
+VAR_IN_W,   VAR_IW,
+VAR_IN_H,   VAR_IH,
+VAR_OUT_W,  VAR_OW,
+VAR_OUT_H,  VAR_OH,
+VAR_A,
+VAR_SAR,
+VAR_DAR,
+VAR_HSUB,
+VAR_VSUB,
+VAR_OHSUB,
+VAR_OVSUB,
+VARS_NB
+};
+
+int ff_scale_eval_dimensions(void *log_ctx,
+const char *w_expr, const char *h_expr,
+AVFilterLink *inlink, AVFilterLink *outlink,
+int *ret_w, int *ret_h)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format);
+const char *expr;
+int w, h;
+int factor_w, factor_h;
+int eval_w, eval_h;
+int ret;
+double var_values[VARS_NB], res;
+
+var_values[VAR_PI]= M_PI;
+var_values[VAR_PHI]   = M_PHI;
+var_values[VAR_E] = M_E;
+var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
+var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
+var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
+var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
+var_values[VAR_A] = (double) inlink->w / inlink->h;
+var_values[VAR_SAR]   = inlink->sample_aspect_ratio.num ?
+(double) inlink->sample_aspect_ratio.num / 
inlink->sample_aspect_ratio.den : 1;
+var_values[VAR_DAR]   = var_values[VAR_A] * var_values[VAR_SAR];
+var_values[VAR_HSUB]  = 1 << desc->log2_chroma_w;
+var_values[VAR_VSUB]  = 1 << desc->log2_chroma_h;
+var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
+var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
+
+/* evaluate width and height */
+av_expr_parse_and_eval(, (expr = w_expr),
+   var_names, var_values,
+   NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
+eval_w = var_values[VAR_OUT_W] = 

[FFmpeg-devel] [PATCH 2/2] avcodec/nvenc: Use the right pix format for YUV444P10 content

2017-02-01 Thread Philip Langdale
Now that we have an accurate pixfmt available, let's use it for
the format mapping in nvenc and stop pretending we support > 10bit.

Signed-off-by: Philip Langdale 
---
 libavcodec/nvenc.c   | 8 
 libavcodec/version.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 7005465..b2b6ec9 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -41,7 +41,7 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_YUV444P10MSB,
 AV_PIX_FMT_0RGB32,
 AV_PIX_FMT_0BGR32,
 AV_PIX_FMT_CUDA,
@@ -49,10 +49,10 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 };
 
 #define IS_10BIT(pix_fmt) (pix_fmt == AV_PIX_FMT_P010 ||\
-   pix_fmt == AV_PIX_FMT_YUV444P16)
+   pix_fmt == AV_PIX_FMT_YUV444P10MSB)
 
 #define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P || \
-pix_fmt == AV_PIX_FMT_YUV444P16)
+pix_fmt == AV_PIX_FMT_YUV444P10MSB)
 
 static const struct {
 NVENCSTATUS nverr;
@@ -1041,7 +1041,7 @@ static NV_ENC_BUFFER_FORMAT nvenc_map_buffer_format(enum 
AVPixelFormat pix_fmt)
 return NV_ENC_BUFFER_FORMAT_YUV420_10BIT;
 case AV_PIX_FMT_YUV444P:
 return NV_ENC_BUFFER_FORMAT_YUV444_PL;
-case AV_PIX_FMT_YUV444P16:
+case AV_PIX_FMT_YUV444P10MSB:
 return NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 case AV_PIX_FMT_0RGB32:
 return NV_ENC_BUFFER_FORMAT_ARGB;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index c038e4b..82a89f9 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  57
-#define LIBAVCODEC_VERSION_MINOR  75
+#define LIBAVCODEC_VERSION_MINOR  76
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/2] avutil: Add MSB packed YUV444P10 format

2017-02-01 Thread Philip Langdale
nvenc supports a YUV444P10 format with the same bit layout as P010,
with the data bits at the MSB end.

Unfortunately, the current YUV444P10 format we have defined puts
the data bits at the LSB end.

This mismatch led to us introducing a fudge in nvenc where we
mapped their 444P10 format to the ffmpeg 444P16 format. This
ensured that the data ends up in the right place if you are
starting with 10bit content, but it leads to other problems.

Specifically:

* >10bit content will be preferrentially converted to 444P16
  to pass to nvenc to 'preserve' the additional bits. However, they
  aren't actually preserved, but are discarded, so we're worse off
  because no dithering took place in swscale.
* On top of that, the input data is almost certainly 4:2:0 and so
  the conversion to 4:4:4 is pointless, while also leading to an
  output file that's incompatible with many playback scenarios
  (no hardware decoder supports 4:4:4 content).

So, for the sake of accuracy, introduce an explicit pixfmt for this
situation. There's no conversion support because you'll basically
never have a use for it. If someone ever finds one, they can write
the swscale code.

In the mean time, common 12 bit content (YUV420P12 or P016) will be
correctly converted to P010 for nvenc.

Signed-off-by: Philip Langdale 
---
 libavutil/pixdesc.c | 24 
 libavutil/pixfmt.h  |  5 +
 libavutil/version.h |  2 +-
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 3b9c45d..fe9b59d 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1565,6 +1565,30 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
 },
+[AV_PIX_FMT_YUV444P10MSBLE] = {
+.name = "yuv444p10msble",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 1, 2, 0, 6, 10, 1, 9, 1 },/* U */
+{ 2, 2, 0, 6, 10, 1, 9, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV444P10MSBBE] = {
+.name = "yuv444p10msbbe",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 1, 2, 0, 6, 10, 1, 9, 1 },/* U */
+{ 2, 2, 0, 6, 10, 1, 9, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
+},
 [AV_PIX_FMT_YUV444P9LE] = {
 .name = "yuv444p9le",
 .nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index dfb1b11..46bf9c0 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -314,6 +314,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_P016LE, ///< like NV12, with 16bpp per component, little-endian
 AV_PIX_FMT_P016BE, ///< like NV12, with 16bpp per component, big-endian
 
+AV_PIX_FMT_YUV444P10MSBLE, /// like YUV444P10 but with data in the high 
bits, zeros in the low bits, little-endian
+AV_PIX_FMT_YUV444P10MSBBE, /// like YUV444P10 but with data in the high 
bits, zeros in the low bits, big-endian
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
@@ -394,6 +397,8 @@ enum AVPixelFormat {
 #define AV_PIX_FMT_P010   AV_PIX_FMT_NE(P010BE,  P010LE)
 #define AV_PIX_FMT_P016   AV_PIX_FMT_NE(P016BE,  P016LE)
 
+#define AV_PIX_FMT_YUV444P10MSB AV_PIX_FMT_NE(YUV444P10MSBBE, YUV444P10MSBLE)
+
 /**
   * Chromaticity coordinates of the source primaries.
   */
diff --git a/libavutil/version.h b/libavutil/version.h
index 8866064..a8b00bf 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR  46
+#define LIBAVUTIL_VERSION_MINOR  47
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 0/2] nvenc: Fix inaccurate use of YUV444P16 format

2017-02-01 Thread Philip Langdale
We have been pretending that the nvenc YUV444P10 format is our
YUV444P16 format, and this is not a good idea. It leads to us
failing to dither >10bit content when transcoding and also
results in encoded files with 4:4:4 sampling which are almost
certainly not what the user wants.

Philip Langdale (2):
  avutil: Add MSB packed YUV444P10 format
  avcodec/nvenc: Use the right pix format for YUV444P10 content

 libavcodec/nvenc.c   |  8 
 libavcodec/version.h |  2 +-
 libavutil/pixdesc.c  | 24 
 libavutil/pixfmt.h   |  5 +
 libavutil/version.h  |  2 +-
 5 files changed, 35 insertions(+), 6 deletions(-)

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


Re: [FFmpeg-devel] [PATCH] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Mark Thompson
On 01/02/17 00:46, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Implements support for height/width expressions in vf_scale_vaapi,
> by refactoring common code into a new libavfilter/scale.c

Nice!  Patch as a whole LGTM, some minor nits below.

> ---
>  libavfilter/Makefile |   8 +--
>  libavfilter/scale.c  | 143 
> +++
>  libavfilter/scale.h  |  31 ++
>  libavfilter/vf_scale.c   | 109 +++--
>  libavfilter/vf_scale_npp.c   |  87 +++---
>  libavfilter/vf_scale_vaapi.c |  18 +-
>  6 files changed, 208 insertions(+), 188 deletions(-)
>  create mode 100644 libavfilter/scale.c
>  create mode 100644 libavfilter/scale.h
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 68a94be..3231f08 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -257,10 +257,10 @@ OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += 
> vf_repeatfields.o
>  OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
>  OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
>  OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
> -OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
> -OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o
> -OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
> -OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
> +OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
> +OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
> +OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> +OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
>  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
>  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
>  OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
> diff --git a/libavfilter/scale.c b/libavfilter/scale.c
> new file mode 100644
> index 000..b0f4be2
> --- /dev/null
> +++ b/libavfilter/scale.c
> @@ -0,0 +1,143 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "scale.h"
> +
> +static const char *const var_names[] = {
> +"PI",
> +"PHI",
> +"E",
> +"in_w",   "iw",
> +"in_h",   "ih",
> +"out_w",  "ow",
> +"out_h",  "oh",
> +"a",
> +"sar",
> +"dar",
> +"hsub",
> +"vsub",
> +"ohsub",
> +"ovsub",
> +NULL
> +};
> +
> +enum var_name {
> +VAR_PI,
> +VAR_PHI,
> +VAR_E,
> +VAR_IN_W,   VAR_IW,
> +VAR_IN_H,   VAR_IH,
> +VAR_OUT_W,  VAR_OW,
> +VAR_OUT_H,  VAR_OH,
> +VAR_A,
> +VAR_SAR,
> +VAR_DAR,
> +VAR_HSUB,
> +VAR_VSUB,
> +VAR_OHSUB,
> +VAR_OVSUB,
> +VARS_NB
> +};
> +
> +int ff_scale_eval_dimensions(void *ctx,
> +const char *w_expr, const char *h_expr,
> +AVFilterLink *inlink, AVFilterLink *outlink,
> +int *ret_w, int *ret_h)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> +const AVPixFmtDescriptor *out_desc = 
> av_pix_fmt_desc_get(outlink->format);
> +const char *expr;
> +int w, h;
> +int factor_w, factor_h;
> +int eval_w, eval_h;
> +int ret;
> +double var_values[VARS_NB], res;
> +
> +var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
> +var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
> +var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
> +var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
> +var_values[VAR_A] = (double) inlink->w / inlink->h;
> +var_values[VAR_SAR]   = inlink->sample_aspect_ratio.num ?
> +(double) inlink->sample_aspect_ratio.num / 
> inlink->sample_aspect_ratio.den : 1;
> +var_values[VAR_DAR]   = var_values[VAR_A] * var_values[VAR_SAR];
> +var_values[VAR_HSUB]  = 1 << desc->log2_chroma_w;
> +var_values[VAR_VSUB]  = 1 << desc->log2_chroma_h;
> +var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
> +var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
> +
> +/* evaluate width and height */
> +av_expr_parse_and_eval(, (expr = w_expr),
> +   var_names, var_values,
> +   

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

2017-02-01 Thread Kieran O Leary
Hi James and Carl,

Thanks for getting back to me. It looks like your comments are similar,
though you might be asking to pull the information from different places?
more below

On Wed, Feb 1, 2017 at 5:01 PM, James Almer  wrote:

>
> I may be missing something and apologizes if it was already mentioned, but
> libavcodec already have options for these, color_trc and if i'm reading
> this right colorspace, making use of the AVColorTransferCharacteristic and
> AVColorSpace enums defined in avutil's pixfmt.h header.
>
> Can't you use them instead?
>
>
>
DPX contains some values that are super-specific to film, such as 'Printing
Density'. I do not see that value in either of those enums but it's a
common value that pops up in film scans.
The larger issue that I see with this approach is that it's an integer that
needs to be written to the 801/802 offsets in the DPX header. So if I want
logarithmic transfer characteristic, 3 needs to be written as the value and
this is interpreted by the decoder. Logarithmic is listed as 9 in
 AVColorTransferCharacteristic - but perhaps this is irrelevant and I'm
misunderstanding how pixfmt.h works? Things like 'unspecified video' are
not in those enums either.

Carl Eugen mentioned AvCodecContext but I don't know enough about this to
be able to see if the values as specified by SMPTE will map.

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


Re: [FFmpeg-devel] [PATCH 3/6] imdct15: rename to mdct15 and add a forward transform

2017-02-01 Thread Rostislav Pehlivanov
On 1 February 2017 at 03:13, Rostislav Pehlivanov 
wrote:

+static __attribute__ ((noinline)) void fft15(const FFTComplex exptab[22],
> FFTComplex *out,
> + const FFTComplex *in, size_t stride)
>
>
Removed the noinline attribute locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] lavc: Add device context field to AVCodecContext

2017-02-01 Thread Mark Thompson
For use by codec implementations which can allocate frames internally.
---
On 01/02/17 14:03, Timo Rothenpieler wrote:
> Am 17.01.2017 um 23:28 schrieb Mark Thompson:
>> For use by codec implementations which require a device to operation
>> but will allocate frames internally.
>> ---
>> The following patches make use of it for qsv.  Is this definition 
>> appropriate to solve the issues with cuvid device setup as well?
>>
>>
>>  doc/APIchanges   |  3 +++
>>  libavcodec/avcodec.h | 38 --
>>  libavcodec/utils.c   |  1 +
>>  libavcodec/version.h |  2 +-
>>  4 files changed, 41 insertions(+), 3 deletions(-)
> 
> ping about this.
> I'd really like to use it for cuvid and get rid of some hackery.

This got more discussion in libav, see below for a patch expressing the 
currently-proposed semantics.

(See also 
 for a 
full implementation for VAAPI, I haven't ported it here yet.)

Thanks,

- Mark


 libavcodec/avcodec.h | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1e681e989b..cd83e6b27f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3533,7 +3533,8 @@ typedef struct AVCodecContext {
 /**
  * A reference to the AVHWFramesContext describing the input (for encoding)
  * or output (decoding) frames. The reference is set by the caller and
- * afterwards owned (and freed) by libavcodec.
+ * afterwards owned (and freed) by libavcodec - it should never be read by
+ * the caller after being set.
  *
  * - decoding: This field should be set by the caller from the get_format()
  * callback. The previous reference (if any) will always be
@@ -3583,6 +3584,25 @@ typedef struct AVCodecContext {
  */
 int64_t max_pixels;
 
+/**
+ * A reference to the AVHWDeviceContext describing the device which will
+ * be used by a hardware encoder/decoder.  The reference is set by the
+ * caller and afterwards owned (and freed) by libavcodec - it should never
+ * be read by the caller after being set.
+ *
+ * This should only be used if either the codec device does not require
+ * hardware frames or any that are used are allocated internally by
+ * libavcodec.  If the user wishes to supply any of the frames used as
+ * encoder input or decoder output then hw_frames_ctx should be used
+ * instead.
+ *
+ * - decoding: This field should be set by the caller from the get_format()
+ * callback.  The previous reference (if any) will always be
+ * unreffed by libavcodec before the get_format() call.
+ *
+ * - encoding: This field should be set before avcodec_open2() is called.
+ */
+AVBufferRef *hw_device_ctx;
 } AVCodecContext;
 
 AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
-- 
2.11.0

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


Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming

2017-02-01 Thread Michael Niedermayer
On Wed, Feb 01, 2017 at 03:26:45PM +0100, wm4 wrote:
> On Wed,  1 Feb 2017 14:35:50 +0100
> Michael Niedermayer  wrote:
> 
> > Found-by: ubitux
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/internal.h | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavutil/internal.h b/libavutil/internal.h
> > index a19975d474..e97034887b 100644
> > --- a/libavutil/internal.h
> > +++ b/libavutil/internal.h
> > @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc,
> >  #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf")
> >  #endif
> >  
> > +// Rename shared function (both use and implementation of them) so they 
> > are not shared
> > +// and each library carries its own copy of a implementation, this is 
> > needed as
> 
> So why are they not appropriately named in the first place?
> 
> > +// the fd numbers are not transportable between libs on windows
> 
> AFAIK they are, as long as they're linked to the same stdlib (which
> probably is the case for libav*).

here is the commit introducing the first function using this system.
I belive its commit message is quite good and explains the reasoning.
Beyond that iam the wrong one to discuss this with, iam not a windows
developer and i didnt design this, which is not to say i like or
dislike it. I just added one function IIRC and i wanted to document it
as ubitux seemed to be confused for a moment when seeing it the first
time

commit e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65
Author: Martin Storsjö 
Date:   Fri Aug 9 11:06:46 2013 +0300

libavutil: Make avpriv_open a library-internal function on msvcrt

Add one copy of the function into each of the libraries, similarly
to what we do for log2_tab. When using static libs, only one
copy of the file_open.o object file gets included, while when
using shared libraries, each of them get a copy of its own.

This fixes DLL builds with a statically linked C runtime, where
each DLL effectively has got its own instance of the C runtime,
where file descriptors can't be shared across runtimes.

On systems not using msvcrt, the function is not duplicated.

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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


Re: [FFmpeg-devel] [PATCH] Allow borderless playback windows

2017-02-01 Thread Marton Balint


On Wed, 1 Feb 2017, Lucas Sandery wrote:


On 2017-02-01 12:34, Marton Balint wrote:
No, your code is not yet committed to the ffmpeg master repository, I am 
not sure which github repo you are referring to. So you might still change 
your mind. Also I plan to squash your two patches into one.


I managed to stuff up (and misuse) my local repo. Attached an updated patch.



Thanks, applied.

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-02-01 Thread compn
On Tue, 31 Jan 2017 17:34:55 +0100
DogFilm  wrote:

> I am still waitinng for an upload facility. Please send me an email
> so I can follow this. Also please consider removing that mis-leading
> information from ffmpeg error msgs, thanks, have to move on!

hi, please use this to upload your file:

http://streams.videolan.org/upload/

thank you.

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


Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-02-01 Thread Chris Cunningham
On Tue, Jan 31, 2017 at 10:18 PM, wm4  wrote:

> On Tue, 31 Jan 2017 12:02:01 -0800
> Chris Cunningham  wrote:
>
> > Thanks for taking a look.
> >
> > Definitely missing a "break;" - will fix in subsequent patch.
> >
> > Agree timestamps should be relative (didn't realize this). Vignesh points
> > out that "0" in the test file is due to a bug in ffmpeg (and probably
> other
> > muxers) where this value is not written as a relative timestamp, but
> > instead as the timestamp of the previous frame. https://github.com/FFmp
> > eg/FFmpeg/blob/master/libavformat/matroskaenc.c#L2053
> >  2FFFmpeg%2FFFmpeg%2Fblob%2Fmaster%2Flibavformat%
> 2Fmatroskaenc.c%23L2053=D=1=AFQjCNGs8m6GsWbhTvCZl0Q_juGAldQblA
> >
>
> Just a few lines below this reads
>
>mkv->last_track_timestamp[track_number - 1] = ts - mkv->cluster_pts;
>
> which looks like it intends to write a relative value. Though "ts" can
> be a DTS, while the other value is always a PTS.
>
> > Anyway, I'm all for following Haali. Its not obvious how best to do
> this. I
> > don't think there's any great default value to indicate "not-set" and the
> > generic embl parsing code that reads the reference timestamp doesn't
> really
> > lend itself to setting an additional field like
> > MatroskaBlock.has_reference. I can sort this out, but I'll pause in case
> > you have a recommendation in-mind.
>
> I don't know a nice way either. Here are 3 potential ways I came up
> with:
>
> 1. Use a better dummy value, like INT64_MIN, which is almost 100%
>unlikely to appear in a valid file. (This is probably equivalent to
>your intention in original patch.)
> 2. Add a new "presence_flag_offset" field to EbmlSyntax - the EBML
>reader will write a 1 to it if the element was found. (This is a bit
>annoying, because 0 is a valid offset, and you surely wouldn't want
>to change all the other element definitions.)
> 3. Add a new type like EBML_PRESENCE, which writes whether the element
>was present or not to data_offset, instead of the element's content
>or its default value. (There are some other special "types" like
>EBML_STOP, so maybe this idea isn't all too hacky.)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Sorry, for crossed threads - thanks for these ideas. I like the first
option best. Will upload a new patch using INT64_MIN and add the break; you
pointed out earlier.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

2017-02-01 Thread u-9iep
Hello,

On Sat, Jan 28, 2017 at 07:53:06PM +0100, Michael Niedermayer wrote:
> please provide a git compatible patch
> git format-patch / send-email

The corresponding patches (concerning comments in cinepak-related files)
have been resent in a git-compatible form 2017-01-29.
This patch applies after them.

It represents a large change in the Cinepak decoder for speed/efficiency.
Cinepak was always very good at speed, now it has become even (much) better.

Bought by the code size growth is a reduction of in-loop checking and
a capability to produce formats directly suitable for output devices,
without applying pixel format conversion afterwards to the whole frame.

Decoding to certain formats is also remarkably faster than to the default
rgb24, on i686
 to rgb32 seems to be about 15% faster than to rgb24
 to rgb565 seems to be over 20% faster than to rgb24

Besides this, on a slow device using a 16-bit depth provides a remarkable
speedup per se, compared to larger depths.

Avoiding frame pixel format conversion by generating rgb565 in the decoder
for a corresponsing video buffer yields in our tests (on MMX-capable
i*86) more than twice [sic] the playback speed compared to decoding to rgb24.

The default output format remains rgb24, with the full quality offered
by the codec.

Splitting this into multiple patches does not look very useful,
the changes make sense together.

Regards,
Rune
>From 300b8a4e712d1a404983b245aac501e09326ee72 Mon Sep 17 00:00:00 2001
From: Rl 
Date: Wed, 1 Feb 2017 19:44:40 +0100
Subject: [PATCH] Efficiently support several output pixel formats in Cinepak
 decoder

Optimize decoding in general and largely improve speed,
among others by the ability to produce device-native pixel formats.

The output format can be chosen at runtime by an option.

The format can be also chosen by setting environment variable
CINEPAK_OUTPUT_FORMAT_OVERRIDE, if this is enabled at build time.
---
 libavcodec/cinepak.c | 957 +--
 1 file changed, 845 insertions(+), 112 deletions(-)

diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index d657e9c0c1..76105fcc0c 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -31,6 +31,8 @@
  *
  * Cinepak colorspace support (c) 2013 Rl, Aetey Global Technologies AB
  * @author Cinepak colorspace, Rl, Aetey Global Technologies AB
+ * Extra output formats / optimizations (c) 2017 Rl, Aetey Global Technologies 
AB
+ * @author Extra output formats / optimizations, Rl, Aetey Global Technologies 
AB
  */
 
 #include 
@@ -39,23 +41,37 @@
 
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+/* #include "libavutil/avassert.h" */
 #include "avcodec.h"
 #include "internal.h"
 
+/* rounding to nearest is quite cheap in my tests
+ * and yields a remarkable quality improvement
+ * compared to simple truncation -- rl */
+#define PACK_RGB_RGB565(r,g,b) 
(((av_clip_uint8((r)+4)>>3)<<11)|((av_clip_uint8((g)+2)>>2)<<5)|(av_clip_uint8((b)+4)>>3))
 
-typedef uint8_t cvid_codebook[12];
+typedef union cvid_codebook {
+uint32_t  rgb32[256][ 4];
+uint8_t   rgb24[256][12];
+uint16_t rgb565[256][ 4];
+uint8_t  yuv420[256][ 6];
+uint8_tpal8[256][ 4];
+} cvid_codebook;
 
-#define MAX_STRIPS  32
+#define MAX_STRIPS  32/* an arbitrary limit -- rl */
 
 typedef struct cvid_strip {
 uint16_t  id;
 uint16_t  x1, y1;
 uint16_t  x2, y2;
-cvid_codebook v4_codebook[256];
-cvid_codebook v1_codebook[256];
+cvid_codebook v4_codebook;
+cvid_codebook v1_codebook;
 } cvid_strip;
 
-typedef struct CinepakContext {
+typedef struct CinepakContext CinepakContext;
+struct CinepakContext {
+const AVClass *class;
 
 AVCodecContext *avctx;
 AVFrame *frame;
@@ -71,24 +87,111 @@ typedef struct CinepakContext {
 int sega_film_skip_bytes;
 
 uint32_t pal[256];
-} CinepakContext;
 
-static void cinepak_decode_codebook (cvid_codebook *codebook,
- int chunk_id, int size, const uint8_t 
*data)
+void (*decode_codebook)(CinepakContext *s,
+cvid_codebook *codebook, int chunk_id,
+int size, const uint8_t *data);
+int  (*decode_vectors)(CinepakContext *s, cvid_strip *strip,
+   int chunk_id, int size, const uint8_t *data);
+/* options */
+enum AVPixelFormat out_pixfmt;
+};
+
+#define OFFSET(x) offsetof(CinepakContext, x)
+#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+static const AVOption options[] = {
+{"output_pixel_format", "set output pixel format: 
rgb24/rgb32/rgb565/yuv420p/pal8; yuv420p is approximate", OFFSET(out_pixfmt), 
AV_OPT_TYPE_PIXEL_FMT, {.i64=AV_PIX_FMT_RGB24}, -1, INT_MAX, VD },
+{ NULL },
+};
+
+static const AVClass cinepak_class = {
+.class_name = "cinepak decoder",
+.item_name  = 

Re: [FFmpeg-devel] [PATCH] avcodec/atrac3: Add multichannel joint stereo ATRAC3

2017-02-01 Thread Paul B Mahol
On 1/30/17, bananaman...@gmail.com  wrote:
> From: bnnm 
>
> Multichannel joint stereo simply interleaves stereo pairs (6ch: 2ch + 2ch +
> 2ch), so each pair is decoded separatedly.
>
> ***
>
> To test my changes, I converted examples to wav with ffmpeg.exe (old and
> new), and compared them to see they are byte-exact.
>
> Regular 2ch files (JS and normal) were straightforward to test.
>
> For multichannel, to check each JS pair is correctly decoded separatedly I
> did:
> - manually demux 6ch.msf into 3 pairs and convert them (2ch_1.wav +
> 2ch_2.wav + 2ch_3.wav)
> - convert the 6ch.msf file to wav (with my changes)
> - manually demux the 6ch.wav into 3 pairs (6ch_d1.wav + 6ch_d2.wav +
> 6ch_d3.wav)
> - compare each pair (ex. 2ch_3.wav vs 6ch_d3.wav): all pairs are byte-exact.
>
> The new code just processes each JS pair separatedly, there are no algorithm
> changes.
> It could be improved a bit but I'm not sure about typical styles.
> I've only seen 6ch .MSF (probably the AT3 spec only supports 2ch audio).
>
> Signed-off-by: bnnm 
> ---
>  libavcodec/atrac3.c | 160
> ++--
>  1 file changed, 91 insertions(+), 69 deletions(-)
>

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


Re: [FFmpeg-devel] [PATCH] [rfc] web/index request incoming ftp server

2017-02-01 Thread Compn
On Wed, 1 Feb 2017 17:45:16 +0100, Carl Eugen Hoyos  wrote:

> 2017-02-01 14:10 GMT+01:00 compn :
> 
> > [05:41]  Compn, http://streams.videolan.org/upload/
> > should work more or less
> >
> > ^ this is currently where we should send users to upload files.
> > an http uploader (not sure about resume support...).
> >
> > [05:49]  Compn, there will be no ftp access to streams, ever
> 
> Apart from the fact that this contradicts a promise that has been
> made:

yes i noticed that too. oh well. i've made the changes to mplayer DOCS, 
although it would be nice to also have a backup ftp server for people using old 
docs and the old ftp url. (todo: update urls in the homepage repo).

> How are we supposed to access the samples?

files uploaded with the vlc http upload
http://streams.videolan.org/upload/

are immediately accessable publically here, with no login.
http://streams.videolan.org/ffmpeg/incoming/

i just tested and all seems to be working. aside from having to put in a vlc 
version for ffmpeg and mplayer.

has anyone reviewed the files in
http://streams.videolan.org/ffmpeg/ 
?

go to http://streams.videolan.org/
and there is a dir for mplayer and mplayer/incoming as well

http://streams.videolan.org/MPlayer/
http://streams.videolan.org/MPlayer/incoming/

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


Re: [FFmpeg-devel] aac_latm: SSR is not implemented

2017-02-01 Thread Carl Eugen Hoyos
2017-02-01 5:06 GMT+01:00 Aman Gupta :
> I have a mpegts file with a HE-AAC audio track that cannot be decoded by
> ffmpeg. I have uploaded a sample at the link below, as requested by the
> decoder.

Maybe ticket #4544, thank you for the sample!

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


Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

2017-02-01 Thread James Almer
On 2/1/2017 9:42 AM, Kieran O Leary wrote:
> Hello,
> 
> I'm cc'ing Vittorio as I don't think that he's subscribed to the list but
> he's contributed to dpxenc.c and recent colorspace filters. The same with
> Kate Murray from the Library of Congress who knows a lot more about DPX
> than me. Apologies if this is inappropriate.
> 
> I mostly based this patch on other ffmpeg encoders, such as pncenc.c. I'm
> not really a C coder, I'm a moving image archivist who needs to be able to
> specify colour metadata in DPX for various workflows. Please excuse my
> ignorance/mistakes.
> 
> This patch adds documentation and two command line options for the DPX
> encoder:
> -trc (Transfer Characteristics) and -clr (Colorimetric Specification),

I may be missing something and apologizes if it was already mentioned, but
libavcodec already have options for these, color_trc and if i'm reading
this right colorspace, making use of the AVColorTransferCharacteristic and
AVColorSpace enums defined in avutil's pixfmt.h header.

Can't you use them instead?

> which set colour metadata values in a DPX file. Currently these are
> hardcoded to always be 2, aka Linear. Ticket #6023 is related to this, but
> there have also been many mailing list posts about this issue:
> https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025630.html
> https://ffmpeg.org/pipermail/ffmpeg-user/2015-December/029456.html

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


Re: [FFmpeg-devel] [PATCH] [rfc] web/index request incoming ftp server

2017-02-01 Thread Carl Eugen Hoyos
2017-02-01 14:10 GMT+01:00 compn :

> [05:41]  Compn, http://streams.videolan.org/upload/
> should work more or less
>
> ^ this is currently where we should send users to upload files.
> an http uploader (not sure about resume support...).
>
> [05:49]  Compn, there will be no ftp access to streams, ever

Apart from the fact that this contradicts a promise that has been
made:
How are we supposed to access the samples?

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


Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

2017-02-01 Thread Carl Eugen Hoyos
2017-02-01 13:42 GMT+01:00 Kieran O Leary :

> +static const AVOption options[] = {
> +{"trc", "Transfer Characteristics", OFFSET(transfer_characteristic),
> AV_OPT_TYPE_INT, {.i64 = 2}, 0, 12, VE },
> +{"clr", "Colorimetric Specification",
> OFFSET(colorimetric_specification), AV_OPT_TYPE_INT, {.i64 = 2}, 0, 12, VE
> },

I would have expected that the values that are written into
the output files come from AVCodecContext->color_trc
and AVCodecContext->color_primaries, not from codec
specific options.

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


Re: [FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

2017-02-01 Thread Steinar H. Gunderson
On Wed, Feb 01, 2017 at 02:17:05AM +0100, Andreas Cadhalpun wrote:
>> Would you mind sharing an input where this actually triggers? None of the
>> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
>> input.
> Indeed it is. I've sent you a sample.

Could you please try the attached patch?

/* Steinar */
-- 
Homepage: https://www.sesse.net/
>From d1c914f869edfc4326e86b1b0c161249196e6900 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" 
Date: Wed, 1 Feb 2017 17:19:18 +0100
Subject: [PATCH] speedhq: fix out-of-bounds write

Certain alpha run lengths (for SHQ1/SHQ3/SHQ5) could be stored in
both long and short versions, and we would only accept the short version,
returning -1 (invalid code) for the others. This could cause an
out-of-bounds write on malicious input, as discovered by
Andreas Cadhalpun during fuzzing.

Fix by simply allowing both versions, leaving no invalid codes
in the alpha VLC.
---
 libavcodec/speedhq.c | 128 +++
 libavcodec/vlc.h |  15 --
 2 files changed, 89 insertions(+), 54 deletions(-)

diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 30160dd3f2..49609342af 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -196,7 +196,7 @@ static inline int decode_alpha_block(const SHQContext *s, GetBitContext *gb, uin
 UPDATE_CACHE_LE(re, gb);
 GET_VLC(run, re, gb, ff_dc_alpha_run_vlc_le.table, ALPHA_VLC_BITS, 2);
 
-if (run == 128) break;
+if (run < 0) break;
 i += run;
 if (i >= 128)
 return AVERROR_INVALIDDATA;
@@ -474,61 +474,89 @@ static int speedhq_decode_frame(AVCodecContext *avctx,
  */
 static av_cold void compute_alpha_vlcs(void)
 {
-uint16_t run_code[129], level_code[256];
-uint8_t run_bits[129], level_bits[256];
-int run, level;
-
-for (run = 0; run < 128; run++) {
-if (!run) {
-/* 0 -> 0. */
-run_code[run] = 0;
-run_bits[run] = 1;
-} else if (run <= 4) {
-/* 10xx -> xx plus 1. */
-run_code[run] = ((run - 1) << 2) | 1;
-run_bits[run] = 4;
-} else {
-/* 111xxx -> . */
-run_code[run] = (run << 3) | 7;
-run_bits[run] = 10;
-}
+uint16_t run_code[134], level_code[266];
+uint8_t run_bits[134], level_bits[266];
+int16_t run_symbols[134], level_symbols[266];
+int entry, i, sign;
+
+/* Initialize VLC for alpha run. */
+entry = 0;
+
+/* 0 -> 0. */
+run_code[entry] = 0;
+run_bits[entry] = 1;
+run_symbols[entry] = 0;
+++entry;
+
+/* 10xx -> xx plus 1. */
+for (i = 0; i < 4; ++i) {
+run_code[entry] = (i << 2) | 1;
+run_bits[entry] = 4;
+run_symbols[entry] = i + 1;
+++entry;
+}
+
+/* 111xxx -> xxx. */
+for (i = 0; i < 128; ++i) {
+run_code[entry] = (i << 3) | 7;
+run_bits[entry] = 10;
+run_symbols[entry] = i;
+++entry;
 }
 
 /* 110 -> EOB. */
-run_code[128] = 3;
-run_bits[128] = 3;
-
-INIT_LE_VLC_STATIC(_dc_alpha_run_vlc_le, ALPHA_VLC_BITS, 129,
-   run_bits, 1, 1,
-   run_code, 2, 2, 160);
-
-for (level = 0; level < 256; level++) {
-int8_t signed_level = (int8_t)level;
-int abs_signed_level = abs(signed_level);
-int sign = (signed_level < 0) ? 1 : 0;
-
-if (abs_signed_level == 1) {
-/* 1s -> -1 or +1 (depending on sign bit). */
-level_code[level] = (sign << 1) | 1;
-level_bits[level] = 2;
-} else if (abs_signed_level >= 2 && abs_signed_level <= 5) {
-/* 01sxx -> xx plus 2 (2..5 or -2..-5, depending on sign bit). */
-level_code[level] = ((abs_signed_level - 2) << 3) | (sign << 2) | 2;
-level_bits[level] = 5;
-} else {
-/*
- * 00 -> , in two's complement. 0 is technically an
- * illegal code (that would be encoded by increasing run), but it
- * doesn't hurt and simplifies indexing.
- */
-level_code[level] = level << 2;
-level_bits[level] = 10;
+run_code[entry] = 3;
+run_bits[entry] = 3;
+run_symbols[entry] = -1;
+++entry;
+
+av_assert0(entry == FF_ARRAY_ELEMS(run_code));
+
+INIT_LE_VLC_SPARSE_STATIC(_dc_alpha_run_vlc_le, ALPHA_VLC_BITS,
+  FF_ARRAY_ELEMS(run_code),
+  run_bits, 1, 1,
+  run_code, 2, 2,
+  run_symbols, 2, 2, 160);
+
+/* Initialize VLC for alpha level. */
+entry = 0;
+
+for (sign = 0; sign <= 1; ++sign) {
+/* 1s -> -1 or +1 (depending on sign bit). */
+level_code[entry] = (sign << 1) | 1;
+level_bits[entry] = 2;
+

Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

2017-02-01 Thread Eran Kornblau
> 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> Sent: Wednesday, February 1, 2017 3:53 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] mov: support for multiple edits and cenc 
> decryption
> 
> ill apply the patches in a moment
> 
Thanks Michael!

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


Re: [FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming

2017-02-01 Thread wm4
On Wed,  1 Feb 2017 14:35:50 +0100
Michael Niedermayer  wrote:

> Found-by: ubitux
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/internal.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index a19975d474..e97034887b 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc,
>  #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf")
>  #endif
>  
> +// Rename shared function (both use and implementation of them) so they are 
> not shared
> +// and each library carries its own copy of a implementation, this is needed 
> as

So why are they not appropriately named in the first place?

> +// the fd numbers are not transportable between libs on windows

AFAIK they are, as long as they're linked to the same stdlib (which
probably is the case for libav*).

>  #define avpriv_open ff_open
>  #define avpriv_tempfile ff_tempfile
> +
>  #define PTRDIFF_SPECIFIER "Id"
>  #define SIZE_SPECIFIER "Iu"
>  #else

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls_flag option to create segments atomically

2017-02-01 Thread Bodecs Bela



2017.01.31. 21:29 keltezéssel, Aman Gupta írta:

From: Aman Gupta 

Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete
and before the file is added to the m3u8 playlist.

This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
---
  libavformat/hlsenc.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..23b9011 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -76,6 +76,7 @@ typedef enum HLSFlags {
  HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in 
segment filenames when use_localtime  e.g.: %%03d
  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size 
(bytes) in segment filenames when use_localtime  e.g.: %%014s
+HLS_TEMP_FILE = (1 << 11),
  } HLSFlags;
  
  typedef enum {

@@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
  
  set_http_options(, c);
  
+if (c->flags & HLS_TEMP_FILE) {

+av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
+}
+
  if (c->key_info_file) {
  if ((err = hls_encryption_start(s)) < 0)
  goto fail;
@@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  
  av_write_frame(oc, NULL); /* Flush any buffered data */
  
+if (hls->flags & HLS_TEMP_FILE) {

+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';
+}
+
  new_start_pos = avio_tell(hls->avf->pb);
  hls->size = new_start_pos - hls->start_pos;
  ret = hls_append_segment(s, hls, hls->duration, hls->start_pos, 
hls->size);
@@ -1406,6 +1420,7 @@ static const AVOption options[] = {
  {"hls_subtitle_path", "set path of hls subtitles", 
OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
  {"hls_flags", "set flags affecting HLS playlist and media file generation", 
OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E, "flags"},
  {"single_file",   "generate a single media file indexed with byte ranges", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E, "flags"},
+{"temp_file", "write segment to temporary file and rename when complete", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E, "flags"},
  {"delete_segments", "delete segment files that are no longer part of the playlist", 
0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0, UINT_MAX,   E, "flags"},
  {"round_durations", "round durations in m3u8 to whole numbers", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E, "flags"},
  {"discont_start", "start the playlist with a discontinuity tag", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
I think the phrase  in your email subject "to create atomically" 
misleading because another renaming may occur afterwards your temp 
renaming if second_level_segment_size or second_level_segment_duration 
flag is on.
But the idea to write segment content into a temp file is good by me. To 
ensure the amoticity the two distinct renamings may be merged.


I have never thought of it but after your idea I concluded  that the 
segment file names are predictable.
In live streaming enviroment somebody predicting the segment name may 
see the program some seconds earlier than any other viewer by 
downloading the unpublished segment. (with one segment duration seconds 
earlier)
If the temp file name would be random name, then your idea may be seen 
as a security feature.

What is your opinion about this possibility?

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


Re: [FFmpeg-devel] [PATCH 1/6] lavc: Add device context field to AVCodecContext

2017-02-01 Thread Timo Rothenpieler
Am 17.01.2017 um 23:28 schrieb Mark Thompson:
> For use by codec implementations which require a device to operation
> but will allocate frames internally.
> ---
> The following patches make use of it for qsv.  Is this definition appropriate 
> to solve the issues with cuvid device setup as well?
> 
> 
>  doc/APIchanges   |  3 +++
>  libavcodec/avcodec.h | 38 --
>  libavcodec/utils.c   |  1 +
>  libavcodec/version.h |  2 +-
>  4 files changed, 41 insertions(+), 3 deletions(-)

ping about this.
I'd really like to use it for cuvid and get rid of some hackery.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-02-01 Thread Timo Rothenpieler
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

2017-02-01 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 06:20:24PM +, Eran Kornblau wrote:
> > On Tue, Jan 31, 2017 at 06:28:16PM +0100, Michael Niedermayer wrote:
> > > On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> > > > patch looks good to me.
> > > 
> > > applied
> > 
> > maybe i asked already but it seems the Author field of your commits is 
> > inconsistet in git
> > 
> > some say:
> > Author: erankor 
> > 
> > some say:
> > Author: Eran Kornblau 
> > 
> > Is the way the patches are intended ?
> > Just double checking as it cannot be changed later 
> > 
> 
> Thanks Michael & Sasi!
> 
> My GitHub user is erankor, that's the user that should be used.
> I've just checked this patch and it says 'erankor', where did you see 'Eran 
> Kornblau'?

in existing commits in git

ill apply the patches in a moment

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

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


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


Re: [FFmpeg-devel] [PATCH] avfilter/scale: refactor common code for scaling height/width expressions

2017-02-01 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 04:46:25PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Implements support for height/width expressions in vf_scale_vaapi,
> by refactoring common code into a new libavfilter/scale.c
> ---
>  libavfilter/Makefile |   8 +--
>  libavfilter/scale.c  | 143 
> +++
>  libavfilter/scale.h  |  31 ++
>  libavfilter/vf_scale.c   | 109 +++--
>  libavfilter/vf_scale_npp.c   |  87 +++---
>  libavfilter/vf_scale_vaapi.c |  18 +-
>  6 files changed, 208 insertions(+), 188 deletions(-)
>  create mode 100644 libavfilter/scale.c
>  create mode 100644 libavfilter/scale.h
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 68a94be..3231f08 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -257,10 +257,10 @@ OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += 
> vf_repeatfields.o
>  OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
>  OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
>  OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
> -OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
> -OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o
> -OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
> -OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
> +OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
> +OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
> +OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> +OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
>  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
>  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
>  OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
> diff --git a/libavfilter/scale.c b/libavfilter/scale.c
> new file mode 100644
> index 000..b0f4be2
> --- /dev/null
> +++ b/libavfilter/scale.c
> @@ -0,0 +1,143 @@
> +/*
> + * This file is part of FFmpeg.

Theres a copyright line in libavfilter/vf_scale.c
but none in the file the code is moved too


> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "scale.h"
> +
> +static const char *const var_names[] = {
> +"PI",
> +"PHI",
> +"E",
> +"in_w",   "iw",
> +"in_h",   "ih",
> +"out_w",  "ow",
> +"out_h",  "oh",
> +"a",
> +"sar",
> +"dar",
> +"hsub",
> +"vsub",
> +"ohsub",
> +"ovsub",
> +NULL
> +};
> +
> +enum var_name {
> +VAR_PI,
> +VAR_PHI,
> +VAR_E,
> +VAR_IN_W,   VAR_IW,
> +VAR_IN_H,   VAR_IH,
> +VAR_OUT_W,  VAR_OW,
> +VAR_OUT_H,  VAR_OH,
> +VAR_A,
> +VAR_SAR,
> +VAR_DAR,
> +VAR_HSUB,
> +VAR_VSUB,
> +VAR_OHSUB,
> +VAR_OVSUB,
> +VARS_NB
> +};
> +

> +int ff_scale_eval_dimensions(void *ctx,

please call ctx, log_ctx


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

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


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


[FFmpeg-devel] [PATCH] avutil/internal: Document ugly looking windows specific file related function renaming

2017-02-01 Thread Michael Niedermayer
Found-by: ubitux
Signed-off-by: Michael Niedermayer 
---
 libavutil/internal.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index a19975d474..e97034887b 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -243,8 +243,12 @@ void avpriv_request_sample(void *avc,
 #pragma comment(linker, "/include:" EXTERN_PREFIX "avpriv_snprintf")
 #endif
 
+// Rename shared function (both use and implementation of them) so they are 
not shared
+// and each library carries its own copy of a implementation, this is needed as
+// the fd numbers are not transportable between libs on windows
 #define avpriv_open ff_open
 #define avpriv_tempfile ff_tempfile
+
 #define PTRDIFF_SPECIFIER "Id"
 #define SIZE_SPECIFIER "Iu"
 #else
-- 
2.11.0

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread wm4
On Wed, 1 Feb 2017 14:17:19 +0100
Paul B Mahol  wrote:

> On 2/1/17, wm4  wrote:
> > On Wed, 1 Feb 2017 13:31:46 +0100
> > Robert Krueger  wrote:
> >  
> >> On Wed, Feb 1, 2017 at 1:07 PM, wm4  wrote:
> >>  
> >> > On Wed,  1 Feb 2017 12:50:51 +0100
> >> > Paul B Mahol  wrote:
> >> >  
> >> > > Signed-off-by: Paul B Mahol 
> >> > > ---
> >> > >  libavformat/mov.c | 25 +
> >> > >  1 file changed, 25 insertions(+)
> >> > >
> >> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> > > index 9ae4f8c..75e1c9c60 100644
> >> > > --- a/libavformat/mov.c
> >> > > +++ b/libavformat/mov.c
> >> > > @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c,  
> >> > AVIOContext *pb, MOVAtom atom)  
> >> > >  return 0;
> >> > >  }
> >> > >
> >> > > +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> >> > > +{
> >> > > +uint8_t *xml;
> >> > > +
> >> > > +if (atom.size < 5)
> >> > > +return 0;
> >> > > +
> >> > > +avio_skip(pb, 4);
> >> > > +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
> >> > > +if (!xml)
> >> > > +return AVERROR(ENOMEM);
> >> > > +
> >> > > +avio_read(pb, xml, atom.size - 4);
> >> > > +av_dict_set(>fc->metadata, "xml", xml, 0);
> >> > > +av_free(xml);
> >> > > +
> >> > > +return 0;
> >> > > +}
> >> > > +
> >> > >  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom
> >> > > atom)
> >> > >  {
> >> > >  int64_t end = avio_tell(pb) + atom.size;
> >> > > @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,  
> >> > AVIOContext *pb, MOVAtom atom)  
> >> > >  parse = mov_read_keys;
> >> > >  }
> >> > >
> >> > > +if (!parse &&
> >> > > +atom.type == MKTAG('m','e','t','a') &&
> >> > > +a.type == MKTAG('x','m','l',' ')) {
> >> > > +parse = mov_read_xml;
> >> > > +}
> >> > > +
> >> > >  if (!parse) { /* skip leaf atoms data */
> >> > >  avio_skip(pb, a.size);
> >> > >  } else {  
> >> >
> >> > We had this discussion recently: the metadata AVDictionary should
> >> > probably only contain real tags, not other information that's contained
> >> > in the format but for which libavformat has no good way to export yet.
> >> >
> >> > There needs to be a concept for distinguishing user-visible tags and
> >> > other data.
> >> >
> >> > (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
> >> > do you?)
> >> >
> >> >  
> >> I thought that was already the case for XMP (i.e. xml) metadata embedded
> >> in
> >> mov. I must look up how that was handled. I seem to remember there was a
> >> flag to suppress this on the command line. With the policy you propose,
> >> libavformat will be of a lot less use for api users. Not that I had a vote
> >> here. It's just 2c of an api user.  
> >
> > I'm not voting for removing it, just that there should be a separate
> > mechanism for this.  
> 
> Can you define/explain such thing in detail?
> If not I will use current approach.

Using side data. Or maybe just a different metadata field. Or clearly
defining which keys are internal and which are meant to be shown to the
user as text (as far as specified by the file format).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread Paul B Mahol
On 2/1/17, wm4  wrote:
> On Wed, 1 Feb 2017 13:31:46 +0100
> Robert Krueger  wrote:
>
>> On Wed, Feb 1, 2017 at 1:07 PM, wm4  wrote:
>>
>> > On Wed,  1 Feb 2017 12:50:51 +0100
>> > Paul B Mahol  wrote:
>> >
>> > > Signed-off-by: Paul B Mahol 
>> > > ---
>> > >  libavformat/mov.c | 25 +
>> > >  1 file changed, 25 insertions(+)
>> > >
>> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > > index 9ae4f8c..75e1c9c60 100644
>> > > --- a/libavformat/mov.c
>> > > +++ b/libavformat/mov.c
>> > > @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c,
>> > AVIOContext *pb, MOVAtom atom)
>> > >  return 0;
>> > >  }
>> > >
>> > > +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> > > +{
>> > > +uint8_t *xml;
>> > > +
>> > > +if (atom.size < 5)
>> > > +return 0;
>> > > +
>> > > +avio_skip(pb, 4);
>> > > +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
>> > > +if (!xml)
>> > > +return AVERROR(ENOMEM);
>> > > +
>> > > +avio_read(pb, xml, atom.size - 4);
>> > > +av_dict_set(>fc->metadata, "xml", xml, 0);
>> > > +av_free(xml);
>> > > +
>> > > +return 0;
>> > > +}
>> > > +
>> > >  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom
>> > > atom)
>> > >  {
>> > >  int64_t end = avio_tell(pb) + atom.size;
>> > > @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,
>> > AVIOContext *pb, MOVAtom atom)
>> > >  parse = mov_read_keys;
>> > >  }
>> > >
>> > > +if (!parse &&
>> > > +atom.type == MKTAG('m','e','t','a') &&
>> > > +a.type == MKTAG('x','m','l',' ')) {
>> > > +parse = mov_read_xml;
>> > > +}
>> > > +
>> > >  if (!parse) { /* skip leaf atoms data */
>> > >  avio_skip(pb, a.size);
>> > >  } else {
>> >
>> > We had this discussion recently: the metadata AVDictionary should
>> > probably only contain real tags, not other information that's contained
>> > in the format but for which libavformat has no good way to export yet.
>> >
>> > There needs to be a concept for distinguishing user-visible tags and
>> > other data.
>> >
>> > (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
>> > do you?)
>> >
>> >
>> I thought that was already the case for XMP (i.e. xml) metadata embedded
>> in
>> mov. I must look up how that was handled. I seem to remember there was a
>> flag to suppress this on the command line. With the policy you propose,
>> libavformat will be of a lot less use for api users. Not that I had a vote
>> here. It's just 2c of an api user.
>
> I'm not voting for removing it, just that there should be a separate
> mechanism for this.

Can you define/explain such thing in detail?
If not I will use current approach.

>
> And I as API user are very bothered by irrelevant crap being dumped
> in what should return user tags (that can be displayed to a user), or
> the fact that these can even show up in remuxes.
>
> Example: just what is the use of "crap" like MAJOR_BRAND or
> COMPATIBLE_BRANDS in Matroska tags? Yeah, let's add some
> meaningless XML garbage to produced files as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] [rfc] web/index request incoming ftp server

2017-02-01 Thread compn
On Wed, 1 Feb 2017 07:34:11 +0100
wm4  wrote:

> On Wed, 1 Feb 2017 00:09:41 -0500
> compn  wrote:
> 
> > not sure if this is the right way to do it, maybe its easier to ask
> > for someone on twitter?
> > 
> > it would be nice to have a backup just in case videolan has
> > problems. then we dont have to ask users to use datafilehost heh.
> > 
> > i dont want to burden ffmpeg admins to maintain some ftp either.
> > 
> > carl, what do you think?
> > ideas welcome.
> > 
> > -compn
> 
> Who maintains this piece of infrastructure at all?

videolan maintained the server, carl does most of the moving files to
our samples repo and bug trac.

but heres the new news from #videolan:

[05:41]  Compn, http://streams.videolan.org/upload/ should work
more or less

^ this is currently where we should send users to upload files. an http
uploader (not sure about resume support...).

[05:49]  Compn, there will be no ftp access to streams, ever
[05:50]  Compn, we're following the Great Leadership of
kernel.org

^^ this is the news on the ftp that we currently have in our docs. so
we should change all of our docs over to the http uploader.

also i suggest we ask for a backup ftp server from another host (by
applying this or similar patch), for those people who prefer to use ftp.

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread wm4
On Wed, 1 Feb 2017 13:31:46 +0100
Robert Krüger  wrote:

> On Wed, Feb 1, 2017 at 1:07 PM, wm4  wrote:
> 
> > On Wed,  1 Feb 2017 12:50:51 +0100
> > Paul B Mahol  wrote:
> >  
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavformat/mov.c | 25 +
> > >  1 file changed, 25 insertions(+)
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index 9ae4f8c..75e1c9c60 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c,  
> > AVIOContext *pb, MOVAtom atom)  
> > >  return 0;
> > >  }
> > >
> > > +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > > +{
> > > +uint8_t *xml;
> > > +
> > > +if (atom.size < 5)
> > > +return 0;
> > > +
> > > +avio_skip(pb, 4);
> > > +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
> > > +if (!xml)
> > > +return AVERROR(ENOMEM);
> > > +
> > > +avio_read(pb, xml, atom.size - 4);
> > > +av_dict_set(>fc->metadata, "xml", xml, 0);
> > > +av_free(xml);
> > > +
> > > +return 0;
> > > +}
> > > +
> > >  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > >  {
> > >  int64_t end = avio_tell(pb) + atom.size;
> > > @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,  
> > AVIOContext *pb, MOVAtom atom)  
> > >  parse = mov_read_keys;
> > >  }
> > >
> > > +if (!parse &&
> > > +atom.type == MKTAG('m','e','t','a') &&
> > > +a.type == MKTAG('x','m','l',' ')) {
> > > +parse = mov_read_xml;
> > > +}
> > > +
> > >  if (!parse) { /* skip leaf atoms data */
> > >  avio_skip(pb, a.size);
> > >  } else {  
> >
> > We had this discussion recently: the metadata AVDictionary should
> > probably only contain real tags, not other information that's contained
> > in the format but for which libavformat has no good way to export yet.
> >
> > There needs to be a concept for distinguishing user-visible tags and
> > other data.
> >
> > (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
> > do you?)
> >
> >  
> I thought that was already the case for XMP (i.e. xml) metadata embedded in
> mov. I must look up how that was handled. I seem to remember there was a
> flag to suppress this on the command line. With the policy you propose,
> libavformat will be of a lot less use for api users. Not that I had a vote
> here. It's just 2c of an api user.

I'm not voting for removing it, just that there should be a separate
mechanism for this.

And I as API user are very bothered by irrelevant crap being dumped
in what should return user tags (that can be displayed to a user), or
the fact that these can even show up in remuxes.

Example: just what is the use of "crap" like MAJOR_BRAND or
COMPATIBLE_BRANDS in Matroska tags? Yeah, let's add some
meaningless XML garbage to produced files as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 5/6] opus_celt: rename structures to better names and reorganize them

2017-02-01 Thread Rostislav Pehlivanov
On 1 February 2017 at 11:51, Michael Niedermayer  wrote:

> On Wed, Feb 01, 2017 at 03:13:08AM +, Rostislav Pehlivanov wrote:
> > This is meant to be applied on top of my previous patch which
> > split PVQ into celt_pvq.c and made opus_celt.h
> >
> > Essentially nothing has been changed other than renaming CeltFrame
> > to CeltBlock (CeltFrame had absolutely nothing at all to do with
> > a frame) and CeltContext to CeltFrame.
> > 3 variables have been put in CeltFrame as they make more sense
> > there rather than being passed around as arguments.
> > The coefficients have been moved to the CeltBlock structure
> > (why the hell were they in CeltContext and not in CeltFrame??).
> >
> > Now the encoder would be able to use the exact context the decoder
> > uses (plus a couple of extra fields in there).
> >
> > FATE passes, no slowdowns, etc.
>
> This doesnt build on arm-linux-gnueabi-gcc-4.5
> (i think arm is unrelated here)
>
> In file included from src/libavcodec/opus_celt.c:28:0:
> src/libavcodec/opus_celt.h:134:3: error: redefinition of typedef
> ‘CeltFrame’
> src/libavcodec/opus.h:82:26: note: previous declaration of ‘CeltFrame’ was
> here
> make: *** [libavcodec/opus_celt.o] Error 1
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Seems older GCC versions are unhappy.
Removed the typedef from the struct definition in opus_celt.h and attached
new patch
From 5038a9894e8bd4c62b5a7e219fe49217890d5674 Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov 
Date: Thu, 10 Nov 2016 16:12:53 +
Subject: [PATCH] opus_celt: rename structures to better names and reorganize
 them

This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h

Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have been put in CeltFrame as they make more sense
there rather than being passed around as arguments.
The coefficients have been moved to the CeltBlock structure
(why the hell were they in CeltContext and not in CeltFrame??).

Now the encoder would be able to use the exact context the decoder
uses (plus a couple of extra fields in there).

FATE passes, no slowdowns, etc.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus.h  |  22 +-
 libavcodec/opus_celt.c | 722 -
 libavcodec/opus_celt.h |  91 ---
 libavcodec/opus_pvq.c  |  50 ++--
 libavcodec/opus_pvq.h  |   2 +-
 libavcodec/opusdec.c   |   7 +-
 libavcodec/opustab.c   |   4 +
 libavcodec/opustab.h   |   4 +
 8 files changed, 459 insertions(+), 443 deletions(-)

diff --git a/libavcodec/opus.h b/libavcodec/opus.h
index be042497ea..c3cbaec35d 100644
--- a/libavcodec/opus.h
+++ b/libavcodec/opus.h
@@ -62,7 +62,9 @@ static const uint8_t opus_default_extradata[30] = {
 enum OpusMode {
 OPUS_MODE_SILK,
 OPUS_MODE_HYBRID,
-OPUS_MODE_CELT
+OPUS_MODE_CELT,
+
+OPUS_MODE_NB
 };
 
 enum OpusBandwidth {
@@ -70,12 +72,14 @@ enum OpusBandwidth {
 OPUS_BANDWIDTH_MEDIUMBAND,
 OPUS_BANDWIDTH_WIDEBAND,
 OPUS_BANDWIDTH_SUPERWIDEBAND,
-OPUS_BANDWIDTH_FULLBAND
+OPUS_BANDWIDTH_FULLBAND,
+
+OPUS_BANDWITH_NB
 };
 
 typedef struct SilkContext SilkContext;
 
-typedef struct CeltContext CeltContext;
+typedef struct CeltFrame CeltFrame;
 
 typedef struct OpusPacket {
 int packet_size;/**< packet size */
@@ -100,7 +104,7 @@ typedef struct OpusStreamContext {
 OpusRangeCoder rc;
 OpusRangeCoder redundancy_rc;
 SilkContext *silk;
-CeltContext *celt;
+CeltFrame *celt;
 AVFloatDSPContext *fdsp;
 
 float silk_buf[2][960];
@@ -185,14 +189,4 @@ int ff_silk_decode_superframe(SilkContext *s, OpusRangeCoder *rc,
   enum OpusBandwidth bandwidth, int coded_channels,
   int duration_ms);
 
-int ff_celt_init(AVCodecContext *avctx, CeltContext **s, int output_channels);
-
-void ff_celt_free(CeltContext **s);
-
-void ff_celt_flush(CeltContext *s);
-
-int ff_celt_decode_frame(CeltContext *s, OpusRangeCoder *rc,
- float **output, int coded_channels, int frame_size,
- int startband,  int endband);
-
 #endif /* AVCODEC_OPUS_H */
diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index 71ef8965e2..af3c100e6e 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2012 Andrew D'Addesio
  * Copyright (c) 2013-2014 Mozilla Corporation
+ * Copyright (c) 2016 Rostislav Pehlivanov 

[FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

2017-02-01 Thread Kieran O Leary
Hello,

I'm cc'ing Vittorio as I don't think that he's subscribed to the list but
he's contributed to dpxenc.c and recent colorspace filters. The same with
Kate Murray from the Library of Congress who knows a lot more about DPX
than me. Apologies if this is inappropriate.

I mostly based this patch on other ffmpeg encoders, such as pncenc.c. I'm
not really a C coder, I'm a moving image archivist who needs to be able to
specify colour metadata in DPX for various workflows. Please excuse my
ignorance/mistakes.

This patch adds documentation and two command line options for the DPX
encoder:
-trc (Transfer Characteristics) and -clr (Colorimetric Specification),
which set colour metadata values in a DPX file. Currently these are
hardcoded to always be 2, aka Linear. Ticket #6023 is related to this, but
there have also been many mailing list posts about this issue:
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025630.html
https://ffmpeg.org/pipermail/ffmpeg-user/2015-December/029456.html

I've kept the default values as 2 (Linear) as this is what was originally
in dpxenc, but I'm not sure of the value of this really. I think that
there's more value in a default of 0 (User-defined) which would just leave
the values unspecified. Or perhaps no value at all! The initial default of
2 for colorimetric was potentially useless as 2 is listed as 'Not
applicable' for colorimetric specification in SMPTE 268M-2003.

The values for each of these options are the integers listed in the SMPTE
standards doc:
https://web.archive.org/web/20050706060025/http://www.smpte.org/smpte_store/standards/pdf/s268m.pdf

Initially I just had one argument that set the Transfer Characteristic and
Colorimetric Specification to the same value, but perhaps some use cases
could require that these values  be different? I'm not sure if they ever
would. I have never seen real world files that suggest this but I can edit
this if it seems weird.

Some of the values from 0-12 are listed as 'Not applicable' for the
colorimetric specification, but I didn't know how to specify just those
numbers (0-1, 4-10) in the patch. Perhaps it's OK to leave it as is,
otherwise hopefully someone can point me to similar code that I can learn
from. Again, apologies for my ignorance.

I'm attaching the patch and pasting it here too:

>From 8ae63b8301e6822686a7885202938fd6e4cba6f2 Mon Sep 17 00:00:00 2001
From: Kieran O'Leary 
Date: Wed, 1 Feb 2017 12:06:38 +
Subject: [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder,
fixes
 ticket #6023

---
 doc/encoders.texi   | 77
+
 libavcodec/dpxenc.c | 25 ++---
 2 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8137465..d3d8eb2 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1269,6 +1269,83 @@ disabled
 A description of some of the currently available video encoders
 follows.

+@section dpx
+
+DPX image encoder.
+
+@subsection Options
+
+@table @option
+@item trc @var{integer}
+Set the transfer characteristics as listed in Table 5A in SMPTE 268M-2003:
+
+@table @samp
+@item 0
+User Defined
+@item 1
+Printing Density
+@item 2
+Linear
+@item 3
+Logarithmic [to be defined by SMPTE I23 Technology Committee, sub-group on
“Transfer Characteristics”]
+@item 4
+Unspecified Video
+@item 5
+SMPTE 274M
+@item 6
+ITU-R 709-4
+@item 7
+ITU-R 601-5 system B or G (625)
+@item 8
+ITU-R 601-5 system M (525)
+@item 9
+Composite video (NTSC); see SMPTE 170M
+@item 10
+Composite video (PAL); see ITU-R 624-4
+@item 11
+Z (depth) – linear
+@item 12
+Z (depth) – homogeneous (distance to screen and angle of view must also be
specified in user-defined section)
+@end table
+
+Default value is @var{2}.
+
+@item clr @var{integer}
+Set the Colorimetric Specification as listed in Table 5B in SMPTE
268M-2003:
+
+@table @samp
+@item 0
+User Defined
+@item 1
+Printing Density
+@item 2
+Not applicable
+@item 3
+Not Applicable
+@item 4
+Unspecified Video
+@item 5
+SMPTE 274M
+@item 6
+ITU-R 709-4
+@item 7
+ITU-R 601-5 system B or G (625)
+@item 8
+ITU-R 601-5 system M (525)
+@item 9
+Composite video (NTSC); see SMPTE 170M
+@item 10
+Composite video (PAL); see ITU-R 624-4
+@item 11
+Not applicable
+@item 12
+Not applicable
+@end table
+
+Default value is @var{2}.
+
+@end table
+
 @section Hap

 Vidvox Hap video encoder.
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index a596033..3b0e890 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -24,15 +24,20 @@
 #include "libavutil/imgutils.h"
 #include "avcodec.h"
 #include "internal.h"
+#include "libavutil/opt.h"

 typedef struct DPXContext {
+AVClass *class;
 int big_endian;
 int bits_per_component;
 int num_components;
 int descriptor;
 int planar;
+int transfer_characteristic;
+int colorimetric_specification;
 } DPXContext;

+
 static av_cold int encode_init(AVCodecContext *avctx)
 {
 

Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread Paul B Mahol
On 2/1/17, Robert Krueger  wrote:
> On Wed, Feb 1, 2017 at 1:07 PM, wm4  wrote:
>
>> On Wed,  1 Feb 2017 12:50:51 +0100
>> Paul B Mahol  wrote:
>>
>> > Signed-off-by: Paul B Mahol 
>> > ---
>> >  libavformat/mov.c | 25 +
>> >  1 file changed, 25 insertions(+)
>> >
>> > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > index 9ae4f8c..75e1c9c60 100644
>> > --- a/libavformat/mov.c
>> > +++ b/libavformat/mov.c
>> > @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> >  return 0;
>> >  }
>> >
>> > +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> > +{
>> > +uint8_t *xml;
>> > +
>> > +if (atom.size < 5)
>> > +return 0;
>> > +
>> > +avio_skip(pb, 4);
>> > +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
>> > +if (!xml)
>> > +return AVERROR(ENOMEM);
>> > +
>> > +avio_read(pb, xml, atom.size - 4);
>> > +av_dict_set(>fc->metadata, "xml", xml, 0);
>> > +av_free(xml);
>> > +
>> > +return 0;
>> > +}
>> > +
>> >  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom
>> > atom)
>> >  {
>> >  int64_t end = avio_tell(pb) + atom.size;
>> > @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> >  parse = mov_read_keys;
>> >  }
>> >
>> > +if (!parse &&
>> > +atom.type == MKTAG('m','e','t','a') &&
>> > +a.type == MKTAG('x','m','l',' ')) {
>> > +parse = mov_read_xml;
>> > +}
>> > +
>> >  if (!parse) { /* skip leaf atoms data */
>> >  avio_skip(pb, a.size);
>> >  } else {
>>
>> We had this discussion recently: the metadata AVDictionary should
>> probably only contain real tags, not other information that's contained
>> in the format but for which libavformat has no good way to export yet.
>>
>> There needs to be a concept for distinguishing user-visible tags and
>> other data.
>>
>> (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
>> do you?)
>>
>>
> I thought that was already the case for XMP (i.e. xml) metadata embedded in
> mov. I must look up how that was handled. I seem to remember there was a
> flag to suppress this on the command line. With the policy you propose,
> libavformat will be of a lot less use for api users. Not that I had a vote
> here. It's just 2c of an api user.
>

Added export_xml option locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread Robert Krüger
On Wed, Feb 1, 2017 at 1:07 PM, wm4  wrote:

> On Wed,  1 Feb 2017 12:50:51 +0100
> Paul B Mahol  wrote:
>
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavformat/mov.c | 25 +
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 9ae4f8c..75e1c9c60 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >  return 0;
> >  }
> >
> > +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > +{
> > +uint8_t *xml;
> > +
> > +if (atom.size < 5)
> > +return 0;
> > +
> > +avio_skip(pb, 4);
> > +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
> > +if (!xml)
> > +return AVERROR(ENOMEM);
> > +
> > +avio_read(pb, xml, atom.size - 4);
> > +av_dict_set(>fc->metadata, "xml", xml, 0);
> > +av_free(xml);
> > +
> > +return 0;
> > +}
> > +
> >  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> >  {
> >  int64_t end = avio_tell(pb) + atom.size;
> > @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >  parse = mov_read_keys;
> >  }
> >
> > +if (!parse &&
> > +atom.type == MKTAG('m','e','t','a') &&
> > +a.type == MKTAG('x','m','l',' ')) {
> > +parse = mov_read_xml;
> > +}
> > +
> >  if (!parse) { /* skip leaf atoms data */
> >  avio_skip(pb, a.size);
> >  } else {
>
> We had this discussion recently: the metadata AVDictionary should
> probably only contain real tags, not other information that's contained
> in the format but for which libavformat has no good way to export yet.
>
> There needs to be a concept for distinguishing user-visible tags and
> other data.
>
> (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
> do you?)
>
>
I thought that was already the case for XMP (i.e. xml) metadata embedded in
mov. I must look up how that was handled. I seem to remember there was a
flag to suppress this on the command line. With the policy you propose,
libavformat will be of a lot less use for api users. Not that I had a vote
here. It's just 2c of an api user.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread Hendrik Leppkes
On Wed, Feb 1, 2017 at 1:20 PM, Paul B Mahol  wrote:
> On 2/1/17, wm4  wrote:
>> On Wed,  1 Feb 2017 12:12:51 +0100
>> Paul B Mahol  wrote:
>>
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/Makefile|   1 +
>>>  libavcodec/allcodecs.c |   1 +
>>>  libavcodec/textstdec.c | 409
>>> +
>>>  3 files changed, 411 insertions(+)
>>>  create mode 100644 libavcodec/textstdec.c
>>>
>
> [...]
>
>>> +
>>> +static void decode_presentation_segment(AVCodecContext *avctx,
>>> GetByteContext *gb, AVSubtitle *sub)
>>> +{
>>> +TextSTContext *s = avctx->priv_data;
>>> +unsigned ii, palette_update_flag, region_count;
>>> +int64_t start_pts, end_pts;
>>> +
>>> +start_pts = decode_pts(gb);
>>> +end_pts   = decode_pts(gb);
>>> +
>>> +sub->pts = start_pts * 100 / 9;
>>
>> I don't think this will work. You should use packet timestamps, not get
>> them from the packet contents. Otherwise we'd be back to the situation
>> with other text subtitles, which used to embed timestamps in the packet
>> data.
>>
>
> pts are stored in packet, they are not available from packet timestamp.
>
> And this succesfully converts TextST to ass format.

In-band timestamps are fragile and don't work half the time. Many
use-cases rely on reading and potentially modifying packet timestamps,
and that just doesn't work if they then get overriden by the decoder -
ie. all sorts of code would need special cases to handle this kind of
stream.
Better to have something on our end that handles them and rips out the
in-band timestamps and puts them into the AVPacket straight out of the
demuxer.

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread Paul B Mahol
On 2/1/17, wm4  wrote:
> On Wed,  1 Feb 2017 12:50:51 +0100
> Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/mov.c | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 9ae4f8c..75e1c9c60 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>>  return 0;
>>  }
>>
>> +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> +{
>> +uint8_t *xml;
>> +
>> +if (atom.size < 5)
>> +return 0;
>> +
>> +avio_skip(pb, 4);
>> +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
>> +if (!xml)
>> +return AVERROR(ENOMEM);
>> +
>> +avio_read(pb, xml, atom.size - 4);
>> +av_dict_set(>fc->metadata, "xml", xml, 0);
>> +av_free(xml);
>> +
>> +return 0;
>> +}
>> +
>>  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>>  {
>>  int64_t end = avio_tell(pb) + atom.size;
>> @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>>  parse = mov_read_keys;
>>  }
>>
>> +if (!parse &&
>> +atom.type == MKTAG('m','e','t','a') &&
>> +a.type == MKTAG('x','m','l',' ')) {
>> +parse = mov_read_xml;
>> +}
>> +
>>  if (!parse) { /* skip leaf atoms data */
>>  avio_skip(pb, a.size);
>>  } else {
>
> We had this discussion recently: the metadata AVDictionary should
> probably only contain real tags, not other information that's contained
> in the format but for which libavformat has no good way to export yet.
>
> There needs to be a concept for distinguishing user-visible tags and
> other data.
>
> (You don't want to show a xml dump in a GUI that happens to use ffmpeg,
> do you?)

You are being just rude, and do not want FFmpeg to improve.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread wm4
On Wed,  1 Feb 2017 12:12:51 +0100
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/textstdec.c | 409 
> +
>  3 files changed, 411 insertions(+)
>  create mode 100644 libavcodec/textstdec.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 43a6add..c042984 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o 
> svq1.o  h263data.o  \
>  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o 
> h264data.o
>  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
>  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
>  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
>  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
>  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f92b2b7..30a6309 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -581,6 +581,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(SUBVIEWER, subviewer);
>  REGISTER_DECODER(SUBVIEWER1,subviewer1);
>  REGISTER_ENCDEC (TEXT,  text);
> +REGISTER_DECODER(TEXTST,textst);
>  REGISTER_DECODER(VPLAYER,   vplayer);
>  REGISTER_ENCDEC (WEBVTT,webvtt);
>  REGISTER_ENCDEC (XSUB,  xsub);
> diff --git a/libavcodec/textstdec.c b/libavcodec/textstdec.c
> new file mode 100644
> index 000..5110cb8
> --- /dev/null
> +++ b/libavcodec/textstdec.c
> @@ -0,0 +1,409 @@
> +/*
> + * HDMV TextST decoder
> + *
> + * Copyright (c) 2014 Petri Hintukainen 
> + * Copyright (c) 2017 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +
> +#include "libavutil/bprint.h"
> +#include "libavutil/colorspace.h"
> +
> +#include "avcodec.h"
> +#include "ass.h"
> +#include "bytestream.h"
> +#include "mathops.h"
> +
> +/* TODO: actually make use of various styles */
> +
> +enum {
> +DIALOG_STYLE_SEGMENT= 0x81,
> +DIALOG_PRESENTATION_SEGMENT = 0x82,
> +};
> +
> +enum {
> +BD_TEXTST_DATA_ESCAPE  = 0x1b,
> +BD_TEXTST_DATA_STRING  = 1,
> +BD_TEXTST_DATA_FONT_ID = 2,
> +BD_TEXTST_DATA_FONT_STYLE  = 3,
> +BD_TEXTST_DATA_FONT_SIZE   = 4,
> +BD_TEXTST_DATA_FONT_COLOR  = 5,
> +BD_TEXTST_DATA_NEWLINE = 0x0a,
> +BD_TEXTST_DATA_RESET_STYLE = 0x0b,
> +};
> +
> +typedef struct TextSTRect {
> +uint16_t xpos;
> +uint16_t ypos;
> +uint16_t width;
> +uint16_t height;
> +} TextSTRect;
> +
> +typedef struct TextSTRegionInfo {
> +TextSTRect region;
> +uint8_tbackground_color; /* palette entry id ref */
> +} TextSTRegionInfo;
> +
> +typedef struct TextSTFontStyle {
> +uint8_t bold;
> +uint8_t italic;
> +uint8_t outline_border;
> +} TextSTFontStyle;
> +
> +typedef struct TextSTRegionStyle {
> +uint8_t  region_style_id;
> +TextSTRegionInfo region_info;
> +TextSTRect   text_box;  /* relative to region */
> +uint8_t  text_flow;
> +uint8_t  text_halign;
> +uint8_t  text_valign;
> +uint8_t  line_space;
> +uint8_t  font_id_ref;
> +TextSTFontStyle  font_style;
> +uint8_t  font_size;
> +uint8_t  font_color;/* palette entry id ref */
> +uint8_t  outline_color; /* palette entry id ref */
> +uint8_t  outline_thickness;
> +} TextSTRegionStyle;
> +
> +typedef struct TextSTUserStyle {
> +uint8_t user_style_id;
> +int16_t region_hpos_delta;
> +int16_t region_vpos_delta;
> +int16_t text_box_hpos_delta;
> +int16_t text_box_vpos_delta;
> +int16_t text_box_width_delta;
> +int16_t text_box_height_delta;
> +int8_t  font_size_delta;
> +int8_t  line_space_delta;
> +} TextSTUserStyle;
> +
> +
> +typedef struct TextSTContext {
> +

Re: [FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread wm4
On Wed,  1 Feb 2017 12:50:51 +0100
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mov.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 9ae4f8c..75e1c9c60 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +uint8_t *xml;
> +
> +if (atom.size < 5)
> +return 0;
> +
> +avio_skip(pb, 4);
> +xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
> +if (!xml)
> +return AVERROR(ENOMEM);
> +
> +avio_read(pb, xml, atom.size - 4);
> +av_dict_set(>fc->metadata, "xml", xml, 0);
> +av_free(xml);
> +
> +return 0;
> +}
> +
>  static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  int64_t end = avio_tell(pb) + atom.size;
> @@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  parse = mov_read_keys;
>  }
>  
> +if (!parse &&
> +atom.type == MKTAG('m','e','t','a') &&
> +a.type == MKTAG('x','m','l',' ')) {
> +parse = mov_read_xml;
> +}
> +
>  if (!parse) { /* skip leaf atoms data */
>  avio_skip(pb, a.size);
>  } else {

We had this discussion recently: the metadata AVDictionary should
probably only contain real tags, not other information that's contained
in the format but for which libavformat has no good way to export yet.

There needs to be a concept for distinguishing user-visible tags and
other data.

(You don't want to show a xml dump in a GUI that happens to use ffmpeg,
do you?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 5/6] opus_celt: rename structures to better names and reorganize them

2017-02-01 Thread Michael Niedermayer
On Wed, Feb 01, 2017 at 03:13:08AM +, Rostislav Pehlivanov wrote:
> This is meant to be applied on top of my previous patch which
> split PVQ into celt_pvq.c and made opus_celt.h
> 
> Essentially nothing has been changed other than renaming CeltFrame
> to CeltBlock (CeltFrame had absolutely nothing at all to do with
> a frame) and CeltContext to CeltFrame.
> 3 variables have been put in CeltFrame as they make more sense
> there rather than being passed around as arguments.
> The coefficients have been moved to the CeltBlock structure
> (why the hell were they in CeltContext and not in CeltFrame??).
> 
> Now the encoder would be able to use the exact context the decoder
> uses (plus a couple of extra fields in there).
> 
> FATE passes, no slowdowns, etc.

This doesnt build on arm-linux-gnueabi-gcc-4.5
(i think arm is unrelated here)

In file included from src/libavcodec/opus_celt.c:28:0:
src/libavcodec/opus_celt.h:134:3: error: redefinition of typedef ‘CeltFrame’
src/libavcodec/opus.h:82:26: note: previous declaration of ‘CeltFrame’ was here
make: *** [libavcodec/opus_celt.o] Error 1


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

No great genius has ever existed without some touch of madness. -- Aristotle


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


[FFmpeg-devel] [PATCH] avformat/mov: export xml metadata

2017-02-01 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavformat/mov.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9ae4f8c..75e1c9c60 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3764,6 +3764,25 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_xml(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+uint8_t *xml;
+
+if (atom.size < 5)
+return 0;
+
+avio_skip(pb, 4);
+xml = av_calloc(atom.size - 4 + 1, sizeof(uint8_t));
+if (!xml)
+return AVERROR(ENOMEM);
+
+avio_read(pb, xml, atom.size - 4);
+av_dict_set(>fc->metadata, "xml", xml, 0);
+av_free(xml);
+
+return 0;
+}
+
 static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 int64_t end = avio_tell(pb) + atom.size;
@@ -5280,6 +5299,12 @@ static int mov_read_default(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 parse = mov_read_keys;
 }
 
+if (!parse &&
+atom.type == MKTAG('m','e','t','a') &&
+a.type == MKTAG('x','m','l',' ')) {
+parse = mov_read_xml;
+}
+
 if (!parse) { /* skip leaf atoms data */
 avio_skip(pb, a.size);
 } else {
-- 
2.9.3

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


Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

2017-02-01 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 11:31:23PM -0800, Jerry Jiang wrote:
> Fixed patch issue.
> 
> > It seems that "mjpeg-trell-qprd-huffman" is missing here.
> 
> Removed the test instead since it's supposed to error.

seems to break
make fate-vsynth1-mjpeg-444

Internal error, put_bits buffer too small
Assertion 0 failed at libavcodec/put_bits.h:189
Aborted

you need configure --assert-level=2
to to reproduce this

thanks

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

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


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


[FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/textstdec.c | 409 +
 3 files changed, 411 insertions(+)
 create mode 100644 libavcodec/textstdec.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..c042984 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  
h263data.o  \
 OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o h264data.o
 OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
 OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
+OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
 OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
 OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
 OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f92b2b7..30a6309 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -581,6 +581,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(SUBVIEWER, subviewer);
 REGISTER_DECODER(SUBVIEWER1,subviewer1);
 REGISTER_ENCDEC (TEXT,  text);
+REGISTER_DECODER(TEXTST,textst);
 REGISTER_DECODER(VPLAYER,   vplayer);
 REGISTER_ENCDEC (WEBVTT,webvtt);
 REGISTER_ENCDEC (XSUB,  xsub);
diff --git a/libavcodec/textstdec.c b/libavcodec/textstdec.c
new file mode 100644
index 000..5110cb8
--- /dev/null
+++ b/libavcodec/textstdec.c
@@ -0,0 +1,409 @@
+/*
+ * HDMV TextST decoder
+ *
+ * Copyright (c) 2014 Petri Hintukainen 
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/bprint.h"
+#include "libavutil/colorspace.h"
+
+#include "avcodec.h"
+#include "ass.h"
+#include "bytestream.h"
+#include "mathops.h"
+
+/* TODO: actually make use of various styles */
+
+enum {
+DIALOG_STYLE_SEGMENT= 0x81,
+DIALOG_PRESENTATION_SEGMENT = 0x82,
+};
+
+enum {
+BD_TEXTST_DATA_ESCAPE  = 0x1b,
+BD_TEXTST_DATA_STRING  = 1,
+BD_TEXTST_DATA_FONT_ID = 2,
+BD_TEXTST_DATA_FONT_STYLE  = 3,
+BD_TEXTST_DATA_FONT_SIZE   = 4,
+BD_TEXTST_DATA_FONT_COLOR  = 5,
+BD_TEXTST_DATA_NEWLINE = 0x0a,
+BD_TEXTST_DATA_RESET_STYLE = 0x0b,
+};
+
+typedef struct TextSTRect {
+uint16_t xpos;
+uint16_t ypos;
+uint16_t width;
+uint16_t height;
+} TextSTRect;
+
+typedef struct TextSTRegionInfo {
+TextSTRect region;
+uint8_tbackground_color; /* palette entry id ref */
+} TextSTRegionInfo;
+
+typedef struct TextSTFontStyle {
+uint8_t bold;
+uint8_t italic;
+uint8_t outline_border;
+} TextSTFontStyle;
+
+typedef struct TextSTRegionStyle {
+uint8_t  region_style_id;
+TextSTRegionInfo region_info;
+TextSTRect   text_box;  /* relative to region */
+uint8_t  text_flow;
+uint8_t  text_halign;
+uint8_t  text_valign;
+uint8_t  line_space;
+uint8_t  font_id_ref;
+TextSTFontStyle  font_style;
+uint8_t  font_size;
+uint8_t  font_color;/* palette entry id ref */
+uint8_t  outline_color; /* palette entry id ref */
+uint8_t  outline_thickness;
+} TextSTRegionStyle;
+
+typedef struct TextSTUserStyle {
+uint8_t user_style_id;
+int16_t region_hpos_delta;
+int16_t region_vpos_delta;
+int16_t text_box_hpos_delta;
+int16_t text_box_vpos_delta;
+int16_t text_box_width_delta;
+int16_t text_box_height_delta;
+int8_t  font_size_delta;
+int8_t  line_space_delta;
+} TextSTUserStyle;
+
+
+typedef struct TextSTContext {
+FFASSDecoderContext ass;
+
+uint32_t palette[256];
+int region_style_count;
+int user_style_count;
+TextSTRegionStyle *region_styles;
+TextSTUserStyle   *user_styles;
+} TextSTContext;
+
+static void decode_region_data(AVCodecContext *avctx, GetByteContext *gb, 
AVBPrint *sub)
+{
+while (bytestream2_get_bytes_left(gb) > 2) {
+

Re: [FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

2017-02-01 Thread Michael Niedermayer
On Wed, Feb 01, 2017 at 09:56:41AM +0100, Steinar H. Gunderson wrote:
> On Wed, Feb 01, 2017 at 02:17:05AM +0100, Andreas Cadhalpun wrote:
> >> Would you mind sharing an input where this actually triggers? None of the
> >> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
> >> input.
> > Indeed it is. I've sent you a sample.
> 
> Thanks; I see what is happening now (and I should have fuzzed SHQ1 too, not
> just SHQ0 :-) ).
> 
> The relevant part is the construction of the (little-endian) alpha VLC:
> 
> if (!run) {
> /* 0 -> 0. */
> run_code[run] = 0;
> run_bits[run] = 1;
> } else if (run <= 4) {
> /* 10xx -> xx plus 1. */
> run_code[run] = ((run - 1) << 2) | 1;
> run_bits[run] = 4;
> } else {
> /* 111xxx -> xxx. */
> run_code[run] = (run << 3) | 7;
> run_bits[run] = 10;
> }
> 
> The sample in question encodes 111000, which is a legal code for 0,
> but we haven't told the VLC this (since simply 0 is a much more logical
> way of doing it), so it returns -1 (signaling invalid). We will see the same
> problem in level_code/level_bits (a few lines further down), but it's not
> used for indexing, so it's not a crash issue.
> 

> My preference would be to simply decode this as 0 instead of returning;
> it would be both the safest and the fastest. Is there a way we can do this?

yes

also please check if there are more "holes" in the VLC table
(this is easy to check by summing the ranges covered by codes ...
 which  would sum to 1 if there are no holes)

ff_init_vlc_sparse()
we seem to be missing a INIT_*VLC_STATIC for that but that should be
trivial to add

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/hlsenc: add hls_flag option to create segments atomically

2017-02-01 Thread Steven Liu
2017-02-01 4:29 GMT+08:00 Aman Gupta :

> From: Aman Gupta 
>
> Adds a `-hls_flags +temp_file` which will write segment data to
> filename.tmp, and then rename to filename when the segment is complete
> and before the file is added to the m3u8 playlist.
>
> This patch is similar in spirit to one used in Plex's ffmpeg fork, and
> allows a transcoding webserver to ensure incomplete segment files are
> never served up accidentally.
> ---
>  libavformat/hlsenc.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bd1e684..23b9011 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -76,6 +76,7 @@ typedef enum HLSFlags {
>  HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index
> in segment filenames when use_localtime  e.g.: %%03d
>  HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment
> duration (microsec) in segment filenames when use_localtime  e.g.: %%09t
>  HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size
> (bytes) in segment filenames when use_localtime  e.g.: %%014s
> +HLS_TEMP_FILE = (1 << 11),
>  } HLSFlags;
>
>  typedef enum {
> @@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
>
>  set_http_options(, c);
>
> +if (c->flags & HLS_TEMP_FILE) {
> +av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
> +}
> +
>  if (c->key_info_file) {
>  if ((err = hls_encryption_start(s)) < 0)
>  goto fail;
> @@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
>  av_write_frame(oc, NULL); /* Flush any buffered data */
>
> +if (hls->flags & HLS_TEMP_FILE) {
> +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';
> +}
> +
>  new_start_pos = avio_tell(hls->avf->pb);
>  hls->size = new_start_pos - hls->start_pos;
>  ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
> hls->size);
> @@ -1406,6 +1420,7 @@ static const AVOption options[] = {
>  {"hls_subtitle_path", "set path of hls subtitles",
> OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
>  {"hls_flags", "set flags affecting HLS playlist and media file
> generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E,
> "flags"},
>  {"single_file",   "generate a single media file indexed with byte
> ranges", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E,
> "flags"},
> +{"temp_file", "write segment to temporary file and rename when
> complete", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E,
> "flags"},
>  {"delete_segments", "delete segment files that are no longer part of
> the playlist", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0,
> UINT_MAX,   E, "flags"},
>  {"round_durations", "round durations in m3u8 to whole numbers", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E,
> "flags"},
>  {"discont_start", "start the playlist with a discontinuity tag", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
> --
> 2.10.1 (Apple Git-78)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Why use temp filename?
There have no info in m3u8 list before the segment complete.
___
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

2017-02-01 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 07:56:39PM -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
> 
[...]
> diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
> index a7bf739..c3b9091 100644
> --- a/tests/fate/libavutil.mak
> +++ b/tests/fate/libavutil.mak
> @@ -101,6 +101,11 @@ FATE_LIBAVUTIL += fate-imgutils
>  fate-imgutils: libavutil/tests/imgutils$(EXESUF)
>  fate-imgutils: CMD = run libavutil/tests/imgutils
>  
> +FATE_LIBAVUTIL += fate-lfg
> +fate-lfg: libavutil/tests/lfg$(EXESUF)
> +fate-lfg: CMD = run libavutil/tests/lfg
> +fate-lfg: REF = /dev/null

This test does not work

for example with:
@@ -109,6 +109,7 @@ int main(void)
 for (i = 0; i < tot_samp; i += 2) {
 double bmg_out[2];
 av_bmg_get(, bmg_out);
+bmg_out[0] = bmg_out[1]  = 0;
 PRN_arr[i  ] = bmg_out[0] * stddev + mean;
 PRN_arr[i+1] = bmg_out[1] * stddev + mean;
 samp_mean   += PRN_arr[i] + PRN_arr[i+1];

"make fate-lfg" still passes

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread wm4
On Wed, 1 Feb 2017 10:23:02 +0100
Paul B Mahol  wrote:

> On 2/1/17, wm4  wrote:
> > On Wed, 01 Feb 2017 11:05:48 +0200
> > Petri Hintukainen  wrote:
> >  
> >> ti, 2017-01-31 kello 16:42 +0100, wm4 kirjoitti:  
> >> > On Tue, 31 Jan 2017 15:22:17 +0100
> >> > Paul B Mahol  wrote:
> >> >  
> >> > > Signed-off-by: Paul B Mahol 
> >> > > ---
> >> > >  libavcodec/Makefile|   2 +
> >> > >  libavcodec/allcodecs.c |   2 +
> >> > >  libavcodec/textst_parser.c |  49 
> >> > >  libavcodec/textstdec.c | 108
> >> > > +
> >> > >  libavformat/utils.c|   1 +
> >> > >  5 files changed, 162 insertions(+)
> >> > >  create mode 100644 libavcodec/textst_parser.c
> >> > >  create mode 100644 libavcodec/textstdec.c
> >> > >
> >> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >> > > index 43a6add..edadb0f 100644
> >> > > --- a/libavcodec/Makefile
> >> > > +++ b/libavcodec/Makefile
> >> > > @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+=
> >> > > svq1enc.o svq1.o  h263data.o  \
> >> > >  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o
> >> > > mpegutils.o h264data.o
> >> > >  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
> >> > >  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> >> > > +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
> >> > >  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
> >> > >  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
> >> > >  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> >> > > @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) +=
> >> > > rv34_parser.o
> >> > >  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
> >> > >  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
> >> > >  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> >> > > +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
> >> > >  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o
> >> > > vc1data.o  \
> >> > >simple_idct.o wmv2data.o
> >> > >  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
> >> > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> >> > > index f92b2b7..9a90533 100644
> >> > > --- a/libavcodec/allcodecs.c
> >> > > +++ b/libavcodec/allcodecs.c
> >> > > @@ -581,6 +581,7 @@ void avcodec_register_all(void)
> >> > >  REGISTER_DECODER(SUBVIEWER, subviewer);
> >> > >  REGISTER_DECODER(SUBVIEWER1,subviewer1);
> >> > >  REGISTER_ENCDEC (TEXT,  text);
> >> > > +REGISTER_DECODER(TEXTST,textst);
> >> > >  REGISTER_DECODER(VPLAYER,   vplayer);
> >> > >  REGISTER_ENCDEC (WEBVTT,webvtt);
> >> > >  REGISTER_ENCDEC (XSUB,  xsub);
> >> > > @@ -704,6 +705,7 @@ void avcodec_register_all(void)
> >> > >  REGISTER_PARSER(RV40,   rv40);
> >> > >  REGISTER_PARSER(SIPR,   sipr);
> >> > >  REGISTER_PARSER(TAK,tak);
> >> > > +REGISTER_PARSER(TEXTST, textst);
> >> > >  REGISTER_PARSER(VC1,vc1);
> >> > >  REGISTER_PARSER(VORBIS, vorbis);
> >> > >  REGISTER_PARSER(VP3,vp3);
> >> > > diff --git a/libavcodec/textst_parser.c
> >> > > b/libavcodec/textst_parser.c
> >> > > new file mode 100644
> >> > > index 000..5079a96
> >> > > --- /dev/null
> >> > > +++ b/libavcodec/textst_parser.c
> >> > > @@ -0,0 +1,49 @@
> >> > > +/*
> >> > > + * This file is part of FFmpeg.
> >> > > + *
> >> > > + * FFmpeg is free software; you can redistribute it and/or
> >> > > + * modify it under the terms of the GNU Lesser General Public
> >> > > + * License as published by the Free Software Foundation; either
> >> > > + * version 2.1 of the License, or (at your option) any later
> >> > > version.
> >> > > + *
> >> > > + * FFmpeg is distributed in the hope that it will be useful,
> >> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> > > GNU
> >> > > + * Lesser General Public License for more details.
> >> > > + *
> >> > > + * You should have received a copy of the GNU Lesser General
> >> > > Public
> >> > > + * License along with FFmpeg; if not, write to the Free Software
> >> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> >> > > 02110-1301 USA
> >> > > + */
> >> > > +
> >> > > +/**
> >> > > + * @file
> >> > > + * HDMV TextST subtitle parser
> >> > > + */
> >> > > +
> >> > > +#include "libavutil/intreadwrite.h"
> >> > > +#include "parser.h"
> >> > > +
> >> > > +static int textst_parse(AVCodecParserContext *s1, AVCodecContext
> >> > > *avctx,
> >> > > +const uint8_t **poutbuf, int
> >> > > 

Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread Paul B Mahol
On 2/1/17, wm4  wrote:
> On Wed, 01 Feb 2017 11:05:48 +0200
> Petri Hintukainen  wrote:
>
>> ti, 2017-01-31 kello 16:42 +0100, wm4 kirjoitti:
>> > On Tue, 31 Jan 2017 15:22:17 +0100
>> > Paul B Mahol  wrote:
>> >
>> > > Signed-off-by: Paul B Mahol 
>> > > ---
>> > >  libavcodec/Makefile|   2 +
>> > >  libavcodec/allcodecs.c |   2 +
>> > >  libavcodec/textst_parser.c |  49 
>> > >  libavcodec/textstdec.c | 108
>> > > +
>> > >  libavformat/utils.c|   1 +
>> > >  5 files changed, 162 insertions(+)
>> > >  create mode 100644 libavcodec/textst_parser.c
>> > >  create mode 100644 libavcodec/textstdec.c
>> > >
>> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> > > index 43a6add..edadb0f 100644
>> > > --- a/libavcodec/Makefile
>> > > +++ b/libavcodec/Makefile
>> > > @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+=
>> > > svq1enc.o svq1.o  h263data.o  \
>> > >  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o
>> > > mpegutils.o h264data.o
>> > >  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
>> > >  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
>> > > +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
>> > >  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
>> > >  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
>> > >  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
>> > > @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) +=
>> > > rv34_parser.o
>> > >  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
>> > >  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
>> > >  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
>> > > +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
>> > >  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o
>> > > vc1data.o  \
>> > >simple_idct.o wmv2data.o
>> > >  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
>> > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> > > index f92b2b7..9a90533 100644
>> > > --- a/libavcodec/allcodecs.c
>> > > +++ b/libavcodec/allcodecs.c
>> > > @@ -581,6 +581,7 @@ void avcodec_register_all(void)
>> > >  REGISTER_DECODER(SUBVIEWER, subviewer);
>> > >  REGISTER_DECODER(SUBVIEWER1,subviewer1);
>> > >  REGISTER_ENCDEC (TEXT,  text);
>> > > +REGISTER_DECODER(TEXTST,textst);
>> > >  REGISTER_DECODER(VPLAYER,   vplayer);
>> > >  REGISTER_ENCDEC (WEBVTT,webvtt);
>> > >  REGISTER_ENCDEC (XSUB,  xsub);
>> > > @@ -704,6 +705,7 @@ void avcodec_register_all(void)
>> > >  REGISTER_PARSER(RV40,   rv40);
>> > >  REGISTER_PARSER(SIPR,   sipr);
>> > >  REGISTER_PARSER(TAK,tak);
>> > > +REGISTER_PARSER(TEXTST, textst);
>> > >  REGISTER_PARSER(VC1,vc1);
>> > >  REGISTER_PARSER(VORBIS, vorbis);
>> > >  REGISTER_PARSER(VP3,vp3);
>> > > diff --git a/libavcodec/textst_parser.c
>> > > b/libavcodec/textst_parser.c
>> > > new file mode 100644
>> > > index 000..5079a96
>> > > --- /dev/null
>> > > +++ b/libavcodec/textst_parser.c
>> > > @@ -0,0 +1,49 @@
>> > > +/*
>> > > + * This file is part of FFmpeg.
>> > > + *
>> > > + * FFmpeg is free software; you can redistribute it and/or
>> > > + * modify it under the terms of the GNU Lesser General Public
>> > > + * License as published by the Free Software Foundation; either
>> > > + * version 2.1 of the License, or (at your option) any later
>> > > version.
>> > > + *
>> > > + * FFmpeg is distributed in the hope that it will be useful,
>> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > > GNU
>> > > + * Lesser General Public License for more details.
>> > > + *
>> > > + * You should have received a copy of the GNU Lesser General
>> > > Public
>> > > + * License along with FFmpeg; if not, write to the Free Software
>> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> > > 02110-1301 USA
>> > > + */
>> > > +
>> > > +/**
>> > > + * @file
>> > > + * HDMV TextST subtitle parser
>> > > + */
>> > > +
>> > > +#include "libavutil/intreadwrite.h"
>> > > +#include "parser.h"
>> > > +
>> > > +static int textst_parse(AVCodecParserContext *s1, AVCodecContext
>> > > *avctx,
>> > > +const uint8_t **poutbuf, int
>> > > *poutbuf_size,
>> > > +const uint8_t *buf, int buf_size)
>> > > +{
>> > > +if (buf_size > 13) {
>> > > +int64_t end;
>> > > +
>> > > +s1->pts = ((int64_t)(buf[3] & 1) << 32) |
>> > > AV_RB32([4]);
>> > > +end = ((int64_t)(buf[8] & 1) << 32) | 

Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread wm4
On Wed, 01 Feb 2017 11:05:48 +0200
Petri Hintukainen  wrote:

> ti, 2017-01-31 kello 16:42 +0100, wm4 kirjoitti:
> > On Tue, 31 Jan 2017 15:22:17 +0100
> > Paul B Mahol  wrote:
> >   
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavcodec/Makefile|   2 +
> > >  libavcodec/allcodecs.c |   2 +
> > >  libavcodec/textst_parser.c |  49 
> > >  libavcodec/textstdec.c | 108
> > > +
> > >  libavformat/utils.c|   1 +
> > >  5 files changed, 162 insertions(+)
> > >  create mode 100644 libavcodec/textst_parser.c
> > >  create mode 100644 libavcodec/textstdec.c
> > > 
> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > > index 43a6add..edadb0f 100644
> > > --- a/libavcodec/Makefile
> > > +++ b/libavcodec/Makefile
> > > @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+=
> > > svq1enc.o svq1.o  h263data.o  \
> > >  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o
> > > mpegutils.o h264data.o
> > >  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
> > >  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> > > +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
> > >  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
> > >  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
> > >  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> > > @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) +=
> > > rv34_parser.o
> > >  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
> > >  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
> > >  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> > > +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
> > >  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o
> > > vc1data.o  \
> > >    simple_idct.o wmv2data.o
> > >  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
> > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > > index f92b2b7..9a90533 100644
> > > --- a/libavcodec/allcodecs.c
> > > +++ b/libavcodec/allcodecs.c
> > > @@ -581,6 +581,7 @@ void avcodec_register_all(void)
> > >  REGISTER_DECODER(SUBVIEWER, subviewer);
> > >  REGISTER_DECODER(SUBVIEWER1,subviewer1);
> > >  REGISTER_ENCDEC (TEXT,  text);
> > > +REGISTER_DECODER(TEXTST,textst);
> > >  REGISTER_DECODER(VPLAYER,   vplayer);
> > >  REGISTER_ENCDEC (WEBVTT,webvtt);
> > >  REGISTER_ENCDEC (XSUB,  xsub);
> > > @@ -704,6 +705,7 @@ void avcodec_register_all(void)
> > >  REGISTER_PARSER(RV40,   rv40);
> > >  REGISTER_PARSER(SIPR,   sipr);
> > >  REGISTER_PARSER(TAK,tak);
> > > +REGISTER_PARSER(TEXTST, textst);
> > >  REGISTER_PARSER(VC1,vc1);
> > >  REGISTER_PARSER(VORBIS, vorbis);
> > >  REGISTER_PARSER(VP3,vp3);
> > > diff --git a/libavcodec/textst_parser.c
> > > b/libavcodec/textst_parser.c
> > > new file mode 100644
> > > index 000..5079a96
> > > --- /dev/null
> > > +++ b/libavcodec/textst_parser.c
> > > @@ -0,0 +1,49 @@
> > > +/*
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later
> > > version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General
> > > Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > > 02110-1301 USA
> > > + */
> > > +
> > > +/**
> > > + * @file
> > > + * HDMV TextST subtitle parser
> > > + */
> > > +
> > > +#include "libavutil/intreadwrite.h"
> > > +#include "parser.h"
> > > +
> > > +static int textst_parse(AVCodecParserContext *s1, AVCodecContext
> > > *avctx,
> > > +const uint8_t **poutbuf, int
> > > *poutbuf_size,
> > > +const uint8_t *buf, int buf_size)
> > > +{
> > > +if (buf_size > 13) {
> > > +int64_t end;
> > > +
> > > +s1->pts = ((int64_t)(buf[3] & 1) << 32) |
> > > AV_RB32([4]);
> > > +end = ((int64_t)(buf[8] & 1) << 32) | AV_RB32([9]);
> > > +s1->duration = (end - s1->pts);
> > > +}
> > > +
> > > +/* always return the full packet. this parser isn't doing any
> 

Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-02-01 Thread Petri Hintukainen
ti, 2017-01-31 kello 16:42 +0100, wm4 kirjoitti:
> On Tue, 31 Jan 2017 15:22:17 +0100
> Paul B Mahol  wrote:
> 
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/Makefile|   2 +
> >  libavcodec/allcodecs.c |   2 +
> >  libavcodec/textst_parser.c |  49 
> >  libavcodec/textstdec.c | 108
> > +
> >  libavformat/utils.c|   1 +
> >  5 files changed, 162 insertions(+)
> >  create mode 100644 libavcodec/textst_parser.c
> >  create mode 100644 libavcodec/textstdec.c
> > 
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 43a6add..edadb0f 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+=
> > svq1enc.o svq1.o  h263data.o  \
> >  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o
> > mpegutils.o h264data.o
> >  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
> >  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> > +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
> >  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
> >  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
> >  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> > @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) +=
> > rv34_parser.o
> >  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
> >  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
> >  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> > +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
> >  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o
> > vc1data.o  \
> >    simple_idct.o wmv2data.o
> >  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index f92b2b7..9a90533 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -581,6 +581,7 @@ void avcodec_register_all(void)
> >  REGISTER_DECODER(SUBVIEWER, subviewer);
> >  REGISTER_DECODER(SUBVIEWER1,subviewer1);
> >  REGISTER_ENCDEC (TEXT,  text);
> > +REGISTER_DECODER(TEXTST,textst);
> >  REGISTER_DECODER(VPLAYER,   vplayer);
> >  REGISTER_ENCDEC (WEBVTT,webvtt);
> >  REGISTER_ENCDEC (XSUB,  xsub);
> > @@ -704,6 +705,7 @@ void avcodec_register_all(void)
> >  REGISTER_PARSER(RV40,   rv40);
> >  REGISTER_PARSER(SIPR,   sipr);
> >  REGISTER_PARSER(TAK,tak);
> > +REGISTER_PARSER(TEXTST, textst);
> >  REGISTER_PARSER(VC1,vc1);
> >  REGISTER_PARSER(VORBIS, vorbis);
> >  REGISTER_PARSER(VP3,vp3);
> > diff --git a/libavcodec/textst_parser.c
> > b/libavcodec/textst_parser.c
> > new file mode 100644
> > index 000..5079a96
> > --- /dev/null
> > +++ b/libavcodec/textst_parser.c
> > @@ -0,0 +1,49 @@
> > +/*
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later
> > version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General
> > Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +/**
> > + * @file
> > + * HDMV TextST subtitle parser
> > + */
> > +
> > +#include "libavutil/intreadwrite.h"
> > +#include "parser.h"
> > +
> > +static int textst_parse(AVCodecParserContext *s1, AVCodecContext
> > *avctx,
> > +const uint8_t **poutbuf, int
> > *poutbuf_size,
> > +const uint8_t *buf, int buf_size)
> > +{
> > +if (buf_size > 13) {
> > +int64_t end;
> > +
> > +s1->pts = ((int64_t)(buf[3] & 1) << 32) |
> > AV_RB32([4]);
> > +end = ((int64_t)(buf[8] & 1) << 32) | AV_RB32([9]);
> > +s1->duration = (end - s1->pts);
> > +}
> > +
> > +/* always return the full packet. this parser isn't doing any
> > splitting or
> > +   combining, only packet analysis */
> > +*poutbuf  = buf;
> > +*poutbuf_size = buf_size;
> > +return buf_size;
> > +}
> > +
> > +AVCodecParser ff_textst_parser = {
> > +.codec_ids  = { AV_CODEC_ID_HDMV_TEXT_SUBTITLE },
> > +.parser_parse   = textst_parse,

Re: [FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

2017-02-01 Thread Steinar H. Gunderson
On Wed, Feb 01, 2017 at 02:17:05AM +0100, Andreas Cadhalpun wrote:
>> Would you mind sharing an input where this actually triggers? None of the
>> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
>> input.
> Indeed it is. I've sent you a sample.

Thanks; I see what is happening now (and I should have fuzzed SHQ1 too, not
just SHQ0 :-) ).

The relevant part is the construction of the (little-endian) alpha VLC:

if (!run) {
/* 0 -> 0. */
run_code[run] = 0;
run_bits[run] = 1;
} else if (run <= 4) {
/* 10xx -> xx plus 1. */
run_code[run] = ((run - 1) << 2) | 1;
run_bits[run] = 4;
} else {
/* 111xxx -> xxx. */
run_code[run] = (run << 3) | 7;
run_bits[run] = 10;
}

The sample in question encodes 111000, which is a legal code for 0,
but we haven't told the VLC this (since simply 0 is a much more logical
way of doing it), so it returns -1 (signaling invalid). We will see the same
problem in level_code/level_bits (a few lines further down), but it's not
used for indexing, so it's not a crash issue.

My preference would be to simply decode this as 0 instead of returning;
it would be both the safest and the fastest. Is there a way we can do this?
Failing that, I would suppose the best fix is

-   if (run == 128) break;
+   if (run < 0 || run >= 128) break;

treating these as EOB codes (with no performance penalty, as it becomes an
unsigned compare -- as in your patch). The reason I'm not too keen on putting
this on the check for i is that if we hit end of stream and read the same
code over and over again (due to the checked bitstream reader), an attacker
_might_ be able to construct a file where run=-1 infinitely and we go into an
infinite loop.

Optionally we can just do

if (run < 0) return AVERROR_INVALIDDATA;

because I don't really think these formats are speed critical :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel