Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

2017-07-03 Thread Paras Chadha 
On Mon, Jul 3, 2017 at 3:56 AM, Moritz Barsnick  wrote:

> On Sun, Jul 02, 2017 at 20:48:17 +0530, Paras Chadha wrote:
> > +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
> [...]
> > +header_size += 80;
> [...]
> > +header_size += 80;
> [...]
> > +header_size += 80;
> [...]
> > +for (i = 0; i < naxis; i++) {
> [...]
> > +header_size += 80;
> [...]
> > +header_size += 80;
> [...]
> > +while (strncmp(buf, "END", 3)) {
> [...]
> > +header_size += 80;
> > +}
> > +
> > +header_size = ceil(header_size/2880.0)*2880;
> > +if (header_size < 0)
> > +return AVERROR_INVALIDDATA;
>
> How can this happen, except by integer overflow?
>

It will not happen except in case of integer overflow.


>
> > +if (data_size < 0)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (!data_size) {
> > +fits->image = 0;
> > +} else {
> > +data_size = ceil(data_size/2880.0)*2880;
> > +if (data_size < 0)
> > +return AVERROR_INVALIDDATA;
>
> How can this occur?


It will not occur except in case of integer overflow.
If you are asking for specific case when this 'if' will execute then, set
data_size = LLONG_MAX - 1. Due to ceil function the final value will become
greater than LLONG_MAX. So, the statement inside 'if' will execute.


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

[FFmpeg-devel] [PATCH] avfilter: add VMAF filter

2017-07-03 Thread Ashish Singh 
Hi, my pull request for vmaf library interface has been merged.
First install vmaf library (libvmaf) from https://github.com/Netflix/vmaf
It can be installed by first doing 'make', then 'make lib' (for building 
libvmaf.a), then
'make install' (for installing) from root directory of vmaf.
Fixed the issues with previous patch.
Do --enable-libvmaf at the time of ./configure .. 

---
 configure|   5 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_vmaf.c| 402 +++
 4 files changed, 409 insertions(+)
 create mode 100644 libavfilter/vf_vmaf.c

diff --git a/configure b/configure
index 5ae5227..bafcd07 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
+  --enable-libvmaf enable vmaf filter via libvmaf [no]
   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
   --enable-libvorbis   enable Vorbis en/decoding via libvorbis,
native implementation exists [no]
@@ -1569,6 +1570,7 @@ EXTERNAL_LIBRARY_LIST="
 libtheora
 libtwolame
 libv4l2
+libvmaf
 libvorbis
 libvpx
 libwavpack
@@ -3172,6 +3174,7 @@ uspp_filter_deps="gpl avcodec"
 vaguedenoiser_filter_deps="gpl"
 vidstabdetect_filter_deps="libvidstab"
 vidstabtransform_filter_deps="libvidstab"
+vmaf_filter_deps="libvmaf"
 zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg"
@@ -5845,6 +5848,8 @@ enabled libtwolame&& require libtwolame twolame.h 
twolame_init -ltwolame
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl
 enabled libvidstab&& require_pkg_config "vidstab >= 0.98" 
vid.stab/libvidstab.h vsMotionDetectInit
+enabled libvmaf   && { check_lib libvmaf "libvmaf.h" "compute_vmaf" 
-lvmaf -lstdc++ -lpthread -lm ||
+   die "ERROR: libvmaf must be installed"; }
 enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
E_IF_init -lvo-amrwbenc
 enabled libvorbis && require libvorbis vorbis/vorbisenc.h 
vorbis_info_init -lvorbisenc -lvorbis -logg
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..1c4bd56 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -314,6 +314,7 @@ OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
+OBJS-$(CONFIG_VMAF_FILTER)   += vf_vmaf.o dualinput.o 
framesync.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4..6894a6f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -325,6 +325,7 @@ static void register_all(void)
 REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);
 REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
 REGISTER_FILTER(VIGNETTE,   vignette,   vf);
+REGISTER_FILTER(VMAF,   vmaf,   vf);
 REGISTER_FILTER(VSTACK, vstack, vf);
 REGISTER_FILTER(W3FDIF, w3fdif, vf);
 REGISTER_FILTER(WAVEFORM,   waveform,   vf);
diff --git a/libavfilter/vf_vmaf.c b/libavfilter/vf_vmaf.c
new file mode 100644
index 000..ce966e4
--- /dev/null
+++ b/libavfilter/vf_vmaf.c
@@ -0,0 +1,402 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * 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
+ * Calculate the VMAF between two input videos.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "l

Re: [FFmpeg-devel] [PATCH v2] avcodec/interplayvideo: Check sizes of decode buffers

2017-07-03 Thread Paul B Mahol 
On 7/2/17, Hein-Pieter van Braam  wrote:
> Fixes: 6503 crash with fuzzed file
>
> Signed-off-by: Hein-Pieter van Braam 
> ---
>  libavcodec/interplayvideo.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/interplayvideo.c b/libavcodec/interplayvideo.c
> index d6f484a..86530e6 100644
> --- a/libavcodec/interplayvideo.c
> +++ b/libavcodec/interplayvideo.c
> @@ -972,6 +972,8 @@ static void
> ipvideo_decode_format_06_opcodes(IpvideoContext *s, AVFrame *frame)
>  x, y, opcode, bytestream2_tell(&s->stream_ptr));
>
>  s->pixel_ptr = frame->data[0] + x + y * frame->linesize[0];
> +if (s->pixel_ptr > (s->pixel_ptr +
> s->upper_motion_limit_offset))
> +return;

This looks strange.

>  ipvideo_format_06_passes[pass](s, frame, opcode);
>  }
>  }
> @@ -1043,6 +1045,12 @@ static void
> ipvideo_decode_format_10_opcodes(IpvideoContext *s, AVFrame *frame)
>  for (y = 0; y < s->avctx->height; y += 8) {
>  for (x = 0; x < s->avctx->width; x += 8) {
>  s->pixel_ptr = s->cur_decode_frame->data[0] + x + y *
> s->cur_decode_frame->linesize[0];
> +if (s->pixel_ptr > s->pixel_ptr +
> s->upper_motion_limit_offset)
> +return;

This too.

> +
> +if (s->cur_decode_frame->width != s->avctx->width ||
> +s->cur_decode_frame->height != s->avctx->height)
> +return;
>
>  while (skip <= 0)  {
>  if (skip != -0x8000 && skip) {
> --
> 2.9.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

2017-07-03 Thread Paul B Mahol 
On 7/2/17, Michael Niedermayer  wrote:
> On Sun, Jul 02, 2017 at 01:14:00PM +0200, wm4 wrote:
>> On Sun,  2 Jul 2017 00:09:42 +0200
>> Michael Niedermayer  wrote:
>>
>> > This reduces the number of strstr() calls per byte
>> > This diasalows empty tags like '< >' as well as '<' in tags like
>> > ''
>> >
>> > Fixes timeout
>> > Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/htmlsubtitles.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
>> > index be5c9316ca..67abc94085 100644
>> > --- a/libavcodec/htmlsubtitles.c
>> > +++ b/libavcodec/htmlsubtitles.c
>> > @@ -110,13 +110,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint
>> > *dst, const char *in)
>> >  case '<':
>> >  tag_close = in[1] == '/';
>> >  len = 0;
>> > -if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >=
>> > 1 && len > 0) {
>> > +if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, &len) >=
>> > 1 && len > 0) {
>> >  const char *tagname = buffer;
>> >  while (*tagname == ' ')
>> >  tagname++;
>> >  if ((param = strchr(tagname, ' ')))
>> >  *param++ = 0;
>> > -if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
>> > +if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack) &&
>> > *tagname) ||
>> >  ( tag_close && sptr > 0 &&
>> > !strcmp(stack[sptr-1].tag, tagname))) {
>> >  int i, j, unknown = 0;
>> >  in += len + tag_close;
>>
>> Invalid syntax is not unusual in SRT files. Are you sure this doesn't
>> make the output worse in files that do not use the syntax correctly?
>
> I do not know if this makes the output worse for files with invalid syntax
> I also do not know if this makes the output better for files with invalid
> syntax
>
> i dont have a large library of (real world invalid syntax) srt files
> whith which to find cases where it makes a difference.
>
> You seem to know alot about srt, maybe you can pick some srt files
> and add fate tests, so we have better coverage of odd and nasty cases
>
> about this patch specifically, what do you suggest ?
> should i try to fix this while maintaining existing behavior for
> invalid syntax exactly? (i dont know how that code would look)

WHat's so wrong with code that you want it changed in bad way?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/alsdec: fix some undefined shifts

2017-07-03 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 libavcodec/alsdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 37d6b38..df5e2bb 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -756,7 +756,7 @@ static int read_var_block_data(ALSDecContext *ctx, 
ALSBlockData *bd)
 }
 
 for (k = 2; k < opt_order; k++)
-quant_cof[k] = (quant_cof[k] << 14) + (add_base << 13);
+quant_cof[k] = (quant_cof[k] * (1 << 14)) + (add_base << 13);
 }
 }
 
@@ -861,7 +861,7 @@ static int read_var_block_data(ALSDecContext *ctx, 
ALSBlockData *bd)
 res >>= 1;
 
 if (cur_k) {
-res <<= cur_k;
+res  *= 1 << cur_k;
 res  |= get_bits_long(gb, cur_k);
 }
 }
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/interplayvideo: Check sizes of decode buffers

2017-07-03 Thread Hein-Pieter van Braam 
On Mon, 2017-07-03 at 11:43 +0200, Paul B Mahol wrote:
> On 7/2/17, Hein-Pieter van Braam  wrote:
> > Fixes: 6503 crash with fuzzed file
> > 
> > Signed-off-by: Hein-Pieter van Braam 
> > ---
> >  libavcodec/interplayvideo.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/libavcodec/interplayvideo.c
> > b/libavcodec/interplayvideo.c
> > index d6f484a..86530e6 100644
> > --- a/libavcodec/interplayvideo.c
> > +++ b/libavcodec/interplayvideo.c
> > @@ -972,6 +972,8 @@ static void
> > ipvideo_decode_format_06_opcodes(IpvideoContext *s, AVFrame *frame)
> >  x, y, opcode, bytestream2_tell(&s-
> > >stream_ptr));
> > 
> >  s->pixel_ptr = frame->data[0] + x + y * frame-
> > >linesize[0];
> > +if (s->pixel_ptr > (s->pixel_ptr +
> > s->upper_motion_limit_offset))
> > +return;
> 
> This looks strange.
> 

The code already has a feature to ensure that movement vectors can't
write past the end of the target AVFrame. I thought I'd reuse this to
prevent writing past the end of the current AVFrame for the 'regular'
pixeldata too. This code checks the value of the pointer into the
AVFrame's pixeldata is not further than the last 8x8 block so that we
can't write past it.

Would there be a better way of doing this?

Although, I suppose if I check the size of the AVFrame itself instead
then it would also be safe because of the for loop. I can also
implement it like that if that's preferred?

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/interplayvideo: Check sizes of decode buffers

2017-07-03 Thread Paul B Mahol 
On 7/3/17, Hein-Pieter van Braam  wrote:
> On Mon, 2017-07-03 at 11:43 +0200, Paul B Mahol wrote:
>> On 7/2/17, Hein-Pieter van Braam  wrote:
>> > Fixes: 6503 crash with fuzzed file
>> >
>> > Signed-off-by: Hein-Pieter van Braam 
>> > ---
>> >  libavcodec/interplayvideo.c | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/libavcodec/interplayvideo.c
>> > b/libavcodec/interplayvideo.c
>> > index d6f484a..86530e6 100644
>> > --- a/libavcodec/interplayvideo.c
>> > +++ b/libavcodec/interplayvideo.c
>> > @@ -972,6 +972,8 @@ static void
>> > ipvideo_decode_format_06_opcodes(IpvideoContext *s, AVFrame *frame)
>> >  x, y, opcode, bytestream2_tell(&s-
>> > >stream_ptr));
>> >
>> >  s->pixel_ptr = frame->data[0] + x + y * frame-
>> > >linesize[0];
>> > +if (s->pixel_ptr > (s->pixel_ptr +
>> > s->upper_motion_limit_offset))
>> > +return;
>>
>> This looks strange.
>>
>
> The code already has a feature to ensure that movement vectors can't
> write past the end of the target AVFrame. I thought I'd reuse this to
> prevent writing past the end of the current AVFrame for the 'regular'
> pixeldata too. This code checks the value of the pointer into the
> AVFrame's pixeldata is not further than the last 8x8 block so that we
> can't write past it.
>
> Would there be a better way of doing this?
>
> Although, I suppose if I check the size of the AVFrame itself instead
> then it would also be safe because of the for loop. I can also
> implement it like that if that's preferred?

You are comparing pointer with same pointer increased by some value.

This is wrong way to fix it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/interplayvideo: Check sizes of decode buffers

2017-07-03 Thread Hein-Pieter van Braam 
On Mon, 2017-07-03 at 11:59 +0200, Paul B Mahol wrote:
> 
> 
> You are comparing pointer with same pointer increased by some value.
> 
> This is wrong way to fix it.

Urgh, you're right, of course. I don't know what I was thinking.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

2017-07-03 Thread wm4 
On Sun, 2 Jul 2017 13:43:57 +0200
Michael Niedermayer  wrote:

> On Sun, Jul 02, 2017 at 01:14:00PM +0200, wm4 wrote:
> > On Sun,  2 Jul 2017 00:09:42 +0200
> > Michael Niedermayer  wrote:
> >   
> > > This reduces the number of strstr() calls per byte
> > > This diasalows empty tags like '< >' as well as '<' in tags like 
> > > ''
> > > 
> > > Fixes timeout
> > > Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/htmlsubtitles.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > > index be5c9316ca..67abc94085 100644
> > > --- a/libavcodec/htmlsubtitles.c
> > > +++ b/libavcodec/htmlsubtitles.c
> > > @@ -110,13 +110,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint 
> > > *dst, const char *in)
> > >  case '<':
> > >  tag_close = in[1] == '/';
> > >  len = 0;
> > > -if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >= 1 
> > > && len > 0) {
> > > +if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, &len) >= 
> > > 1 && len > 0) {
> > >  const char *tagname = buffer;
> > >  while (*tagname == ' ')
> > >  tagname++;
> > >  if ((param = strchr(tagname, ' ')))
> > >  *param++ = 0;
> > > -if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
> > > +if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack) && 
> > > *tagname) ||
> > >  ( tag_close && sptr > 0 && 
> > > !strcmp(stack[sptr-1].tag, tagname))) {
> > >  int i, j, unknown = 0;
> > >  in += len + tag_close;  
> > 
> > Invalid syntax is not unusual in SRT files. Are you sure this doesn't
> > make the output worse in files that do not use the syntax correctly?  
> 
> I do not know if this makes the output worse for files with invalid syntax
> I also do not know if this makes the output better for files with invalid
> syntax
> 
> i dont have a large library of (real world invalid syntax) srt files
> whith which to find cases where it makes a difference.
> 
> You seem to know alot about srt, maybe you can pick some srt files
> and add fate tests, so we have better coverage of odd and nasty cases
> 
> about this patch specifically, what do you suggest ?
> should i try to fix this while maintaining existing behavior for
> invalid syntax exactly? (i dont know how that code would look)
> 
> [...]

I don't know either, but due to the messy syntax situation, I'd rather
not change the code in unpredictable ways just to get faster fuzzing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

2017-07-03 Thread Michael Niedermayer 
On Mon, Jul 03, 2017 at 11:44:26AM +0200, Paul B Mahol wrote:
> On 7/2/17, Michael Niedermayer  wrote:
> > On Sun, Jul 02, 2017 at 01:14:00PM +0200, wm4 wrote:
> >> On Sun,  2 Jul 2017 00:09:42 +0200
> >> Michael Niedermayer  wrote:
> >>
> >> > This reduces the number of strstr() calls per byte
> >> > This diasalows empty tags like '< >' as well as '<' in tags like
> >> > ''
> >> >
> >> > Fixes timeout
> >> > Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
> >> >
> >> > Found-by: continuous fuzzing process
> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavcodec/htmlsubtitles.c | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> >> > index be5c9316ca..67abc94085 100644
> >> > --- a/libavcodec/htmlsubtitles.c
> >> > +++ b/libavcodec/htmlsubtitles.c
> >> > @@ -110,13 +110,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint
> >> > *dst, const char *in)
> >> >  case '<':
> >> >  tag_close = in[1] == '/';
> >> >  len = 0;
> >> > -if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >=
> >> > 1 && len > 0) {
> >> > +if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, &len) >=
> >> > 1 && len > 0) {
> >> >  const char *tagname = buffer;
> >> >  while (*tagname == ' ')
> >> >  tagname++;
> >> >  if ((param = strchr(tagname, ' ')))
> >> >  *param++ = 0;
> >> > -if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
> >> > +if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack) &&
> >> > *tagname) ||
> >> >  ( tag_close && sptr > 0 &&
> >> > !strcmp(stack[sptr-1].tag, tagname))) {
> >> >  int i, j, unknown = 0;
> >> >  in += len + tag_close;
> >>
> >> Invalid syntax is not unusual in SRT files. Are you sure this doesn't
> >> make the output worse in files that do not use the syntax correctly?
> >
> > I do not know if this makes the output worse for files with invalid syntax
> > I also do not know if this makes the output better for files with invalid
> > syntax
> >
> > i dont have a large library of (real world invalid syntax) srt files
> > whith which to find cases where it makes a difference.
> >
> > You seem to know alot about srt, maybe you can pick some srt files
> > and add fate tests, so we have better coverage of odd and nasty cases
> >
> > about this patch specifically, what do you suggest ?
> > should i try to fix this while maintaining existing behavior for
> > invalid syntax exactly? (i dont know how that code would look)
> 
> WHat's so wrong with code that you want it changed in bad way?

IIRC
If you have tags like < you end up checking
<

<<<
...

then form the closing tag



...

and then search the whole input for each closing tag

On top of this there are special cases and limitations like
fixed size buffers and a fixed size stack, so it will not always do
all the steps above.

But in practice this is slow. The same issue should happen on real
files if they contain syntax issues and conatin a lot of unescaped '<'


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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default

2017-07-03 Thread wm4 
On Sat, 1 Jul 2017 07:10:47 -0700
Philip Langdale  wrote:

> On Sat,  1 Jul 2017 11:40:38 +0200
> wm4  wrote:
> 
> > NVIDIA broke its own API when using VDPAU decoding. If you retrieve
> > the decoded YUV data, or if you map the surfaces with GL interop, the
> > result are interlacing artifacts. The only way to get non-broken data
> > is by using the vdpau video mixer to convert it to RGB. There is no
> > way to block the non-working operations in a reasonable way (a
> > VdpVideoSurface has to support all operations).
> > 
> > NVIDIA refuses to fix this issue (it "fixed" it by making it work with
> > the video mixer, but the rest is still broken). There is no sign of
> > that changing.
> > 
> > Do not use HEVC by default with the generic hwaccle API. Detect
> > whether it's the NVIDIA native implementation, and exit with an
> > error. (The same thing work with the MESA implementation.)
> > 
> > As an escape hatch and to allow applications to use the decoder if
> > they really want to (perhaps because they make sure to explicitly use
> > the video mixer), reuse AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH to
> > disable this check.
> > 
> > Once NVIDIA fixes the bug, working driver versions could be detected,
> > and it could be allowed again.
> > ---
> >  libavcodec/vdpau.c | 19 +++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
> > index 9c7804a287..42ebddbeee 100644
> > --- a/libavcodec/vdpau.c
> > +++ b/libavcodec/vdpau.c
> > @@ -127,6 +127,8 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
> > VdpDecoderProfile profile, VdpVideoSurfaceQueryCapabilities
> > *surface_query_caps; VdpDecoderQueryCapabilities *decoder_query_caps;
> >  VdpDecoderCreate *create;
> > +VdpGetInformationString *info;
> > +const char *info_string;
> >  void *func;
> >  VdpStatus status;
> >  VdpBool supported;
> > @@ -209,6 +211,23 @@ int ff_vdpau_common_init(AVCodecContext *avctx,
> > VdpDecoderProfile profile, return AVERROR(ENOTSUP);
> >  
> >  status = vdctx->get_proc_address(vdctx->device,
> > +
> > VDP_FUNC_ID_GET_INFORMATION_STRING,
> > + &func);
> > +if (status != VDP_STATUS_OK)
> > +return vdpau_error(status);
> > +else
> > +info = func;
> > +
> > +status = info(&info_string);
> > +if (status != VDP_STATUS_OK)
> > +return vdpau_error(status);
> > +if (avctx->codec_id == AV_CODEC_ID_HEVC && strncmp(info_string,
> > "NVIDIA ", 7) == 0 &&
> > +!(avctx->hwaccel_flags &
> > AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)) {
> > +av_log(avctx, AV_LOG_VERBOSE, "HEVC with NVIDIA VDPAU
> > drivers is buggy, skipping.\n");
> > +return AVERROR(ENOTSUP);
> > +}
> > +
> > +status = vdctx->get_proc_address(vdctx->device,
> >   
> > VDP_FUNC_ID_VIDEO_SURFACE_QUERY_CAPABILITIES,
> >   &func);
> >  if (status != VDP_STATUS_OK)  
> 
> Go for it.

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

[FFmpeg-devel] [PATCH] avcodec/vp9: AVX2 ipred_dl_32x32 improvement

2017-07-03 Thread Ilia Valiakhmetov 
Use symmetry properties of the ipred_dl function for better performance.

vp9_diag_downleft_32x32_12bpp_c: 1534.2
vp9_diag_downleft_32x32_12bpp_sse2: 145.9
vp9_diag_downleft_32x32_12bpp_ssse3: 140.0
vp9_diag_downleft_32x32_12bpp_avx: 134.8
vp9_diag_downleft_32x32_12bpp_avx2: 78.9

~40% faster than avx

Signed-off-by: Ilia Valiakhmetov 
---
 libavcodec/x86/vp9intrapred_16bpp.asm | 47 ---
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm 
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 8d8d65e..33a8a7f 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -901,49 +901,68 @@ cglobal vp9_ipred_dl_32x32_16, 2, 6, 7, dst, stride, l, a
 LOWPASS  1,  2,  3 ; RSTUVWXYZ..5
 vperm2i128  m2, m1, m4, q0201  ; Z..5
 vperm2i128  m5, m0, m1, q0201  ; JKLMNOPQRSTUVWXY
-DEFINE_ARGS dst, stride, stride3, cnt
+vperm2i128  m6, m2, m2, q0101
+DEFINE_ARGS dst, stride, stride3, dst16, cnt
 lea   stride3q, [strideq*3]
-mov   cntd, 4
+lea dst16q, [dstq+strideq*8]
+lea dst16q, [dst16q+strideq*8]
+mov   cntd, 2
 
 .loop:
 mova   [dstq+strideq*0 + 0], m0
 mova   [dstq+strideq*0 +32], m1
+mova  [dst16q+strideq*0+ 0], m1
+mova  [dst16q+strideq*0+32], m6
 vpalignr m3, m5, m0, 2
 vpalignr m4, m2, m1, 2
 mova   [dstq+strideq*1 + 0], m3
 mova   [dstq+strideq*1 +32], m4
+mova  [dst16q+strideq*1 +0], m4
+mova [dst16q+strideq*1 +32], m6
 vpalignr m3, m5, m0, 4
 vpalignr m4, m2, m1, 4
 mova   [dstq+strideq*2 + 0], m3
 mova   [dstq+strideq*2 +32], m4
+mova   [dst16q+strideq*2+0], m4
+mova  [dst16q+strideq*2+32], m6
 vpalignr m3, m5, m0, 6
-vpalignr m4, m2, m1, 6
+vpalignr m4, m2, m1, 6  
 mova   [dstq+stride3q*1+ 0], m3
 mova   [dstq+stride3q*1+32], m4
-leadstq, [dstq+strideq*4]
+mova  [dst16q+stride3q*1+0], m4
+mova [dst16q+stride3q*1+32], m6
 vpalignr m3, m5, m0, 8
 vpalignr m4, m2, m1, 8
+leadstq, [dstq+strideq*4]
+lea  dst16q, [dst16q+strideq*4]
 mova   [dstq+strideq*0 + 0], m3
 mova   [dstq+strideq*0 +32], m4
+mova  [dst16q+strideq*0 +0], m4
+mova [dst16q+strideq*0 +32], m6
 vpalignr m3, m5, m0, 10
 vpalignr m4, m2, m1, 10
 mova   [dstq+strideq*1 + 0], m3
 mova   [dstq+strideq*1 +32], m4
+mova  [dst16q+strideq*1 +0], m4
+mova [dst16q+strideq*1 +32], m6
 vpalignr m3, m5, m0, 12
 vpalignr m4, m2, m1, 12
-mova   [dstq+strideq*2+ 0], m3
-mova   [dstq+strideq*2+32], m4
+mova[dstq+strideq*2+ 0], m3
+mova[dstq+strideq*2+32], m4
+mova   [dst16q+strideq*2+0], m4
+mova  [dst16q+strideq*2+32], m6
 vpalignr m3, m5, m0, 14
 vpalignr m4, m2, m1, 14
-mova   [dstq+stride3q+  0], m3
-mova   [dstq+stride3q+ 32], m4
-vpalignr m3, m5, m0, 16
-vpalignr m4, m2, m1, 16
-vperm2i128   m5, m3, m4, q0201
-vperm2i128   m2, m4, m4, q0101
-mova m0, m3
-mova m1, m4
+mova[dstq+stride3q+  0], m3
+mova[dstq+stride3q+ 32], m4
+mova   [dst16q+stride3q+ 0], m4
+mova   [dst16q+stride3q+32], m6
+mova m0, m5
+mova m1, m2
+vperm2i128   m5, m5, m2, q0201
+mova m2, m6
 leadstq, [dstq+strideq*4]
+lea  dst16q, [dst16q+strideq*4]
 deccntd
 jg .loop
 RET
-- 
2.8.3

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

[FFmpeg-devel] [PATCH] avcodec/vp9: AVX2 ipred_vl_16x16

2017-07-03 Thread Ilia Valiakhmetov 
vp9_vert_left_16x16_12bpp_c: 273.8
vp9_vert_left_16x16_12bpp_sse2: 69.4
vp9_vert_left_16x16_12bpp_ssse3: 35.3
vp9_vert_left_16x16_12bpp_avx: 34.6
vp9_vert_left_16x16_12bpp_avx2: 22.4

~35% faster than avx

Signed-off-by: Ilia Valiakhmetov 
---
 libavcodec/x86/vp9dsp_init_16bpp.c|  2 ++
 libavcodec/x86/vp9intrapred_16bpp.asm | 53 +++
 2 files changed, 55 insertions(+)

diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c 
b/libavcodec/x86/vp9dsp_init_16bpp.c
index 60d10a1..da8b74c 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp.c
@@ -55,6 +55,7 @@ decl_ipred_fn(dl,   16, 16, avx2);
 decl_ipred_fn(dl,   32, 16, avx2);
 decl_ipred_fn(dr,   16, 16, avx2);
 decl_ipred_fn(dr,   32, 16, avx2);
+decl_ipred_fn(vl,   16, 16, avx2);
 
 #define decl_ipred_dir_funcs(type) \
 decl_ipred_fns(type, 16, sse2,  sse2); \
@@ -143,6 +144,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
 #if ARCH_X86_64
 init_ipred_func(dr, DIAG_DOWN_RIGHT, 32, 16, avx2);
 #endif
+init_ipred_func(vl, VERT_LEFT, 16, 16, avx2);
 }
 
 #endif /* HAVE_X86ASM */
diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm 
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 32b6982..8d8d65e 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -1538,6 +1538,59 @@ VL_FUNCS 1
 INIT_XMM avx
 VL_FUNCS 1
 
+%if HAVE_AVX2_EXTERNAL
+INIT_YMM avx2
+cglobal vp9_ipred_vl_16x16_16, 2, 4, 6, dst, stride, l, a
+movifnidn   aq, amp
+movam0, [aq]; abcdefghijklmnop
+vpbroadcastw   xm5, [aq+30] ; 
+vperm2i128  m1, m0, m5, q0201   ; ijklmnop
+vpalignrm2, m1, m0, 2   ; bcdefghijklmnopp
+vpalignrm3, m1, m0, 4   ; cdefghijklmnoppp
+movam4, m2
+pavgw   m4, m0
+LOWPASS  0,  2,  3  ; BCDEFGHIJKLMNOPp
+vperm2i128  m2, m0, m5, q0201
+vperm2i128  m3, m4, m5, q0201
+DEFINE_ARGS dst, stride, stride3
+lea   stride3q, [strideq*3]
+
+mova  [dstq+strideq*0], m4
+mova  [dstq+strideq*1], m0
+vpalignrm1, m2, m0, 2
+vpalignrm5, m3, m4, 2
+mova  [dstq+strideq*2], m5
+mova  [dstq+stride3q ], m1
+vpalignrm1, m2, m0, 4
+vpalignrm5, m3, m4, 4
+lea   dstq, [dstq+strideq*4]
+mova  [dstq+strideq*0], m5
+mova  [dstq+strideq*1], m1
+vpalignrm1, m2, m0, 6
+vpalignrm5, m3, m4, 6
+mova  [dstq+strideq*2], m5
+mova  [dstq+stride3q ], m1
+vpalignrm1, m2, m0, 8
+vpalignrm5, m3, m4, 8
+lea   dstq, [dstq+strideq*4]
+mova  [dstq+strideq*0], m5
+mova  [dstq+strideq*1], m1
+vpalignrm1, m2, m0, 10
+vpalignrm5, m3, m4, 10
+mova  [dstq+strideq*2], m5
+mova  [dstq+stride3q ], m1
+vpalignrm1, m2, m0, 12
+vpalignrm5, m3, m4, 12
+lea   dstq, [dstq+strideq*4]
+mova  [dstq+strideq*0], m5
+mova  [dstq+strideq*1], m1
+vpalignrm1, m2, m0, 14
+vpalignrm5, m3, m4, 14
+mova  [dstq+strideq*2], m5
+mova  [dstq+stride3q ], m1
+RET
+%endif
+
 %macro VR_FUNCS 0
 cglobal vp9_ipred_vr_4x4_16, 4, 4, 3, dst, stride, l, a
 movum0, [aq-2]
-- 
2.8.3

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

[FFmpeg-devel] [PATCH] htmlsubtitles: support tag

2017-07-03 Thread wm4 
Some .srt files use this tag.

(An alternative implementation would be correctly ignoring unknown tags,
and treating them as whitespace. libass can do automatic line wrapping.)
---
 libavcodec/htmlsubtitles.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index be5c9316ca..fe991678d5 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -167,6 +167,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
const char *in)
 }
 } else if (tagname[0] && !tagname[1] && strspn(tagname, 
"bisu") == 1) {
 av_bprintf(dst, "{\\%c%d}", tagname[0], !tag_close);
+} else if (!strcmp(tagname, "br")) {
+av_bprintf(dst, "\\N");
 } else {
 unknown = 1;
 snprintf(tmp, sizeof(tmp), "", tagname);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] htmlsubtitles: support tag

2017-07-03 Thread Clément Bœsch 
On Mon, Jul 03, 2017 at 01:43:43PM +0200, wm4 wrote:
> Some .srt files use this tag.
> 
> (An alternative implementation would be correctly ignoring unknown tags,
> and treating them as whitespace. libass can do automatic line wrapping.)
> ---
>  libavcodec/htmlsubtitles.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> index be5c9316ca..fe991678d5 100644
> --- a/libavcodec/htmlsubtitles.c
> +++ b/libavcodec/htmlsubtitles.c
> @@ -167,6 +167,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> const char *in)
>  }
>  } else if (tagname[0] && !tagname[1] && strspn(tagname, 
> "bisu") == 1) {
>  av_bprintf(dst, "{\\%c%d}", tagname[0], !tag_close);
> +} else if (!strcmp(tagname, "br")) {
> +av_bprintf(dst, "\\N");
>  } else {
>  unknown = 1;
>  snprintf(tmp, sizeof(tmp), "", tagname);

So this supports , <   br > and ?

Which makes me think we should use (av_)strcasecmp instead. I think there
is a patch for this on the ml (which you may want to apply before this
one).

I assume you tested fate-subtitles.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] htmlsubtitles: support tag

2017-07-03 Thread wm4 
On Mon, 3 Jul 2017 13:54:50 +0200
Clément Bœsch  wrote:

> On Mon, Jul 03, 2017 at 01:43:43PM +0200, wm4 wrote:
> > Some .srt files use this tag.
> > 
> > (An alternative implementation would be correctly ignoring unknown tags,
> > and treating them as whitespace. libass can do automatic line wrapping.)
> > ---
> >  libavcodec/htmlsubtitles.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > index be5c9316ca..fe991678d5 100644
> > --- a/libavcodec/htmlsubtitles.c
> > +++ b/libavcodec/htmlsubtitles.c
> > @@ -167,6 +167,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> > const char *in)
> >  }
> >  } else if (tagname[0] && !tagname[1] && 
> > strspn(tagname, "bisu") == 1) {
> >  av_bprintf(dst, "{\\%c%d}", tagname[0], 
> > !tag_close);
> > +} else if (!strcmp(tagname, "br")) {
> > +av_bprintf(dst, "\\N");
> >  } else {
> >  unknown = 1;
> >  snprintf(tmp, sizeof(tmp), "", tagname);  
> 
> So this supports , <   br > and ?

No idea.

> Which makes me think we should use (av_)strcasecmp instead. I think there
> is a patch for this on the ml (which you may want to apply before this
> one).

The font tag also uses strcmp(), so that's orthogonal.

> I assume you tested fate-subtitles.
> 

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

[FFmpeg-devel] [PATCH] lavf/utils: update stream duration only if it is not set or 0

2017-07-03 Thread Matthieu Bouron 
---

The following patch makes lavf/utils only update stream duration only if it is
not set or 0 in fill_all_stream_timings (which is called by
avformat_find_stream_info).

In the context of mov demuxing, the patch makes the last packet duration the
same as the one declared in the stts table for example (ie: we trust what the
demuxer reports).

The patch passes fate, however it might not be valid but I would like to
understand what is the purpose / use-case of the update_stream_timing /
fill_all_stream_timings functions which are not too well documented.

Thanks.

---
 libavformat/utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 38d247c6cd..00adf026e6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2654,7 +2654,8 @@ static void fill_all_stream_timings(AVFormatContext *ic)
 if (ic->start_time != AV_NOPTS_VALUE)
 st->start_time = av_rescale_q(ic->start_time, AV_TIME_BASE_Q,
   st->time_base);
-if (ic->duration != AV_NOPTS_VALUE)
+if (ic->duration != AV_NOPTS_VALUE &&
+(st->duration == 0 || st->duration == AV_NOPTS_VALUE))
 st->duration = av_rescale_q(ic->duration, AV_TIME_BASE_Q,
 st->time_base);
 }
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] avfomat/hlsenc: support fmp4 format in hls

2017-07-03 Thread Steven Liu 
2017-07-01 20:05 GMT+08:00 Steven Liu :
> add the fmp4 format into hlsenc
> because the fmp4 format add into hls from version 7.
> the spec link is:
> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20
> and the describe on WWDC
> https://developer.apple.com/videos/play/wwdc2017/515/
>
> Signed-off-by: Steven Liu 
> ---
>  doc/muxers.texi  |  17 
>  libavformat/hlsenc.c | 107 
> +++
>  2 files changed, 108 insertions(+), 16 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 0866142..94472ce 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -614,6 +614,23 @@ in the playlist.
>  Hex-coded 16byte initialization vector for every segment instead
>  of the autogenerated ones.
>
> +@item hls_segment_type @var{flags}
> +Possible values:
> +
> +@table @samp
> +@item mpegts
> +If this flag is set, the hls segment files will format to mpegts.
> +the mpegts files is used in all hls versions.
> +
> +@item fmp4
> +If this flag is set, the hls segment files will format to fragment mp4 looks 
> like dash.
> +the fmp4 files is used in hls after version 7.
> +
> +@end table
> +
> +@item hls_fmp4_init_filename @var{filename}
> +set filename to the fragment files header file, default filename is 
> @file{init.mp4}.
> +
>  @item hls_flags @var{flags}
>  Possible values:
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 40143c8..a49b594 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -88,6 +88,11 @@ typedef enum HLSFlags {
>  } HLSFlags;
>
>  typedef enum {
> +SEGMENT_TYPE_MPEGTS,
> +SEGMENT_TYPE_FMP4,
> +} SegmentType;
> +
> +typedef enum {
>  PLAYLIST_TYPE_NONE,
>  PLAYLIST_TYPE_EVENT,
>  PLAYLIST_TYPE_VOD,
> @@ -115,6 +120,9 @@ typedef struct HLSContext {
>  uint32_t flags;// enum HLSFlags
>  uint32_t pl_type;  // enum PlaylistType
>  char *segment_filename;
> +char *fmp4_init_filename;
> +int segment_type;
> +int fmp4_init_mode;
>
>  int use_localtime;  ///< flag to expand filename with localtime
>  int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
> @@ -256,6 +264,16 @@ fail:
>  return -1;
>  }
>
> +static void write_styp(AVIOContext *pb)
> +{
> +avio_wb32(pb, 24);
> +ffio_wfourcc(pb, "styp");
> +ffio_wfourcc(pb, "msdh");
> +avio_wb32(pb, 0); /* minor */
> +ffio_wfourcc(pb, "msdh");
> +ffio_wfourcc(pb, "msix");
> +}
> +
>  static int hls_delete_old_segments(AVFormatContext *s, HLSContext *hls) {
>
>  HLSSegment *segment, *previous_segment = NULL;
> @@ -508,6 +526,7 @@ static int read_chomp_line(AVIOContext *s, char *buf, int 
> maxlen)
>
>  static int hls_mux_init(AVFormatContext *s)
>  {
> +AVDictionary *options = NULL;
>  HLSContext *hls = s->priv_data;
>  AVFormatContext *oc;
>  AVFormatContext *vtt_oc = NULL;
> @@ -553,7 +572,35 @@ static int hls_mux_init(AVFormatContext *s)
>  }
>  hls->start_pos = 0;
>  hls->new_start = 1;
> +hls->fmp4_init_mode = 0;
>
> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> +hls->fmp4_init_mode = 1;
> +if ((ret = s->io_open(s, &oc->pb, hls->fmp4_init_filename, 
> AVIO_FLAG_WRITE, NULL)) < 0) {
> +av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n", 
> hls->fmp4_init_filename);
> +return ret;
> +}
> +
> +if (hls->format_options_str) {
> +ret = av_dict_parse_string(&hls->format_options, 
> hls->format_options_str, "=", ":", 0);
> +if (ret < 0) {
> +av_log(s, AV_LOG_ERROR, "Could not parse format options list 
> '%s'\n",
> +   hls->format_options_str);
> +return ret;
> +}
> +}
> +
> +av_dict_copy(&options, hls->format_options, 0);
> +av_dict_set(&options, "fflags", "-autobsf", 0);
> +av_dict_set(&options, "movflags", "frag_custom+dash+delay_moov", 0);
> +ret = avformat_init_output(oc, &options);
> +if (av_dict_count(options)) {
> +av_log(s, AV_LOG_ERROR, "Some of the provided format options in 
> '%s' are not recognized\n", hls->format_options_str);
> +av_dict_free(&options);
> +return AVERROR(EINVAL);
> +}
> +av_dict_free(&options);
> +}
>  return 0;
>  }
>
> @@ -922,6 +969,9 @@ static void write_m3u8_head_block(HLSContext *hls, 
> AVIOContext *out, int version
>  }
>  avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
>  avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> +avio_printf(out, "#EXT-X-MAP:URI=\"%s\"\n", hls->fmp4_init_filename);
> +}
>  av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", 
> sequence);
>  }
>
> @@ -961,6 +1011,10 @@ static int hls_window(AVFormatContext *s, int last)
>  sequence = 0;

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: add sbrdsp tests

2017-07-03 Thread Matthieu Bouron 
On Fri, Jun 30, 2017 at 05:16:37PM +0200, Matthieu Bouron wrote:
> On Fri, Jun 30, 2017 at 03:55:52PM +0200, Michael Niedermayer wrote:
> > On Thu, Jun 29, 2017 at 10:53:06PM -0300, James Almer wrote:
> > > On 6/29/2017 10:14 PM, Henrik Gramner wrote:
> > > > On Fri, Jun 30, 2017 at 1:58 AM, Michael Niedermayer
> > > >  wrote:
> > > >> Program received signal SIGSEGV, Segmentation fault.
> > > >> 0x00684919 in ff_sbr_hf_gen_sse ()
> > > > 
> > > >>0x00684909 :   sub%r9,%r8
> > > > 
> > > >> => 0x00684919 :   movaps 
> > > >> (%rsi,%r8,1),%xmm0
> > > > 
> > > >> r9 0xdeadbeef0080   -2401053092612145024
> > > > 
> > > > Another case of a 32-bit int being used as part of a 64-bit operation.
> > > 
> > > I can't reproduce it on my ArchLinux x86_64 environment for some reason,
> > > but based on what you said i assume the attached patch should fix it.
> > 
> > no crash occurs here with this, so it seems fixed
> 
> Should i push the patchset or wait a little bit longer ?

Patchset applied.

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

[FFmpeg-devel] [PATCH] avfilter: add ANSNR filter

2017-07-03 Thread Ashish Singh 
This is ANSNR filter, one of the component filters of VMAF.
Run it using: ffmpeg -i main -i ref -lavfi ansnr -f null -
Currently it outputs the average ansnr score over all frames.

---
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/ansnr.h  |  32 
 libavfilter/vf_ansnr.c   | 403 +++
 4 files changed, 437 insertions(+)
 create mode 100644 libavfilter/ansnr.h
 create mode 100644 libavfilter/vf_ansnr.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..705e5a1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -124,6 +124,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER)  += 
asink_anullsink.o
 # video filters
 OBJS-$(CONFIG_ALPHAEXTRACT_FILTER)   += vf_extractplanes.o
 OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o
+OBJS-$(CONFIG_ANSNR_FILTER)  += vf_ansnr.o dualinput.o 
framesync.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 OBJS-$(CONFIG_ATADENOISE_FILTER) += vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4..c1f67c4 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -136,6 +136,7 @@ static void register_all(void)
 
 REGISTER_FILTER(ALPHAEXTRACT,   alphaextract,   vf);
 REGISTER_FILTER(ALPHAMERGE, alphamerge, vf);
+REGISTER_FILTER(ANSNR,  ansnr,  vf);
 REGISTER_FILTER(ASS,ass,vf);
 REGISTER_FILTER(ATADENOISE, atadenoise, vf);
 REGISTER_FILTER(AVGBLUR,avgblur,vf);
diff --git a/libavfilter/ansnr.h b/libavfilter/ansnr.h
new file mode 100644
index 000..effd722
--- /dev/null
+++ b/libavfilter/ansnr.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_PSNR_H
+#define AVFILTER_PSNR_H
+
+#include 
+#include 
+
+static int compute_ansnr(const void *ref, const void *dis, int w,
+ int h, int ref_stride, int dis_stride, double *score,
+ double *score_psnr, double peak, double psnr_max, 
void *ctx);
+
+#endif /* AVFILTER_PSNR_H */
diff --git a/libavfilter/vf_ansnr.c b/libavfilter/vf_ansnr.c
new file mode 100644
index 000..f8d44bf
--- /dev/null
+++ b/libavfilter/vf_ansnr.c
@@ -0,0 +1,403 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * 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
+ * Calculate the ANSNR between two input videos.
+ */
+
+#include 
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "dualinput.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "internal.h"
+#include "ansnr.h"
+#include "video.h"
+
+typedef struct ANSNRContext {
+const AVClass *class;
+FFDualInputContext dinput;
+int width;
+int height;
+char *format;
+float *data_buf;
+double ansnr_sum;
+uint64_t nb_frames;
+} ANSNRContext;
+
+#define OFFSET(x) offsetof(ANSNRContext, x)
+#define MAX_ALIGN 32
+#define ALIGN_CEIL(x) ((x) + ((x) % MAX_ALIGN ? MAX_ALIGN - (x) % MAX_ALIGN : 
0))
+#define OPT_RANGE_PIXEL_OFFSET (-128)
+
+const int ansnr_filter2d_ref_width = 3;
+const int ansnr_filter2d_dis_width = 5;
+const float ansnr_filter2d_ref[3 * 3] = {
+1

Re: [FFmpeg-devel] [PATCH] avfilter: add ANSNR filter

2017-07-03 Thread Moritz Barsnick 
On Mon, Jul 03, 2017 at 18:39:38 +0530, Ashish Singh wrote:
> This is ANSNR filter, one of the component filters of VMAF.

Would you please expand the abbreviation in at least one place?
Optimally in doc/filters.texi, the content of which is missing (as it
still is in your VMAF patch). (And perhaps in the header of the .c
file.)

> +++ b/libavfilter/ansnr.h
[...]
> +#ifndef AVFILTER_PSNR_H
> +#define AVFILTER_PSNR_H

Incorrect header guard.

> +const float ansnr_filter2d_dis[5 * 5] = {
> +2.0 / 571.0,  7.0 / 571.0,  12.0 / 571.0,  7.0 / 571.0,  2.0 / 571.0,
> +7.0 / 571.0,  31.0 / 571.0, 52.0 / 571.0,  31.0 / 571.0, 7.0 / 571.0,
> +12.0 / 571.0, 52.0 / 571.0, 127.0 / 571.0, 52.0 / 571.0, 12.0 / 571.0,
> +7.0 / 571.0,  31.0 / 571.0, 52.0 / 571.0,  31.0 / 571.0, 7.0 / 571.0,
> +2.0 / 571.0,  7.0 / 571.0,  12.0 / 571.0,  7.0 / 571.0,  2.0 / 571.0

If you can align these along the decimal dots, it's easier to read.

> +for (i = 0; i < h; ++i) {
> +for (j = 0; j < w; ++j) {

I believe ffmpeg style prefers "i++".

> +signal_sum   += pow_2(ref[ref_ind]);
> +noise_sum += pow_2(ref[ref_ind] - dis[dis_ind]);

Whitespace.

> +*score = (noise==0) ? (psnr_max) : (10.0 * log10(signal / noise));
> +
> +*score_psnr = FFMIN(10 * log10(pow_2(peak) * w * h / FFMAX(noise, eps)),
> +psnr_max);

Inconsistent: Why 10.0 in the first case, 10 in the second?

> +double score = 0.0;
> +double score_psnr = 0;

Inconsistent: Why 0.0 in the first case, 0 in the second?

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

Re: [FFmpeg-devel] [PATCH 1/5] movenc: use correct tag list for AVOutputFormat.codec_tag

2017-07-03 Thread Derek Buitenhuis 
On 7/3/2017 3:00 AM, James Almer wrote:
>> +{ AV_CODEC_ID_EAC3, MKTAG('a', 'c', '-', '3') },
> Should be ec-3. Changing it fixes fate-copy-trac3074 as pointed by
> Michael in a reply to patch 2/5.

OK, this was my bug; Libav does't have that entry at all.

> 
>> +{ AV_CODEC_ID_DTS , MKTAG('m', 'p', '4', 'a') },
> Doesn't DTS have a bunch of unique tags? The ones listed in
> ff_codec_movaudio_tags and http://www.mp4ra.org/codecs.html

I'll check into it.

- Derek

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

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Derek Buitenhuis 
On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
> breaks fate

I'll look into it tonight; busy today.

.
.
.

Aside:

I'll just add, though, that these two word 'breaks fate' emails
are kind of obnoxious when the test in question was added days
after I sent the set, so I couldn't have possibly tested against
it, and the commit that added the test and this email has /zero/
info about what the test actually tests (a bug id is not a commit
message).

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

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread wm4 
On Mon, 3 Jul 2017 16:17:42 +0100
Derek Buitenhuis  wrote:

> On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
> > breaks fate  
> 
> I'll look into it tonight; busy today.
> 
> .
> .
> .
> 
> Aside:
> 
> I'll just add, though, that these two word 'breaks fate' emails
> are kind of obnoxious when the test in question was added days
> after I sent the set, so I couldn't have possibly tested against
> it, and the commit that added the test and this email has /zero/
> info about what the test actually tests (a bug id is not a commit
> message).

This. These opaque fate tests are so much work to get around. It went
far enough that I added bullshit to ffmpeg.c to get around some of the
questionable tests.

Also, TRAC issue numbers have 0 information contents. Even if you go
through the obnoxious process of looking it up on TRAC and trying to
extract iunformation from a confusing discussion with a confused user
(99% of TRAC issues), TRAC could easily go away. It already happened
once, and some of the bug numbers in old commits obviously don't match
with what's on current TRAC.

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

2017-07-03 Thread Michael Niedermayer 
On Mon, Jul 03, 2017 at 12:40:13PM +0200, wm4 wrote:
> On Sun, 2 Jul 2017 13:43:57 +0200
> Michael Niedermayer  wrote:
> 
> > On Sun, Jul 02, 2017 at 01:14:00PM +0200, wm4 wrote:
> > > On Sun,  2 Jul 2017 00:09:42 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > This reduces the number of strstr() calls per byte
> > > > This diasalows empty tags like '< >' as well as '<' in tags like 
> > > > ''
> > > > 
> > > > Fixes timeout
> > > > Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/htmlsubtitles.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > > > index be5c9316ca..67abc94085 100644
> > > > --- a/libavcodec/htmlsubtitles.c
> > > > +++ b/libavcodec/htmlsubtitles.c
> > > > @@ -110,13 +110,13 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint 
> > > > *dst, const char *in)
> > > >  case '<':
> > > >  tag_close = in[1] == '/';
> > > >  len = 0;
> > > > -if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >= 
> > > > 1 && len > 0) {
> > > > +if (sscanf(in+tag_close+1, "%127[^<>]>%n", buffer, &len) 
> > > > >= 1 && len > 0) {
> > > >  const char *tagname = buffer;
> > > >  while (*tagname == ' ')
> > > >  tagname++;
> > > >  if ((param = strchr(tagname, ' ')))
> > > >  *param++ = 0;
> > > > -if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
> > > > +if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack) && 
> > > > *tagname) ||
> > > >  ( tag_close && sptr > 0 && 
> > > > !strcmp(stack[sptr-1].tag, tagname))) {
> > > >  int i, j, unknown = 0;
> > > >  in += len + tag_close;  
> > > 
> > > Invalid syntax is not unusual in SRT files. Are you sure this doesn't
> > > make the output worse in files that do not use the syntax correctly?  
> > 
> > I do not know if this makes the output worse for files with invalid syntax
> > I also do not know if this makes the output better for files with invalid
> > syntax
> > 
> > i dont have a large library of (real world invalid syntax) srt files
> > whith which to find cases where it makes a difference.
> > 
> > You seem to know alot about srt, maybe you can pick some srt files
> > and add fate tests, so we have better coverage of odd and nasty cases
> > 
> > about this patch specifically, what do you suggest ?
> > should i try to fix this while maintaining existing behavior for
> > invalid syntax exactly? (i dont know how that code would look)
> > 
> > [...]
> 
> I don't know either, but due to the messy syntax situation, I'd rather
> not change the code in unpredictable ways just to get faster fuzzing.

Its primarly intended to fix the potential denial of service.
That is moderate sized files with short duration, few streams, low
resolution, low channel count should not consume huge amounts of
cpu time.


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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

2017-07-03 Thread Aaron Levinson 

On 6/30/2017 5:05 PM, Marton Balint wrote:

This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.

Signed-off-by: Marton Balint 
---
  doc/indevs.texi  |  4 ++--
  libavdevice/decklink_dec.cpp | 56 +++-
  2 files changed, 42 insertions(+), 18 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 51c304f3ec..330617a7c9 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -250,8 +250,8 @@ specifically lines 6 to 22, and lines 318 to 335. Line 6 is 
the LSB in the mask.
  Selected lines which do not contain teletext information will be ignored. You
  can use the special @option{all} constant to select all possible lines, or
  @option{standard} to skip lines 6, 318 and 319, which are not compatible with 
all
-receivers. Capturing teletext only works for SD PAL sources in 8 bit mode.
-To use this option, ffmpeg needs to be compiled with @code{--enable-libzvbi}.
+receivers. Capturing teletext only works for SD PAL sources. To use this
+option, ffmpeg needs to be compiled with @code{--enable-libzvbi}.
  
  @item channels

  Defines number of audio channels to capture. Must be @samp{2}, @samp{8} or 
@samp{16}.
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 39974e3ff4..88af01be70 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -54,21 +54,40 @@ static uint8_t calc_parity_and_line_offset(int line)
  return ret;
  }
  
-int teletext_data_unit_from_vbi_data(int line, uint8_t *src, uint8_t *tgt)

+static void fill_data_unit_head(int line, uint8_t *tgt)
+{
+tgt[0] = 0x02; // data_unit_id
+tgt[1] = 0x2c; // data_unit_length
+tgt[2] = calc_parity_and_line_offset(line); // field_parity, line_offset
+tgt[3] = 0xe4; // framing code
+}
+
+static uint8_t* teletext_data_unit_from_vbi_data(int line, uint8_t *src, 
uint8_t *tgt, vbi_pixfmt fmt)
  {
  vbi_bit_slicer slicer;
  
-vbi_bit_slicer_init(&slicer, 720, 1350, 6937500, 6937500, 0x00e4, 0x, 18, 6, 42 * 8, VBI_MODULATION_NRZ_MSB, VBI_PIXFMT_UYVY);

+vbi_bit_slicer_init(&slicer, 720, 1350, 6937500, 6937500, 0x00e4, 
0x, 18, 6, 42 * 8, VBI_MODULATION_NRZ_MSB, fmt);
  
  if (vbi_bit_slice(&slicer, src, tgt + 4) == FALSE)

-return -1;
+return tgt;
  
-tgt[0] = 0x02; // data_unit_id

-tgt[1] = 0x2c; // data_unit_length
-tgt[2] = calc_parity_and_line_offset(line); // field_parity, line_offset
-tgt[3] = 0xe4; // framing code
+fill_data_unit_head(line, tgt);
  
-return 0;

+return tgt + 46;
+}
+
+static uint8_t* teletext_data_unit_from_vbi_data_10bit(int line, uint8_t *src, 
uint8_t *tgt)
+{
+uint8_t y[720];
+uint8_t *py = y;
+uint8_t *pend = y + 720;
+while (py < pend) {
+*py++ = (src[1] >> 4) + ((src[2] & 15) << 4);
+*py++ = (src[4] >> 2) + ((src[5] & 3 ) << 6);
+*py++ = (src[6] >> 6) + ((src[7] & 63) << 2);
+src += 8;
+}


It would seem that the purpose of this code is to convert between the 
Blackmagic 10-bit format (v210, according to the Blackmagic 
documentation) and YUV420 (which is presumably easier than converting to 
UYVY).  Why not use a color converter for this?  Looking through the 
ffmpeg code base, I see that v210 is handled using a decoder/encoder and 
not as a pixel format, which seems odd, but maybe there is some way to 
take advantage of that support instead of doing it yourself.  At the 
very least, it seems reasonable to add a comment explaining what this 
code is doing.


Also, I understand that this is being done because libzvbi doesn't 
support the v210 pixel format (which would be useful to explain in a 
comment), but I have to wonder if the conversion between the 10-bit v210 
pixel format and the 8-bit YUV420 pixel format will result in a loss of 
data that is relevant for teletext.  If you've accommodated that 
possibility, it would be good to describe in a comment.



+return teletext_data_unit_from_vbi_data(line, y, tgt, VBI_PIXFMT_YUV420);
  }
  #endif
  
@@ -359,7 +378,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(

  //fprintf(stderr,"Video Frame size %d ts %d\n", pkt.size, pkt.pts);
  
  #if CONFIG_LIBZVBI

-if (!no_video && ctx->teletext_lines && videoFrame->GetPixelFormat() == 
bmdFormat8BitYUV && videoFrame->GetWidth() == 720) {
+if (!no_video && ctx->teletext_lines) {
  IDeckLinkVideoFrameAncillary *vanc;
  AVPacket txt_pkt;
  uint8_t txt_buf0[1611]; // max 35 * 46 bytes decoded teletext 
lines + 1 byte data_identifier
@@ -368,16 +387,21 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
  if (videoFrame->GetAncillaryData(&vanc) == S_OK) {
  int i;
  int64_t line_mask = 1;
+BMDPixelFormat vanc_format = vanc->GetPixelFormat();
  txt_buf[0] = 0x10;// data_

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: relax opt_order limit

2017-07-03 Thread Thilo Borgmann 
Am 02.07.17 um 19:45 schrieb Paul B Mahol:
> On 6/11/16, Thilo Borgmann  wrote:
>>
>> Hi,
>>
>>> Am 09.06.2016 um 03:33 schrieb Michael Niedermayer
>>> :
>>>
>>> Fixes: Ticket5297
>>>
>>> Needs review by maintainer / author to check that this is ok and
>>> sufficient
>>> ---
>>> libavcodec/alsdec.c |   10 +-
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> I'll have a look but I need some more days to do so.
>>
>> -Thilo
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> Looks like Michael had same idea like I.

Sorry this have to slipped through these days. However, as I said in a recent
review of a patch from Paul, just adding 2*max_order to the buffer's size is
still a guesswork hackaround an unknown bug.

-Thilo

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: remove unused header

2017-07-03 Thread Thilo Borgmann 
Am 03.07.17 um 08:01 schrieb Steven Liu:
> 2017-07-02 4:24 GMT+08:00 Paul B Mahol :
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/alsdec.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
>> index 31e95e2..ac59885 100644
>> --- a/libavcodec/alsdec.c
>> +++ b/libavcodec/alsdec.c
>> @@ -31,7 +31,6 @@
>>  #include "get_bits.h"
>>  #include "unary.h"
>>  #include "mpeg4audio.h"
>> -#include "bytestream.h"
>>  #include "bgmc.h"
>>  #include "bswapdsp.h"
>>  #include "internal.h"
>> --
>> 2.9.3
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> complied ok!

Ok.

-Thilo

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

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Hendrik Leppkes 
On Mon, Jul 3, 2017 at 5:39 PM, wm4  wrote:
> On Mon, 3 Jul 2017 16:17:42 +0100
> Derek Buitenhuis  wrote:
>
>> On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
>> > breaks fate
>>
>> I'll look into it tonight; busy today.
>>
>> .
>> .
>> .
>>
>> Aside:
>>
>> I'll just add, though, that these two word 'breaks fate' emails
>> are kind of obnoxious when the test in question was added days
>> after I sent the set, so I couldn't have possibly tested against
>> it, and the commit that added the test and this email has /zero/
>> info about what the test actually tests (a bug id is not a commit
>> message).
>
> This. These opaque fate tests are so much work to get around. It went
> far enough that I added bullshit to ffmpeg.c to get around some of the
> questionable tests.
>
> Also, TRAC issue numbers have 0 information contents. Even if you go
> through the obnoxious process of looking it up on TRAC and trying to
> extract iunformation from a confusing discussion with a confused user
> (99% of TRAC issues), TRAC could easily go away. It already happened
> once, and some of the bug numbers in old commits obviously don't match
> with what's on current TRAC.
>

I agree, this test could've easily been named something useful, like
fate-mp4-copy-eac3 or whatever namespaces we use for mp4 tests, which
would convey the same information without having to lookup the ticket
on trac.

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

Re: [FFmpeg-devel] [PATCH] htmlsubtitles: support tag

2017-07-03 Thread Michael Niedermayer 
On Mon, Jul 03, 2017 at 01:54:50PM +0200, Clément Bœsch wrote:
> On Mon, Jul 03, 2017 at 01:43:43PM +0200, wm4 wrote:
> > Some .srt files use this tag.
> > 
> > (An alternative implementation would be correctly ignoring unknown tags,
> > and treating them as whitespace. libass can do automatic line wrapping.)
> > ---
> >  libavcodec/htmlsubtitles.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > index be5c9316ca..fe991678d5 100644
> > --- a/libavcodec/htmlsubtitles.c
> > +++ b/libavcodec/htmlsubtitles.c
> > @@ -167,6 +167,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> > const char *in)
> >  }
> >  } else if (tagname[0] && !tagname[1] && 
> > strspn(tagname, "bisu") == 1) {
> >  av_bprintf(dst, "{\\%c%d}", tagname[0], 
> > !tag_close);
> > +} else if (!strcmp(tagname, "br")) {
> > +av_bprintf(dst, "\\N");
> >  } else {
> >  unknown = 1;
> >  snprintf(tmp, sizeof(tmp), "", tagname);
> 
> So this supports , <   br > and ?

i dont think this supports  from a quick look


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: fix some undefined shifts

2017-07-03 Thread Thilo Borgmann 
Am 03.07.17 um 11:49 schrieb Paul B Mahol:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/alsdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Ok if you really feel we are anywhere near a sign bit here.

-Thilo

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

[FFmpeg-devel] [PATCH] avfilter: add ANSNR filter

2017-07-03 Thread Ashish Singh 
Added ansnr section in doc/filters.texi and changelog and fixed issues.

---
 Changelog|   1 +
 doc/filters.texi |  24 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/ansnr.h  |  29 
 libavfilter/vf_ansnr.c   | 403 +++
 6 files changed, 459 insertions(+)
 create mode 100644 libavfilter/ansnr.h
 create mode 100644 libavfilter/vf_ansnr.c

diff --git a/Changelog b/Changelog
index 1778980..bfe848a 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - config.log and other configuration files moved into ffbuild/ directory
 - update cuvid/nvenc headers to Video Codec SDK 8.0.14
 - afir audio filter
+- ansnr video filter
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index 5985db6..a8068df 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4419,6 +4419,30 @@ input reaches end of stream. This will cause problems if 
your encoding
 pipeline drops frames. If you're trying to apply an image as an
 overlay to a video stream, consider the @var{overlay} filter instead.
 
+@section ansnr
+
+Obtain the average ANSNR (Anti-Noise Signal to Noise
+Ratio) between two input videos.
+
+This filter takes in input two input videos, the first input is
+considered the "main" source and is passed unchanged to the
+output. The second input is used as a "reference" video for computing
+the ANSNR.
+
+Both video inputs must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The obtained average ANSNR is printed through the logging system.
+
+For example:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi ansnr -f null -
+@end example
+
+On this example the input file @file{main.mpg} being processed is compared 
with the
+reference file @file{ref.mpg}.
+
 @section ass
 
 Same as the @ref{subtitles} filter, except that it doesn't require libavcodec
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..705e5a1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -124,6 +124,7 @@ OBJS-$(CONFIG_ANULLSINK_FILTER)  += 
asink_anullsink.o
 # video filters
 OBJS-$(CONFIG_ALPHAEXTRACT_FILTER)   += vf_extractplanes.o
 OBJS-$(CONFIG_ALPHAMERGE_FILTER) += vf_alphamerge.o
+OBJS-$(CONFIG_ANSNR_FILTER)  += vf_ansnr.o dualinput.o 
framesync.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 OBJS-$(CONFIG_ATADENOISE_FILTER) += vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4..c1f67c4 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -136,6 +136,7 @@ static void register_all(void)
 
 REGISTER_FILTER(ALPHAEXTRACT,   alphaextract,   vf);
 REGISTER_FILTER(ALPHAMERGE, alphamerge, vf);
+REGISTER_FILTER(ANSNR,  ansnr,  vf);
 REGISTER_FILTER(ASS,ass,vf);
 REGISTER_FILTER(ATADENOISE, atadenoise, vf);
 REGISTER_FILTER(AVGBLUR,avgblur,vf);
diff --git a/libavfilter/ansnr.h b/libavfilter/ansnr.h
new file mode 100644
index 000..44fb3ba
--- /dev/null
+++ b/libavfilter/ansnr.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_ANSNR_H
+#define AVFILTER_ANSNR_H
+
+static int compute_ansnr(const void *ref, const void *dis, int w,
+ int h, int ref_stride, int dis_stride, double *score,
+ double *score_psnr, double peak, double psnr_max, 
void *ctx);
+
+#endif /* AVFILTER_ANSNR_H */
diff --git a/libavfilter/vf_ansnr.c b/libavfilter/vf_ansnr.c
new file mode 100644
index 000..88d33b2
--- /dev/null
+++ b/libavfilter/vf_ansnr.c
@@ -0,0 +1,403 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it

[FFmpeg-devel] [PATCH] lavc/mediacodec: rescale pts before decoding for both hw and sw buffers

2017-07-03 Thread Aman Gupta 
From: Aman Gupta 

Replicates the logic used in the wrap_hw_buffer path to wrap_sw_buffer
as well.

This fixes decoding issues observed on AMLogic devices with
OMX.amlogic.mpeg2.decoder.awesome, where the decoder would spit out a
constant stream of "mPtsRecoveryCount" errors and decoded frames were
returned in the incorrect order.
---
 libavcodec/mediacodecdec_common.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 1263188d34..316cdba9c1 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -282,10 +282,16 @@ static int mediacodec_wrap_sw_buffer(AVCodecContext 
*avctx,
  * on the last avpacket received which is not in sync with the frame:
  *   * N avpackets can be pushed before 1 frame is actually returned
  *   * 0-sized avpackets are pushed to flush remaining frames at EOS */
-frame->pts = info->presentationTimeUs;
+if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
+frame->pts = av_rescale_q(info->presentationTimeUs,
+  av_make_q(1, 100),
+  avctx->pkt_timebase);
+} else {
+frame->pts = info->presentationTimeUs;
+}
 #if FF_API_PKT_PTS
 FF_DISABLE_DEPRECATION_WARNINGS
-frame->pkt_pts = info->presentationTimeUs;
+frame->pkt_pts = frame->pts;
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 frame->pkt_dts = AV_NOPTS_VALUE;
@@ -613,7 +619,7 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 memcpy(data, pkt->data + offset, size);
 offset += size;
 
-if (s->surface && avctx->pkt_timebase.num && 
avctx->pkt_timebase.den) {
+if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
 pts = av_rescale_q(pts, avctx->pkt_timebase, av_make_q(1, 
100));
 }
 
-- 
2.11.0 (Apple Git-81)

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

Re: [FFmpeg-devel] [PATCH 2/2] avdevice/decklink_dec: add support for receiving op47 teletext

2017-07-03 Thread Aaron Levinson 

On 6/30/2017 5:05 PM, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
  doc/indevs.texi  |  18 ---
  libavdevice/decklink_dec.cpp | 125 +++
  2 files changed, 125 insertions(+), 18 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 330617a7c9..2815248750 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -245,13 +245,17 @@ of uyvy422. Not all Blackmagic devices support this 
option.
  
  @item teletext_lines

  If set to nonzero, an additional teletext stream will be captured from the
-vertical ancillary data. This option is a bitmask of the VBI lines checked,
-specifically lines 6 to 22, and lines 318 to 335. Line 6 is the LSB in the 
mask.
-Selected lines which do not contain teletext information will be ignored. You
-can use the special @option{all} constant to select all possible lines, or
-@option{standard} to skip lines 6, 318 and 319, which are not compatible with 
all
-receivers. Capturing teletext only works for SD PAL sources. To use this
-option, ffmpeg needs to be compiled with @code{--enable-libzvbi}.
+vertical ancillary data. Both SD PAL and HD sources (OP47) are supported.
+
+This option is a bitmask of the SD VBI lines captured, specifically lines 6 to


Probably should be "SD PAL VBI lines" to make it clear that NTSC is not 
supported.



+22, and lines 318 to 335. Line 6 is the LSB in the mask. Selected lines which
+do not contain teletext information will be ignored. You can use the special
+@option{all} constant to select all possible lines, or @option{standard} to
+skip lines 6, 318 and 319, which are not compatible with all receivers.
+
+For SD sources ffmpeg needs to be compiled with @code{--enable-libzvbi}. For HD
+sources on older (pre-4K) DeckLink card models you have to capture in 10 bit
+mode.


Would be good to indicate that the bit mask is ignored for HD sources.

The documentation indicates that both SD PAL and HD sources are 
supported, but an examination of the changes indicates that only some HD 
sources are supported.  Specifically, for HD sources to work, it expects 
a width of 1920.  This would cover both 1080i and 1080p, but it doesn't 
cover 720p, with is also an HD video mode.  My guess is that the code 
has probably only been tested with 1080i as well, and in that case, it 
would make sense to only specify 1080i in the documentation.  Further, 
since the original code only supports SD PAL, I would suspect that the 
latest code has only been tested using "PAL" frame rates at 1080i, i.e. 
1080i50.  If it is unclear if the code will also work with 1080i59.94 
and 1080i60, then it would be best to only support 1080i50.


Also, should have a comma after "For SD sources" and after "For HD sources".

  
  @item channels

  Defines number of audio channels to capture. Must be @samp{2}, @samp{8} or 
@samp{16}.
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 88af01be70..a4781dd072 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -35,6 +35,7 @@ extern "C" {
  #include "libavutil/imgutils.h"
  #include "libavutil/time.h"
  #include "libavutil/mathematics.h"
+#include "libavutil/reverse.h"
  #if CONFIG_LIBZVBI
  #include 
  #endif
@@ -43,7 +44,6 @@ extern "C" {
  #include "decklink_common.h"
  #include "decklink_dec.h"
  
-#if CONFIG_LIBZVBI

  static uint8_t calc_parity_and_line_offset(int line)
  {
  uint8_t ret = (line < 313) << 5;
@@ -62,6 +62,7 @@ static void fill_data_unit_head(int line, uint8_t *tgt)
  tgt[3] = 0xe4; // framing code
  }
  
+#if CONFIG_LIBZVBI

  static uint8_t* teletext_data_unit_from_vbi_data(int line, uint8_t *src, 
uint8_t *tgt, vbi_pixfmt fmt)
  {
  vbi_bit_slicer slicer;
@@ -91,6 +92,94 @@ static uint8_t* teletext_data_unit_from_vbi_data_10bit(int 
line, uint8_t *src, u
  }
  #endif
  
+static uint8_t* teletext_data_unit_from_op47_vbi_packet(int line, int *py, uint8_t *tgt)

+{
+int i;
+
+if (py[0] != 0x255 || py[1] != 0x255 || py[2] != 0x227)
+return tgt;
+
+fill_data_unit_head(line, tgt);
+
+py += 3;
+tgt += 4;
+
+for (i = 0; i < 42; i++)
+   *tgt++ = ff_reverse[py[i] & 255];
+
+return tgt;
+}
+
+static int linemask_matches(int line, int64_t mask)
+{
+int shift = -1;
+if (line >= 6 && line <= 22)
+shift = line - 6;
+if (line >= 318 && line <= 335)
+shift = line - 318 + 17;
+return shift >= 0 && ((1ULL << shift) & mask);
+}
+
+static uint8_t* teletext_data_unit_from_op47_data(int *py, int *pend, uint8_t 
*tgt, int64_t wanted_lines)
+{
+if (py < pend - 9) {
+if (py[0] == 0x151 && py[1] == 0x115 && py[3] == 0x102) {  // 
identifier, identifier, format code for WST teletext
+int *descriptors = py + 4;
+int i;
+py += 9;
+for (i = 0; i < 5 && py < pend - 45; i++, py += 45) {
+int line = (descriptors[i] & 31) + (!(descriptors[i] & 128)) * 
313;
+

[FFmpeg-devel] [PATCH] avfilter: add VMAF filter

2017-07-03 Thread Ashish Singh 
Added vmaf section in doc/filters.texi and Changelog.

---
 Changelog|   1 +
 configure|   5 +
 doc/filters.texi |  33 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_vmaf.c| 402 +++
 6 files changed, 443 insertions(+)
 create mode 100644 libavfilter/vf_vmaf.c

diff --git a/Changelog b/Changelog
index 1778980..311b55b 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - config.log and other configuration files moved into ffbuild/ directory
 - update cuvid/nvenc headers to Video Codec SDK 8.0.14
 - afir audio filter
+- vmaf video filter
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/configure b/configure
index 5ae5227..bafcd07 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,7 @@ External library support:
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
+  --enable-libvmaf enable vmaf filter via libvmaf [no]
   --enable-libvo-amrwbenc  enable AMR-WB encoding via libvo-amrwbenc [no]
   --enable-libvorbis   enable Vorbis en/decoding via libvorbis,
native implementation exists [no]
@@ -1569,6 +1570,7 @@ EXTERNAL_LIBRARY_LIST="
 libtheora
 libtwolame
 libv4l2
+libvmaf
 libvorbis
 libvpx
 libwavpack
@@ -3172,6 +3174,7 @@ uspp_filter_deps="gpl avcodec"
 vaguedenoiser_filter_deps="gpl"
 vidstabdetect_filter_deps="libvidstab"
 vidstabtransform_filter_deps="libvidstab"
+vmaf_filter_deps="libvmaf"
 zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg"
@@ -5845,6 +5848,8 @@ enabled libtwolame&& require libtwolame twolame.h 
twolame_init -ltwolame
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2.h v4l2_ioctl
 enabled libvidstab&& require_pkg_config "vidstab >= 0.98" 
vid.stab/libvidstab.h vsMotionDetectInit
+enabled libvmaf   && { check_lib libvmaf "libvmaf.h" "compute_vmaf" 
-lvmaf -lstdc++ -lpthread -lm ||
+   die "ERROR: libvmaf must be installed"; }
 enabled libvo_amrwbenc&& require libvo_amrwbenc vo-amrwbenc/enc_if.h 
E_IF_init -lvo-amrwbenc
 enabled libvorbis && require libvorbis vorbis/vorbisenc.h 
vorbis_info_init -lvorbisenc -lvorbis -logg
 
diff --git a/doc/filters.texi b/doc/filters.texi
index 5985db6..792a11c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14701,6 +14701,39 @@ vignette='PI/4+random(1)*PI/50':eval=frame
 
 @end itemize
 
+@section vmaf
+
+Obtain the average VMAF (Video Multi-Method Assessment Fusion)
+score between two input videos.
+
+This filter takes in input two input videos, the first input is
+considered the "main" source and is passed unchanged to the
+output. The second input is used as a "reference" video for computing
+the VMAF score.
+
+Both video inputs must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The obtained average VMAF score is printed through the logging system.
+
+Currently it requires Netflix's vmaf library (libvmaf) as a pre-requisite.
+It can be enabled using --enable-libvmaf at ./configure ..
+If no model path is not specified it uses default model.
+
+For example:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf -f null -
+@end example
+
+Example with options:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf="psnr=1:enable-transform=1" -f null -
+@end example
+
+On this example the input file @file{main.mpg} being processed is compared 
with the
+reference file @file{ref.mpg}.
+
 @section vstack
 Stack input videos vertically.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8a..1c4bd56 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -314,6 +314,7 @@ OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
+OBJS-$(CONFIG_VMAF_FILTER)   += vf_vmaf.o dualinput.o 
framesync.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4..6894a6f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -325,6 +325,7 @@ static void register_all(void)
 REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Marton Balint 



On Mon, 3 Jul 2017, Hendrik Leppkes wrote:


On Mon, Jul 3, 2017 at 5:39 PM, wm4  wrote:

On Mon, 3 Jul 2017 16:17:42 +0100
Derek Buitenhuis  wrote:


On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
> breaks fate

I'll look into it tonight; busy today.

.
.
.

Aside:

I'll just add, though, that these two word 'breaks fate' emails
are kind of obnoxious when the test in question was added days
after I sent the set, so I couldn't have possibly tested against
it, and the commit that added the test and this email has /zero/
info about what the test actually tests (a bug id is not a commit
message).


This. These opaque fate tests are so much work to get around. It went
far enough that I added bullshit to ffmpeg.c to get around some of the
questionable tests.

Also, TRAC issue numbers have 0 information contents. Even if you go
through the obnoxious process of looking it up on TRAC and trying to
extract iunformation from a confusing discussion with a confused user
(99% of TRAC issues), TRAC could easily go away. It already happened
once, and some of the bug numbers in old commits obviously don't match
with what's on current TRAC.



I agree, this test could've easily been named something useful, like
fate-mp4-copy-eac3 or whatever namespaces we use for mp4 tests, which
would convey the same information without having to lookup the ticket
on trac.



Can't the project pay someone to make fate tests from fixed trac tickets? 
Or make this an outreachy goal, like API tests, or something like that.


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

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Paul B Mahol 
On 7/3/17, Marton Balint  wrote:
>
>
> On Mon, 3 Jul 2017, Hendrik Leppkes wrote:
>
>> On Mon, Jul 3, 2017 at 5:39 PM, wm4  wrote:
>>> On Mon, 3 Jul 2017 16:17:42 +0100
>>> Derek Buitenhuis  wrote:
>>>
 On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
 > breaks fate

 I'll look into it tonight; busy today.

 .
 .
 .

 Aside:

 I'll just add, though, that these two word 'breaks fate' emails
 are kind of obnoxious when the test in question was added days
 after I sent the set, so I couldn't have possibly tested against
 it, and the commit that added the test and this email has /zero/
 info about what the test actually tests (a bug id is not a commit
 message).
>>>
>>> This. These opaque fate tests are so much work to get around. It went
>>> far enough that I added bullshit to ffmpeg.c to get around some of the
>>> questionable tests.
>>>
>>> Also, TRAC issue numbers have 0 information contents. Even if you go
>>> through the obnoxious process of looking it up on TRAC and trying to
>>> extract iunformation from a confusing discussion with a confused user
>>> (99% of TRAC issues), TRAC could easily go away. It already happened
>>> once, and some of the bug numbers in old commits obviously don't match
>>> with what's on current TRAC.
>>>
>>
>> I agree, this test could've easily been named something useful, like
>> fate-mp4-copy-eac3 or whatever namespaces we use for mp4 tests, which
>> would convey the same information without having to lookup the ticket
>> on trac.
>>
>
> Can't the project pay someone to make fate tests from fixed trac tickets?
> Or make this an outreachy goal, like API tests, or something like that.

What would then remain for Carl and folks?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Nicolas George 
Le quintidi 15 messidor, an CCXXV, Paul B Mahol a écrit :
> What would then remain for Carl and folks?

Do you show such despise for other people's work on purpose or is it
your real opinion seeping through?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread James Almer 
On 7/3/2017 12:45 PM, Hendrik Leppkes wrote:
> On Mon, Jul 3, 2017 at 5:39 PM, wm4  wrote:
>> On Mon, 3 Jul 2017 16:17:42 +0100
>> Derek Buitenhuis  wrote:
>>
>>> On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
 breaks fate
>>>
>>> I'll look into it tonight; busy today.
>>>
>>> .
>>> .
>>> .
>>>
>>> Aside:
>>>
>>> I'll just add, though, that these two word 'breaks fate' emails
>>> are kind of obnoxious when the test in question was added days
>>> after I sent the set, so I couldn't have possibly tested against
>>> it, and the commit that added the test and this email has /zero/
>>> info about what the test actually tests (a bug id is not a commit
>>> message).
>>
>> This. These opaque fate tests are so much work to get around. It went
>> far enough that I added bullshit to ffmpeg.c to get around some of the
>> questionable tests.
>>
>> Also, TRAC issue numbers have 0 information contents. Even if you go
>> through the obnoxious process of looking it up on TRAC and trying to
>> extract iunformation from a confusing discussion with a confused user
>> (99% of TRAC issues), TRAC could easily go away. It already happened
>> once, and some of the bug numbers in old commits obviously don't match
>> with what's on current TRAC.
>>
> 
> I agree, this test could've easily been named something useful, like
> fate-mp4-copy-eac3 or whatever namespaces we use for mp4 tests, which
> would convey the same information without having to lookup the ticket
> on trac.

The test can be renamed. What can't be changed in the sample name if
it's already used in a release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

2017-07-03 Thread Marton Balint 



On Mon, 3 Jul 2017, Aaron Levinson wrote:

+static uint8_t* teletext_data_unit_from_vbi_data_10bit(int line, uint8_t 

*src, uint8_t *tgt)

+{
+uint8_t y[720];
+uint8_t *py = y;
+uint8_t *pend = y + 720;
+while (py < pend) {
+*py++ = (src[1] >> 4) + ((src[2] & 15) << 4);
+*py++ = (src[4] >> 2) + ((src[5] & 3 ) << 6);
+*py++ = (src[6] >> 6) + ((src[7] & 63) << 2);
+src += 8;
+}


It would seem that the purpose of this code is to convert between the 
Blackmagic 10-bit format (v210, according to the Blackmagic 
documentation) and YUV420 (which is presumably easier than converting to 
UYVY).  Why not use a color converter for this?


Because I only need the luma component and only in 8 bit, so getting 
anything else would be a waste of resources. Also the code is short enough 
and more readable than factorizing something from v210dec.


Looking through the 
ffmpeg code base, I see that v210 is handled using a decoder/encoder and 
not as a pixel format, which seems odd, but maybe there is some way to 
take advantage of that support instead of doing it yourself.  At the 
very least, it seems reasonable to add a comment explaining what this 
code is doing.


ok for the comment.



Also, I understand that this is being done because libzvbi doesn't 
support the v210 pixel format (which would be useful to explain in a 
comment), but I have to wonder if the conversion between the 10-bit v210 
pixel format and the 8-bit YUV420 pixel format will result in a loss of 
data that is relevant for teletext.  If you've accommodated that 
possibility, it would be good to describe in a comment.


I understand your concern, but for teletext you decode roughly 0.5 bit of 
information from a 8 bit value. So even using 8bit is a lot more than what 
you need. I will add a comment about this.



  #if CONFIG_LIBZVBI
-if (!no_video && ctx->teletext_lines && 
videoFrame->GetPixelFormat() == bmdFormat8BitYUV && videoFrame->GetWidth() == 
720) {

+if (!no_video && ctx->teletext_lines) {
  IDeckLinkVideoFrameAncillary *vanc;
  AVPacket txt_pkt;
  uint8_t txt_buf0[1611]; // max 35 * 46 bytes decoded teletext 

lines + 1 byte data_identifier
@@ -368,16 +387,21 @@ HRESULT 

decklink_input_callback::VideoInputFrameArrived(

  if (videoFrame->GetAncillaryData(&vanc) == S_OK) {
  int i;
  int64_t line_mask = 1;
+BMDPixelFormat vanc_format = vanc->GetPixelFormat();
  txt_buf[0] = 0x10;// data_identifier - EBU_data
  txt_buf++;
-for (i = 6; i < 336; i++, line_mask <<= 1) {
-uint8_t *buf;
-if ((ctx->teletext_lines & line_mask) && 

vanc->GetBufferForVerticalBlankingLine(i, (void**)&buf) == S_OK) {
-if (teletext_data_unit_from_vbi_data(i, buf, 

txt_buf) >= 0)

-txt_buf += 46;
+if (videoFrame->GetWidth() == 720 && (vanc_format == 

bmdFormat8BitYUV || vanc_format == bmdFormat10BitYUV)) {

According to the documentation in indevs.texi, the teletext support only 
works for SD PAL.  Yet, this check doesn't isolate things just to SD 
PAL.  I know that this issue was preexisting (although you have moved 
the check to a different place in the code), but if you want to restrict 
this code to SD PAL, then the best way is to check if the BMDDisplayMode 
is bmdModePAL.  If you want to base things on the width/height, you 
could check for a width of 720 and a height of 576, although this could 
indicate either bmdModePAL or bmdModePALp (although there may be no 
Blackmagic devices that support bmdModePALp on input).  Just checking 
for a width of 720 includes NTSC, NTSCp, PAL, and PALp.


Ok.




+for (i = 6; i < 336; i++, line_mask <<= 1) {
+uint8_t *buf;
+if ((ctx->teletext_lines & line_mask) && 

vanc->GetBufferForVerticalBlankingLine(i, (void**)&buf) == S_OK) {

+if (vanc_format == bmdFormat8BitYUV)
+txt_buf = 

teletext_data_unit_from_vbi_data(i, buf, txt_buf, VBI_PIXFMT_UYVY);

+else
+txt_buf = 

teletext_data_unit_from_vbi_data_10bit(i, buf, txt_buf);

Since you already know if the format is 10-bit or 8-bit prior to 
entering the for loop, putting the check here may result in an 
unnecessary branch every loop iteration, depending on how the compiler 
optimizes the code.  So, for efficiency, it would make more sense to 
move the if check to earlier, prior to executing the for loop, but this 
will end up causing you to effectively duplicate the for loop code the 
way it is currently written.




The overhead is negligable (35 if-s per frame) and I find this more 
readable than duplicating the whole loop.



+}
+

Re: [FFmpeg-devel] [PATCH 2/2] avdevice/decklink_dec: add support for receiving op47 teletext

2017-07-03 Thread Marton Balint 


On Mon, 3 Jul 2017, Aaron Levinson wrote:


+
+This option is a bitmask of the SD VBI lines captured, specifically lines 

6 to

Probably should be "SD PAL VBI lines" to make it clear that NTSC is not 
supported.


ok.



+22, and lines 318 to 335. Line 6 is the LSB in the mask. Selected lines 

which
+do not contain teletext information will be ignored. You can use the 

special
+@option{all} constant to select all possible lines, or @option{standard} 

to

+skip lines 6, 318 and 319, which are not compatible with all receivers.
+
+For SD sources ffmpeg needs to be compiled with @code{--enable-libzvbi}. 

For HD
+sources on older (pre-4K) DeckLink card models you have to capture in 10 

bit

+mode.


Would be good to indicate that the bit mask is ignored for HD sources.


Actually it is not. Any HD line can contain an OP47 packet referencing any 
SD line, the bitmask is checked against the decoded source line number 
from OP47.




The documentation indicates that both SD PAL and HD sources are 
supported, but an examination of the changes indicates that only some HD 
sources are supported.  Specifically, for HD sources to work, it expects 
a width of 1920.  This would cover both 1080i and 1080p, but it doesn't 
cover 720p, with is also an HD video mode.  My guess is that the code 
has probably only been tested with 1080i as well, and in that case, it 
would make sense to only specify 1080i in the documentation.  Further, 
since the original code only supports SD PAL, I would suspect that the 
latest code has only been tested using "PAL" frame rates at 1080i, i.e. 
1080i50.  If it is unclear if the code will also work with 1080i59.94 
and 1080i60, then it would be best to only support 1080i50.


1080i/p/59.94/60 should work all the same. For 720p different VANC lines 
might be needed. I will change the HD references to "Full HD" so it will 
be more clear.




Also, should have a comma after "For SD sources" and after "For HD sources".


Ok.

+static uint8_t* teletext_data_unit_from_vanc_data(uint8_t *src, uint8_t 

*tgt, int64_t wanted_lines)

+{
+int y[1920];
+int *py = y;
+int *pend = y + 1920;
+while (py < pend) {
+*py++ = (src[1] >> 2) + ((src[2] & 15) << 6);
+*py++ =  src[4]   + ((src[5] &  3) << 8);
+*py++ = (src[6] >> 4) + ((src[7] & 63) << 4);
+src += 8;
+}


My comments from the last review pertain to this code.  Plus, now this 
code is duplicated, so it would make sense to consolidate it to a new 
function.


Not exaclty the same, because I need the 10 bit data here. Only thing 
I could do is use some DEFINE magic to factorize this.





+py = y;
+while (py < pend - 6) {
+if (py[0] == 0 && py[1] == 0x3ff && py[2] == 0x3ff) { 

// ancilliary data flag

"ancilliary" -> "ancillary" in the comment


ok.


-#if CONFIG_LIBZVBI
  if (!no_video && ctx->teletext_lines) {
  IDeckLinkVideoFrameAncillary *vanc;
  AVPacket txt_pkt;
-uint8_t txt_buf0[1611]; // max 35 * 46 bytes decoded teletext 

lines + 1 byte data_identifier
+uint8_t txt_buf0[3531]; // 35 * 46 bytes decoded teletext 

lines + 1 byte data_identifier + 1920 bytes OP47 decode buffer

It is a little hard to follow this code, but it would seem that a max of 
1611 or 1920 bytes would be needed (so 1920), not 1611 + 1920 bytes.


Not exactly, in the HD case 1611 bytes are reserved for existing decoded 
packets, 1920 bytes are reserved for the teletext decoded from the next 
VANC line, which might contain multiple teletext lines.





  uint8_t *txt_buf = txt_buf0;

  if (videoFrame->GetAncillaryData(&vanc) == S_OK) {
@@ -390,6 +478,7 @@ HRESULT 

decklink_input_callback::VideoInputFrameArrived(

  BMDPixelFormat vanc_format = vanc->GetPixelFormat();
  txt_buf[0] = 0x10;// data_identifier - EBU_data
  txt_buf++;
+#if CONFIG_LIBZVBI
  if (videoFrame->GetWidth() == 720 && (vanc_format == 

bmdFormat8BitYUV || vanc_format == bmdFormat10BitYUV)) {

  for (i = 6; i < 336; i++, line_mask <<= 1) {
  uint8_t *buf;
@@ -403,6 +492,20 @@ HRESULT 

decklink_input_callback::VideoInputFrameArrived(

  i = 317;
  }
  }
+#endif
+if (videoFrame->GetWidth() == 1920 && vanc_format == 

bmdFormat10BitYUV) {

As written, this would support all 1080p and 1080i video modes supported 
by DeckLink.  I would suspect that is not the desired behavior.  See the 
relevant comments from my review of the first patch.


It is in this case.




+for (i = 8; i < 584; i++) {
+uint8_t *buf;
+if (vanc->GetBufferForVerticalBlankingLine(i, 

(void**)&buf) == S_OK)
+txt_buf = 

teletext_data_unit_from_vanc_data(buf, txt_buf, ctx->teletext_lines);

+

[FFmpeg-devel] [PATCH] lavc/mediacodec: add missing newline on warning

2017-07-03 Thread Aman Gupta 
From: Aman Gupta 

---
 libavcodec/mediacodecdec_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 1263188d34..f88b2cde54 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -478,7 +478,7 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 
 profile = ff_AMediaCodecProfile_getProfileFromAVCodecContext(avctx);
 if (profile < 0) {
-av_log(avctx, AV_LOG_WARNING, "Unsupported or unknown profile");
+av_log(avctx, AV_LOG_WARNING, "Unsupported or unknown profile\n");
 }
 
 s->codec_name = ff_AMediaCodecList_getCodecNameByType(mime, profile, 0, 
avctx);
-- 
2.11.0 (Apple Git-81)

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

Re: [FFmpeg-devel] [PATCH 2/2] avdevice/decklink_dec: add support for receiving op47 teletext

2017-07-03 Thread Aaron Levinson 

On 7/3/2017 1:06 PM, Marton Balint wrote:


On Mon, 3 Jul 2017, Aaron Levinson wrote:

+22, and lines 318 to 335. Line 6 is the LSB in the mask. Selected lines 

which
+do not contain teletext information will be ignored. You can use the 

special
+@option{all} constant to select all possible lines, or 
@option{standard} 

to

+skip lines 6, 318 and 319, which are not compatible with all receivers.
+
+For SD sources ffmpeg needs to be compiled with 
@code{--enable-libzvbi}. 

For HD
+sources on older (pre-4K) DeckLink card models you have to capture 
in 10 

bit

+mode.


Would be good to indicate that the bit mask is ignored for HD sources.


Actually it is not. Any HD line can contain an OP47 packet referencing 
any SD line, the bitmask is checked against the decoded source line 
number from OP47.




The documentation indicates that both SD PAL and HD sources are 
supported, but an examination of the changes indicates that only some 
HD sources are supported.  Specifically, for HD sources to work, it 
expects a width of 1920.  This would cover both 1080i and 1080p, but 
it doesn't cover 720p, with is also an HD video mode.  My guess is 
that the code has probably only been tested with 1080i as well, and in 
that case, it would make sense to only specify 1080i in the 
documentation.  Further, since the original code only supports SD PAL, 
I would suspect that the latest code has only been tested using "PAL" 
frame rates at 1080i, i.e. 1080i50.  If it is unclear if the code will 
also work with 1080i59.94 and 1080i60, then it would be best to only 
support 1080i50.


1080i/p/59.94/60 should work all the same. For 720p different VANC lines 
might be needed. I will change the HD references to "Full HD" so it will 
be more clear.


Searching for "full HD" tends to indicate that term is usually 
associated with 1080p but not with 720p nor 1080i (for example, at 
http://www.pcmag.com/article2/0,2817,2413044,00.asp ).  I think it would 
be clearer to call out the specific video modes that are supported.


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

Re: [FFmpeg-devel] [PATCH 2/2] avdevice/decklink_dec: add support for receiving op47 teletext

2017-07-03 Thread Marton Balint 



On Mon, 3 Jul 2017, Aaron Levinson wrote:


On 7/3/2017 1:06 PM, Marton Balint wrote:


On Mon, 3 Jul 2017, Aaron Levinson wrote:

+22, and lines 318 to 335. Line 6 is the LSB in the mask. Selected lines 

which
+do not contain teletext information will be ignored. You can use the 

special
+@option{all} constant to select all possible lines, or 
@option{standard} 

to

+skip lines 6, 318 and 319, which are not compatible with all receivers.
+
+For SD sources ffmpeg needs to be compiled with 
@code{--enable-libzvbi}. 

For HD
+sources on older (pre-4K) DeckLink card models you have to capture 
in 10 

bit

+mode.


Would be good to indicate that the bit mask is ignored for HD sources.


Actually it is not. Any HD line can contain an OP47 packet referencing 
any SD line, the bitmask is checked against the decoded source line 
number from OP47.




The documentation indicates that both SD PAL and HD sources are 
supported, but an examination of the changes indicates that only some 
HD sources are supported.  Specifically, for HD sources to work, it 
expects a width of 1920.  This would cover both 1080i and 1080p, but 
it doesn't cover 720p, with is also an HD video mode.  My guess is 
that the code has probably only been tested with 1080i as well, and in 
that case, it would make sense to only specify 1080i in the 
documentation.  Further, since the original code only supports SD PAL, 
I would suspect that the latest code has only been tested using "PAL" 
frame rates at 1080i, i.e. 1080i50.  If it is unclear if the code will 
also work with 1080i59.94 and 1080i60, then it would be best to only 
support 1080i50.


1080i/p/59.94/60 should work all the same. For 720p different VANC lines 
might be needed. I will change the HD references to "Full HD" so it will 
be more clear.


Searching for "full HD" tends to indicate that term is usually 
associated with 1080p but not with 720p nor 1080i (for example, at 
http://www.pcmag.com/article2/0,2817,2413044,00.asp ).  I think it would 
be clearer to call out the specific video modes that are supported.


I disagree. Full HD is resolution, not fps. Anybody working with 
interlaced signals will know that full HD means both progressive and 
interlaced here.


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

[FFmpeg-devel] [PATCH] decode.c: Handle 0-size packets in compat_decode

2017-07-03 Thread Reimar Döffinger 
The old API did that just fine, and if we provide
a compatibility layer it should at least be compatible.
For the test-case (feeding AVParser output directly to
decoder, failing to discard 0-size packets) just discarding
0-size packets at the start works, but not sure if in some
cases we might want to pass them on to e.g. allow retrieving
additional pending frames.
---
 libavcodec/decode.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 052f93d82f..c63090f137 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -842,6 +842,7 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
*frame,
 avci->compat_decode = 1;
 
 if (avci->compat_decode_partial_size > 0 &&
+pkt->size &&
 avci->compat_decode_partial_size != pkt->size) {
 av_log(avctx, AV_LOG_ERROR,
"Got unexpected packet size after a partial decode\n");
@@ -902,7 +903,10 @@ finish:
 ret = FFMIN(avci->compat_decode_consumed, pkt->size);
 }
 avci->compat_decode_consumed = 0;
-avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
+// for compatibility with old API behaviour handle
+// 0-size specially
+if (pkt->size)
+avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
 
 return ret;
 }
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] decode.c: Handle 0-size packets in compat_decode

2017-07-03 Thread wm4 
On Mon,  3 Jul 2017 20:57:21 +0200
Reimar Döffinger  wrote:

> The old API did that just fine, and if we provide
> a compatibility layer it should at least be compatible.
> For the test-case (feeding AVParser output directly to
> decoder, failing to discard 0-size packets) just discarding
> 0-size packets at the start works, but not sure if in some
> cases we might want to pass them on to e.g. allow retrieving
> additional pending frames.
> ---
>  libavcodec/decode.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 052f93d82f..c63090f137 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -842,6 +842,7 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  avci->compat_decode = 1;
>  
>  if (avci->compat_decode_partial_size > 0 &&
> +pkt->size &&
>  avci->compat_decode_partial_size != pkt->size) {
>  av_log(avctx, AV_LOG_ERROR,
> "Got unexpected packet size after a partial decode\n");
> @@ -902,7 +903,10 @@ finish:
>  ret = FFMIN(avci->compat_decode_consumed, pkt->size);
>  }
>  avci->compat_decode_consumed = 0;
> -avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
> +// for compatibility with old API behaviour handle
> +// 0-size specially
> +if (pkt->size)
> +avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
>  
>  return ret;
>  }

I thought it was decided that 0-sized packets are always disallowed for
encoding? Also, 0-sized packets are drain packets even with the old
API, and thus could never properly work. You just relied in implicit
restart behavior (i.e. leaving the drained state by feeding a new
non-0-sized packet), which also didn't work with all decoders.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add limiter filter

2017-07-03 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  17 +++
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/limiter.h |  33 ++
 libavfilter/vf_limiter.c  | 228 ++
 libavfilter/x86/Makefile  |   2 +
 libavfilter/x86/vf_limiter.asm|  80 +
 libavfilter/x86/vf_limiter_init.c |  41 +++
 8 files changed, 403 insertions(+)
 create mode 100644 libavfilter/limiter.h
 create mode 100644 libavfilter/vf_limiter.c
 create mode 100644 libavfilter/x86/vf_limiter.asm
 create mode 100644 libavfilter/x86/vf_limiter_init.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 930ca4c..dbf0fc1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9639,6 +9639,23 @@ The formula that generates the correction is:
 where @var{r_0} is halve of the image diagonal and @var{r_src} and @var{r_tgt} 
are the
 distances from the focal point in the source and target images, respectively.
 
+@section limiter
+
+Limits the pixel components values to the specified range [min, max].
+
+The filter accepts the following options:
+
+@table @option
+@item min
+Lower bound. Defaults to the lowest allowed value for the input.
+
+@item max
+Upper bound. Defaults to the highest allowed value for the input.
+
+@item planes
+Specify which planes will be processed.
+@end table
+
 @section loop
 
 Loop video frames.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f023a0d..4d85f65 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -216,6 +216,7 @@ OBJS-$(CONFIG_INTERLACE_FILTER)  += 
vf_interlace.o
 OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
 OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
 OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
+OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
 OBJS-$(CONFIG_LOOP_FILTER)   += f_loop.o
 OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
 OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c1c5233..0a990ca 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -228,6 +228,7 @@ static void register_all(void)
 REGISTER_FILTER(INTERLEAVE, interleave, vf);
 REGISTER_FILTER(KERNDEINT,  kerndeint,  vf);
 REGISTER_FILTER(LENSCORRECTION, lenscorrection, vf);
+REGISTER_FILTER(LIMITER,limiter,vf);
 REGISTER_FILTER(LOOP,   loop,   vf);
 REGISTER_FILTER(LUMAKEY,lumakey,vf);
 REGISTER_FILTER(LUT,lut,vf);
diff --git a/libavfilter/limiter.h b/libavfilter/limiter.h
new file mode 100644
index 000..54d423d
--- /dev/null
+++ b/libavfilter/limiter.h
@@ -0,0 +1,33 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_LIMITER_H
+#define AVFILTER_LIMITER_H
+
+#include 
+#include 
+
+typedef struct LimiterDSPContext {
+void (*limiter)(const uint8_t *src, uint8_t *dst,
+ptrdiff_t slinesize, ptrdiff_t dlinesize,
+int w, int h, int min, int max);
+} LimiterDSPContext;
+
+void ff_limiter_init_x86(LimiterDSPContext *dsp, int bpp);
+
+#endif /* AVFILTER_LIMITER_H */
diff --git a/libavfilter/vf_limiter.c b/libavfilter/vf_limiter.c
new file mode 100644
index 000..d6f5745
--- /dev/null
+++ b/libavfilter/vf_limiter.c
@@ -0,0 +1,228 @@
+/*
+ * 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

Re: [FFmpeg-devel] [PATCH] avfilter: add limiter filter

2017-07-03 Thread James Almer 
On 7/3/2017 4:45 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  17 +++
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/limiter.h |  33 ++
>  libavfilter/vf_limiter.c  | 228 
> ++
>  libavfilter/x86/Makefile  |   2 +
>  libavfilter/x86/vf_limiter.asm|  80 +
>  libavfilter/x86/vf_limiter_init.c |  41 +++
>  8 files changed, 403 insertions(+)
>  create mode 100644 libavfilter/limiter.h
>  create mode 100644 libavfilter/vf_limiter.c
>  create mode 100644 libavfilter/x86/vf_limiter.asm
>  create mode 100644 libavfilter/x86/vf_limiter_init.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 930ca4c..dbf0fc1 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9639,6 +9639,23 @@ The formula that generates the correction is:
>  where @var{r_0} is halve of the image diagonal and @var{r_src} and 
> @var{r_tgt} are the
>  distances from the focal point in the source and target images, respectively.
>  
> +@section limiter
> +
> +Limits the pixel components values to the specified range [min, max].
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item min
> +Lower bound. Defaults to the lowest allowed value for the input.
> +
> +@item max
> +Upper bound. Defaults to the highest allowed value for the input.
> +
> +@item planes
> +Specify which planes will be processed.
> +@end table
> +
>  @section loop
>  
>  Loop video frames.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index f023a0d..4d85f65 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -216,6 +216,7 @@ OBJS-$(CONFIG_INTERLACE_FILTER)  += 
> vf_interlace.o
>  OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
>  OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
>  OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
> +OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
>  OBJS-$(CONFIG_LOOP_FILTER)   += f_loop.o
>  OBJS-$(CONFIG_LUMAKEY_FILTER)+= vf_lumakey.o
>  OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c1c5233..0a990ca 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -228,6 +228,7 @@ static void register_all(void)
>  REGISTER_FILTER(INTERLEAVE, interleave, vf);
>  REGISTER_FILTER(KERNDEINT,  kerndeint,  vf);
>  REGISTER_FILTER(LENSCORRECTION, lenscorrection, vf);
> +REGISTER_FILTER(LIMITER,limiter,vf);
>  REGISTER_FILTER(LOOP,   loop,   vf);
>  REGISTER_FILTER(LUMAKEY,lumakey,vf);
>  REGISTER_FILTER(LUT,lut,vf);
> diff --git a/libavfilter/limiter.h b/libavfilter/limiter.h
> new file mode 100644
> index 000..54d423d
> --- /dev/null
> +++ b/libavfilter/limiter.h
> @@ -0,0 +1,33 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVFILTER_LIMITER_H
> +#define AVFILTER_LIMITER_H
> +
> +#include 
> +#include 
> +
> +typedef struct LimiterDSPContext {
> +void (*limiter)(const uint8_t *src, uint8_t *dst,
> +ptrdiff_t slinesize, ptrdiff_t dlinesize,
> +int w, int h, int min, int max);
> +} LimiterDSPContext;
> +
> +void ff_limiter_init_x86(LimiterDSPContext *dsp, int bpp);
> +
> +#endif /* AVFILTER_LIMITER_H */
> diff --git a/libavfilter/vf_limiter.c b/libavfilter/vf_limiter.c
> new file mode 100644
> index 000..d6f5745
> --- /dev/null
> +++ b/libavfilter/vf_limiter.c
> @@ -0,0 +1,228 @@
> +/*
> + * 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
> + * MERCHANTABI

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add missing newline on warning

2017-07-03 Thread Matthieu Bouron 
On Mon, Jul 03, 2017 at 11:07:36AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mediacodecdec_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index 1263188d34..f88b2cde54 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -478,7 +478,7 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  
>  profile = ff_AMediaCodecProfile_getProfileFromAVCodecContext(avctx);
>  if (profile < 0) {
> -av_log(avctx, AV_LOG_WARNING, "Unsupported or unknown profile");
> +av_log(avctx, AV_LOG_WARNING, "Unsupported or unknown profile\n");
>  }
>  
>  s->codec_name = ff_AMediaCodecList_getCodecNameByType(mime, profile, 0, 
> avctx);
> -- 
> 2.11.0 (Apple Git-81)

Applied. Thanks.

[...]

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: rescale pts before decoding for both hw and sw buffers

2017-07-03 Thread Matthieu Bouron 
On Mon, Jul 03, 2017 at 09:21:50AM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Replicates the logic used in the wrap_hw_buffer path to wrap_sw_buffer
> as well.
> 
> This fixes decoding issues observed on AMLogic devices with
> OMX.amlogic.mpeg2.decoder.awesome, where the decoder would spit out a
> constant stream of "mPtsRecoveryCount" errors and decoded frames were
> returned in the incorrect order.
> ---
>  libavcodec/mediacodecdec_common.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index 1263188d34..316cdba9c1 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -282,10 +282,16 @@ static int mediacodec_wrap_sw_buffer(AVCodecContext 
> *avctx,
>   * on the last avpacket received which is not in sync with the frame:
>   *   * N avpackets can be pushed before 1 frame is actually returned
>   *   * 0-sized avpackets are pushed to flush remaining frames at EOS */
> -frame->pts = info->presentationTimeUs;
> +if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
> +frame->pts = av_rescale_q(info->presentationTimeUs,
> +  av_make_q(1, 100),
> +  avctx->pkt_timebase);
> +} else {
> +frame->pts = info->presentationTimeUs;
> +}
>  #if FF_API_PKT_PTS
>  FF_DISABLE_DEPRECATION_WARNINGS
> -frame->pkt_pts = info->presentationTimeUs;
> +frame->pkt_pts = frame->pts;
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  frame->pkt_dts = AV_NOPTS_VALUE;
> @@ -613,7 +619,7 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  memcpy(data, pkt->data + offset, size);
>  offset += size;
>  
> -if (s->surface && avctx->pkt_timebase.num && 
> avctx->pkt_timebase.den) {
> +if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
>  pts = av_rescale_q(pts, avctx->pkt_timebase, av_make_q(1, 
> 100));
>  }
>  
> -- 
> 2.11.0 (Apple Git-81)

Applied. Thanks.

[...]

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

Re: [FFmpeg-devel] [PATCH] decode.c: Handle 0-size packets in compat_decode

2017-07-03 Thread Reimar Döffinger 
On 03.07.2017, at 21:07, wm4  wrote:

> On Mon,  3 Jul 2017 20:57:21 +0200
> Reimar Döffinger  wrote:
> 
>> The old API did that just fine, and if we provide
>> a compatibility layer it should at least be compatible.
>> For the test-case (feeding AVParser output directly to
>> decoder, failing to discard 0-size packets) just discarding
>> 0-size packets at the start works, but not sure if in some
>> cases we might want to pass them on to e.g. allow retrieving
>> additional pending frames.
>> ---
>> libavcodec/decode.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index 052f93d82f..c63090f137 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -842,6 +842,7 @@ static int compat_decode(AVCodecContext *avctx, AVFrame 
>> *frame,
>> avci->compat_decode = 1;
>> 
>> if (avci->compat_decode_partial_size > 0 &&
>> +pkt->size &&
>> avci->compat_decode_partial_size != pkt->size) {
>> av_log(avctx, AV_LOG_ERROR,
>>"Got unexpected packet size after a partial decode\n");
>> @@ -902,7 +903,10 @@ finish:
>> ret = FFMIN(avci->compat_decode_consumed, pkt->size);
>> }
>> avci->compat_decode_consumed = 0;
>> -avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
>> +// for compatibility with old API behaviour handle
>> +// 0-size specially
>> +if (pkt->size)
>> +avci->compat_decode_partial_size = (ret >= 0) ? pkt->size - ret : 0;
>> 
>> return ret;
>> }
> 
> I thought it was decided that 0-sized packets are always disallowed for
> encoding?

This function is for decoding, I have not checked encoding side...

> Also, 0-sized packets are drain packets even with the old
> API, and thus could never properly work. You just relied in implicit
> restart behavior (i.e. leaving the drained state by feeding a new
> non-0-sized packet), which also didn't work with all decoders.

I don't know, and I don't really care, I just noticed that we have a huge 
compatibility wrapper function that isn't even compatible, which is a bit 
ridiculous.
So I proposed to make it at least more compatible.
I don't mind changing it to be simpler and just discard them right at the 
start, if you think that makes more sense. Though even if there's just one 
decoder where 0-sized packets had some working practical use it might be better 
to pass them through...
Note that I don't disagree that this was probably a bug that 0-sized packets 
got in (though I didn't re-check the parser API), just saying I do not see much 
reason to not be backwards-compatible.
I know for sure that the ac3 and mp3 audio codecs at least had no issues with 
0-size packets before.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] movenc: simplify codec_tag lookup

2017-07-03 Thread Reimar Döffinger 
On 03.07.2017, at 17:17, Derek Buitenhuis  wrote:

> On 7/3/2017 2:18 AM, Michael Niedermayer wrote:
>> breaks fate
> 
> I'll look into it tonight; busy today.
> 
> .
> .
> .
> 
> Aside:
> 
> I'll just add, though, that these two word 'breaks fate' emails
> are kind of obnoxious when the test in question was added days
> after I sent the set, so I couldn't have possibly tested against
> it, and the commit that added the test and this email has /zero/
> info about what the test actually tests (a bug id is not a commit
> message).

Sure, it would be nice if they had nice names etc., but it's a regression test, 
it caught a real issue, and it certainly costs on average less time to debug 
even these opaque test than debugging and fixing after a user finds it...
Or maybe I've just been working for too long with randomly generated tests that 
you simply have to accept and debug as not making any sense...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

2017-07-03 Thread Reimar Döffinger 

> +static int64_t find_size(AVIOContext * pb, FITSContext * fits)
> +{
> +int bitpix, naxis, dim_no, i, naxisn[999], groups=0;
> +int64_t header_size = 0, data_size=0, ret, pcount=0, gcount=1, d;
> +char buf[81], c;

This is more than 4kB of data on the stack.
Large stack arrays have a huge amount of security implications, please put such 
buffers (if really needed) into the context.

> +memset(buf, 0, 81);
> +if ((ret = avio_read(pb, buf, 80)) != 80)
> +return AVERROR_EOF;

Seems a bit overkill to memset all if only one is not being read.
Though mostly I wanted to comment that I still think it's really bad style to 
put the assignment into the if, it makes it quite a bit harder to read and 
we've had a few bugs because of it just to avoid one line of code...

> +if (!strncmp(buf, "SIMPLE", 6) || !strncmp(buf, "XTENSION= 'IMAGE", 16)) 
> {
> +fits->image = 1;
> +} else {
> +fits->image = 0;
> +}

Could be simplified to fits->image = !strncmp...

> +header_size = ceil(header_size/2880.0)*2880;

Please avoid floating point. It rarely ends well to use it, especially since 
its range is smaller than the range of the int64 type you operate on.
It's the same as doing ((header_size + 2879)/2880)*2880, though there might be 
nicer-looking ways.

> +if (header_size < 0)
> +return AVERROR_INVALIDDATA;

As you said, this can only happen in case of overflow.
But if it overflowed (though I would claim this is not really possible), you 
already invoked undefined behaviour. Checking after undefined behaviour 
happened is like putting a bandage on the broken hand of a beheaded person...
Not to mention that it doesn't even catch the loss of precision in the 
floating-point operation above.

> +data_size *= naxisn[i];
> +if (data_size < 0)
> +return AVERROR_INVALIDDATA;

If this is supposed to be overlow check as well: same issue as before: you need 
to PREVENT the overflow, afterwards it's too late, at least for signed types.
Also the golden rule of input sanitization: sanitize/range check FIRST, THEN do 
the arithmetic.
NEVER do it the other way run without at least spending 30 minutes per 
operation making sure it's really still safe.

> 
> +fits->image = 0;
> +pos = avio_tell(s->pb);
> +while (!fits->image) {
> +if ((ret = avio_seek(s->pb, pos+size, SEEK_SET)) < 0)
> +return ret;
> +
> +if (avio_feof(s->pb))
> +return AVERROR_EOF;
> +
> +pos = avio_tell(s->pb);
> +if ((size = find_size(s->pb, fits)) < 0)
> +return size;
> +}
> +
> +if ((ret = avio_seek(s->pb, pos, SEEK_SET)) < 0)
> +return ret;

Does this seek ever do anything?
Either way, I do not like all this seeking, especially not when they all use 
SEEK_SET, it makes it rather hard to see if this all works when the input is 
being streamed or not...

> +ret = av_get_packet(s->pb, pkt, size);
> +if (ret != size) {
> +if (ret > 0) av_packet_unref(pkt);
> +return AVERROR(EIO);
> +}

I don't know what the current rules are, but back when I was more active the 
rule was to always extract as much data as possible.
So if you only get a partial packet, return that, and maybe the application can 
still do at least something with it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

2017-07-03 Thread Nicolas George 
Hi. Nice to see you back.

Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
> This is more than 4kB of data on the stack.
> Large stack arrays have a huge amount of security implications, please
> put such buffers (if really needed) into the context.

4 ko is not large, and neither is what is used here. We have a lot stack
allocations of that size and more and a few significantly larger.

And data that do not survive the function call do not belong in the
context.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

2017-07-03 Thread Steven Liu 
2017-06-13 19:02 GMT+08:00 wm4 :
> On Tue, 13 Jun 2017 11:17:35 +0100
> Mark Thompson  wrote:
>
>> > +vp8_rkmpp_hwaccel_deps="rkmpp"
>> >  vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
>> >  vp9_d3d11va_hwaccel_select="vp9_decoder"
>> >  vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
>>
>> Why do these hwaccels exist?  They don't appear to do anything, since you 
>> only have hardware surface output anyway.
>
> Well I guess you might have a point - as long as get_format isn't
> actually involved, they're technically not needed. And we've apparently
> always had hw decoders which can output both sw and hw surfaces, so
> this never came up (probably).
>
>
> I still think there's no harm in adding them.
>
>> > ...
>> > diff --git a/libavcodec/drmprime.h b/libavcodec/drmprime.h
>> > new file mode 100644
>> > index 000..44816db
>> > --- /dev/null
>> > +++ b/libavcodec/drmprime.h
>> > @@ -0,0 +1,17 @@
>> > +#ifndef AVCODEC_DRMPRIME_H
>> > +#define AVCODEC_DRMPRIME_H
>> > +
>> > +#include 
>> > +
>> > +#define AV_DRMPRIME_NUM_PLANES  4   // maximum number of planes
>> > +
>> > +typedef struct av_drmprime {
>> > +
>> > +int strides[AV_DRMPRIME_NUM_PLANES];// stride in byte of the 
>> > according plane
>> > +int offsets[AV_DRMPRIME_NUM_PLANES];// offset from start in byte 
>> > of the according plane
>> > +int fds[AV_DRMPRIME_NUM_PLANES];// file descriptor for the 
>> > plane, (0) if unused.
>> > +uint32_t format;// FOURC_CC drm format for 
>> > the image
>> > +
>> > +} av_drmprime;
>> > +
>> > +#endif // AVCODEC_DRMPRIME_H
>>
>> I'm not sure that a structure like this should be baked into the API/ABI now 
>> as a generic thing.  Are you confident that it is sufficient to represent 
>> any picture in a DRM object which might be used in future?  (Including 
>> things like tiling modes, field splitting, other craziness that GPU makers 
>> dream up?)
>
> This includes the DRM FourCC, which should take most craziness into
> account. The RockChip decoder itself does something pretty crazy (10
> bit _packed_ _planar_ format, wtf?), and it sort of fits in.
>
> I had similar concerns, and I think I basically requested that all
> standard eglCreateImageKHR() parameters for this to be included in this
> struct (which was done).
>
> It's true though that drivers could invent additional craziness as
> additional EGL attributes, or by adding new DRM API calls.
>
> It boils down to how the DRM kernel API handles these things, which I
> don't know. (Not like kernel devs would write docs - they'd possibly be
> forced to create something consistent!)
>
> Longchair replied with the EGL mapping as use case, but you can also
> map it as DRM framebuffer, which appears to happen around here:
>
> https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmprime_drm.c#L102
>
>> Can you explain the cases you are using this in?  Are you intending to make 
>> other components with input / output in this format?
>>
>> With just this decoder in isolation, it would seem preferable to me to make 
>> a structure specific to the API for now (or use the existing one - is 
>> MppFrame sufficient?).  If later there are multiple implementations and need 
>> for a common structure like this then it will be clearer what the 
>> requirements are.  Compare VAAPI and QSV (possibly also CUDA, CUVID, VDPAU?) 
>> - they can expose DRM objects, but don't currently in the ffmpeg API because 
>> any consumers which want them in that form generally prefer the wrapping 
>> object including the relevant metadata anyway.
>
> So output those as MppFrames, and then map them as DRM frames? We'd
> have the same issues. Also, the API would be harder to use. The
> assumption is that native MppFrames are pretty useless anyway, other
> than for using them with the MPP decode API.
>
>> Also, zero is a valid file descriptor.
>
> Technically yes, not sure if we care about that case.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Hello? What about this support? This is a very interesting function :D
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: copy codec_tag when stream copy

2017-07-03 Thread Steven Liu 
when use fmp4 segment type in hls and use codec copy,
there have an error message.
error message:
   [mp4 @ 0x25df020] Tag avc1 incompatible with output codec id '28' 
([33][0][0][0])
   [hls @ 0x2615c80] Some of the provided format options in '(null)' are not 
recognized
   Could not write header for output file #0 (incorrect codec parameters ?): 
Invalid argument
this patch can fix it.

Signed-off-by: Liu Qi 
---
 libavformat/hlsenc.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a49b594..4c94ffd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -566,6 +566,14 @@ static int hls_mux_init(AVFormatContext *s)
 if (!(st = avformat_new_stream(loc, NULL)))
 return AVERROR(ENOMEM);
 avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
+if (!oc->oformat->codec_tag ||
+av_codec_get_id (oc->oformat->codec_tag, 
s->streams[i]->codecpar->codec_tag) == st->codecpar->codec_id ||
+av_codec_get_tag(oc->oformat->codec_tag, 
s->streams[i]->codecpar->codec_id) <= 0) {
+st->codecpar->codec_tag = s->streams[i]->codecpar->codec_tag;
+} else {
+st->codecpar->codec_tag = 0;
+}
+
 st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
 st->time_base = s->streams[i]->time_base;
 av_dict_copy(&st->metadata, s->streams[i]->metadata, 0);
-- 
1.7.1



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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

2017-07-03 Thread Reimar Döffinger 
On 04.07.2017, at 00:51, Nicolas George  wrote:

> Hi. Nice to see you back.
> 
> Le sextidi 16 messidor, an CCXXV, Reimar Döffinger a écrit :
>> This is more than 4kB of data on the stack.
>> Large stack arrays have a huge amount of security implications, please
>> put such buffers (if really needed) into the context.
> 
> 4 ko is not large, and neither is what is used here. We have a lot stack
> allocations of that size and more and a few significantly larger.

Ok, I won't try to change policy, but the guard pages (if even implemented) are 
4kB and thus anything not significantly smaller increases security risks.
As does any type of array that presents an overflow risk.
Those may rather be kernel issues admittedly, but considering all OS kernels 
seem to have the same issues they should probably not be entirely ignored by 
application.

> And data that do not survive the function call do not belong in the
> context.

From a security standpoint, I believe any array and anything that is more than 
a handful bytes ideally should not be on the stack, if the added complexity is 
minimal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: require pkg-config for libvorbis

2017-07-03 Thread Reimar Döffinger 
On 30.06.2017, at 20:06, Ricardo Constantino  wrote:

> libvorbis comes with pkg-config files since at least v1.0.1, way back
> in 2003.
> 
> The extra check is needed for shared builds, as the pkg-config file
> for vorbisenc doesn't include vorbis and ogg if --static isn't used.

If you still manually add -lvorbis that IMHO defeats the purpose of using 
pkg-config the first place.
I don't know if our actual code using vorbisenc depend on libvorbis and libogg, 
but if it does then the flags for all 3 would have to be requested via 
pkg-config.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel