[FFmpeg-devel] [PATCH] lavfi/vf_overlay: support NV12 and NV21

[Rodger Combs]

---
 libavfilter/vf_overlay.c| 22 +-
 tests/fate/filter-video.mak | 10 ++
 tests/filtergraphs/overlay_nv12 |  5 +
 tests/filtergraphs/overlay_nv21 |  5 +
 4 files changed, 37 insertions(+), 5 deletions(-)
 create mode 100644 tests/filtergraphs/overlay_nv12
 create mode 100644 tests/filtergraphs/overlay_nv21

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index c592dca..b249ad7 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -125,6 +125,7 @@ typedef struct OverlayContext {
 int main_pix_step[4];   ///< steps per pixel for each plane of the 
main output
 int overlay_pix_step[4];///< steps per pixel for each plane of the 
overlay
 int hsub, vsub; ///< chroma subsampling values
+const AVPixFmtDescriptor *main_desc; ///< format descriptor for main input
 
 double var_values[VAR_VARS_NB];
 char *x_expr, *y_expr;
@@ -215,7 +216,9 @@ static int query_formats(AVFilterContext *ctx)
 
 /* overlay formats contains alpha, for avoiding conversion with alpha 
information loss */
 static const enum AVPixelFormat main_pix_fmts_yuv420[] = {
-AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVA420P, 
AV_PIX_FMT_NONE
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_NV12, AV_PIX_FMT_NV21,
+AV_PIX_FMT_NONE
 };
 static const enum AVPixelFormat overlay_pix_fmts_yuv420[] = {
 AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE
@@ -470,6 +473,7 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
  int x, int y,
  int main_has_alpha)
 {
+OverlayContext *ol = ctx->priv;
 int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
 int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
 int dst_wp = AV_CEIL_RSHIFT(dst_w, hsub);
@@ -479,14 +483,20 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
 uint8_t *s, *sp, *d, *dp, *a, *ap;
 int jmax, j, k, kmax;
 
+int dst_plane  = ol->main_desc->comp[i].plane;
+int dst_offset = ol->main_desc->comp[i].offset;
+int dst_step   = ol->main_desc->comp[i].step;
+
 j = FFMAX(-yp, 0);
 sp = src->data[i] + j * src->linesize[i];
-dp = dst->data[i] + (yp+j)* dst->linesize[i];
+dp = dst->data[dst_plane]
+  + (yp+j)* dst->linesize[dst_plane]
+  + dst_offset;
 ap = src->data[3] + (j<linesize[3];
 
 for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
 k = FFMAX(-xp, 0);
-d = dp + xp+k;
+d = dp + (xp+k) * dst_step;
 s = sp + k;
 a = ap + (k<linesize[i];
+dp += dst->linesize[dst_plane];
 sp += src->linesize[i];
 ap += (1 << vsub) * src->linesize[3];
 }
@@ -626,6 +636,8 @@ static int config_input_main(AVFilterLink *inlink)
 s->hsub = pix_desc->log2_chroma_w;
 s->vsub = pix_desc->log2_chroma_h;
 
+s->main_desc = pix_desc;
+
 s->main_is_packed_rgb =
 ff_fill_rgba_map(s->main_rgba_map, inlink->format) >= 0;
 s->main_has_alpha = ff_fmt_is_in(inlink->format, alpha_pix_fmts);
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index e2513f5..ec22d25 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -172,6 +172,16 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER 
SCALE_FILTER PAD_FILTER OVERLAY_F
 fate-filter-overlay_yuv420: tests/data/filtergraphs/overlay_yuv420
 fate-filter-overlay_yuv420: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420
 
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_nv12
+fate-filter-overlay_nv12: tests/data/filtergraphs/overlay_nv12
+fate-filter-overlay_nv12: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv12
+fate-filter-overlay_nv12: REF = 
$(SRC_PATH)/tests/ref/fate/filter-overlay_yuv420
+
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_nv21
+fate-filter-overlay_nv21: tests/data/filtergraphs/overlay_nv21
+fate-filter-overlay_nv21: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv21
+fate-filter-overlay_nv21: REF = 
$(SRC_PATH)/tests/ref/fate/filter-overlay_yuv420
+
 FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_yuv422
 fate-filter-overlay_yuv422: 

Re: [FFmpeg-devel] [PATCH] lavf/flvdec: init AVPacket::pos to FLVTAG offset

[Michael Niedermayer]

On Wed, Oct 19, 2016 at 12:14:57PM -0700, Suman Kancherla (సుమన్) wrote:
> Thanks for taking time to review my patch! I appreciate it very much!!
> 
> "Suman-" is my ID on github; Unless it is objectionable, I intend to use it
> for code submissions.

patch applied

thanks

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 01:35:34AM +0200, Andreas Cadhalpun wrote:
> On 26.10.2016 01:26, Michael Niedermayer wrote:
> > On Wed, Oct 26, 2016 at 01:16:13AM +0200, Andreas Cadhalpun wrote:
> >>  configure |7 ++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >> 742684cf379693d08075d43fdfb75ed5e2e936c6  
> >> 0001-configure-make-sure-LTO-does-not-optimize-out-the-te.patch
> >> From bb289a0b2b0948afa99227bcff188301c1143624 Mon Sep 17 00:00:00 2001
> >> From: Andreas Cadhalpun 
> >> Date: Tue, 25 Oct 2016 19:09:46 +0200
> >> Subject: [PATCH] configure: make sure LTO does not optimize out the test
> >>  functions
> >>
> >> Fixes trac ticket #5909
> >>
> >> Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  configure | 7 ++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 481f692..54faef1 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -1150,7 +1150,12 @@ check_func_headers(){
> >>  for func in $funcs; do
> >>  echo "long check_$func(void) { return (long) $func; }"
> >>  done
> >> -echo "int main(void) { return 0; }"
> >> +echo "int main(void) { int ret = 0;"
> >> +# LTO could optimize out the test functions without this
> >> +for func in $funcs; do
> >> +echo " ret |= ((intptr_t)check_$func) & 0x;"
> >> +done
> >> +echo "return ret; }"
> > 
> > breaks configure
> > 
> > i get this:
> > 
> > ERROR: LoadLibrary/dlopen not found for avisynth
> 
> I forgot to include stdint.h. Fixed patch attached.

seems working here now

Acked-by: Michael

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH v3 3/3] fate: Add MXF D10/DV25 probe tests

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 10:25:22AM +0200, Tobias Rapp wrote:
> On 21.10.2016 11:58, Tobias Rapp wrote:
> >On 20.10.2016 09:36, Tobias Rapp wrote:
> >>On 19.10.2016 23:06, Michael Niedermayer wrote:
> >>>On Wed, Oct 19, 2016 at 02:35:22PM +0200, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  tests/fate/mxf.mak| 19 ++-
>  tests/ref/fate/mxf-probe-d10  |  3 +++
>  tests/ref/fate/mxf-probe-dv25 |  4 
>  3 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/mxf-probe-d10
>  create mode 100644 tests/ref/fate/mxf-probe-dv25
> >>>
> >>>Applying: fate: Add MXF D10/DV25 probe tests
> >>>fatal: corrupt patch at line 60
> >>>didnt check deeply but some lines looks quite long, maybe something in
> >>>the mail chain didnt like that
> >>>
> >>>[...]
> >>
> >>Took the chance to change ffprobe output format from "compact" to
> >>"default". The reference files are only <80 bytes larger but it avoids
> >>the long lines and improves reading future diffs (git blame).
> >>
> >>Also added a DNXHD probe test using an existing fate sample so
> >>progressive field order is covered now, too.
> >
> >The DNXHD probe test reference file has changed after the recent commits
> >to mxfdec.c . Find updated patch attached.
> 
> Updated the patch once more after commit
> 73ead477ddd9dbfbe6f7e8d3fc90ebfd21b271b0.
> 
> When applying please remember to clean up the unused files in the
> FATE_SAMPLES server directory (rm mxf/Avid-5.{txt,xml}
> mxf/Sony-1.{txt,xml}).
> 
> Regards,
> Tobias

>  fate/mxf.mak |   23 +
>  ref/fate/mxf-probe-d10   |  108 +++
>  ref/fate/mxf-probe-dnxhd |  182 
> +++
>  ref/fate/mxf-probe-dv25  |  149 ++
>  4 files changed, 461 insertions(+), 1 deletion(-)
> 008e9d6f86323b0b731825730994b8faf6c20cdc  
> 0003-fate-Add-MXF-D10-DNXHD-DV25-probe-tests.patch
> From 0518d124a58cd9a7fd80e6cf97e614ca0d44f91d Mon Sep 17 00:00:00 2001
> From: Tobias Rapp 
> Date: Tue, 25 Oct 2016 10:06:15 +0200
> Subject: [PATCH 3/3] fate: Add MXF D10/DNXHD/DV25 probe tests

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[Andreas Cadhalpun]

On 25.10.2016 14:56, Hendrik Leppkes wrote:
> On Tue, Oct 25, 2016 at 2:39 PM, wm4  wrote:
>> On Tue, 25 Oct 2016 09:47:29 +0200
>> Hendrik Leppkes  wrote:
>>
>>> On Tue, Oct 25, 2016 at 1:50 AM, Andreas Cadhalpun
>>>  wrote:
 This should reduce the impact of a demuxer (or API user) setting bogus
 codec parameters.


>>>
>>> This seems rather noisy

I've added a macro to make it less noisy.

>>> and doesn't really solve anything, does it?

As you analyze below, it was fixing only a part of the problem.

>>> Decoders still need to validate values instead of blindly trusting
>>> them, and this just hides some problems in these decoders,

Yes, the problem hiding is bad, which is why I added av_assert2's
so that developers can easily check if the validation fails.

>>> instead of
>>> fixing them there. API users of avcodec would not fill
>>> AVCodecParameters, they would fill a codec context directly.
>>
>> You could also argue that the demuxer shouldn't return invalid
>> parameters either.
> 
> It should not, but this patch does not address this.

Indeed, the demuxers should be fixed in addition to this patch.

> There is various combinations of component usage that are possible,
> and in fact are used in the real world:
> 
> avformat -> avcodec
> other demuxer -> avcodec
> avformat -> other decoder
> 
> This patch only addresses the first case, and only if you actually use
> this function (which I for example do not, since I have an abstraction
> layer in between, so I never have AVCodecParameters and AVCodecContext
> in the same function).
> So in short, it just doesn't fix much, and you can still get invalid
> output from avformat, and potentially still undefined behavior in
> avcodec if its fed those values through other means.

For the third case, the demuxers have to be fixed. Having the asserts
in the central code makes it much easier to find these problems.

>> How about this: always convert the params to a temporary codecpar, and
>> provide a function to determine the validity of a codecpar. This way
>> the check could be done in multiple places without duplicating the code
>> needed for it.
> 
> That still sounds odd, although slightly better. At the very least it
> should be a dedicated function that checks the values in a key place,
> say you want to check params that are fed to a decoder, then call this
> check in avcodec_open, because thats something everyone has to call to
> use avcodec.

I tried to implement the suggestions of both of you, see attached patch.

Note that the added asserts are triggered by *many* of my fuzzed samples.
I'm happy to write patches for these cases, if we achieve agreement
that the central check alone is insufficient.
Another noteworthy point is that this patch makes it easy to trigger
the av_assert0 in iff_read_packet. I think that assert should be replaced
with an error return.

Best regards,
Andreas

>From f371be7a027da3958e221b4dc88ad558c1489107 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 25 Oct 2016 01:45:27 +0200
Subject: [PATCH] avcodec: validate codec parameters

This should reduce the impact of a broken demuxer (or API user) setting bogus
codec parameters.

The av_assert2 calls should ease detecting broken demuxers.

Suggested-by: wm4
Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/utils.c | 82 --
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 87de15f..9773b0b 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1243,6 +1243,7 @@ int attribute_align_arg avcodec_open2(AVCodecContext *avctx, const AVCodec *code
 int ret = 0;
 AVDictionary *tmp = NULL;
 const AVPixFmtDescriptor *pixdesc;
+AVCodecParameters *par = NULL;
 
 if (avcodec_is_open(avctx))
 return 0;
@@ -1259,8 +1260,14 @@ int attribute_align_arg avcodec_open2(AVCodecContext *avctx, const AVCodec *code
 if (!codec)
 codec = avctx->codec;
 
-if (avctx->extradata_size < 0 || avctx->extradata_size >= FF_MAX_EXTRADATA_SIZE)
-return AVERROR(EINVAL);
+par = avcodec_parameters_alloc();
+if (!par)
+return AVERROR(ENOMEM);
+/* check if the codec parameters in the context are valid */
+ret = avcodec_parameters_from_context(par, avctx);
+avcodec_parameters_free();
+if (ret < 0)
+return ret;
 
 if (options)
 av_dict_copy(, *options, 0);
@@ -4124,6 +4131,66 @@ static void codec_parameters_reset(AVCodecParameters *par)
 par->level   = FF_LEVEL_UNKNOWN;
 }
 
+#define CHECK_PARAMETER(parameter, name, check) {   \
+av_assert2(!(check));   \
+if (check) {   

Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern

[Michael Niedermayer]

On Mon, Oct 24, 2016 at 03:20:14PM -0600, Roger Pack wrote:
> On 10/16/16, Michael Niedermayer  wrote:
> > On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
> >> On 9/22/16, Roger Pack  wrote:
> >> > On 1/4/12, Yuval Adam  wrote:
> >> >> From: Yuval Adam 
> >> >>
> >> >> The image2 muxer now supports timestamps in output filenames.
> >> >> When used in an output patterm '%t' will be replaced with the frames
> >> >> timestamp in hours, minutes and seconds (hh:mm:ss).
> >> >
> >> > A somewhat updated (but not yet cleaned up) revision:
> >> >
> >> > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04
> >> >
> >> > see also https://trac.ffmpeg.org/ticket/1452
> >>
> >> OK attached is the "cleaned up" patch, ready for review/commit.
> >>
> >> how to test:
> >> (apply then) run this:
> >>
> >> ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg
> >> and compare filenames with the timestamps from video packets of
> >> ffprobe -show_packets.
> >>
> >> Probably a better way would have been to mix it into
> >> av_bprint_strftime however I wasn't sure how to use that within
> >> libavformat/utils.c av_get_frame_filename2
> >>
> >> Adam's initial patch
> >> (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525)
> >> also deprecated av_get_frame_filename
> >>
> >> but I wasn't sure if we wanted that here or not so didn't include it.
> >> Thank you for your consideration.
> >> -roger-
> >
> >>  doc/muxers.texi|   19 ---
> >>  libavformat/avformat.h |3 ++-
> >>  libavformat/hlsenc.c   |6 +++---
> >>  libavformat/img2enc.c  |7 +--
> >>  libavformat/utils.c|   36 
> >>  5 files changed, 58 insertions(+), 13 deletions(-)
> >> 06950fc8ba5a9163ffb838a2bff9933e69255b41
> >> 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch
> >> From 11deddfacc595c43a4f542fffe5e90b142e39c85 Mon Sep 17 00:00:00 2001
> >> From: rogerdpack 
> >> Date: Mon, 10 Oct 2016 14:50:20 -0600
> >> Subject: [PATCH] img2 encoder: allow %t in filename, based on patch from
> >> Yuval
> >>  Adam
> >>
> >> Signed-off-by: rogerdpack 
> >> ---
> >>  doc/muxers.texi| 19 ---
> >>  libavformat/avformat.h |  3 ++-
> >>  libavformat/hlsenc.c   |  6 +++---
> >>  libavformat/img2enc.c  |  7 +--
> >>  libavformat/utils.c| 36 
> >>  5 files changed, 58 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >> index 9ec2e31..6fff966 100644
> >> --- a/doc/muxers.texi
> >> +++ b/doc/muxers.texi
> >> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
> >> first filename of
> >>  the file list specified will contain the number 1, all the following
> >>  numbers will be sequential.
> >>
> >> +If the pattern contains "%t", the frame's timestamps will be inserted
> >> +in the filename like "00.00.00.000" for hours, minutes, seconds,
> >> +and milliseconds.
> >> +
> >> +The "%t" and "%d" patterns may be used simultaneously.
> >> +
> >>  The pattern may contain a suffix which is used to automatically
> >>  determine the format of the image files to write.
> >>
> >> @@ -635,7 +641,7 @@ The following example shows how to use
> >> @command{ffmpeg} for creating a
> >>  sequence of files @file{img-001.jpeg}, @file{img-002.jpeg}, ...,
> >>  taking one image every second from the input video:
> >>  @example
> >> -ffmpeg -i in.avi -vsync 1 -r 1 -f image2 'img-%03d.jpeg'
> >> +ffmpeg -i in.avi -vsync cfr -r 1 -f image2 'img-%03d.jpeg'
> >>  @end example
> >>
> >>  Note that with @command{ffmpeg}, if the format is not specified with the
> >> @@ -643,12 +649,12 @@ Note that with @command{ffmpeg}, if the format is
> >> not specified with the
> >>  format, the image2 muxer is automatically selected, so the previous
> >>  command can be written as:
> >>  @example
> >> -ffmpeg -i in.avi -vsync 1 -r 1 'img-%03d.jpeg'
> >> +ffmpeg -i in.avi -vsync cfr -r 1 'img-%03d.jpeg'
> >>  @end example
> >>
> >>  Note also that the pattern must not necessarily contain "%d" or
> >>  "%0@var{N}d", for example to create a single image file
> >> -@file{img.jpeg} from the input video you can employ the command:
> >> +@file{img.jpeg} from the start of the input video you can employ the
> >> command:
> >>  @example
> >>  ffmpeg -i in.avi -f image2 -frames:v 1 img.jpeg
> >>  @end example
> >> @@ -664,6 +670,13 @@ can be used:
> >>  ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
> >> "%Y-%m-%d_%H-%M-%S.jpg"
> >>  @end example
> >>
> >> +The following example uses the timestamp parameter to generate one
> >> +image file per video frame from the input, and name it including its
> >> original
> >> +timestamp.
> >> +@example
> >> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
> >> +@end example
> >> +
> >>  

Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 05:07:34PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2016-10-18 16:06:47 +0200, Michael Niedermayer encoded:
> > On Tue, Oct 18, 2016 at 01:33:27PM +0200, Stefano Sabatini wrote:
> > > On date Thursday 2016-10-13 19:46:41 +0200, Stefano Sabatini encoded:
> > > > On date Thursday 2016-09-29 21:55:11 +0200, wm4 encoded:
> > > [...]
> > > > > This seems like a rather special use case. Why does it have a demuxer,
> > > > > and can't be in your own C code using libavcodec/libavformat?
> > > > > 
> > > > 
> > > > > In addition, I think using the ffprobe "format" is an 
> > > > > overcomplication,
> > > > > and will justify adding even more stuff to the demuxer, until it's a
> > > > > similarily complex mess like the ffm demuxer/muxer.
> > > > 
> > > > I'm aware of the issue. OTOH I think the feature per-se is useful, at
> > > > least for the two mentioned use cases (debugging - especially if
> > > > coupled with a corresponding muxer), and data streams (generated by
> > > > script) injection, since it relies on a textual format easily
> > > > scriptable and editable by hand.
> > > > 
> > > > I thus leave the choice to the community. I guess this will require a
> > > > vote if we cannot find an agreement.
> > > > 
> > > > Latest patch in attachment with ffprobe demuxer disabled by default,
> > > > and extended documentation. (I'm also attaching the ff_get_line2 patch
> > > > which is used by this new patch).
> > > 
> > > Updated, depends on the ff_get_line2() patch.
> > > -- 
> > > FFmpeg = Fanciful and Fundamentalist Magnificient Ponderous Elastic Game
> > 
> > >  configure|3 
> > >  doc/demuxers.texi|   18 ++
> > >  doc/ffprobe-format.texi  |  121 ++
> > >  doc/formats.texi |1 
> > >  libavformat/Makefile |1 
> > >  libavformat/allformats.c |1 
> > >  libavformat/ffprobedec.c |  405 
> > > +++
> > >  7 files changed, 550 insertions(+)
> > > 1d8a987564e907802dfd84722e3f5aafa69919ee  
> > > 0002-lavf-add-ffprobe-demuxer.patch
> > > From bef4930a2bf280425b5952de0e2281f03897ff7c Mon Sep 17 00:00:00 2001
> > > From: Nicolas George 
> > > Date: Sat, 11 Jan 2014 19:42:41 +0100
> > > Subject: [PATCH] lavf: add ffprobe demuxer
> > > 
> > > With several modifications and documentation by Stefano Sabatini
> > > .
> > > 
> > > Signed-off-by: Nicolas George 
> > > ---
> > [...]
> > > +static int read_section_packet(AVFormatContext *avf, AVPacket *pkt)
> > > +{
> > > +FFprobeContext *ffp = avf->priv_data;
> > > +uint8_t buf[4096];
> > > +int ret;
> > > +AVPacket p;
> > > +char flags;
> > > +
> > > +av_init_packet();
> > > +p.pos = avio_tell(avf->pb);
> > > +p.stream_index = -1;
> > > +p.size = -1;
> > > +av_bprint_clear(>data);
> > > +while ((ret = read_section_line(avf, buf, sizeof(buf {
> > > +int has_time = 0;
> > > +int64_t pts, dts, duration;
> > > +char timebuf[1024];
> > > +
> > > +if (ret < 0)
> > > +return ret;
> > > +if (sscanf(buf, "stream_index=%d", _index)) {
> > > +if ((unsigned)p.stream_index >= avf->nb_streams) {
> > > +av_log(avf, AV_LOG_ERROR, "Invalid stream number %d 
> > > specified in packet number %d\n",
> > > +   p.stream_index, ffp->packet_nb);
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > > +}
> > > +
> > > +#define PARSE_TIME(name_, is_duration)  \
> > > +sscanf(buf, #name_ "=%"SCNi64, _);   \
> > 
> > > +has_time = sscanf(buf, #name_ "_time=%s", timebuf); \
> > 
> 
> > %s may be unsafe, not sure if theres a check elsewhere that prevents
> > writing over the outut buffer
> 
> Now the buffer is big enough, since it has the same size of the read
> line.
> -- 
> FFmpeg = Fanciful and Formidable Maxi Patchable Ecletic Geisha

>  configure|3 
>  doc/demuxers.texi|   18 ++
>  doc/ffprobe-format.texi  |  121 ++
>  doc/formats.texi |1 
>  libavformat/Makefile |1 
>  libavformat/allformats.c |1 
>  libavformat/ffprobedec.c |  405 
> +++
>  7 files changed, 550 insertions(+)
> 267580c51d49daf94e73a33175c63ecfed6a0bed  0002-lavf-add-ffprobe-demuxer.patch
> From 4e0aac4bc00104483859f9950af2ffb15fea6c12 Mon Sep 17 00:00:00 2001
> From: Nicolas George 
> Date: Sat, 11 Jan 2014 19:42:41 +0100
> Subject: [PATCH] lavf: add ffprobe demuxer
> 
> With several modifications and documentation by Stefano Sabatini
> .
> 
> Signed-off-by: Nicolas George 
> ---
>  configure|   3 +
>  doc/demuxers.texi|  18 +++
>  doc/ffprobe-format.texi  | 121 ++
>  doc/formats.texi |   

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[Andreas Cadhalpun]

On 25.10.2016 13:43, Michael Niedermayer wrote:
> On Tue, Oct 25, 2016 at 01:50:47AM +0200, Andreas Cadhalpun wrote:
>> This should reduce the impact of a demuxer (or API user) setting bogus
>> codec parameters.
>>
>> Suggested-by: wm4
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/utils.c | 82 
>> +-
>>  1 file changed, 81 insertions(+), 1 deletion(-)
> 
> This adds some warnings:
> 
> libavcodec/utils.c: In function ‘avcodec_parameters_to_context’:
> libavcodec/utils.c:4256:9: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> libavcodec/utils.c:4261:9: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> libavcodec/utils.c:4266:9: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> libavcodec/utils.c:4271:9: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> libavcodec/utils.c:4276:9: warning: comparison of unsigned expression < 0 is 
> always false [-Wtype-limits]
> 
> i guess thats enum (un)signednes ...

I'll just cast the enums to unsigned and check for > *_NB.

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Andreas Cadhalpun]

On 26.10.2016 01:26, Michael Niedermayer wrote:
> On Wed, Oct 26, 2016 at 01:16:13AM +0200, Andreas Cadhalpun wrote:
>>  configure |7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>> 742684cf379693d08075d43fdfb75ed5e2e936c6  
>> 0001-configure-make-sure-LTO-does-not-optimize-out-the-te.patch
>> From bb289a0b2b0948afa99227bcff188301c1143624 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Tue, 25 Oct 2016 19:09:46 +0200
>> Subject: [PATCH] configure: make sure LTO does not optimize out the test
>>  functions
>>
>> Fixes trac ticket #5909
>>
>> Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  configure | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 481f692..54faef1 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1150,7 +1150,12 @@ check_func_headers(){
>>  for func in $funcs; do
>>  echo "long check_$func(void) { return (long) $func; }"
>>  done
>> -echo "int main(void) { return 0; }"
>> +echo "int main(void) { int ret = 0;"
>> +# LTO could optimize out the test functions without this
>> +for func in $funcs; do
>> +echo " ret |= ((intptr_t)check_$func) & 0x;"
>> +done
>> +echo "return ret; }"
> 
> breaks configure
> 
> i get this:
> 
> ERROR: LoadLibrary/dlopen not found for avisynth

I forgot to include stdint.h. Fixed patch attached.

Best regards,
Andreas

>From 3f062e381b69c8e9b59f6caa700c23deaec53b45 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 25 Oct 2016 19:09:46 +0200
Subject: [PATCH] configure: make sure LTO does not optimize out the test
 functions

Fixes trac ticket #5909

Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
Signed-off-by: Andreas Cadhalpun 
---
 configure | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 481f692..5ee78eb 100755
--- a/configure
+++ b/configure
@@ -1147,10 +1147,16 @@ check_func_headers(){
 for hdr in $headers; do
 print_include $hdr
 done
+echo "#include "
 for func in $funcs; do
 echo "long check_$func(void) { return (long) $func; }"
 done
-echo "int main(void) { return 0; }"
+echo "int main(void) { int ret = 0;"
+# LTO could optimize out the test functions without this
+for func in $funcs; do
+echo " ret |= ((intptr_t)check_$func) & 0x;"
+done
+echo "return ret; }"
 } | check_ld "cc" "$@" && enable $funcs && enable_safe $headers
 }
 
-- 
2.9.3

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 05:11:23PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-27 15:30 GMT+02:00 Michael Niedermayer :
> 
> > Its long since FFmpeg 3.1, so its time to make 3.2
> 
> The configure option --enable-incompatible-libav-abi was intentionally
> broken some time ago, if it cannot get removed it should at least be
> removed from the help output.

feel free to remove it, i dont have any references at hand to explain
it in the commit message

thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 01:16:13AM +0200, Andreas Cadhalpun wrote:
> On 25.10.2016 23:34, Carl Eugen Hoyos wrote:
> > 2016-10-25 19:19 GMT+02:00 Andreas Cadhalpun 
> > :
> > 
> >> +# LTO could optimize out the test functions without this
> >> +echo "#if defined(__GNUC__) && __GNUC__ >= 4"
> >> +echo "  #define USED __attribute__((used))"
> >> +echo "#else"
> >> +echo "  #define USED"
> >> +echo "#endif"
> > 
> > Why is the ugly #if - #else - #endif necessary?
> 
> I'm under the impression that __attribute__((used)) is not available for all 
> compilers,
> see e.g. libavutil/attributes.h.
> But thinking more about it, a better way is to actually use the functions so 
> that
> LTO can't optimize them out. This avoids the ugly preprocessor checks.
> 
> > Please mention ticket #5909 if it is related.
> 
> Sure, new patch attached.
> 
> By the way, this is not a regression in 3.1.5, but a fix included in that
> release allowed them to drop their distro-specific patch, exposing the problem
> with LTO.
> 
> Best regards,
> Andreas
> 

>  configure |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 742684cf379693d08075d43fdfb75ed5e2e936c6  
> 0001-configure-make-sure-LTO-does-not-optimize-out-the-te.patch
> From bb289a0b2b0948afa99227bcff188301c1143624 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 25 Oct 2016 19:09:46 +0200
> Subject: [PATCH] configure: make sure LTO does not optimize out the test
>  functions
> 
> Fixes trac ticket #5909
> 
> Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
> Signed-off-by: Andreas Cadhalpun 
> ---
>  configure | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 481f692..54faef1 100755
> --- a/configure
> +++ b/configure
> @@ -1150,7 +1150,12 @@ check_func_headers(){
>  for func in $funcs; do
>  echo "long check_$func(void) { return (long) $func; }"
>  done
> -echo "int main(void) { return 0; }"
> +echo "int main(void) { int ret = 0;"
> +# LTO could optimize out the test functions without this
> +for func in $funcs; do
> +echo " ret |= ((intptr_t)check_$func) & 0x;"
> +done
> +echo "return ret; }"

breaks configure

i get this:

ERROR: LoadLibrary/dlopen not found for avisynth

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solve the problem.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Andreas Cadhalpun]

On 25.10.2016 23:34, Carl Eugen Hoyos wrote:
> 2016-10-25 19:19 GMT+02:00 Andreas Cadhalpun 
> :
> 
>> +# LTO could optimize out the test functions without this
>> +echo "#if defined(__GNUC__) && __GNUC__ >= 4"
>> +echo "  #define USED __attribute__((used))"
>> +echo "#else"
>> +echo "  #define USED"
>> +echo "#endif"
> 
> Why is the ugly #if - #else - #endif necessary?

I'm under the impression that __attribute__((used)) is not available for all 
compilers,
see e.g. libavutil/attributes.h.
But thinking more about it, a better way is to actually use the functions so 
that
LTO can't optimize them out. This avoids the ugly preprocessor checks.

> Please mention ticket #5909 if it is related.

Sure, new patch attached.

By the way, this is not a regression in 3.1.5, but a fix included in that
release allowed them to drop their distro-specific patch, exposing the problem
with LTO.

Best regards,
Andreas

>From bb289a0b2b0948afa99227bcff188301c1143624 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Tue, 25 Oct 2016 19:09:46 +0200
Subject: [PATCH] configure: make sure LTO does not optimize out the test
 functions

Fixes trac ticket #5909

Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
Signed-off-by: Andreas Cadhalpun 
---
 configure | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 481f692..54faef1 100755
--- a/configure
+++ b/configure
@@ -1150,7 +1150,12 @@ check_func_headers(){
 for func in $funcs; do
 echo "long check_$func(void) { return (long) $func; }"
 done
-echo "int main(void) { return 0; }"
+echo "int main(void) { int ret = 0;"
+# LTO could optimize out the test functions without this
+for func in $funcs; do
+echo " ret |= ((intptr_t)check_$func) & 0x;"
+done
+echo "return ret; }"
 } | check_ld "cc" "$@" && enable $funcs && enable_safe $headers
 }
 
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] removing comma at final enumeration items to fix pedantic warnings

[Michael Behrisch]

Hi all,

Am 21.10.2016 um 10:32 schrieb Michael Behrisch:
> Am 20.10.2016 um 10:00 schrieb Clément Bœsch:
>> On Thu, Oct 20, 2016 at 09:55:17AM +0200, Nicolas George wrote:
>>> Le nonidi 29 vendémiaire, an CCXXV, Clement Boesch a écrit :
 it's really a trivial and harmless patch.
>>> 
>>> Which is not enough to accept it.
>>> 
>> 
>> but the patch is perfectly fine and semantically more correct (it 
>> explicits that it's wrong to add entry afterward).
>> 
>>> I am sure there are better uses of contributors' time than that.
>>> 
>> 
>> people are free to do whatever they feel like; you're just wasting
>> yours by bikeshedding about this stuff you could just ignore.
>> 
> 
> So here is the patch again, this time without the line breaks,
> hopefully.

does the lack of further reaction mean that the patch was rejected or
does the discussion continue elsewhere?

Best regards,
Michael




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

Re: [FFmpeg-devel] Fate : add metadata test for aphasemeter

[Michael Niedermayer]

On Mon, Oct 24, 2016 at 11:06:13PM +0200, Martin Vignali wrote:
> Hello,
> 
> In attach a patch to add 2 test for aphasemeter metadata
> 
> The sample can be found here :
> 

> https://we.tl/AP7SY8eNSe

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] avcodec/dvdsubdec: Fix off by 1 error

[Michael Niedermayer]

Fixes out of array read

Found-by: Thomas Garnier using libFuzzer
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvdsubdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index b81b481..18475ec 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -185,7 +185,7 @@ static void guess_palette(DVDSubContext* ctx,
 for(i = 0; i < 4; i++) {
 if (alpha[i] != 0) {
 if (!color_used[colormap[i]])  {
-level = level_map[nb_opaque_colors][j];
+level = level_map[nb_opaque_colors - 1][j];
 r = (((subtitle_color >> 16) & 0xff) * level) >> 8;
 g = (((subtitle_color >> 8) & 0xff) * level) >> 8;
 b = (((subtitle_color >> 0) & 0xff) * level) >> 8;
-- 
2.10.1

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

Re: [FFmpeg-devel] is it possible that avfilter graph updates its setting in realtime?

[Chao Liu]

On Mon, Oct 24, 2016 at 11:24 PM, qw  wrote:

> Hi,
>
>
> I have one question about some rare usage for avfilter graph:
>
>
> Sometimes, I want to change the setting in avfilter graph. For example,
> fps filter is used to set output frame rate, and it's expected that fps can
> be changed in accordance to real needs. Sometimes, fps is set to 25, and
> later 15 as network bandwidth is not good. Is it possible that avfilter
> graph updates its setting in realtime, such as fps in fps filter, and
> widthxheight in scale filter?
>
(You probably want to send such questions to libav-u...@ffmpeg.org instead.)
I guess you are looking for avfilter_graph_send_command.
Unfortunately, "fps" filter doesn't provide any command you can use.
"scale" does have it, see here
.


>
> Thanks!
>
>
> Regards
>
>
> Andrew
> ___
> 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] is it possible that avfilter graph updates its setting in realtime?

[Moritz Barsnick]

On Tue, Oct 25, 2016 at 14:24:34 +0800, qw wrote:
> I have one question about some rare usage for avfilter graph:

Wrong list for usage.

> Sometimes, I want to change the setting in avfilter graph. For
> example, fps filter is used to set output frame rate, and it's
> expected that fps can be changed in accordance to real needs.
> Sometimes, fps is set to 25, and later 15 as network bandwidth is not
> good. Is it possible that avfilter graph updates its setting in
> realtime, such as fps in fps filter, and widthxheight in scale
> filter?

Have a look at the zmq filter. I gave an example here:
http://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-September/033776.html

It seems it doesn't actually work for the fps filter (patch perhaps
welcome).

Good luck,
Moritz

P.S.: Syntax for two parameters: Something like
  echo 'Parsed_scale_1 width 600 height 400' | tools/zmqsend
P.P.S.: I recall some patch for actually changing the filter *graph*
  (i.e. chain(s)) during runtime, don't know where, or what
  happened.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Ronald S. Bultje]

Hi,

On Tue, Oct 25, 2016 at 5:12 PM, Moritz Barsnick  wrote:

> On Tue, Oct 25, 2016 at 14:28:38 +0200, u-9...@aetey.se wrote:
> > In a perfect world the user might be offered a build time choice:
> > either lose N% of the performance or take the consequences of not
> > following the ABI.
>
> That was exactly my thought too, assuming it doesn't pollute the code
> even more:
> --disable-fast-simd or --enable-compliant-mmx or something. "auto"
> would detect musl and/or test for the necessity to use emms_c() or
> other measures.


If you don't care about performance, issue a emms upon RET in INIT_MMX
functions (just like we do for vzeroupper in INIT_YMM functions) using
x86inc.asm. Of course, this should be disabled for x86-64 or non-musl
builds.

(That doesn't yet deal with inline asm.)

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Carl Eugen Hoyos]

2016-10-25 19:19 GMT+02:00 Andreas Cadhalpun :

> +# LTO could optimize out the test functions without this
> +echo "#if defined(__GNUC__) && __GNUC__ >= 4"
> +echo "  #define USED __attribute__((used))"
> +echo "#else"
> +echo "  #define USED"
> +echo "#endif"

Why is the ugly #if - #else - #endif necessary?

Please mention ticket #5909 if it is related.

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

Re: [FFmpeg-devel] [PATCH 01/12] adxdec: validate sample_rate

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 07:45:25PM +0200, Andreas Cadhalpun wrote:
> On 25.10.2016 12:58, Paul B Mahol wrote:
> > patch(es)have good intent, but better fix is doing/checking it in single 
> > place.
> 
> I don't agree.
> In general, validity checks should be where the values are actually read.
> This eliminates the risk that bogus values could cause problems between being 
> set
> and being checked.
> Also, having only a check in a central place is bad for debugging, because it 
> is
> not immediately clear where the bogus value came from, when the check is 
> triggered.
> (I know this from personal experience debugging all the cases triggering the
> assert in av_rescale_rnd.)
> 
> The problem with that approach is that such checks can easily be forgotten, 
> which
> is why I think a check in a central place would make sense in addition to 
> checking
> the individual cases.

some formats may also lack a sample rate like mpeg ps/ts
the fact is known insude the demuxer, generic code after it doesnt
know. Doing the only check after the parser is a bit late OTOH

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] vf_colorspace: don't spam console with warnings if range is unspecified.

[Moritz Barsnick]

On Sat, Oct 22, 2016 at 22:02:15 -0400, Ronald S. Bultje wrote:
> I was hoping for documentation on what it expects, not what can be changed
> about it :) Anyway, I'll change it, I don't really care.

I had found this to be quite clear:
> End with a comment. The checker assumes that this comment is
> acknowledging a fallthrough. The comment can start anywhere on the
> last line, or be a multi-line C comment.

So: It expects a comment (*any* comment) on the last line (which, to
me, is the exact line preceding the next case label).

Sorry for the late remark,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Moritz Barsnick]

On Tue, Oct 25, 2016 at 14:28:38 +0200, u-9...@aetey.se wrote:
> In a perfect world the user might be offered a build time choice:
> either lose N% of the performance or take the consequences of not
> following the ABI.

That was exactly my thought too, assuming it doesn't pollute the code
even more:
--disable-fast-simd or --enable-compliant-mmx or something. "auto"
would detect musl and/or test for the necessity to use emms_c() or
other measures.

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

Re: [FFmpeg-devel] [PATCH] scale_npp: fix passthrough mode

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 11:39:01AM +0200, Timo Rothenpieler wrote:
> LGTM

applied

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] libavcodec/tests: Added test for libavcodec/avpacket.c

[Michael Niedermayer]

On Sat, Oct 22, 2016 at 11:40:42PM -0700, Thomas Turner wrote:
> Function(s) Tested: av_packet_clone().
> 
> This test checks if av_packet_clone() can successfully make a copy of an 
> AVPacket.
> Compares all data members in AVPacket EXCEPT for "buf" because "buf" is 
> initialized
> to NIL in the original AVPacket [to be cloned].
> 
> This test also prints out the all the contents of the original and cloned 
> AVPackets.
> 
> Signed-off-by: Thomas Turner 
> ---
>  libavcodec/Makefile |   3 +-
>  libavcodec/tests/avpacket.c | 303 
> 
>  tests/fate/libavcodec.mak   |   5 +
>  3 files changed, 310 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/tests/avpacket.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f1d5bf1..46e3af7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1019,7 +1019,8 @@ SKIPHEADERS-$(CONFIG_VDA)  += vda.h 
> vda_vt_internal.h
>  SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
>  SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vda_vt_internal.h
>  
> -TESTPROGS = imgconvert  \
> +TESTPROGS = avpacket\
> +imgconvert  \
>  jpeg2000dwt \
>  mathops\
>  options \
> diff --git a/libavcodec/tests/avpacket.c b/libavcodec/tests/avpacket.c
> new file mode 100644
> index 000..752cf3c
> --- /dev/null
> +++ b/libavcodec/tests/avpacket.c
> @@ -0,0 +1,303 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "libavcodec/avcodec.h"
> +#include "libavutil/error.h"
> +
> +
> +
> +
> +#define AVPACKET_FIELDS \
> +X(static AVBufferRef*, buf, "%p")   \
> +X(static int64_t, pts, "%" PRId64)  \
> +X(static int64_t, dts, "%" PRId64)  \
> +X(static uint8_t*, data, "%p")  \
> +X(static int, size, "%d")   \
> +X(static int, stream_index, "%d")   \
> +X(static int, flags, "%d")  \
> +X(static AVPacketSideData*, side_data, "%p")\
> +X(static int, side_data_elems, "%d")\
> +X(static int64_t, duration, "%" PRId64) \
> +X(static int64_t, pos, "%" PRId64)
> +
> +#define AVBUFFERREF_FIELDS  \
> +Y(static AVBuffer*, buffer, "%p")   \
> +Y(static uint8_t*, data, "%p")  \
> +Y(static int, size, "%d")
> +
> +#define AVPACKETSIDEDATA_FIELDS \
> +Z(static uint8_t*, data, "%p")  \
> +Z(static int, size, "%d")   \
> +Z(static enum AVPacketSideDataType, type, "%d")
> +
> +
> +
> +

> +#define AV_MESSAGE_1(format, name, p1, p2)  \
> +do {\
> +const char* str = "cloned variable \"%s\" equals " format   \
> +" but should be " format "\n";  \
> +av_log(NULL, AV_LOG_ERROR, str, #name, p2->name, p1->name );\
> +} while (0)
> +
> +#define AV_MESSAGE_2(name, p1, p2)  \
> +do {\
> +const char* str = "contents of cloned variable "\
> +"%s equals \"%.*s\"\nbut should be \"%.*s\"\n"; \
> +av_log(NULL, AV_LOG_ERROR, str, #name, p1->size,\
> +p2->data, p1->size, p1->data);  \
> +} while(0)
> +
> +#define AV_MESSAGE_3(name)  \
> +do {   

Re: [FFmpeg-devel] [PATCH] lavfi/vf_overlay: support NV12 and NV21

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 01:52:28AM -0500, Rodger Combs wrote:
> ---
>  libavfilter/vf_overlay.c| 22 +-
>  tests/fate/filter-video.mak | 10 ++
>  tests/filtergraphs/overlay_nv12 |  5 +
>  tests/filtergraphs/overlay_nv21 |  5 +
>  4 files changed, 37 insertions(+), 5 deletions(-)
>  create mode 100644 tests/filtergraphs/overlay_nv12
>  create mode 100644 tests/filtergraphs/overlay_nv21

fails:
mkdir tmp-delthis
cd  tmp-delthis
../configure  && make -j12 fate-filter-overlay_nv12
...
TESTfilter-overlay_nv12
reference file 'tests/ref/fate/filter-overlay_yuv420' not found
ffmpeg/tests/fate-run.sh: 370: ffmpeg/tests/fate-run.sh: cannot open 
tests/data/fate/filter-overlay_nv12.diff: No such file
Test filter-overlay_nv12 failed. Look at 
tests/data/fate/filter-overlay_nv12.err for details.
make: *** [fate-filter-overlay_nv12] Error 1

using make fate -j12  from a subdir fails similarly

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

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


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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[u-9iep]

On Tue, Oct 25, 2016 at 05:48:50PM +0200, Henrik Gramner wrote:
> On Tue, Oct 25, 2016 at 2:28 PM,   wrote:
> > It would be nice to look at a benchmarking comparison, to be able to
> > see the actual practical performance gain of the decision not to follow
> > the ABI.
> 
> Just a quick comparison from adding EMMS to a random MMX function
> (from x264, because I happened to have the source for that but not
> ffmpeg on this machine and I was too lazy to download it).
> 
> sad_4x4_c: 359
> sad_4x4_mmx: 94
> sad_4x4_mmx (emms): 186

This is unfortunatly not exactly the numbers a user or a packager would
need to know. The relevant ones would be what time it takes to actually
compress or decompress a given file.

(if most of the time is spent calling this very function, then we can
extrapolate the numbers to the net result, otherwise we shouldn't)

If we nevertheless assume that the net performance is proportional
to the numbers above, we learn that omission of MMX acceleration
compatible with the standard ABI would lead to 50% performance loss
for the ABI-compliant users (pure C instead of compliant MMX).

This would be a pity, even if the circle of the users who depend
on strict ABI-compliance is limited, for the moment.

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Sven C. Dack]

On 23/10/16 13:29, Nicolas George wrote:

The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.

On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 to ~3300 at smaller size (640×480),
similar to legacy x11grab.

Plus, shared memory segments are a scarce resource,
allocating potentially many is a bad idea.

Note: if the application were to drop all references to the
buffer before the next call to av_read_frame(), then passing
the shared memory segment as a refcounted buffer would be
even more efficient, but it is hard to guarantee, and it does
not happen with the ffmpeg command-line tool. Using a small
number of preallocated buffers and resorting to a copy when
the pool is exhausted would be a solution to get the better
of both worlds.


192fps -> 315fps (+64%)

Sven

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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Clément Bœsch]

On Tue, Oct 25, 2016 at 07:58:56PM +0200, Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXV, Clement Boesch a écrit :
> > > The framework will allocate a buffer and copy the data to it,
> > > that takes time.
> 
> > Sorry if this is a dumb question but: can you describe what happens if the
> > previous packet still held the same pkt->data = c->buffer?
> > 
> > That is, when and how the buffer copy does happen?
> > 
> > (no need for a av_buffer_create with RO flag?)
> 
> Not dumb, but the answer was in the first sentence of the commit message.
> 

I was wondering where and how,

> The corresponding code is in ff_read_packet():
> 
> if (!pkt->buf) {
> AVPacket tmp = { 0 };
> ret = av_packet_ref(, pkt);
> if (ret < 0)
> return ret;
> *pkt = tmp;
> }
> 
> And av_packet_ref() creates a refcounted buffer if the given one is not
> refcounted.

I see, that makes sense. Thanks for clarifying.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXV, Clement Boesch a écrit :
> > The framework will allocate a buffer and copy the data to it,
> > that takes time.

> Sorry if this is a dumb question but: can you describe what happens if the
> previous packet still held the same pkt->data = c->buffer?
> 
> That is, when and how the buffer copy does happen?
> 
> (no need for a av_buffer_create with RO flag?)

Not dumb, but the answer was in the first sentence of the commit message.

The corresponding code is in ff_read_packet():

if (!pkt->buf) {
AVPacket tmp = { 0 };
ret = av_packet_ref(, pkt);
if (ret < 0)
return ret;
*pkt = tmp;
}

And av_packet_ref() creates a refcounted buffer if the given one is not
refcounted.

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] order T-shirts

[Steven Liu]

John Warburton 于2016年9月28日 周三下午6:22写道：

> On Sun, Sep 4, 2016 at 10:34 PM, Thomas Volkert  wrote:
>
> > Hi,
> >
> > Some guys at the VDD asked for FFmpeg T-shirts.
> > I'd like to do a new T-shirt order. The shirts could be given to
> > multimedia devs who stop at one of our next booths.
> >
> > ​I'd *buy* one. XL. Wear it at the lectures I give.​
>
> ​JW
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Clément Bœsch]

On Sun, Oct 23, 2016 at 02:29:37PM +0200, Nicolas George wrote:
> The framework will allocate a buffer and copy the data to it,
> that takes time. But it avoids constently creating and
> destroyng the shared memory segment, and that saves more time.
> 
> On my setup,
> from ~200 to ~300 FPS at full screen (1920×1200),
> from ~1400 to ~3300 at smaller size (640×480),
> similar to legacy x11grab.
> 
> Plus, shared memory segments are a scarce resource,
> allocating potentially many is a bad idea.
> 
> Note: if the application were to drop all references to the
> buffer before the next call to av_read_frame(), then passing
> the shared memory segment as a refcounted buffer would be
> even more efficient, but it is hard to guarantee, and it does
> not happen with the ffmpeg command-line tool. Using a small
> number of preallocated buffers and resorting to a copy when
> the pool is exhausted would be a solution to get the better
> of both worlds.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavdevice/xcbgrab.c | 65 
> +++
>  1 file changed, 35 insertions(+), 30 deletions(-)
> 
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index 9da46c8..702e66c 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -49,6 +49,8 @@
>  typedef struct XCBGrabContext {
>  const AVClass *class;
>  
> +uint8_t *buffer;
> +
>  xcb_connection_t *conn;
>  xcb_screen_t *screen;
>  xcb_window_t window;
> @@ -219,22 +221,16 @@ static int check_shm(xcb_connection_t *conn)
>  return 0;
>  }
>  
> -static void dealloc_shm(void *unused, uint8_t *data)
> -{
> -shmdt(data);
> -}
> -
> -static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
> +static int allocate_shm(AVFormatContext *s)
>  {
>  XCBGrabContext *c = s->priv_data;
> -xcb_shm_get_image_cookie_t iq;
> -xcb_shm_get_image_reply_t *img;
> -xcb_drawable_t drawable = c->screen->root;
> -uint8_t *data;
>  int size = c->frame_size + AV_INPUT_BUFFER_PADDING_SIZE;
> -int id   = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
> -xcb_generic_error_t *e = NULL;
> +uint8_t *data;
> +int id;
>  
> +if (c->buffer)
> +return 0;
> +id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
>  if (id == -1) {
>  char errbuf[1024];
>  int err = AVERROR(errno);
> @@ -243,15 +239,31 @@ static int xcbgrab_frame_shm(AVFormatContext *s, 
> AVPacket *pkt)
> size, errbuf);
>  return err;
>  }
> -
>  xcb_shm_attach(c->conn, c->segment, id, 0);
> +data = shmat(id, NULL, 0);
> +shmctl(id, IPC_RMID, 0);
> +if ((intptr_t)data == -1 || !data)
> +return AVERROR(errno);
> +c->buffer = data;
> +return 0;
> +}
> +
> +static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
> +{
> +XCBGrabContext *c = s->priv_data;
> +xcb_shm_get_image_cookie_t iq;
> +xcb_shm_get_image_reply_t *img;
> +xcb_drawable_t drawable = c->screen->root;
> +xcb_generic_error_t *e = NULL;
> +int ret;
> +
> +ret = allocate_shm(s);
> +if (ret < 0)
> +return ret;
>  
>  iq = xcb_shm_get_image(c->conn, drawable,
> c->x, c->y, c->width, c->height, ~0,
> XCB_IMAGE_FORMAT_Z_PIXMAP, c->segment, 0);
> -
> -xcb_shm_detach(c->conn, c->segment);
> -
>  img = xcb_shm_get_image_reply(c->conn, iq, );
>  
>  xcb_flush(c->conn);
> @@ -264,25 +276,12 @@ static int xcbgrab_frame_shm(AVFormatContext *s, 
> AVPacket *pkt)
> e->response_type, e->error_code,
> e->sequence, e->resource_id, e->minor_code, e->major_code);
>  
> -shmctl(id, IPC_RMID, 0);
>  return AVERROR(EACCES);
>  }
>  
>  free(img);
>  
> -data = shmat(id, NULL, 0);
> -shmctl(id, IPC_RMID, 0);
> -
> -if ((intptr_t)data == -1)
> -return AVERROR(errno);
> -
> -pkt->buf = av_buffer_create(data, size, dealloc_shm, NULL, 0);
> -if (!pkt->buf) {
> -shmdt(data);
> -return AVERROR(ENOMEM);
> -}
> -
> -pkt->data = pkt->buf->data;
> +pkt->data = c->buffer;
>  pkt->size = c->frame_size;

Sorry if this is a dumb question but: can you describe what happens if the
previous packet still held the same pkt->data = c->buffer?

That is, when and how the buffer copy does happen?

(no need for a av_buffer_create with RO flag?)

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/12] adxdec: validate sample_rate

[Andreas Cadhalpun]

On 25.10.2016 12:58, Paul B Mahol wrote:
> patch(es)have good intent, but better fix is doing/checking it in single 
> place.

I don't agree.
In general, validity checks should be where the values are actually read.
This eliminates the risk that bogus values could cause problems between being 
set
and being checked.
Also, having only a check in a central place is bad for debugging, because it is
not immediately clear where the bogus value came from, when the check is 
triggered.
(I know this from personal experience debugging all the cases triggering the
assert in av_rescale_rnd.)

The problem with that approach is that such checks can easily be forgotten, 
which
is why I think a check in a central place would make sense in addition to 
checking
the individual cases.

Best regards,
Andreas


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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Clément Bœsch]

On Sun, Oct 23, 2016 at 02:29:37PM +0200, Nicolas George wrote:
> The framework will allocate a buffer and copy the data to it,
> that takes time. But it avoids constently creating and
> destroyng the shared memory segment, and that saves more time.
> 
> On my setup,
> from ~200 to ~300 FPS at full screen (1920×1200),

./ffmpeg -framerate 1 -f x11grab -video_size hd1080 -i :0.0 -t 20 -f null -

before: fps=324
after:  fps=627

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Michael Niedermayer]

On Sun, Oct 23, 2016 at 02:29:37PM +0200, Nicolas George wrote:
> The framework will allocate a buffer and copy the data to it,
> that takes time. But it avoids constently creating and
> destroyng the shared memory segment, and that saves more time.
> 
> On my setup,
> from ~200 to ~300 FPS at full screen (1920×1200),
> from ~1400 to ~3300 at smaller size (640×480),
> similar to legacy x11grab.
> 
> Plus, shared memory segments are a scarce resource,
> allocating potentially many is a bad idea.
> 
> Note: if the application were to drop all references to the
> buffer before the next call to av_read_frame(), then passing
> the shared memory segment as a refcounted buffer would be
> even more efficient, but it is hard to guarantee, and it does
> not happen with the ffmpeg command-line tool. Using a small
> number of preallocated buffers and resorting to a copy when
> the pool is exhausted would be a solution to get the better
> of both worlds.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavdevice/xcbgrab.c | 65 
> +++
>  1 file changed, 35 insertions(+), 30 deletions(-)

Tested-by: Michael
126fps -> 141 here

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

[FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Andreas Cadhalpun]

Bud-Id: https://bugs.gentoo.org/show_bug.cgi?id=598054
Signed-off-by: Andreas Cadhalpun 
---
 configure | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 481f692..14a20ed 100755
--- a/configure
+++ b/configure
@@ -1147,8 +1147,14 @@ check_func_headers(){
 for hdr in $headers; do
 print_include $hdr
 done
+# LTO could optimize out the test functions without this
+echo "#if defined(__GNUC__) && __GNUC__ >= 4"
+echo "  #define USED __attribute__((used))"
+echo "#else"
+echo "  #define USED"
+echo "#endif"
 for func in $funcs; do
-echo "long check_$func(void) { return (long) $func; }"
+echo "USED long check_$func(void) { return (long) $func; }"
 done
 echo "int main(void) { return 0; }"
 } | check_ld "cc" "$@" && enable $funcs && enable_safe $headers
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Henrik Gramner]

On Tue, Oct 25, 2016 at 2:28 PM,   wrote:
> It would be nice to look at a benchmarking comparison, to be able to
> see the actual practical performance gain of the decision not to follow
> the ABI.

Just a quick comparison from adding EMMS to a random MMX function
(from x264, because I happened to have the source for that but not
ffmpeg on this machine and I was too lazy to download it).

sad_4x4_c: 359
sad_4x4_mmx: 94
sad_4x4_mmx (emms): 186
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/matroskaenc: fix cue relative position values when CRC32 is enabled

[James Almer]

The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
don't take it into account. This resulted in CueRelativePosition values being
six bytes short.
This is a regression since 6724525a1576ca334d2ffdc085620bb44aea7394

Instead of adding yet another custom check for CRC32 to fix a size or an offset,
remove the existing ones and reserve the six bytes in the dynamic buffer.

Signed-off-by: James Almer 
---
 libavformat/matroskaenc.c | 39 +--
 tests/ref/fate/rgb24-mkv  |  2 +-
 tests/ref/lavf/mkv|  4 ++--
 3 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 03d5326..d91055f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -322,17 +322,19 @@ static void end_ebml_master(AVIOContext *pb, ebml_master 
master)
 avio_seek(pb, pos, SEEK_SET);
 }
 
-static int start_ebml_master_crc32(AVIOContext *pb, AVIOContext **dyn_cp, 
ebml_master *master,
-   unsigned int elementid, uint64_t 
expectedsize)
+static int start_ebml_master_crc32(AVIOContext *pb, AVIOContext **dyn_cp, 
MatroskaMuxContext *mkv,
+   ebml_master *master, unsigned int 
elementid, uint64_t expectedsize)
 {
 int ret;
 
 if ((ret = avio_open_dyn_buf(dyn_cp)) < 0)
 return ret;
 
-if (pb->seekable)
+if (pb->seekable) {
 *master = start_ebml_master(pb, elementid, expectedsize);
-else
+if (mkv->write_crc && mkv->mode != MODE_WEBM)
+put_ebml_void(*dyn_cp, 6); /* Reserve space for CRC32 so 
position/size calculations using avio_tell() take it into account */
+} else
 *master = start_ebml_master(*dyn_cp, elementid, expectedsize);
 
 return 0;
@@ -342,15 +344,16 @@ static void end_ebml_master_crc32(AVIOContext *pb, 
AVIOContext **dyn_cp, Matrosk
   ebml_master master)
 {
 uint8_t *buf, crc[4];
-int size;
+int size, skip = 0;
 
 if (pb->seekable) {
 size = avio_close_dyn_buf(*dyn_cp, );
 if (mkv->write_crc && mkv->mode != MODE_WEBM) {
-AV_WL32(crc, av_crc(av_crc_get_table(AV_CRC_32_IEEE_LE), 
UINT32_MAX, buf, size) ^ UINT32_MAX);
+skip = 6; /* Skip reserved 6-byte long void element from the 
dynamic buffer. */
+AV_WL32(crc, av_crc(av_crc_get_table(AV_CRC_32_IEEE_LE), 
UINT32_MAX, buf + skip, size - skip) ^ UINT32_MAX);
 put_ebml_binary(pb, EBML_ID_CRC32, crc, sizeof(crc));
 }
-avio_write(pb, buf, size);
+avio_write(pb, buf + skip, size - skip);
 end_ebml_master(pb, master);
 } else {
 end_ebml_master(*dyn_cp, master);
@@ -465,7 +468,7 @@ static int64_t mkv_write_seekhead(AVIOContext *pb, 
MatroskaMuxContext *mkv)
 }
 }
 
-if (start_ebml_master_crc32(pb, _cp, , MATROSKA_ID_SEEKHEAD,
+if (start_ebml_master_crc32(pb, _cp, mkv, , 
MATROSKA_ID_SEEKHEAD,
 seekhead->reserved_size) < 0) {
 currentpos = -1;
 goto fail;
@@ -541,7 +544,7 @@ static int64_t mkv_write_cues(AVFormatContext *s, mkv_cues 
*cues, mkv_track *tra
 int i, j, ret;
 
 currentpos = avio_tell(pb);
-ret = start_ebml_master_crc32(pb, _cp, _element, 
MATROSKA_ID_CUES, 0);
+ret = start_ebml_master_crc32(pb, _cp, mkv, _element, 
MATROSKA_ID_CUES, 0);
 if (ret < 0)
 return ret;
 
@@ -1269,7 +1272,7 @@ static int mkv_write_tracks(AVFormatContext *s)
 if (ret < 0)
 return ret;
 
-ret = start_ebml_master_crc32(pb, _cp, , MATROSKA_ID_TRACKS, 0);
+ret = start_ebml_master_crc32(pb, _cp, mkv, , 
MATROSKA_ID_TRACKS, 0);
 if (ret < 0)
 return ret;
 
@@ -1300,7 +1303,7 @@ static int mkv_write_chapters(AVFormatContext *s)
 ret = mkv_add_seekhead_entry(mkv->main_seekhead, MATROSKA_ID_CHAPTERS, 
avio_tell(pb));
 if (ret < 0) return ret;
 
-ret = start_ebml_master_crc32(pb, _cp, , 
MATROSKA_ID_CHAPTERS, 0);
+ret = start_ebml_master_crc32(pb, _cp, mkv, , 
MATROSKA_ID_CHAPTERS, 0);
 if (ret < 0) return ret;
 
 editionentry = start_ebml_master(dyn_cp, MATROSKA_ID_EDITIONENTRY, 0);
@@ -1387,7 +1390,7 @@ static int mkv_write_tag_targets(AVFormatContext *s,
 ret = mkv_add_seekhead_entry(mkv->main_seekhead, MATROSKA_ID_TAGS, 
avio_tell(s->pb));
 if (ret < 0) return ret;
 
-start_ebml_master_crc32(s->pb, >tags_bc, tags, MATROSKA_ID_TAGS, 
0);
+start_ebml_master_crc32(s->pb, >tags_bc, mkv, tags, 
MATROSKA_ID_TAGS, 0);
 }
 pb = mkv->tags_bc;
 
@@ -1524,7 +1527,7 @@ static int mkv_write_tags(AVFormatContext *s)
 
 if (mkv->tags.pos) {
 if (s->pb->seekable && !mkv->is_live)
-put_ebml_void(s->pb, avio_tell(mkv->tags_bc) + ((mkv->write_crc && 
mkv->mode != MODE_WEBM) ? 2 /* ebml id + data size */ + 4 /* CRC32 */ : 0));
+put_ebml_void(s->pb, 

Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Stefano Sabatini]

On date Tuesday 2016-10-18 16:06:47 +0200, Michael Niedermayer encoded:
> On Tue, Oct 18, 2016 at 01:33:27PM +0200, Stefano Sabatini wrote:
> > On date Thursday 2016-10-13 19:46:41 +0200, Stefano Sabatini encoded:
> > > On date Thursday 2016-09-29 21:55:11 +0200, wm4 encoded:
> > [...]
> > > > This seems like a rather special use case. Why does it have a demuxer,
> > > > and can't be in your own C code using libavcodec/libavformat?
> > > > 
> > > 
> > > > In addition, I think using the ffprobe "format" is an overcomplication,
> > > > and will justify adding even more stuff to the demuxer, until it's a
> > > > similarily complex mess like the ffm demuxer/muxer.
> > > 
> > > I'm aware of the issue. OTOH I think the feature per-se is useful, at
> > > least for the two mentioned use cases (debugging - especially if
> > > coupled with a corresponding muxer), and data streams (generated by
> > > script) injection, since it relies on a textual format easily
> > > scriptable and editable by hand.
> > > 
> > > I thus leave the choice to the community. I guess this will require a
> > > vote if we cannot find an agreement.
> > > 
> > > Latest patch in attachment with ffprobe demuxer disabled by default,
> > > and extended documentation. (I'm also attaching the ff_get_line2 patch
> > > which is used by this new patch).
> > 
> > Updated, depends on the ff_get_line2() patch.
> > -- 
> > FFmpeg = Fanciful and Fundamentalist Magnificient Ponderous Elastic Game
> 
> >  configure|3 
> >  doc/demuxers.texi|   18 ++
> >  doc/ffprobe-format.texi  |  121 ++
> >  doc/formats.texi |1 
> >  libavformat/Makefile |1 
> >  libavformat/allformats.c |1 
> >  libavformat/ffprobedec.c |  405 
> > +++
> >  7 files changed, 550 insertions(+)
> > 1d8a987564e907802dfd84722e3f5aafa69919ee  
> > 0002-lavf-add-ffprobe-demuxer.patch
> > From bef4930a2bf280425b5952de0e2281f03897ff7c Mon Sep 17 00:00:00 2001
> > From: Nicolas George 
> > Date: Sat, 11 Jan 2014 19:42:41 +0100
> > Subject: [PATCH] lavf: add ffprobe demuxer
> > 
> > With several modifications and documentation by Stefano Sabatini
> > .
> > 
> > Signed-off-by: Nicolas George 
> > ---
> [...]
> > +static int read_section_packet(AVFormatContext *avf, AVPacket *pkt)
> > +{
> > +FFprobeContext *ffp = avf->priv_data;
> > +uint8_t buf[4096];
> > +int ret;
> > +AVPacket p;
> > +char flags;
> > +
> > +av_init_packet();
> > +p.pos = avio_tell(avf->pb);
> > +p.stream_index = -1;
> > +p.size = -1;
> > +av_bprint_clear(>data);
> > +while ((ret = read_section_line(avf, buf, sizeof(buf {
> > +int has_time = 0;
> > +int64_t pts, dts, duration;
> > +char timebuf[1024];
> > +
> > +if (ret < 0)
> > +return ret;
> > +if (sscanf(buf, "stream_index=%d", _index)) {
> > +if ((unsigned)p.stream_index >= avf->nb_streams) {
> > +av_log(avf, AV_LOG_ERROR, "Invalid stream number %d 
> > specified in packet number %d\n",
> > +   p.stream_index, ffp->packet_nb);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +}
> > +
> > +#define PARSE_TIME(name_, is_duration)  \
> > +sscanf(buf, #name_ "=%"SCNi64, _);   \
> 
> > +has_time = sscanf(buf, #name_ "_time=%s", timebuf); \
> 

> %s may be unsafe, not sure if theres a check elsewhere that prevents
> writing over the outut buffer

Now the buffer is big enough, since it has the same size of the read
line.
-- 
FFmpeg = Fanciful and Formidable Maxi Patchable Ecletic Geisha
>From 4e0aac4bc00104483859f9950af2ffb15fea6c12 Mon Sep 17 00:00:00 2001
From: Nicolas George 
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer

With several modifications and documentation by Stefano Sabatini
.

Signed-off-by: Nicolas George 
---
 configure|   3 +
 doc/demuxers.texi|  18 +++
 doc/ffprobe-format.texi  | 121 ++
 doc/formats.texi |   1 +
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/ffprobedec.c | 405 +++
 7 files changed, 550 insertions(+)
 create mode 100644 doc/ffprobe-format.texi
 create mode 100644 libavformat/ffprobedec.c

diff --git a/configure b/configure
index 1e6834f..7974c12 100755
--- a/configure
+++ b/configure
@@ -3346,6 +3346,9 @@ for n in $COMPONENT_LIST; do
 eval ${n}_if_any="\$$v"
 done
 
+# Disable ffprobe demuxer for security concerns
+disable ffprobe_demuxer
+
 enable $ARCH_EXT_LIST
 
 die_unknown(){
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2934a1c..0e6dfbd 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -243,6 +243,24 @@ 

Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Stefano Sabatini]

On date Wednesday 2016-10-19 17:37:36 +0200, Moritz Barsnick encoded:
> On Tue, Oct 18, 2016 at 13:33:27 +0200, Stefano Sabatini wrote:
> > > Latest patch in attachment with ffprobe demuxer disabled by default,
> > > and extended documentation. (I'm also attaching the ff_get_line2 patch
> > > which is used by this new patch).
> > Updated, depends on the ff_get_line2() patch.
> [...]
> > +The ffprobe demuxer format is inspired by the output generated by the
> > +ffprobe default format.
> 

> Unfortunately, you dropped the ffprobe command line which can be used
> to create exactly that format. I found that quite practical.
> (Presumably a mix of ffprobe "-show_format", "-show_streams",
> "-show_packets -show_data"?) But I think it was incorrect anyway in the
> previous patches. ;-)

The fact is that without the -show_headers_first option it is not
possible to generate that output anymore (and you need to edit the
output generated by ffprobe anyway). I'm going to add a muxer for
that.

> > +A ffprobe demuxer file might look like this:
> ^ nit: An

Fixed, thanks.
-- 
FFmpeg = Fascinating and Friendly Majestic Political Enhanced Governor
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/flvdec: init AVPacket::pos to FLVTAG offset

[సుమన్]

Gentle ping!

On Wed, Oct 19, 2016 at 12:14 PM, Suman Kancherla (సుమన్) <
sumankanche...@google.com> wrote:

> Thanks for taking time to review my patch! I appreciate it very much!!
>
> "Suman-" is my ID on github; Unless it is objectionable, I intend to use
> it for code submissions.
>
> Thanks!
> Suman
>
>
> On Wed, Oct 19, 2016 at 12:03 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Tue, Oct 18, 2016 at 03:13:23PM -0700, Suman- wrote:
>> > Current code doesn't initialize AVPacket::pos. Made it point to FLVTAG
>> so flv_read_packet can decode from pos
>> > ---
>> >  libavformat/flvdec.c|  1 +
>> >  tests/ref/seek/acodec-adpcm-swf | 46
>> -
>> >  tests/ref/seek/acodec-adpcm-swf-trellis | 46
>> -
>> >  tests/ref/seek/lavf-flv_fmt | 36 +-
>> >  tests/ref/seek/vsynth_lena-flashsv  | 40
>> ++--
>> >  tests/ref/seek/vsynth_lena-flv  | 40
>> ++--
>> >  6 files changed, 105 insertions(+), 104 deletions(-)
>>
>> Is it intended that the author of this patch is set to "Suman-" ?
>>
>> If its incomplete then please resubmit the patch with correctly set
>> author
>>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Many things microsoft did are stupid, but not doing something just because
>> microsoft did it is even more stupid. If everything ms did were stupid
>> they
>> would be bankrupt already.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
>
> --
> Many thanks!
> Suman
>
>


-- 
Many thanks!
Suman
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[Hendrik Leppkes]

On Tue, Oct 25, 2016 at 2:39 PM, wm4  wrote:
> On Tue, 25 Oct 2016 09:47:29 +0200
> Hendrik Leppkes  wrote:
>
>> On Tue, Oct 25, 2016 at 1:50 AM, Andreas Cadhalpun
>>  wrote:
>> > This should reduce the impact of a demuxer (or API user) setting bogus
>> > codec parameters.
>> >
>> >
>>
>> This seems rather noisy and doesn't really solve anything, does it?
>> Decoders still need to validate values instead of blindly trusting
>> them, and this just hides some problems in these decoders, instead of
>> fixing them there. API users of avcodec would not fill
>> AVCodecParameters, they would fill a codec context directly.
>
> You could also argue that the demuxer shouldn't return invalid
> parameters either.

It should not, but this patch does not address this.

There is various combinations of component usage that are possible,
and in fact are used in the real world:

avformat -> avcodec
other demuxer -> avcodec
avformat -> other decoder

This patch only addresses the first case, and only if you actually use
this function (which I for example do not, since I have an abstraction
layer in between, so I never have AVCodecParameters and AVCodecContext
in the same function).
So in short, it just doesn't fix much, and you can still get invalid
output from avformat, and potentially still undefined behavior in
avcodec if its fed those values through other means.

>
> How about this: always convert the params to a temporary codecpar, and
> provide a function to determine the validity of a codecpar. This way
> the check could be done in multiple places without duplicating the code
> needed for it.

That still sounds odd, although slightly better. At the very least it
should be a dedicated function that checks the values in a key place,
say you want to check params that are fed to a decoder, then call this
check in avcodec_open, because thats something everyone has to call to
use avcodec.

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

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[wm4]

On Tue, 25 Oct 2016 09:47:29 +0200
Hendrik Leppkes  wrote:

> On Tue, Oct 25, 2016 at 1:50 AM, Andreas Cadhalpun
>  wrote:
> > This should reduce the impact of a demuxer (or API user) setting bogus
> > codec parameters.
> >
> >  
> 
> This seems rather noisy and doesn't really solve anything, does it?
> Decoders still need to validate values instead of blindly trusting
> them, and this just hides some problems in these decoders, instead of
> fixing them there. API users of avcodec would not fill
> AVCodecParameters, they would fill a codec context directly.

You could also argue that the demuxer shouldn't return invalid
parameters either.

How about this: always convert the params to a temporary codecpar, and
provide a function to determine the validity of a codecpar. This way
the check could be done in multiple places without duplicating the code
needed for it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[u-9iep]

On Mon, Oct 24, 2016 at 09:53:22PM +0200, Henrik Gramner wrote:
> The decision to issue emms manually instead of after every MMX
> function was a deliberate decision. I'd hardly call it "misdesigned"
> to make SIMD code twice as fast at the cost of technically abusing the

It would be nice to look at a benchmarking comparison, to be able to
see the actual practical performance gain of the decision not to follow
the ABI.

My expectation is among others that using MMX in a compliant way would
remain remarkably beneficial compared to no SIMD.

In a perfect world the user might be offered a build time choice:
either lose N% of the performance or take the consequences of not
following the ABI. Apparently, different users/packagers would make
different choices, but the crucial thing would be knowing the N.

Of course, offering to disable MMX _is_ such a choice, but having instead
an option of "somewhat slower, compliant MMX" would be much nicer.

my 2c
Rune

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

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 01:50:47AM +0200, Andreas Cadhalpun wrote:
> This should reduce the impact of a demuxer (or API user) setting bogus
> codec parameters.
> 
> Suggested-by: wm4
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/utils.c | 82 
> +-
>  1 file changed, 81 insertions(+), 1 deletion(-)

This adds some warnings:

libavcodec/utils.c: In function ‘avcodec_parameters_to_context’:
libavcodec/utils.c:4256:9: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]
libavcodec/utils.c:4261:9: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]
libavcodec/utils.c:4266:9: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]
libavcodec/utils.c:4271:9: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]
libavcodec/utils.c:4276:9: warning: comparison of unsigned expression < 0 is 
always false [-Wtype-limits]

i guess thats enum (un)signednes ...

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

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


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

Re: [FFmpeg-devel] [PATCH]lavc/utvideoenc: Set bits_per_coded_sample for rgba input.

[Paul B Mahol]

On 10/25/16, Carl Eugen Hoyos  wrote:
> 2016-10-25 13:01 GMT+02:00 Paul B Mahol :
>> On 10/25/16, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> Attached patch may fix an issue reported on the gusari forum.
>
>> Please clearly explain what is actual problem and what this patch
>> actually solves. I do not have time of all existence to search forums
>> on internet.
>
> Currently, ff_put_bmp_header() always writes "24" as biBitCount
> for utvideo because bits_per_coded_sample is never set by the
> encoder. Attached patch fixes the value of bits_per_coded_sample
> for rgba utvideo.
> (I do not know if the patch fixes an actual issue reported by a
> user and I cannot test.)
>
> Carl Eugen
>
>> ___
>> 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
>

Please put above explanation in commit log. Patch lgtm.

Have a nice day.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/utvideoenc: Set bits_per_coded_sample for rgba input.

[Carl Eugen Hoyos]

2016-10-25 13:01 GMT+02:00 Paul B Mahol :
> On 10/25/16, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch may fix an issue reported on the gusari forum.

> Please clearly explain what is actual problem and what this patch
> actually solves. I do not have time of all existence to search forums
> on internet.

Currently, ff_put_bmp_header() always writes "24" as biBitCount
for utvideo because bits_per_coded_sample is never set by the
encoder. Attached patch fixes the value of bits_per_coded_sample
for rgba utvideo.
(I do not know if the patch fixes an actual issue reported by a
user and I cannot test.)

Carl Eugen

> ___
> 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]lavc/utvideoenc: Set bits_per_coded_sample for rgba input.

[Paul B Mahol]

On 10/25/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch may fix an issue reported on the gusari forum.
>
> Please comment, Carl Eugen
>

Please clearly explain what is actual problem and what this patch
actually solves. I do not have time of all existence to search forums
on internet.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/utvideoenc: Set bits_per_coded_sample for rgba input.

[Carl Eugen Hoyos]

Hi!

Attached patch may fix an issue reported on the gusari forum.

Please comment, Carl Eugen
From 20d2713bc1d4997a03bde52afd4192bbb48d3bb8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 25 Oct 2016 12:55:54 +0200
Subject: [PATCH] lavc/utvideoenc: Set bits_per_coded_sample for rgba input.

Allow to write correct biBitCount into the BITMAPINFOHEADER.
---
 libavcodec/utvideoenc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
index 8ffc263..6082943 100644
--- a/libavcodec/utvideoenc.c
+++ b/libavcodec/utvideoenc.c
@@ -77,6 +77,7 @@ static av_cold int utvideo_encode_init(AVCodecContext *avctx)
 c->planes= 4;
 avctx->codec_tag = MKTAG('U', 'L', 'R', 'A');
 original_format  = UTVIDEO_RGBA;
+avctx->bits_per_coded_sample = 32;
 break;
 case AV_PIX_FMT_YUV420P:
 if (avctx->width & 1 || avctx->height & 1) {
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 01/12] adxdec: validate sample_rate

[Paul B Mahol]

On 10/23/16, Andreas Cadhalpun  wrote:
> A negative sample rate doesn't make sense and triggers assertions in
> av_rescale_rnd.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/adxdec.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c
> index cf44531..0315ecb 100644
> --- a/libavformat/adxdec.c
> +++ b/libavformat/adxdec.c
> @@ -109,6 +109,11 @@ static int adx_read_header(AVFormatContext *s)
>  return AVERROR_INVALIDDATA;
>  }
>
> +if (par->sample_rate <= 0) {
> +av_log(s, AV_LOG_ERROR, "Invalid sample rate %d\n",
> par->sample_rate);
> +return AVERROR_INVALIDDATA;
> +}
> +
>  par->codec_type  = AVMEDIA_TYPE_AUDIO;
>  par->codec_id= s->iformat->raw_codec_id;
>  par->bit_rate= par->sample_rate * par->channels * BLOCK_SIZE * 8LL
> / BLOCK_SAMPLES;
> --
> 2.9.3
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

patch(es)have good intent, but better fix is doing/checking it in single place.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/13] avcodec/utvideoenc: Clear MMX state after predict loop

[Paul B Mahol]

On 10/22/16, Michael Niedermayer  wrote:
> The subsequent huffman code performs several memory allocations, MMX state
> thus needs to be cleared between
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utvideoenc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
> index 8ffc263..fd27caa 100644
> --- a/libavcodec/utvideoenc.c
> +++ b/libavcodec/utvideoenc.c
> @@ -442,6 +442,7 @@ static int encode_plane(AVCodecContext *avctx, uint8_t
> *src,
> c->frame_pred);
>  return AVERROR_OPTION_NOT_FOUND;
>  }
> +emms_c();
>
>  /* Count the usage of values */
>  count_usage(dst, width, height, counts);
> --
> 2.10.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] scale_npp: fix passthrough mode

[Timo Rothenpieler]

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

Re: [FFmpeg-devel] [PATCH v3 3/3] fate: Add MXF D10/DV25 probe tests

[Tobias Rapp]

On 21.10.2016 11:58, Tobias Rapp wrote:

On 20.10.2016 09:36, Tobias Rapp wrote:

On 19.10.2016 23:06, Michael Niedermayer wrote:

On Wed, Oct 19, 2016 at 02:35:22PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp 
---
 tests/fate/mxf.mak| 19 ++-
 tests/ref/fate/mxf-probe-d10  |  3 +++
 tests/ref/fate/mxf-probe-dv25 |  4 
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/mxf-probe-d10
 create mode 100644 tests/ref/fate/mxf-probe-dv25


Applying: fate: Add MXF D10/DV25 probe tests
fatal: corrupt patch at line 60
didnt check deeply but some lines looks quite long, maybe something in
the mail chain didnt like that

[...]


Took the chance to change ffprobe output format from "compact" to
"default". The reference files are only <80 bytes larger but it avoids
the long lines and improves reading future diffs (git blame).

Also added a DNXHD probe test using an existing fate sample so
progressive field order is covered now, too.


The DNXHD probe test reference file has changed after the recent commits
to mxfdec.c . Find updated patch attached.


Updated the patch once more after commit 
73ead477ddd9dbfbe6f7e8d3fc90ebfd21b271b0.


When applying please remember to clean up the unused files in the 
FATE_SAMPLES server directory (rm mxf/Avid-5.{txt,xml} 
mxf/Sony-1.{txt,xml}).


Regards,
Tobias
>From 0518d124a58cd9a7fd80e6cf97e614ca0d44f91d Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Tue, 25 Oct 2016 10:06:15 +0200
Subject: [PATCH 3/3] fate: Add MXF D10/DNXHD/DV25 probe tests

Signed-off-by: Tobias Rapp 
---
 tests/fate/mxf.mak |  23 +-
 tests/ref/fate/mxf-probe-d10   | 108 
 tests/ref/fate/mxf-probe-dnxhd | 182 +
 tests/ref/fate/mxf-probe-dv25  | 149 +
 4 files changed, 461 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/mxf-probe-d10
 create mode 100644 tests/ref/fate/mxf-probe-dnxhd
 create mode 100644 tests/ref/fate/mxf-probe-dv25

diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
index 124c250..201cb93 100644
--- a/tests/fate/mxf.mak
+++ b/tests/fate/mxf.mak
@@ -14,7 +14,28 @@ fate-mxf-metadata-source-ref1: CMD = fmtstdout ffmetadata -i $(TARGET_SAMPLES)/m
 FATE_MXF += fate-mxf-metadata-source-ref2
 fate-mxf-metadata-source-ref2: CMD = fmtstdout ffmetadata -i $(TARGET_SAMPLES)/mxf/track_02_a01.mxf -fflags +bitexact -flags +bitexact -map 0:0 -map 0:1 -map 0:3  -map_metadata:g -1
 
+#
+# Tests probing MXF format and stream properties
+#
+PROBE_FORMAT_STREAMS_COMMAND = \
+ffprobe$(PROGSSUF)$(EXESUF) -show_entries format=format_name,duration,bit_rate:format_tags:streams:stream_tags \
+-print_format default -bitexact -v 0
+
+FATE_MXF_PROBE-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += fate-mxf-probe-d10
+fate-mxf-probe-d10: SRC = $(TARGET_SAMPLES)/mxf/Sony-1.mxf
+fate-mxf-probe-d10: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
+
+FATE_MXF_PROBE-$(call ENCDEC, DNXHD, MXF) += fate-mxf-probe-dnxhd
+fate-mxf-probe-dnxhd: SRC = $(TARGET_SAMPLES)/mxf/multiple_components.mxf
+fate-mxf-probe-dnxhd: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
+
+FATE_MXF_PROBE-$(call ENCDEC2, DVVIDEO, PCM_S16LE, MXF) += fate-mxf-probe-dv25
+fate-mxf-probe-dv25: SRC = $(TARGET_SAMPLES)/mxf/Avid-5.mxf
+fate-mxf-probe-dv25: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
+
 FATE_MXF-$(CONFIG_MXF_DEMUXER) += $(FATE_MXF)
 
 FATE_SAMPLES_AVCONV += $(FATE_MXF-yes)
-fate-mxf: $(FATE_MXF-yes)
+FATE_SAMPLES_FFPROBE += $(FATE_MXF_PROBE-yes)
+
+fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes)
diff --git a/tests/ref/fate/mxf-probe-d10 b/tests/ref/fate/mxf-probe-d10
new file mode 100644
index 000..30ceaaf
--- /dev/null
+++ b/tests/ref/fate/mxf-probe-d10
@@ -0,0 +1,108 @@
+[STREAM]
+index=0
+codec_name=mpeg2video
+profile=0
+codec_type=video
+codec_time_base=1/25
+codec_tag_string=[0][0][0][0]
+codec_tag=0x
+width=720
+height=608
+coded_width=0
+coded_height=0
+has_b_frames=0
+sample_aspect_ratio=152:135
+display_aspect_ratio=4:3
+pix_fmt=yuv422p
+level=5
+color_range=tv
+color_space=unknown
+color_transfer=unknown
+color_primaries=unknown
+chroma_location=topleft
+field_order=tt
+timecode=N/A
+refs=1
+id=N/A
+r_frame_rate=25/1
+avg_frame_rate=25/1
+time_base=1/25
+start_pts=0
+start_time=0.00
+duration_ts=4
+duration=0.16
+bit_rate=5000
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0

Re: [FFmpeg-devel] [PATCH] avcodec: validate codec parameters in avcodec_parameters_to_context

[Hendrik Leppkes]

On Tue, Oct 25, 2016 at 1:50 AM, Andreas Cadhalpun
 wrote:
> This should reduce the impact of a demuxer (or API user) setting bogus
> codec parameters.
>
>

This seems rather noisy and doesn't really solve anything, does it?
Decoders still need to validate values instead of blindly trusting
them, and this just hides some problems in these decoders, instead of
fixing them there. API users of avcodec would not fill
AVCodecParameters, they would fill a codec context directly.

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

Re: [FFmpeg-devel] [PATCH 2/3] ffprobe: report field order for video streams

[Tobias Rapp]

On 20.10.2016 18:01, Dave Rice wrote:



On Oct 20, 2016, at 3:28 AM, Tobias Rapp  wrote:

On 19.10.2016 23:15, Michael Niedermayer wrote:

On Wed, Oct 19, 2016 at 02:35:21PM +0200, Tobias Rapp wrote:

From: Rodger Combs 

Reviewed-by: Tobias Rapp 
---
doc/ffprobe.xsd |  1 +
ffprobe.c   | 13 +
tests/ref/fate/concat-demuxer-extended-lavf-mxf |  2 +-
tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 |  2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf  |  2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10  |  2 +-
tests/ref/fate/concat-demuxer-simple2-lavf-ts   |  2 +-
tests/ref/fate/ffprobe_compact  |  4 ++--
tests/ref/fate/ffprobe_csv  |  4 ++--
tests/ref/fate/ffprobe_default  |  2 ++
tests/ref/fate/ffprobe_flat |  2 ++
tests/ref/fate/ffprobe_ini  |  2 ++
12 files changed, 29 insertions(+), 9 deletions(-)


This too doesnt apply:

Applying: ffprobe: report field order for video streams
Using index info to reconstruct a base tree...
error: patch failed: tests/ref/fate/ffprobe_compact:27
error: tests/ref/fate/ffprobe_compact: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.



Could be due to encoding problems or long lines. Have rebased the patch onto 
current git HEAD and attached it as a file.


I tested this and the new version applied for me. The output of xml=q=1 
validated against the revision. LGTM. Having this data in ffprobe is really 
helpful.


Apparently this patch has been pushed by Rodger in the meanwhile.

Thanks,
Tobias

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

[FFmpeg-devel] [PATCH] lavfi/vf_overlay: support NV12 and NV21

[Rodger Combs]

---
 libavfilter/vf_overlay.c| 22 +-
 tests/fate/filter-video.mak | 10 ++
 tests/filtergraphs/overlay_nv12 |  5 +
 tests/filtergraphs/overlay_nv21 |  5 +
 4 files changed, 37 insertions(+), 5 deletions(-)
 create mode 100644 tests/filtergraphs/overlay_nv12
 create mode 100644 tests/filtergraphs/overlay_nv21

diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index c592dca..b249ad7 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -125,6 +125,7 @@ typedef struct OverlayContext {
 int main_pix_step[4];   ///< steps per pixel for each plane of the 
main output
 int overlay_pix_step[4];///< steps per pixel for each plane of the 
overlay
 int hsub, vsub; ///< chroma subsampling values
+const AVPixFmtDescriptor *main_desc; ///< format descriptor for main input
 
 double var_values[VAR_VARS_NB];
 char *x_expr, *y_expr;
@@ -215,7 +216,9 @@ static int query_formats(AVFilterContext *ctx)
 
 /* overlay formats contains alpha, for avoiding conversion with alpha 
information loss */
 static const enum AVPixelFormat main_pix_fmts_yuv420[] = {
-AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVA420P, 
AV_PIX_FMT_NONE
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_NV12, AV_PIX_FMT_NV21,
+AV_PIX_FMT_NONE
 };
 static const enum AVPixelFormat overlay_pix_fmts_yuv420[] = {
 AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE
@@ -470,6 +473,7 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
  int x, int y,
  int main_has_alpha)
 {
+OverlayContext *ol = ctx->priv;
 int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
 int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
 int dst_wp = AV_CEIL_RSHIFT(dst_w, hsub);
@@ -479,14 +483,20 @@ static av_always_inline void blend_plane(AVFilterContext 
*ctx,
 uint8_t *s, *sp, *d, *dp, *a, *ap;
 int jmax, j, k, kmax;
 
+int dst_plane  = ol->main_desc->comp[i].plane;
+int dst_offset = ol->main_desc->comp[i].offset;
+int dst_step   = ol->main_desc->comp[i].step;
+
 j = FFMAX(-yp, 0);
 sp = src->data[i] + j * src->linesize[i];
-dp = dst->data[i] + (yp+j)* dst->linesize[i];
+dp = dst->data[dst_plane]
+  + (yp+j)* dst->linesize[dst_plane]
+  + dst_offset;
 ap = src->data[3] + (j<linesize[3];
 
 for (jmax = FFMIN(-yp + dst_hp, src_hp); j < jmax; j++) {
 k = FFMAX(-xp, 0);
-d = dp + xp+k;
+d = dp + (xp+k) * dst_step;
 s = sp + k;
 a = ap + (k<linesize[i];
+dp += dst->linesize[dst_plane];
 sp += src->linesize[i];
 ap += (1 << vsub) * src->linesize[3];
 }
@@ -626,6 +636,8 @@ static int config_input_main(AVFilterLink *inlink)
 s->hsub = pix_desc->log2_chroma_w;
 s->vsub = pix_desc->log2_chroma_h;
 
+s->main_desc = pix_desc;
+
 s->main_is_packed_rgb =
 ff_fill_rgba_map(s->main_rgba_map, inlink->format) >= 0;
 s->main_has_alpha = ff_fmt_is_in(inlink->format, alpha_pix_fmts);
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index e2513f5..81c50f7 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -172,6 +172,16 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER 
SCALE_FILTER PAD_FILTER OVERLAY_F
 fate-filter-overlay_yuv420: tests/data/filtergraphs/overlay_yuv420
 fate-filter-overlay_yuv420: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420
 
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_nv12
+fate-filter-overlay_nv12: tests/data/filtergraphs/overlay_nv12
+fate-filter-overlay_nv12: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv12
+fate-filter-overlay_nv12: REF = tests/ref/fate/filter-overlay_yuv420
+
+FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_nv21
+fate-filter-overlay_nv21: tests/data/filtergraphs/overlay_nv21
+fate-filter-overlay_nv21: CMD = framecrc -c:v pgmyuv -i $(SRC) 
-filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv21
+fate-filter-overlay_nv21: REF = tests/ref/fate/filter-overlay_yuv420
+
 FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER 
OVERLAY_FILTER) += fate-filter-overlay_yuv422
 fate-filter-overlay_yuv422: tests/data/filtergraphs/overlay_yuv422
 

[FFmpeg-devel] is it possible that avfilter graph updates its setting in realtime?

[qw]

Hi,


I have one question about some rare usage for avfilter graph:


Sometimes, I want to change the setting in avfilter graph. For example, fps 
filter is used to set output frame rate, and it's expected that fps can be 
changed in accordance to real needs. Sometimes, fps is set to 25, and later 15 
as network bandwidth is not good. Is it possible that avfilter graph updates 
its setting in realtime, such as fps in fps filter, and widthxheight in scale 
filter?


Thanks!


Regards


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