Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

2019-04-25 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jing Sun
> Sent: Tuesday, April 2, 2019 3:02 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Sun, Jing A ; Huang, Zhengxu
> ; Jun Zhao ; Tmar,
> Hassene 
> Subject: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc

Is it V11 now? (Just saw several V10 and I am a litter confused.)

> encoder wrapper

Since there is some existed software HEVC encoder, how about add a link to the 
SVT-HEVC writepaper in the commit message
to make other easily to understand what is the advantage of SVT-HEVC and the 
benefit to plugin to FFmpeg?

> Signed-off-by: Zhengxu Huang 
> Signed-off-by: Hassene Tmar 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Jing Sun 
> ---
>  configure|   4 +
>  libavcodec/Makefile  |   1 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/libsvt_hevc.c | 482
> +++
>  4 files changed, 488 insertions(+)
>  create mode 100644 libavcodec/libsvt_hevc.c
> 
> diff --git a/configure b/configure
> index 938ff10..2aabac4 100755
> --- a/configure
> +++ b/configure
> @@ -264,6 +264,7 @@ External library support:
>--enable-libspeexenable Speex de/encoding via libspeex [no]
>--enable-libsrt  enable Haivision SRT protocol via libsrt [no]
>--enable-libssh  enable SFTP protocol via libssh [no]
> +  --enable-libsvthevc  enable HEVC encoding via svt [no]
>--enable-libtensorflow   enable TensorFlow as a DNN module backend
> for DNN based filters like sr [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
> @@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
>  libspeex
>  libsrt
>  libssh
> +libsvthevc
>  libtensorflow
>  libtesseract
>  libtheora
> @@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
>  libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
> +libsvt_hevc_encoder_deps="libsvthevc"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
> @@ -6209,6 +6212,7 @@ enabled libsoxr   && require libsoxr
> soxr.h soxr_create -lsoxr
>  enabled libssh&& require_pkg_config libssh libssh
> libssh/sftp.h sftp_init
>  enabled libspeex  && require_pkg_config libspeex speex
> speex/speex.h speex_decoder_init
>  enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0"
> srt/srt.h srt_socket
> +enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc
> EbApi.h EbInitHandle
>  enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h
> TF_Version -ltensorflow
>  enabled libtesseract  && require_pkg_config libtesseract tesseract
> tesseract/capi.h TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h
> th_info_init -ltheoraenc -ltheoradec -logg
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile index
> 15c43a8..c93e545 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)
> += libopusenc.o libopus.o \
>  OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
>  OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
> +OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
>  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) +=
> libvo-amrwbenc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index
> b26aeca..e93f66f 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;  extern
> AVCodec ff_libshine_encoder;  extern AVCodec ff_libspeex_encoder;
> extern AVCodec ff_libspeex_decoder;
> +extern AVCodec ff_libsvt_hevc_encoder;
>  extern AVCodec ff_libtheora_encoder;
>  extern AVCodec ff_libtwolame_encoder;
>  extern AVCodec ff_libvo_amrwbenc_encoder; diff --git
> a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c new file mode 100644
> index 000..5534389
> --- /dev/null
> +++ b/libavcodec/libsvt_hevc.c
> @@ -0,0 +1,482 @@
> +/*
> +* Scalable Video Technology for HEVC encoder library plugin
> +*
> +* Copyright (c) 2019 Intel Corporation
> +*
> +* 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 Licen

Re: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

2019-04-25 Thread Li, Zhong
> From: Sun, Jing A
> Sent: Tuesday, April 2, 2019 2:02 PM
> To: Li, Zhong ; FFmpeg development discussions and
> patches 
> Cc: Huang, Zhengxu ; Jun Zhao
> ; Tmar, Hassene 
> Subject: RE: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc
> encoder wrapper
> 
> -Original Message-
> From: Li, Zhong
> Sent: Friday, March 29, 2019 6:59 PM
> To: FFmpeg development discussions and patches
> 
> Cc: Sun, Jing A ; Huang, Zhengxu
> ; Jun Zhao ; Tmar,
> Hassene 
> Subject: RE: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc
> encoder wrapper
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Jing Sun
> > Sent: Friday, March 29, 2019 4:22 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Sun, Jing A ; Huang, Zhengxu
> > ; Jun Zhao ; Tmar,
> > Hassene 
> > Subject: [FFmpeg-devel] [PATCH v10 1/2] lavc/svt_hevc: add libsvt hevc
> > encoder wrapper
> >
> > Signed-off-by: Zhengxu Huang 
> > Signed-off-by: Hassene Tmar 
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: Jing Sun 
> > ---
> >  configure|   4 +
> >  libavcodec/Makefile  |   1 +
> >  libavcodec/allcodecs.c   |   1 +
> >  libavcodec/libsvt_hevc.c | 500
> > +++
> >  4 files changed, 506 insertions(+)
> >  create mode 100644 libavcodec/libsvt_hevc.c
> >
> > diff --git a/configure b/configure
> > index 938ff10..2aabac4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -264,6 +264,7 @@ External library support:
> >--enable-libspeexenable Speex de/encoding via libspeex [no]
> >--enable-libsrt  enable Haivision SRT protocol via libsrt [no]
> >--enable-libssh  enable SFTP protocol via libssh [no]
> > +  --enable-libsvthevc  enable HEVC encoding via svt [no]
> >--enable-libtensorflow   enable TensorFlow as a DNN module
> backend
> > for DNN based filters like sr [no]
> >--enable-libtesseractenable Tesseract, needed for ocr filter [no]
> > @@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
> >  libspeex
> >  libsrt
> >  libssh
> > +libsvthevc
> >  libtensorflow
> >  libtesseract
> >  libtheora
> > @@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
> >  libspeex_decoder_deps="libspeex"
> >  libspeex_encoder_deps="libspeex"
> >  libspeex_encoder_select="audio_frame_queue"
> > +libsvt_hevc_encoder_deps="libsvthevc"
> >  libtheora_encoder_deps="libtheora"
> >  libtwolame_encoder_deps="libtwolame"
> >  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
> > @@ -6209,6 +6212,7 @@ enabled libsoxr   && require libsoxr
> > soxr.h soxr_create -lsoxr
> >  enabled libssh&& require_pkg_config libssh libssh
> > libssh/sftp.h sftp_init
> >  enabled libspeex  && require_pkg_config libspeex speex
> > speex/speex.h speex_decoder_init
> >  enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0"
> > srt/srt.h srt_socket
> > +enabled libsvthevc&& require_pkg_config libsvthevc
> SvtHevcEnc
> > EbApi.h EbInitHandle
> >  enabled libtensorflow && require libtensorflow
> tensorflow/c/c_api.h
> > TF_Version -ltensorflow
> >  enabled libtesseract  && require_pkg_config libtesseract tesseract
> > tesseract/capi.h TessBaseAPICreate
> >  enabled libtheora && require libtheora theora/theoraenc.h
> > th_info_init -ltheoraenc -ltheoradec -logg diff --git
> > a/libavcodec/Makefile b/libavcodec/Makefile index
> > 15c43a8..c93e545 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)
> > += libopusenc.o libopus.o \
> >  OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
> >  OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
> >  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
> > +OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
> >  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
> >  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
> >  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) +=
> > libvo-amrwbenc.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index
> > b26aeca..e93f66f 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;  extern
> AVCodec
> > ff_libshine_encoder;  extern AVCodec ff_libspeex_encoder; extern
> > AVCodec ff_libspeex_decoder;
> > +extern AVCodec ff_libsvt_hevc_encoder;
> >  extern AVCodec ff_libtheora_encoder;
> >  extern AVCodec ff_libtwolame_encoder;  extern AVCodec
> > ff_libvo_amrwbenc_encoder; diff --git a/libavcodec/libsvt_hevc.c
> > b/libavcodec/libsvt_hevc.c new file mode 100644 index 000..4ef06a8
> > --- /dev/null
> > +++ b/libavcodec/libsvt_hevc.c
> > @@ -0,0 +1,500 @@
> > +/*
> > +* Scalable Video Technology for HEVC encoder library plugin
> > +*
> > +* Copyright (c) 2018 Intel Corporation
> 
> It is 2019 now.
> 
> [Jing] To be modified.
> 
> > +* This

[FFmpeg-devel] [PATCH v3] avfilter/avf_showwaves: Add draw mode also to showwavespic filter

2019-04-25 Thread Martin Vobruba
See commit a8c2d375ca68b7f001564ced14d8ac0757f53a29
---
 doc/filters.texi| 14 ++
 libavfilter/avf_showwaves.c |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index e9cbccc..2aabe8a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22645,6 +22645,20 @@ Cubic root.
 @end table
 
 Default is linear.
+
+@item draw
+Set the draw mode.
+
+Available values are:
+@table @samp
+@item scale
+Scale pixel values for each drawn sample.
+
+@item full
+Draw every sample directly.
+@end table
+
+Default value is @code{scale}.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0e683cf..a0d2b25 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -765,6 +765,9 @@ static const AVOption showwavespic_options[] = {
 { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
.flags=FLAGS, .unit="scale"},
 { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
.flags=FLAGS, .unit="scale"},
 { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
.flags=FLAGS, .unit="scale"},
+{ "draw", "set draw mode", OFFSET(draw_mode), AV_OPT_TYPE_INT, {.i64 = 
DRAW_SCALE}, 0, DRAW_NB-1, FLAGS, .unit="draw" },
+{ "scale", "scale pixel values for each drawn sample", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_SCALE}, .flags=FLAGS, .unit="draw"},
+{ "full",  "draw every pixel for sample directly", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_FULL},  .flags=FLAGS, .unit="draw"},
 { NULL }
 };
 
-- 
2.7.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] native mode in FFmpeg DNN module

2019-04-25 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Guo, Yejun
> Sent: Friday, April 19, 2019 11:22 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] native mode in FFmpeg DNN module
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Pedro Arthur
> > Sent: Friday, April 19, 2019 10:43 PM
> > To: FFmpeg development discussions and patches
> 
> > Subject: Re: [FFmpeg-devel] native mode in FFmpeg DNN module
> >
> > Hi,
> >
> > Em sex, 19 de abr de 2019 às 05:41, Guo, Yejun 
> > escreveu:
> > >
> > > Option 2)
> > > Write c code in FFmpeg to convert tensorflow file format (format 1) 
> > > directly
> > into memory representation (format 3), and so we controls everything in
> > ffmpeg community. And the conversion can be extended to import more file
> > formats such as torch, darknet, etc. One example is that OpenCV uses this
> > method.
> > >
> > > The in memory representation (format 3) can still be current.
> > >
> >
> > Option 2 would be ideal, as it does not introduce any dependency for
> > using the native backend.
> > Yet I'm not sure  how complex implementing the tf model reader can be,
> > If I remember correctly the student said it was not trivial at the
> > time.
> 
> yes, it is not easy, but I think it is worthy to do it. Here is a reference 
> example
> for the complexity, see
> https://github.com/opencv/opencv/blob/master/modules/dnn/src/tensorflow/
> tf_importer.cpp.
> 
> >
> > Is the tf model file stable? if not it will be a maintenance burden to
> > keep it working whenever tf releases a new version. This point makes
> > me think having control over our file format is good.
> 
> imho, this issue is always there, no matter which method used, unless our
> format could be exported by tensorflow (it has little possibility).
> 
> Whenever tf releases a new version with a new file format, we still have to
> change the python script in phase 1 (convert tf file model to our format) 
> which
> is even an external dependency at
> https://github.com/HighVoltageRocknRoll/sr,
> 
> As from effort perspective, the current implementation is better since python
> script is simpler. But I think we are still worth implementing option 2 as the
> ideal technical direction.

I checked a bit more about https://github.com/HighVoltageRocknRoll/sr, it is 
actually
not an converter (from tf model to native model), but hard code for given 
models.
And the native model is not exactly the same as tf model, it even changes the 
behavior
of pad parameter of conv layer.

If community is open to option 2, I'll try it.

> 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-04-25 Thread Philip Langdale
On Fri, 26 Apr 2019 09:43:39 +0530
ManojGuptaBonda  wrote:

> Latest generation video decoder on Turing Chips supports decoding HEVC
> 4:4:4 decoding. These changes adds support for the same for VDPAU
> 
> ManojGuptaBonda (3):
>   VDPAU: Add support for decoding HEVC 4:4:4 content
>   Pass sps and pps range extension flags to VDPAU.
>   Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.
> 
>  libavcodec/hevcdec.c|  9 +++-
>  libavcodec/vdpau_hevc.c | 41
> + libavcodec/vdpau_internal.h |
> 3 +++ libavutil/hwcontext_vdpau.c |  8 
>  4 files changed, 56 insertions(+), 5 deletions(-)
> 

Hi Manoj,

Thanks for putting these patches together. I'll push these this weekend
if there aren't any comments from anyone else.

If you're feeling generous, you could take a look at the vdpau
opengl interop in mpv and add support for 444 to the direct path. (It
already works correctly when using the vdpau mixer).

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] Pass sps and pps range extension flags to VDPAU.

2019-04-25 Thread ManojGuptaBonda
Pass SPS, PPS range extensions to VDPAU layer via VdpPictureInfoHEVC444.
Added VdpPictureInfoHEVC444 struct to VdpPictureInfo union to populate
the range extension params. Mapped FF_PROFILE_HEVC_REXT to
VDP_DECODER_PROFILE_HEVC_MAIN_444.
---
 libavcodec/vdpau_hevc.c | 41 +
 libavcodec/vdpau_internal.h |  3 +++
 2 files changed, 44 insertions(+)

diff --git a/libavcodec/vdpau_hevc.c b/libavcodec/vdpau_hevc.c
index 421135bce2..a68e1361fb 100644
--- a/libavcodec/vdpau_hevc.c
+++ b/libavcodec/vdpau_hevc.c
@@ -38,6 +38,9 @@ static int vdpau_hevc_start_frame(AVCodecContext *avctx,
 struct vdpau_picture_context *pic_ctx = pic->hwaccel_picture_private;
 
 VdpPictureInfoHEVC *info = &pic_ctx->info.hevc;
+#ifdef VDP_DECODER_PROFILE_HEVC_MAIN_444
+VdpPictureInfoHEVC444 *info2 = &pic_ctx->info.hevc_444;
+#endif
 
 const HEVCSPS *sps = h->ps.sps;
 const HEVCPPS *pps = h->ps.pps;
@@ -355,6 +358,41 @@ static int vdpau_hevc_start_frame(AVCodecContext *avctx,
 }
 }
 
+#ifdef VDP_DECODER_PROFILE_HEVC_MAIN_444
+if (sps->sps_range_extension_flag) {
+info2->sps_range_extension_flag = 1;
+info2->transformSkipRotationEnableFlag  = 
sps->transform_skip_rotation_enabled_flag;
+info2->transformSkipContextEnableFlag   = 
sps->transform_skip_context_enabled_flag;
+info2->implicitRdpcmEnableFlag  = 
sps->implicit_rdpcm_enabled_flag;
+info2->explicitRdpcmEnableFlag  = 
sps->explicit_rdpcm_enabled_flag;
+info2->extendedPrecisionProcessingFlag  = 
sps->extended_precision_processing_flag;
+info2->intraSmoothingDisabledFlag   = 
sps->intra_smoothing_disabled_flag;
+info2->highPrecisionOffsetsEnableFlag   = 
sps->high_precision_offsets_enabled_flag;
+info2->persistentRiceAdaptationEnableFlag   = 
sps->persistent_rice_adaptation_enabled_flag;
+info2->cabacBypassAlignmentEnableFlag   = 
sps->cabac_bypass_alignment_enabled_flag;
+} else {
+info2->sps_range_extension_flag = 0;
+}
+if (pps->pps_range_extensions_flag) {
+info2->pps_range_extension_flag = 1;
+info2->log2MaxTransformSkipSize = 
pps->log2_max_transform_skip_block_size;
+info2->crossComponentPredictionEnableFlag   = 
pps->cross_component_prediction_enabled_flag;
+info2->chromaQpAdjustmentEnableFlag = 
pps->chroma_qp_offset_list_enabled_flag;
+info2->diffCuChromaQpAdjustmentDepth= 
pps->diff_cu_chroma_qp_offset_depth;
+info2->chromaQpAdjustmentTableSize  = 
pps->chroma_qp_offset_list_len_minus1 + 1;
+info2->log2SaoOffsetScaleLuma   = 
pps->log2_sao_offset_scale_luma;
+info2->log2SaoOffsetScaleChroma = 
pps->log2_sao_offset_scale_chroma;
+for (ssize_t i = 0; i < info2->chromaQpAdjustmentTableSize; i++)
+{
+info2->cb_qp_adjustment[i] = pps->cb_qp_offset_list[i];
+info2->cr_qp_adjustment[i] = pps->cr_qp_offset_list[i];
+}
+
+} else {
+info2->pps_range_extension_flag = 0;
+}
+#endif
+
 return ff_vdpau_common_start_frame(pic_ctx, buffer, size);
 }
 
@@ -406,6 +444,9 @@ static int vdpau_hevc_init(AVCodecContext *avctx)
 case FF_PROFILE_HEVC_MAIN_STILL_PICTURE:
 profile = VDP_DECODER_PROFILE_HEVC_MAIN_STILL;
 break;
+case FF_PROFILE_HEVC_REXT:
+profile = VDP_DECODER_PROFILE_HEVC_MAIN_444;
+break;
 default:
 return AVERROR(ENOTSUP);
 }
diff --git a/libavcodec/vdpau_internal.h b/libavcodec/vdpau_internal.h
index 4d63e50b16..ebe4a8e9d5 100644
--- a/libavcodec/vdpau_internal.h
+++ b/libavcodec/vdpau_internal.h
@@ -51,6 +51,9 @@ union VDPAUPictureInfo {
 #ifdef VDP_DECODER_PROFILE_HEVC_MAIN
 VdpPictureInfoHEVChevc;
 #endif
+#ifdef VDP_DECODER_PROFILE_HEVC_MAIN
+VdpPictureInfoHEVC444 hevc_444;
+#endif
 };
 
 typedef struct VDPAUHWContext {
-- 
2.17.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.

2019-04-25 Thread ManojGuptaBonda
New VdpYCbCr Formats VDP_YCBCR_FORMAT_Y_U_V_444 and,
VDP_YCBCR_FORMAT_Y_UV_444 have been added in VDPAU to be used in
get/putbits for YUV 4:4:4 surfaces. Earlier mapping of
AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_YV12 is not valid.

Hence this Change maps AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_Y_U_V_444
to access the YUV 4:4:4 surface via read-back API's of VDPAU.
---
 libavutil/hwcontext_vdpau.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/hwcontext_vdpau.c b/libavutil/hwcontext_vdpau.c
index c11c3cfdab..786a51f802 100644
--- a/libavutil/hwcontext_vdpau.c
+++ b/libavutil/hwcontext_vdpau.c
@@ -73,8 +73,8 @@ static const VDPAUPixFmtMap pix_fmts_422[] = {
 };
 
 static const VDPAUPixFmtMap pix_fmts_444[] = {
-{ VDP_YCBCR_FORMAT_YV12, AV_PIX_FMT_YUV444P },
-{ 0, AV_PIX_FMT_NONE,   },
+{ VDP_YCBCR_FORMAT_Y_U_V_444, AV_PIX_FMT_YUV444P },
+{ 0,  AV_PIX_FMT_NONE,   },
 };
 
 static const struct {
@@ -349,7 +349,7 @@ static int vdpau_transfer_data_from(AVHWFramesContext *ctx, 
AVFrame *dst,
 return AVERROR(EINVAL);
 }
 
-if (vdpau_format == VDP_YCBCR_FORMAT_YV12)
+if ((vdpau_format == VDP_YCBCR_FORMAT_YV12) || (vdpau_format == 
VDP_YCBCR_FORMAT_Y_U_V_444))
 FFSWAP(void*, data[1], data[2]);
 
 err = priv->get_data(surf, vdpau_format, data, linesize);
@@ -400,7 +400,7 @@ static int vdpau_transfer_data_to(AVHWFramesContext *ctx, 
AVFrame *dst,
 return AVERROR(EINVAL);
 }
 
-if (vdpau_format == VDP_YCBCR_FORMAT_YV12)
+if ((vdpau_format == VDP_YCBCR_FORMAT_YV12) || (vdpau_format == 
VDP_YCBCR_FORMAT_Y_U_V_444))
 FFSWAP(const void*, data[1], data[2]);
 
 err = priv->put_data(surf, vdpau_format, data, linesize);
-- 
2.17.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-04-25 Thread ManojGuptaBonda
Latest generation video decoder on Turing Chips supports decoding HEVC
4:4:4 decoding. These changes adds support for the same for VDPAU

ManojGuptaBonda (3):
  VDPAU: Add support for decoding HEVC 4:4:4 content
  Pass sps and pps range extension flags to VDPAU.
  Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.

 libavcodec/hevcdec.c|  9 +++-
 libavcodec/vdpau_hevc.c | 41 +
 libavcodec/vdpau_internal.h |  3 +++
 libavutil/hwcontext_vdpau.c |  8 
 4 files changed, 56 insertions(+), 5 deletions(-)

-- 
2.17.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] VDPAU: Add support for decoding HEVC 4:4:4 content

2019-04-25 Thread ManojGuptaBonda
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. This change adds AV_PIX_FMT_VDPAU as a valid format
for HEVC 4:4:4 8 bit.
---
 libavcodec/hevcdec.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 857c10dd12..515b346535 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -408,8 +408,15 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 *fmt++ = AV_PIX_FMT_CUDA;
 #endif
 break;
-case AV_PIX_FMT_YUV420P12:
 case AV_PIX_FMT_YUV444P:
+#if CONFIG_HEVC_VDPAU_HWACCEL
+*fmt++ = AV_PIX_FMT_VDPAU;
+#endif
+#if CONFIG_HEVC_NVDEC_HWACCEL
+*fmt++ = AV_PIX_FMT_CUDA;
+#endif
+break;
+case AV_PIX_FMT_YUV420P12:
 case AV_PIX_FMT_YUV444P10:
 case AV_PIX_FMT_YUV444P12:
 #if CONFIG_HEVC_NVDEC_HWACCEL
-- 
2.17.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/3] *** VDPAU: HEVC YUV 4:4:4 Support ***

2019-04-25 Thread ManojGuptaBonda
Latest generation video decoder on Turing Chips supports decoding HEVC
4:4:4 decoding. These changes adds support for the same for VDPAU

ManojGuptaBonda (3):
  VDPAU: Add support for decoding HEVC 4:4:4 content
  Pass sps and pps range extension flags to VDPAU.
  Map 444 pix fmts to new VdpYCbCr types defined in VDPAU.

 libavcodec/hevcdec.c|  9 +++-
 libavcodec/vdpau_hevc.c | 41 +
 libavcodec/vdpau_internal.h |  3 +++
 libavutil/hwcontext_vdpau.c |  8 
 4 files changed, 56 insertions(+), 5 deletions(-)

-- 
2.17.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 1/2] lavfi/opencl: add more opencl helper macro

2019-04-25 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, April 17, 2019 5:25 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 1/2] lavfi/opencl: add more opencl
> helper macro
> 
> On 12/04/2019 16:09, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavfilter/opencl.h | 38 ++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
> > index 0b06232ade..0fa5b49d3f 100644
> > --- a/libavfilter/opencl.h
> > +++ b/libavfilter/opencl.h
> > @@ -73,6 +73,44 @@ typedef struct OpenCLFilterContext {
> >  goto fail; \
> >  }  \
> >  } while(0)
> > +/**
> > +  * release an OpenCL Kernel
> > +  */
> > +#define CL_RELEASE_KERNEL(k)  \
> > +do {  \
> > +if (k) {  \
> > +cle = clReleaseKernel(k); \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "OpenCL kernel: %d.\n", cle);  \
> > +} \
> > +} while(0)
> > +
> > +/**
> > +  * release an OpenCL Memory Object
> > +  */
> > +#define CL_RELEASE_MEMORY(m)  \
> > +do {  \
> > +if (m) {  \
> > +cle = clReleaseMemObject(m);  \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "OpenCL memory: %d.\n", cle);  \
> > +} \
> > +} while(0)
> > +
> > +/**
> > +  * release an OpenCL Command Queue
> > +  */
> > +#define CL_RELEASE_QUEUE(q)   \
> > +do {  \
> > +if (q) {  \
> > +cle = clReleaseCommandQueue(q);   \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "cl command queue: %d.\n", cle);   \
> > +} \
> > +} while(0)
> >
> >  /**
> >   * Return that all inputs and outputs support only AV_PIX_FMT_OPENCL.
> >
> 
> LGTM.
Pushed this patch so we can use it in other opencl filters. Thanks!
> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avfilter/avf_showwaves: Add draw mode also to showwavespic filter

2019-04-25 Thread Michael Niedermayer
On Thu, Apr 25, 2019 at 11:37:28AM +0200, Martin Vobruba wrote:
> See commit a8c2d375ca68b7f001564ced14d8ac0757f53a29
> ---
>  doc/filters.texi| 15 +++
>  libavfilter/avf_showwaves.c |  3 +++
>  2 files changed, 18 insertions(+)

breaks build
HTMLdoc/ffmpeg-all.html
doc/filters.texi:22650: @item outside of table or list
doc/filters.texi:22663: unmatched `@end table'
make: *** [doc/ffmpeg-all.html] Error 1
HTMLdoc/ffplay-all.html
doc/filters.texi:22650: @item outside of table or list
doc/filters.texi:22663: unmatched `@end table'
make: *** [doc/ffplay-all.html] Error 1
HTMLdoc/ffprobe-all.html
doc/filters.texi:22650: @item outside of table or list
doc/filters.texi:22663: unmatched `@end table'
make: *** [doc/ffprobe-all.html] Error 1
HTMLdoc/ffmpeg-filters.html
doc/filters.texi:22650: @item outside of table or list
doc/filters.texi:22663: unmatched `@end table'
make: *** [doc/ffmpeg-filters.html] Error 1
make: Target `all' not remade because of errors.


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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/aacdec: fix demuxing of very small frames

2019-04-25 Thread James Almer
10 bytes (id3v2 header amount of bytes) were being read before any checks
were made on the bitstream. The result was that we were overreading into
the next frame if the current one was 8 or 9 bytes long.

Fixes tickets #7271 and #7869.

Signed-off-by: James Almer 
---
 libavformat/aacdec.c | 34 +-
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index bd324a1420..8a5450880b 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -20,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/intreadwrite.h"
 #include "avformat.h"
 #include "avio_internal.h"
@@ -154,17 +155,8 @@ static int adts_aac_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 {
 int ret, fsize;
 
-// Parse all the ID3 headers between frames
-while (1) {
-ret = av_get_packet(s->pb, pkt, FFMAX(ID3v2_HEADER_SIZE, 
ADTS_HEADER_SIZE));
-if (ret >= ID3v2_HEADER_SIZE && ff_id3v2_match(pkt->data, 
ID3v2_DEFAULT_MAGIC)) {
-if ((ret = handle_id3(s, pkt)) >= 0) {
-continue;
-}
-}
-break;
-}
-
+retry:
+ret = av_get_packet(s->pb, pkt, ADTS_HEADER_SIZE);
 if (ret < 0)
 return ret;
 
@@ -174,8 +166,24 @@ static int adts_aac_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 
 if ((AV_RB16(pkt->data) >> 4) != 0xfff) {
-av_packet_unref(pkt);
-return AVERROR_INVALIDDATA;
+// Parse all the ID3 headers between frames
+int append = ID3v2_HEADER_SIZE - ADTS_HEADER_SIZE;
+
+av_assert2(append > 0);
+ret = av_append_packet(s->pb, pkt, append);
+if (ret != append) {
+av_packet_unref(pkt);
+return AVERROR(EIO);
+}
+if (!ff_id3v2_match(pkt->data, ID3v2_DEFAULT_MAGIC)) {
+av_packet_unref(pkt);
+return AVERROR_INVALIDDATA;
+}
+ret = handle_id3(s, pkt);
+if (ret < 0)
+return ret;
+
+goto retry;
 }
 
 fsize = (AV_RB32(pkt->data + 3) >> 13) & 0x1FFF;
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/scpr: check remaining data after decode

2019-04-25 Thread Michael Niedermayer
Fixes Timeout (29sec -> 14sec)
Fixes: 
13713/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5756778069884928

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/scpr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index e5d7d13cf0..0ccc250bfa 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -572,6 +572,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 if (ret < 0)
 return ret;
 
+if (bytestream2_get_bytes_left(gb) > 5)
+return AVERROR_INVALIDDATA;
+
 if (avctx->bits_per_coded_sample != 16) {
 ret = av_frame_ref(data, s->current_frame);
 if (ret < 0)
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/subtitles: ignore extra '\r' at line endings

2019-04-25 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavformat/microdvddec.c | 2 ++
 libavformat/subtitles.c   | 2 +-
 libavformat/subtitles.h   | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/microdvddec.c b/libavformat/microdvddec.c
index ef6bcfbc73..598093309c 100644
--- a/libavformat/microdvddec.c
+++ b/libavformat/microdvddec.c
@@ -130,6 +130,8 @@ static int microdvd_read_header(AVFormatContext *s)
 continue;   \
 }   \
 p++
+if (!*p)
+continue;
 SKIP_FRAME_ID;
 SKIP_FRAME_ID;
 if (!*p)
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 93c9ef05cf..659c99d1cf 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -417,7 +417,7 @@ ptrdiff_t ff_subtitles_read_line(FFTextReader *tr, char 
*buf, size_t size)
 buf[cur++] = c;
 buf[cur] = '\0';
 }
-if (ff_text_peek_r8(tr) == '\r')
+while (ff_text_peek_r8(tr) == '\r')
 ff_text_r8(tr);
 if (ff_text_peek_r8(tr) == '\n')
 ff_text_r8(tr);
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index ca78db224d..6b418e3621 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -188,7 +188,7 @@ static av_always_inline int ff_subtitles_next_line(const 
char *ptr)
 {
 int n = strcspn(ptr, "\r\n");
 ptr += n;
-if (*ptr == '\r') {
+while (*ptr == '\r') {
 ptr++;
 n++;
 }
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter/vf_stack: use time_base from framesync

2019-04-25 Thread Paul B Mahol
Fixes non-monotonous timestamps.

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_stack.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 8731674aa7..b836d96bf0 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -174,7 +174,6 @@ static int config_output(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
 StackContext *s = ctx->priv;
-AVRational time_base = ctx->inputs[0]->time_base;
 AVRational frame_rate = ctx->inputs[0]->frame_rate;
 AVRational sar = ctx->inputs[0]->sample_aspect_ratio;
 int height = ctx->inputs[0]->h;
@@ -281,7 +280,6 @@ static int config_output(AVFilterLink *outlink)
 
 outlink->w  = width;
 outlink->h  = height;
-outlink->time_base  = time_base;
 outlink->frame_rate = frame_rate;
 outlink->sample_aspect_ratio = sar;
 
@@ -301,7 +299,10 @@ static int config_output(AVFilterLink *outlink)
 in[i].after  = s->shortest ? EXT_STOP : EXT_INFINITY;
 }
 
-return ff_framesync_configure(&s->fs);
+ret = ff_framesync_configure(&s->fs);
+outlink->time_base = s->fs.time_base;
+
+return ret;
 }
 
 static av_cold void uninit(AVFilterContext *ctx)
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Paul B Mahol (12019-04-25):
> Not really, it works with 2x/3x/4x/5x.. sample rate or 1/2 / 1/3 / 1/4 / 1/5
> o sample rate in other direction.

I do not think so: the algorithm can work for absolutely any ratio. The
effect on the spectrum will not be as clean if the ratio is not an
integer, but that is another problem.

> It can not be done in aresample filter because of limitations of query_formats
> code in libavfilter

Please elaborate.

> and doing it anyway for aresample filter would
> cause many regressions.

I do not think so. Please elaborate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Paul B Mahol
On 4/25/19, Nicolas George  wrote:
> Paul B Mahol (12019-04-25):
>> The filter does not take sample rate as argument, but integer factor
>> instead.
>> So that make it impossible to be used with lswr.
>
> No need for an argument: the filter knows the negotiated input and
> output sample rate.

Not really, it works with 2x/3x/4x/5x.. sample rate or 1/2 / 1/3 / 1/4 / 1/5
o sample rate in other direction.
It can not be done in aresample filter because of limitations of query_formats
code in libavfilter and doing it anyway for aresample filter would
cause many regressions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] lavf/webm_chunk: Respect buffer size

2019-04-25 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> The last argument of av_strlcpy is supposed to contain the size of the
> destination buffer, but it was filled with the size of the source
> string, effectively negating its very purpose.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/webm_chunk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
> index ec1ec4bf91..2c99753b5b 100644
> --- a/libavformat/webm_chunk.c
> +++ b/libavformat/webm_chunk.c
> @@ -96,7 +96,7 @@ static int get_chunk_filename(AVFormatContext *s, int 
> is_header, char *filename)
>  av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
>  return AVERROR(EINVAL);
>  }
> -av_strlcpy(filename, wc->header_filename, 
> strlen(wc->header_filename) + 1);
> +av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
>  } else {
>  if (av_get_frame_filename(filename, MAX_FILENAME_SIZE,
>s->url, wc->chunk_index - 1) < 0) {
> 

I'd like to ping the whole patchset.

- Andreas

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Paul B Mahol (12019-04-25):
> The filter does not take sample rate as argument, but integer factor instead.
> So that make it impossible to be used with lswr.

No need for an argument: the filter knows the negotiated input and
output sample rate.

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Paul B Mahol
On 4/25/19, Nicolas George  wrote:
> Hendrik Leppkes (12019-04-25):
>> The point of this kind of filtering is not that they are necessary to
>> perform filtering, because you can filter at any sample rate, but that
>> oversampling for certain filters, and downsampling after, improves
>> quality. As such, negotiation is not really equipped to handle it,
>> since its designed to deal with compatibility between filters, not
>> quality concerns, and you also wouldn't want to remove the ability to
>> filter at ordinary sample rates either.
>
> I do not want them to be available ONLY with negotiation. If people want
> to add them, fine.
>
> But when negotiation decides a conversion needs to happen somewhere,
> these treatments must be available for it, at the place where it is
> needed, which is often not known to the user.
>
> And the simplest way of achieving that is to make it an option of the
> resample filter, or even better, en option if lswr. After all, it is
> only the audio equivalent of sws_flags=neighbor.

The filter does not take sample rate as argument, but integer factor instead.
So that make it impossible to be used with lswr.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Hendrik Leppkes (12019-04-25):
> The point of this kind of filtering is not that they are necessary to
> perform filtering, because you can filter at any sample rate, but that
> oversampling for certain filters, and downsampling after, improves
> quality. As such, negotiation is not really equipped to handle it,
> since its designed to deal with compatibility between filters, not
> quality concerns, and you also wouldn't want to remove the ability to
> filter at ordinary sample rates either.

I do not want them to be available ONLY with negotiation. If people want
to add them, fine.

But when negotiation decides a conversion needs to happen somewhere,
these treatments must be available for it, at the place where it is
needed, which is often not known to the user.

And the simplest way of achieving that is to make it an option of the
resample filter, or even better, en option if lswr. After all, it is
only the audio equivalent of sws_flags=neighbor.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] x86/opusdsp: replace loads with shuffles

2019-04-25 Thread Lynne



Apr 25, 2019, 6:44 PM by one...@gmail.com:

> On 4/25/19, Paul B Mahol <> one...@gmail.com > > 
> wrote:
>
>> On 4/24/19, Lynne <>> d...@lynne.ee >> > wrote:
>>
>>> Has a slight speedup.
>>> Can't be carried over to aarch64, since it has no shufps-like
>>> instruction.
>>>
>>
>> On what CPU? And by how much?
>>
>
> Patch should generally be OK if output does not change.
>
> Is this code covered by FATE?
>

Yes, fate-opus.
CPU is Skylake, speedup was about 30 decicycles (10512 -> 10482), low enough it 
could just be noise. The patch just removes some redundant tables.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] x86/opusdsp: replace loads with shuffles

2019-04-25 Thread Paul B Mahol
On 4/25/19, Paul B Mahol  wrote:
> On 4/24/19, Lynne  wrote:
>> Has a slight speedup.
>> Can't be carried over to aarch64, since it has no shufps-like
>> instruction.
>>
>>
>
> On what CPU? And by how much?
>

Patch should generally be OK if output does not change.

Is this code covered by FATE?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] x86/opusdsp: replace loads with shuffles

2019-04-25 Thread Paul B Mahol
On 4/24/19, Lynne  wrote:
> Has a slight speedup.
> Can't be carried over to aarch64, since it has no shufps-like instruction.
>
>

On what CPU? And by how much?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/gdv: Check input palette size before rescale()

2019-04-25 Thread Paul B Mahol
On 4/25/19, Michael Niedermayer  wrote:
> Fixes: Timeout (22sec -> 11sec)
> Fixes:
> 13576/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5681024577568768
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/gdv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
> index 183286b55f..0c16ad850a 100644
> --- a/libavcodec/gdv.c
> +++ b/libavcodec/gdv.c
> @@ -475,15 +475,14 @@ static int gdv_decode_frame(AVCodecContext *avctx,
> void *data,
>  if (pal && pal_size == AVPALETTE_SIZE)
>  memcpy(gdv->pal, pal, AVPALETTE_SIZE);
>
> +if (compression < 2 && bytestream2_get_bytes_left(gb) < 256*3)
> +return AVERROR_INVALIDDATA;
>  rescale(gdv, gdv->frame, avctx->width, avctx->height,
>  !!(flags & 0x10), !!(flags & 0x20));
> -

Unrelated.

>  switch (compression) {
>  case 1:
>  memset(gdv->frame + PREAMBLE_SIZE, 0, gdv->frame_size -
> PREAMBLE_SIZE);
>  case 0:
> -if (bytestream2_get_bytes_left(gb) < 256*3)
> -return AVERROR_INVALIDDATA;
>  for (i = 0; i < 256; i++) {
>  unsigned r = bytestream2_get_byte(gb);
>  unsigned g = bytestream2_get_byte(gb);
> --
> 2.21.0

Otherwise ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Hendrik Leppkes
On Thu, Apr 25, 2019 at 7:25 PM Nicolas George  wrote:
>
> Paul B Mahol (12019-04-25):
> > I did reacted. It plays well with negotiation.
>
> I missed that part, sorry. But it did not address my concern.
>
> > Can you be more specific what exactly you mean by "plays well with
> > sample rate negotiation"?
>
> If the user judges that this is the kind of sample rate change that is
> necessary, then when the negotiation detects a sample rate change is
> necessary, these filters are used.
>

The point of this kind of filtering is not that they are necessary to
perform filtering, because you can filter at any sample rate, but that
oversampling for certain filters, and downsampling after, improves
quality. As such, negotiation is not really equipped to handle it,
since its designed to deal with compatibility between filters, not
quality concerns, and you also wouldn't want to remove the ability to
filter at ordinary sample rates either.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Paul B Mahol (12019-04-25):
> I did reacted. It plays well with negotiation.

I missed that part, sorry. But it did not address my concern.

> Can you be more specific what exactly you mean by "plays well with
> sample rate negotiation"?

If the user judges that this is the kind of sample rate change that is
necessary, then when the negotiation detects a sample rate change is
necessary, these filters are used.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/gdv: Check input palette size before rescale()

2019-04-25 Thread Michael Niedermayer
Fixes: Timeout (22sec -> 11sec)
Fixes: 
13576/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5681024577568768

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/gdv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 183286b55f..0c16ad850a 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -475,15 +475,14 @@ static int gdv_decode_frame(AVCodecContext *avctx, void 
*data,
 if (pal && pal_size == AVPALETTE_SIZE)
 memcpy(gdv->pal, pal, AVPALETTE_SIZE);
 
+if (compression < 2 && bytestream2_get_bytes_left(gb) < 256*3)
+return AVERROR_INVALIDDATA;
 rescale(gdv, gdv->frame, avctx->width, avctx->height,
 !!(flags & 0x10), !!(flags & 0x20));
-
 switch (compression) {
 case 1:
 memset(gdv->frame + PREAMBLE_SIZE, 0, gdv->frame_size - PREAMBLE_SIZE);
 case 0:
-if (bytestream2_get_bytes_left(gb) < 256*3)
-return AVERROR_INVALIDDATA;
 for (i = 0; i < 256; i++) {
 unsigned r = bytestream2_get_byte(gb);
 unsigned g = bytestream2_get_byte(gb);
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Paul B Mahol
On 4/25/19, Nicolas George  wrote:
> Paul B Mahol (12019-04-25):
>> You haven't replied any more, and nothing that you said earlier is valid.
>
> I have stated: rejected until it plays well with sample rate
> negotiation. You have not reacted to it.

I did reacted. It plays well with negotiation.
Can you be more specific what exactly you mean by "plays well with
sample rate negotiation"?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Paul B Mahol (12019-04-25):
> You haven't replied any more, and nothing that you said earlier is valid.

I have stated: rejected until it plays well with sample rate
negotiation. You have not reacted to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Paul B Mahol
On 4/25/19, Nicolas George  wrote:
> Paul B Mahol (12019-04-25):
>> As there appears to be no more comments or valid arguments against this
>
> Saying it does not make it true.

You haven't replied any more, and nothing that you said earlier is valid.

>
>> set I will apply it.
>
> Do it and I will revert and ask that your commits rights be revoked.

Michael, please remove Nicolas from committers as he want to revert
my patches and do not have valid technical arguments for his actions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/jpeg2000dec: Check PLT data somewhat

2019-04-25 Thread Michael Niedermayer
On Thu, Apr 25, 2019 at 04:34:00PM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: Timeout (21sec -> 0.6sec)
> > Fixes: 
> > 14134/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5768371078955008
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/jpeg2000dec.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 9198cf87cb..62b0b1f9b7 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -832,15 +832,21 @@ static uint8_t get_tlm(Jpeg2000DecoderContext *s, int 
> > n)
> >  static uint8_t get_plt(Jpeg2000DecoderContext *s, int n)
> >  {
> >  int i;
> > +int v;
> >  
> >  av_log(s->avctx, AV_LOG_DEBUG,
> >  "PLT marker at pos 0x%X\n", bytestream2_tell(&s->g) - 4);
> >  
> > +if (n < 4)
> > +return AVERROR_INVALIDDATA;
> > +
> >  /*Zplt =*/ bytestream2_get_byte(&s->g);
> >  
> >  for (i = 0; i < n - 3; i++) {
> > -bytestream2_get_byte(&s->g);
> > +v = bytestream2_get_byte(&s->g);
> >  }
> > +if (v & 0x80)
> > +return AVERROR_INVALIDDATA;
> >  
> >  return 0;
> >  }
> > 
> get_tlm should probably return int as uint8_t can't hold the
> AVERROR_INVALIDDATA. gcc gives Woverflow warnings because of that.
> 
> Currently, the return value of get_tlm is always >= 0 and so is the
> return value of jpeg2000_read_main_headers and of
> jpeg2000_decode_frame if one runs into the AVERROR_INVALIDDATA checks.
> (I didn't test it, just took a quick glimpse at the code.)

will fix

thanks

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/af_astats: count number of NaNs/Infs/denormals for floating-point audio too

2019-04-25 Thread Paul B Mahol
On 4/23/19, Alexander Strasser  wrote:
> Hi Paul,
>
> just three small comments from me...
>
> On 2019-04-22 11:51 +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi|  6 +++
>>  libavfilter/af_astats.c | 86 ++---
>>  2 files changed, 86 insertions(+), 6 deletions(-)
>
> I was a bit surprised when I first saw the number of lines it
> takes to add this feature. OTOH this is not a problem of this
> patch, because it is mostly caused by the structure of the
> code that was in place before.
>
> Changing the structure doesn't seem worth it yet. If
> there will be an addition that is applicable to all the
> individual stats, it should IMHO be reconsidered.

What are you proposing to change?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/jpeg2000dec: Check PLT data somewhat

2019-04-25 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Michael Niedermayer:
>> Fixes: Timeout (21sec -> 0.6sec)
>> Fixes: 
>> 14134/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5768371078955008
>>
>> Found-by: continuous fuzzing process 
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/jpeg2000dec.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
>> index 9198cf87cb..62b0b1f9b7 100644
>> --- a/libavcodec/jpeg2000dec.c
>> +++ b/libavcodec/jpeg2000dec.c
>> @@ -832,15 +832,21 @@ static uint8_t get_tlm(Jpeg2000DecoderContext *s, int 
>> n)
>>  static uint8_t get_plt(Jpeg2000DecoderContext *s, int n)
>>  {
>>  int i;
>> +int v;
>>  
>>  av_log(s->avctx, AV_LOG_DEBUG,
>>  "PLT marker at pos 0x%X\n", bytestream2_tell(&s->g) - 4);
>>  
>> +if (n < 4)
>> +return AVERROR_INVALIDDATA;
>> +
>>  /*Zplt =*/ bytestream2_get_byte(&s->g);
>>  
>>  for (i = 0; i < n - 3; i++) {
>> -bytestream2_get_byte(&s->g);
>> +v = bytestream2_get_byte(&s->g);
>>  }
>> +if (v & 0x80)
>> +return AVERROR_INVALIDDATA;
>>  
>>  return 0;
>>  }
>>
> get_tlm should probably return int as uint8_t can't hold the
> AVERROR_INVALIDDATA. gcc gives Woverflow warnings because of that.
> 
> Currently, the return value of get_tlm is always >= 0 and so is the
> return value of jpeg2000_read_main_headers and of
> jpeg2000_decode_frame if one runs into the AVERROR_INVALIDDATA checks.
> (I didn't test it, just took a quick glimpse at the code.)
> 
> - Andreas
> 
get_plt, not get_tlm. Sorry.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/jpeg2000dec: Check PLT data somewhat

2019-04-25 Thread Andreas Rheinhardt
Michael Niedermayer:
> Fixes: Timeout (21sec -> 0.6sec)
> Fixes: 
> 14134/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5768371078955008
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jpeg2000dec.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 9198cf87cb..62b0b1f9b7 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -832,15 +832,21 @@ static uint8_t get_tlm(Jpeg2000DecoderContext *s, int n)
>  static uint8_t get_plt(Jpeg2000DecoderContext *s, int n)
>  {
>  int i;
> +int v;
>  
>  av_log(s->avctx, AV_LOG_DEBUG,
>  "PLT marker at pos 0x%X\n", bytestream2_tell(&s->g) - 4);
>  
> +if (n < 4)
> +return AVERROR_INVALIDDATA;
> +
>  /*Zplt =*/ bytestream2_get_byte(&s->g);
>  
>  for (i = 0; i < n - 3; i++) {
> -bytestream2_get_byte(&s->g);
> +v = bytestream2_get_byte(&s->g);
>  }
> +if (v & 0x80)
> +return AVERROR_INVALIDDATA;
>  
>  return 0;
>  }
> 
get_tlm should probably return int as uint8_t can't hold the
AVERROR_INVALIDDATA. gcc gives Woverflow warnings because of that.

Currently, the return value of get_tlm is always >= 0 and so is the
return value of jpeg2000_read_main_headers and of
jpeg2000_decode_frame if one runs into the AVERROR_INVALIDDATA checks.
(I didn't test it, just took a quick glimpse at the code.)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

2019-04-25 Thread Andreas Håkon

‐‐‐ Original Message ‐‐‐
On Thursday, 25 de April de 2019 17:36, Ali KIZIL  wrote:

> Andreas Håkon andreas.ha...@protonmail.com, 25 Nis 2019 Per, 17:49
> tarihinde şunu yazdı:
>
> I got the point. Yet, sorry for being curious, would can affect TR101 290
> analyze results and/or null stuffing on CBR mpegts out?
> I can do these tests if needed, by tomorrow.
>

Don't worry! I'm glad to discuss it.

And no, it doesn't violate the rules of the standards in any way.
So pass all the analyzers. And it never generates null stuffing (pid 8191).

It even correctly agrees with the restriction of not increasing the CC
counter when no payload is found in the TS packet.

So please check it with as many analyzers as you can.
I'm sure it'll pass them.

Regards,
A.H.

---

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Nicolas George
Paul B Mahol (12019-04-25):
> As there appears to be no more comments or valid arguments against this

Saying it does not make it true.

> set I will apply it.

Do it and I will revert and ask that your commits rights be revoked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add audio upsample filter

2019-04-25 Thread Paul B Mahol
On 4/22/19, Paul B Mahol  wrote:
> On 4/22/19, Nicolas George  wrote:
>> Paul B Mahol (12019-04-21):
>>> https://dspguru.com/dsp/faqs/multirate/resampling/
>>>
>>> Resampling involves interpolation.
>>> If I do resampling with aresample and resampling with factor 2 from
>>> 44100 to 88200
>>> I can see there is still some spectrum data in highest frequencies.
>>
>> Resampling MAY involve interpolation, to enhance the subjective quality
>> of the output.
>
> It is not MAY, it MUST involve interpolation in almost any scenario.
>
>>
>>> If you haven't noticed, this is just upsampling/downsampling without
>>> lowpass.
>>> And that is not resampling in any way.
>>
>> No matter how many times you repeat it, saying that changing the sample
>> rate is not resampling will not make it true.
>
> By your flawed reasoning asetrate filter is doing resamping too.
>
>>
>>> That is just your opinion now, you need to provide technical terms
>>> to support your statements.
>>
>> I have given technical considerations: we have automatic sample rate
>> negotiation. These filter would not fit with it.
>
> If you haven't tried them, they fit well with sample rate negotiation.
> Filters change sample rate metadata by integer factor up or down.
>
>>
>> What have you provided besides your opinion and links to generic
>> considerations that do not substantiate your views?
>
> I have provided actual facts, and not opinions unlike you.
>
>>
>>> Another option to aresample filter would just confuse users.
>>
>> Less so than yet another pair of filters that do almost exactly the same
>> thing as others.
>
> No filter in libavfilter does what those filters do.
>
> And there is reason why SoX have those as separate filters and not some
> strange combination with their generic resampling effect.
>

As there appears to be no more comments or valid arguments against this
set I will apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

2019-04-25 Thread Ali KIZIL
Andreas Håkon , 25 Nis 2019 Per, 17:49
tarihinde şunu yazdı:

>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 25 de April de 2019 16:23, Ali KIZIL 
> wrote:
>
> > Andreas Håkon andreas.ha...@protonmail.com, 25 Nis 2019 Per, 12:07
> > tarihinde şunu yazdı:
> >
> > > Hi,
> > > A patch for a new optional parameter for the mpegtsenc muxer.
> > > Regards.
> > > A.H.
> > > ---___
> >
> > Is this patch related with "[FFmpeg-devel] [PATCH] libavformat: forced
> PCR
> > pid in mpegts muxer" patchwork ?
>
> No. They're complementary, but totally different patches/objectives!
>
> >
> > Is the purpose of the patch to avoid null stuffing in forced pcr pid ?
>
> No. The purpose is to avoid having PCR marks in packets with payload.
>
> >
> > I can not figure out the usage. A texi can be useful.
> > Normally, if PCR in on Video PID, why should I prefer to avoid video
> > payload ?
> >
>
> When you move the PCR marks to empty packets then you can transform the
> Transport Stream without touching the PES packets at all. Imagine a TS
> processor that duplicates or process the PCR packets for other purposes.
> As these packets doesn't have any payload the stream processor is free
> to do it whatever it needs. This is just one example. This option can
> be useful in various scenarios. In my research the target are several
> multi-resolution streams for mobile devices.
>
> In any case I have to say that this patch is completely transparent
> and only adds optional functionality.
>
> Regards.
> A.H.
>
> ---
>

I got the point. Yet, sorry for being curious, would can affect TR101 290
analyze results  and/or null stuffing on CBR mpegts out?
I can do these tests if needed, by tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

2019-04-25 Thread Andreas Håkon



‐‐‐ Original Message ‐‐‐
On Thursday, 25 de April de 2019 16:23, Ali KIZIL  wrote:

> Andreas Håkon andreas.ha...@protonmail.com, 25 Nis 2019 Per, 12:07
> tarihinde şunu yazdı:
>
> > Hi,
> > A patch for a new optional parameter for the mpegtsenc muxer.
> > Regards.
> > A.H.
> > ---___
>
> Is this patch related with "[FFmpeg-devel] [PATCH] libavformat: forced PCR
> pid in mpegts muxer" patchwork ?

No. They're complementary, but totally different patches/objectives!

>
> Is the purpose of the patch to avoid null stuffing in forced pcr pid ?

No. The purpose is to avoid having PCR marks in packets with payload.

>
> I can not figure out the usage. A texi can be useful.
> Normally, if PCR in on Video PID, why should I prefer to avoid video
> payload ?
>

When you move the PCR marks to empty packets then you can transform the
Transport Stream without touching the PES packets at all. Imagine a TS
processor that duplicates or process the PCR packets for other purposes.
As these packets doesn't have any payload the stream processor is free
to do it whatever it needs. This is just one example. This option can
be useful in various scenarios. In my research the target are several
multi-resolution streams for mobile devices.

In any case I have to say that this patch is completely transparent
and only adds optional functionality.

Regards.
A.H.

---

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

2019-04-25 Thread Paul B Mahol
On 4/25/19, Reto Kromer  wrote:
> Paul B Mahol wrote:
>
>>Found 65x65x65 3D LUT in wild
>
> FYI: 128x128x128 3D LUTs do also exist in film production.
>

Thank you, changed locally.

> Best regards, Reto
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

2019-04-25 Thread Paul B Mahol
On 4/25/19, Moritz Barsnick  wrote:
> On Thu, Apr 25, 2019 at 14:57:25 +0200, Paul B Mahol wrote:
>> Found 65x65x65 3D LUT in wild
> [...]
>>  /* 3D LUT don't often go up to level 32, but it is common to have a Hald
>> CLUT
>>   * of 512x512 (64x64x64) */
>> -#define MAX_LEVEL 64
>> +#define MAX_LEVEL 65
>
> You may also want to fix the values in the comment right above.

Nope. It should stay. Extreme cases are not common.

>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

2019-04-25 Thread Reto Kromer
Paul B Mahol wrote:

>Found 65x65x65 3D LUT in wild

FYI: 128x128x128 3D LUTs do also exist in film production.

Best regards, Reto

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

2019-04-25 Thread Ali KIZIL
Andreas Håkon , 25 Nis 2019 Per, 12:07
tarihinde şunu yazdı:

> Hi,
>
> A patch for a new optional parameter for the mpegtsenc muxer.
>
> Regards.
> A.H.
>
> ---___
>

Is this patch related with "[FFmpeg-devel] [PATCH] libavformat: forced PCR
pid in mpegts muxer" patchwork ?

Is the purpose of the patch to avoid null stuffing in forced pcr pid ?

I can not figure out the usage. A texi can be useful.
Normally, if PCR in on Video PID, why should I prefer to avoid video
payload ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi: add gblur_opencl filter

2019-04-25 Thread Moritz Barsnick
On Thu, Apr 25, 2019 at 22:41:49 +1000, Dylan Fernando wrote:

> +static const AVOption gblur_opencl_options[] = {
> +{ "sigma",  "set horizontal size",  OFFSET(sigma), AV_OPT_TYPE_FLOAT, 
> {.dbl=0.5},   0.0, 1024, FLAGS },
   ^

Shouldn't this be "set sigma"?

> +{ "planes", "set planes to filter", OFFSET(planes),  AV_OPT_TYPE_INT, 
> {.i64=0xF}, 0,  0xF, FLAGS },
> +{ "sigmaV", "set vertical sigma",   OFFSET(sigmaV), AV_OPT_TYPE_FLOAT, 
> {.dbl=-1},   -1, 1024, FLAGS },
> +{ NULL }

Please also add documentation to doc/filters.texi. You could do this by
reference to the "gblur" filter, but as this filter's options are
slightly different, you will need to copy the relevant sections.

Furthermore, CamelCase variables aren't usually accepted for ffmpeg own
variables, but this mirrors the gblur filter, so - oh well.

> +matrix_horiz = av_malloc(matrix_bytes_horiz);
> +if (!matrix_horiz) {
> +av_freep(&matrix_horiz);

If av_malloc() returned 0/NULL, does it ever need to be freed???

> +matrix_vert = av_malloc(matrix_bytes_vert);
> +if (!matrix_vert) {
> +av_freep(&matrix_vert);

Ditto

I can't judge on the rest.

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

2019-04-25 Thread Moritz Barsnick
On Thu, Apr 25, 2019 at 14:57:25 +0200, Paul B Mahol wrote:
> Found 65x65x65 3D LUT in wild
[...]
>  /* 3D LUT don't often go up to level 32, but it is common to have a Hald CLUT
>   * of 512x512 (64x64x64) */
> -#define MAX_LEVEL 64
> +#define MAX_LEVEL 65

You may also want to fix the values in the comment right above.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_lut3d: fix range domain processing for .cube format

2019-04-25 Thread Paul B Mahol
The ranges are for input, not for output.

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_lut3d.c | 73 +-
 1 file changed, 51 insertions(+), 22 deletions(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index d1974b0e05..c3dd6eb69f 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -64,6 +64,7 @@ typedef struct LUT3DContext {
 uint8_t rgba_map[4];
 int step;
 avfilter_action_func *interp;
+struct rgbvec scale;
 struct rgbvec lut[MAX_LEVEL][MAX_LEVEL][MAX_LEVEL];
 int lutsize;
 #if CONFIG_HALDCLUT_FILTER
@@ -219,7 +220,9 @@ static int 
interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
 const uint8_t *srcbrow = in->data[1] + slice_start * in->linesize[1];  
\
 const uint8_t *srcrrow = in->data[2] + slice_start * in->linesize[2];  
\
 const uint8_t *srcarow = in->data[3] + slice_start * in->linesize[3];  
\
-const float scale = (1. / ((1scale.r / ((1scale.g / ((1scale.b / ((1width; x++) {  
\
-const struct rgbvec scaled_rgb = {srcr[x] * scale, 
\
-  srcg[x] * scale, 
\
-  srcb[x] * scale};
\
+const struct rgbvec scaled_rgb = {srcr[x] * scale_r,   
\
+  srcg[x] * scale_g,   
\
+  srcb[x] * scale_b};  
\
 struct rgbvec vec = interp_##name(lut3d, &scaled_rgb); 
\
 dstr[x] = av_clip_uintp2(vec.r * (float)((1data[0] + slice_start * out->linesize[0]; 
 \
 const uint8_t *srcrow = in ->data[0] + slice_start * in ->linesize[0]; 
 \
-const float scale = (1. / ((1scale.r / ((1scale.g / ((1scale.b / ((1width * step; x += step) { 
 \
-const struct rgbvec scaled_rgb = {src[x + r] * scale,  
 \
-  src[x + g] * scale,  
 \
-  src[x + b] * scale}; 
 \
+const struct rgbvec scaled_rgb = {src[x + r] * scale_r,
 \
+  src[x + g] * scale_g,
 \
+  src[x + b] * scale_b};   
 \
 struct rgbvec vec = interp_##name(lut3d, &scaled_rgb); 
 \
 dst[x + r] = av_clip_uint##nbits(vec.r * (float)((1g, 
&vec->b) != 3)
 return AVERROR_INVALIDDATA;
-vec->r *= max[0] - min[0];
-vec->g *= max[1] - 

[FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

2019-04-25 Thread Paul B Mahol
Found 65x65x65 3D LUT in wild

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_lut3d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 50ea5a8545..d1974b0e05 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -55,7 +55,7 @@ struct rgbvec {
 
 /* 3D LUT don't often go up to level 32, but it is common to have a Hald CLUT
  * of 512x512 (64x64x64) */
-#define MAX_LEVEL 64
+#define MAX_LEVEL 65
 
 typedef struct LUT3DContext {
 const AVClass *class;
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavfi: add gblur_opencl filter

2019-04-25 Thread Dylan Fernando
---
 configure |   1 +
 libavfilter/Makefile  |   2 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/gblur.cl   |  62 +++
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_gblur_opencl.c | 370 ++
 6 files changed, 437 insertions(+)
 create mode 100644 libavfilter/opencl/gblur.cl
 create mode 100644 libavfilter/vf_gblur_opencl.c

diff --git a/configure b/configure
index bbeaf2fadc..8c1d3cdf92 100755
--- a/configure
+++ b/configure
@@ -3451,6 +3451,7 @@ freezedetect_filter_select="scene_sad"
 frei0r_filter_deps="frei0r libdl"
 frei0r_src_filter_deps="frei0r libdl"
 fspp_filter_deps="gpl"
+gblur_opencl_filter_deps="opencl"
 geq_filter_deps="gpl"
 histeq_filter_deps="gpl"
 hqdn3d_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..230315ef39 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -243,6 +243,8 @@ OBJS-$(CONFIG_FREEZEDETECT_FILTER)   += 
vf_freezedetect.o
 OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
 OBJS-$(CONFIG_FSPP_FILTER)   += vf_fspp.o
 OBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
+OBJS-$(CONFIG_GBLUR_OPENCL_FILTER)   += vf_gblur_opencl.o opencl.o \
+opencl/gblur.o
 OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
 OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
 OBJS-$(CONFIG_GRAPHMONITOR_FILTER)   += f_graphmonitor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..cb0fc051cc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -229,6 +229,7 @@ extern AVFilter ff_vf_freezedetect;
 extern AVFilter ff_vf_frei0r;
 extern AVFilter ff_vf_fspp;
 extern AVFilter ff_vf_gblur;
+extern AVFilter ff_vf_gblur_opencl;
 extern AVFilter ff_vf_geq;
 extern AVFilter ff_vf_gradfun;
 extern AVFilter ff_vf_graphmonitor;
diff --git a/libavfilter/opencl/gblur.cl b/libavfilter/opencl/gblur.cl
new file mode 100644
index 00..4fece30d4a
--- /dev/null
+++ b/libavfilter/opencl/gblur.cl
@@ -0,0 +1,62 @@
+/*
+ * Copyright (c) 2018 Dylan Fernando
+ *
+ * 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
+ */
+
+
+__kernel void gblur_conv_horz(__write_only image2d_t dst,
+  __read_only  image2d_t src,
+  int coef_matrix_dim,
+  __constant float *coef_matrix)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_ADDRESS_CLAMP_TO_EDGE   |
+   CLK_FILTER_NEAREST);
+
+const int half_matrix_dim = (coef_matrix_dim / 2);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+float4 convPix = (float4)(0.0f, 0.0f, 0.0f, 0.0f);
+
+for (int conv_j = -half_matrix_dim; conv_j <= half_matrix_dim; conv_j++) {
+float4 px = read_imagef(src, sampler, loc + (int2)(conv_j, 0));
+convPix += px * coef_matrix[(conv_j + half_matrix_dim)];
+}
+
+write_imagef(dst, loc, convPix);
+}
+
+__kernel void gblur_conv_vert(__write_only image2d_t dst,
+  __read_only  image2d_t src,
+  int coef_matrix_dim,
+  __constant float *coef_matrix)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_ADDRESS_CLAMP_TO_EDGE   |
+   CLK_FILTER_NEAREST);
+
+const int half_matrix_dim = (coef_matrix_dim / 2);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+float4 convPix = (float4)(0.0f, 0.0f, 0.0f, 0.0f);
+
+for (int conv_j = -half_matrix_dim; conv_j <= half_matrix_dim; conv_j++) {
+float4 px = read_imagef(src, sampler, loc + (int2)(0, conv_j));
+convPix += px * coef_matrix[(conv_j + half_matrix_dim)];
+}
+
+write_imagef(dst, loc, convPix);
+}
diff --git a/libavfilter/opencl_source.h b/libavfilter/opencl_source.h
index 4118138c30..be7e826c4c 100644
--- a/libavfilter/opencl_source.h
+++ b/libavfilter/opencl_source.h
@@ -20,6 +20,7 @@
 #define AVFILTER_OPENCL_SOURCE_H
 
 extern const char *ff_opencl_source_avgblur;
+extern const char 

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/jpeg2000: Check stepsize before using it

2019-04-25 Thread Michael Niedermayer
On Tue, Apr 16, 2019 at 04:48:32PM +0200, Michael Niedermayer wrote:
> Fixes: value 1.87633e+10 is outside the range of representable values of type 
> 'int'
> Fixes: Undefined behavior
> Fixes: 
> 14246/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5758393601490944
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jpeg2000.c | 5 +
>  1 file changed, 5 insertions(+)

will apply jpeg2000 patchset


[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec_fixed: Fix undefined shift in noise_scale()

2019-04-25 Thread Michael Niedermayer
On Fri, Mar 29, 2019 at 09:18:04AM +0100, Michael Niedermayer wrote:
> Fixes: 
> 13655/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5120559430500352
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacdec_fixed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/qtrle: Check how much of the chunk is available before decoding

2019-04-25 Thread Michael Niedermayer
On Tue, Apr 02, 2019 at 02:48:37AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (10sec -> 2sec)
> Fixes: 
> 13979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-5635157718990848
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/qtrle.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

will apply

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] avfilter/avf_showwaves: Add draw mode also to showwavespic filter

2019-04-25 Thread Martin Vobruba
See commit a8c2d375ca68b7f001564ced14d8ac0757f53a29
---
 doc/filters.texi| 15 +++
 libavfilter/avf_showwaves.c |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index e9cbccc..e8636da 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22647,6 +22647,21 @@ Cubic root.
 Default is linear.
 @end table
 
+@item draw
+Set the draw mode.
+
+Available values are:
+@table @samp
+@item scale
+Scale pixel values for each drawn sample.
+
+@item full
+Draw every sample directly.
+@end table
+
+Default value is @code{scale}.
+@end table
+
 @subsection Examples
 
 @itemize
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0e683cf..a0d2b25 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -765,6 +765,9 @@ static const AVOption showwavespic_options[] = {
 { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
.flags=FLAGS, .unit="scale"},
 { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
.flags=FLAGS, .unit="scale"},
 { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
.flags=FLAGS, .unit="scale"},
+{ "draw", "set draw mode", OFFSET(draw_mode), AV_OPT_TYPE_INT, {.i64 = 
DRAW_SCALE}, 0, DRAW_NB-1, FLAGS, .unit="draw" },
+{ "scale", "scale pixel values for each drawn sample", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_SCALE}, .flags=FLAGS, .unit="draw"},
+{ "full",  "draw every pixel for sample directly", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_FULL},  .flags=FLAGS, .unit="draw"},
 { NULL }
 };
 
-- 
2.7.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/bintext: Add error message when resolution is too small for font.

2019-04-25 Thread Michael Niedermayer
On Wed, Apr 10, 2019 at 10:25:45PM +0200, Michael Niedermayer wrote:
> On Mon, Apr 08, 2019 at 03:22:10PM -0700, Nikolas Bowe via ffmpeg-devel wrote:
> > ---
> >  libavcodec/bintext.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> LGTM

will apply

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showwaves: Add draw mode also to showwavespic filter

2019-04-25 Thread Paul B Mahol
On 4/25/19, Martin Vobruba  wrote:
> See commit a8c2d375ca68b7f001564ced14d8ac0757f53a29
> ---
>  doc/filters.texi| 15 +++
>  libavfilter/avf_showwaves.c |  3 +++
>  2 files changed, 18 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e9cbccc..9b92189 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -22647,6 +22647,21 @@ Cubic root.
>  Default is linear.
>  @end table
>
> +@item draw
> +Set the draw mode. This is mostly useful to set for high @var{n}.

This is misleading users, @var{n} is not exported for showspectrumpic.

> +
> +Available values are:
> +@table @samp
> +@item scale
> +Scale pixel values for each drawn sample.
> +
> +@item full
> +Draw every sample directly.
> +@end table
> +
> +Default value is @code{scale}.
> +@end table
> +
>  @subsection Examples
>
>  @itemize
> diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
> index 0e683cf..a0d2b25 100644
> --- a/libavfilter/avf_showwaves.c
> +++ b/libavfilter/avf_showwaves.c
> @@ -765,6 +765,9 @@ static const AVOption showwavespic_options[] = {
>  { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG},
> .flags=FLAGS, .unit="scale"},
>  { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT},
> .flags=FLAGS, .unit="scale"},
>  { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT},
> .flags=FLAGS, .unit="scale"},
> +{ "draw", "set draw mode", OFFSET(draw_mode), AV_OPT_TYPE_INT, {.i64 =
> DRAW_SCALE}, 0, DRAW_NB-1, FLAGS, .unit="draw" },
> +{ "scale", "scale pixel values for each drawn sample", 0,
> AV_OPT_TYPE_CONST, {.i64=DRAW_SCALE}, .flags=FLAGS, .unit="draw"},
> +{ "full",  "draw every pixel for sample directly", 0,
> AV_OPT_TYPE_CONST, {.i64=DRAW_FULL},  .flags=FLAGS, .unit="draw"},
>  { NULL }
>  };
>
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

2019-04-25 Thread Andreas Håkon
Hi,

A patch for a new optional parameter for the mpegtsenc muxer.

Regards.
A.H.

---From 7f9f1a992615e15121b661d4cd1b9c1e32e1c894 Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Thu, 25 Apr 2019 09:49:29 +0100
Subject: [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

This patch provides a new optional parameter for the mpegtsenc muxer.
The parameter "-pcr_without_payload" can be used to override the default
behaviour of writing PCR timestamps in TS packets with payload.
Using a value greater than 0 all TS packets carrying PCR timestamps will
be forced to have an empty payload. Otherwise (with 0) the regular behaviour is
used and PCR packets can have payload. Futhermore with a value greater than 1
the packet with the PCR will be repeated the number of times indicated.
The default value is "-pcr_without_payload 0", which corresponds to the current
behaviour.
This can be handy for many reasons.

Signed-off-by: Andreas Hakon 
---
 doc/muxers.texi |5 +
 libavformat/mpegtsenc.c |   18 ++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 83ae017..9acdee3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1564,6 +1564,11 @@ Set a constant muxrate. Default is VBR.
 @item pes_payload_size @var{integer}
 Set minimum PES packet payload in bytes. Default is @code{2930}.
 
+@item pcr_without_payload @var{integer}
+Generates PCR packets without payload. When the value is greater than 1
+it repeats the PCR packet N times. With a 0 value it generates regular
+PCR packets with payload. Default is @code{0}.
+
 @item mpegts_flags @var{flags}
 Set mpegts flags. Accepts the following options:
 @table @samp
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..0cc42cd 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -97,6 +97,7 @@ typedef struct MpegTSWrite {
 int pmt_start_pid;
 int start_pid;
 int m2ts_mode;
+int pcr_repetition;
 
 int reemit_pat_pmt; // backward compatibility
 
@@ -1093,12 +1094,13 @@ static void mpegts_insert_null_packet(AVFormatContext 
*s)
 }
 
 /* Write a single transport stream packet with a PCR and no payload */
-static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st)
+static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st, int 
repetition)
 {
 MpegTSWrite *ts = s->priv_data;
 MpegTSWriteStream *ts_st = st->priv_data;
 uint8_t *q;
 uint8_t buf[TS_PACKET_SIZE];
+int i;
 
 q= buf;
 *q++ = 0x47;
@@ -1119,7 +1121,9 @@ static void mpegts_insert_pcr_only(AVFormatContext *s, 
AVStream *st)
 /* stuffing bytes */
 memset(q, 0xFF, TS_PACKET_SIZE - (q - buf));
 mpegts_prefix_m2ts_header(s);
-avio_write(s->pb, buf, TS_PACKET_SIZE);
+for (i=0; ipb, buf, TS_PACKET_SIZE);
+}
 }
 
 static void write_pts(uint8_t *q, int fourbits, int64_t pts)
@@ -1212,12 +1216,15 @@ static void mpegts_write_pes(AVFormatContext *s, 
AVStream *st,
 (dts - get_pcr(ts, s->pb) / 300) > delay) {
 /* pcr insert gets priority over null packet insert */
 if (write_pcr)
-mpegts_insert_pcr_only(s, st);
+mpegts_insert_pcr_only(s, st, ts->pcr_repetition < 1 ? 1 : 
ts->pcr_repetition);
 else
 mpegts_insert_null_packet(s);
 /* recalculate write_pcr and possibly retransmit si_info */
 continue;
 }
+if (write_pcr && ts->pcr_repetition > 0) {
+mpegts_insert_pcr_only(s, st, ts->pcr_repetition);
+}
 
 /* prepare packet header */
 q= buf;
@@ -1241,7 +1248,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream 
*st,
 set_af_flag(buf, 0x40);
 q = get_ts_payload_start(buf);
 }
-if (write_pcr) {
+if (write_pcr && ts->pcr_repetition == 0) {
 set_af_flag(buf, 0x10);
 q = get_ts_payload_start(buf);
 // add 11, pcr references the last byte of program clock reference 
base
@@ -1926,6 +1933,9 @@ static const AVOption options[] = {
 { "pes_payload_size", "Minimum PES packet payload in bytes",
   offsetof(MpegTSWrite, pes_payload_size), AV_OPT_TYPE_INT,
   { .i64 = DEFAULT_PES_PAYLOAD_SIZE }, 0, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM },
+{ "pcr_without_payload", "Generate PCR packets without payload",
+  offsetof(MpegTSWrite, pcr_repetition), AV_OPT_TYPE_INT,
+  { .i64 = 0 }, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
 { "mpegts_flags", "MPEG-TS muxing flags",
   offsetof(MpegTSWrite, flags), AV_OPT_TYPE_FLAGS, { .i64 = 0 }, 0, 
INT_MAX,
   AV_OPT_FLAG_ENCODING_PARAM, "mpegts_flags" },
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.o

Re: [FFmpeg-devel] [PATCH v1] lavf/dashenc: Add option for calculting pkt duration

2019-04-25 Thread Jeyapal, Karthick

On 4/25/19 1:15 PM, Jun Li wrote:
>
>
>
> On Wed, Apr 24, 2019 at 11:07 PM Jeyapal, Karthick  
> wrote:
>
>
> On 4/24/19 11:30 PM, Jun Li wrote:
> > On Sun, Apr 21, 2019 at 5:51 PM Jun Li  wrote:
> >
> >> Fix #7144.
> >> The current packet duration calculation is heuristic, which uses the
> >> historical durtion as current duration. This commit adds the option
> >> to buffer one packet and calcuate its duration when next packet 
> arrives.
> Thanks for sending this patch. Here is opinion about this approach.
> Even when the next packet arrives you cannot calculate its duration 
> reliably from pts or dts in muxer side.
> For example, when there are B-frames and variable frame rate this method 
> of calculating duration from Next packet's DTS won't work.
> I believe that this issue should be fixed at the demuxer side before the 
> raw stream passes thru an encoder.
> A raw stream's PTS from the capture device is guaranteed to be in-order 
> and hence a demuxer can calculate its duration reliably from the next 
> packet's PTS.
> Once it passes thru an encoder the frames could get out-of-order due to 
> B-frames and using PTS on the muxer could give wrong duration for VFR.
> Basically, this method is also a heuristic method.
> Maybe it fixes the ticket you mentioned for that particular input(Maybe 
> no B frames). But it won't work for all inputs.
> >> Obviously it adds one frame latency, which might be significant for
> >> VFR live content, so expose it as an option for user to choose.
> >> ---
> >>  doc/muxers.texi   |  4 
> >>  libavformat/dashenc.c | 44 +--
> >>  2 files changed, 46 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >> index ee99ef621e..76954877a6 100644
> >> --- a/doc/muxers.texi
> >> +++ b/doc/muxers.texi
> >> @@ -321,6 +321,10 @@ This is an experimental feature.
> >>  @item -master_m3u8_publish_rate @var{master_m3u8_publish_rate}
> >>  Publish master playlist repeatedly every after specified number of
> >> segment intervals.
> >>
> >> +@item -skip_estimate_pkt_duration
> >> +If this flag is set, packet duration will be calcuated as the diff of 
> the
> >> current and next packet timestamp. The option is not for constant 
> frame rate
> >> +content because heuristic estimation will be accurate in this case.
> >> Default value is 0.
> >> +
> >>  @end table
> >>
> >>  @anchor{framecrc}
> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >> index 5f1333e436..f89d68a51b 100644
> >> --- a/libavformat/dashenc.c
> >> +++ b/libavformat/dashenc.c
> >> @@ -101,6 +101,7 @@ typedef struct OutputStream {
> >>  double availability_time_offset;
> >>  int total_pkt_size;
> >>  int muxer_overhead;
> >> +AVPacket* prev_pkt;
> >>  } OutputStream;
> >>
> >>  typedef struct DASHContext {
> >> @@ -145,6 +146,7 @@ typedef struct DASHContext {
> >>  int ignore_io_errors;
> >>  int lhls;
> >>  int master_publish_rate;
> >> +int skip_estiamte_pkt_duration;
> >>  int nr_of_streams_to_flush;
> >>  int nr_of_streams_flushed;
> >>  } DASHContext;
> >> @@ -1559,7 +1561,7 @@ static int dash_flush(AVFormatContext *s, int 
> final,
> >> int stream)
> >>  } else {
> >>  snprintf(os->full_path, sizeof(os->full_path), "%s%s",
> >> c->dirname, os->initfile);
> >>  }
> >> -
> >> +
> >>  ret = flush_dynbuf(c, os, &range_length);
> >>  if (ret < 0)
> >>  break;
> >> @@ -1643,7 +1645,7 @@ static int dash_flush(AVFormatContext *s, int 
> final,
> >> int stream)
> >>  return ret;
> >>  }
> >>
> >> -static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
> >> +static int dash_write_packet_internal(AVFormatContext *s, AVPacket 
> *pkt)
> >>  {
> >>  DASHContext *c = s->priv_data;
> >>  AVStream *st = s->streams[pkt->stream_index];
> >> @@ -1789,11 +1791,47 @@ static int dash_write_packet(AVFormatContext 
> *s,
> >> AVPacket *pkt)
> >>  return ret;
> >>  }
> >>
> >> +static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
> >> +{
> >> +DASHContext *c = s->priv_data;
> >> +if (!c->skip_estiamte_pkt_duration)
> >> +return dash_write_packet_internal(s, pkt);
> >> +
> >> +AVStream *st = s->streams[pkt->stream_index];
> >> +OutputStream *os = &c->streams[pkt->stream_index];
> >> +int ret = 0;
> >> +
> >> +if (os->prev_pkt) {
> >> +if (!os->prev_pkt->duration && pkt->dts >= os->prev_pkt->dts)
> >> +os->prev_pkt->duration = pkt->dts - os->prev_pkt->dts;
> >> +ret 

Re: [FFmpeg-devel] [PATCH] avformat/mpegenc - reject unsupported audio streams

2019-04-25 Thread Gyan



On 25-04-2019 01:23 PM, Ali KIZIL wrote:


There are also Dolby Codecs (ac3 & eac3). Will it also throw error for
these codecs ?


AC3   is  supported before and after this patch.
EAC3 is unsupported before and after this patch.

But it's sent to the same decoder, so support could be added. I'll check.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter/avf_showwaves: Add draw mode also to showwavespic filter

2019-04-25 Thread Martin Vobruba
See commit a8c2d375ca68b7f001564ced14d8ac0757f53a29
---
 doc/filters.texi| 15 +++
 libavfilter/avf_showwaves.c |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index e9cbccc..9b92189 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22647,6 +22647,21 @@ Cubic root.
 Default is linear.
 @end table
 
+@item draw
+Set the draw mode. This is mostly useful to set for high @var{n}.
+
+Available values are:
+@table @samp
+@item scale
+Scale pixel values for each drawn sample.
+
+@item full
+Draw every sample directly.
+@end table
+
+Default value is @code{scale}.
+@end table
+
 @subsection Examples
 
 @itemize
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0e683cf..a0d2b25 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -765,6 +765,9 @@ static const AVOption showwavespic_options[] = {
 { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
.flags=FLAGS, .unit="scale"},
 { "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
.flags=FLAGS, .unit="scale"},
 { "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
.flags=FLAGS, .unit="scale"},
+{ "draw", "set draw mode", OFFSET(draw_mode), AV_OPT_TYPE_INT, {.i64 = 
DRAW_SCALE}, 0, DRAW_NB-1, FLAGS, .unit="draw" },
+{ "scale", "scale pixel values for each drawn sample", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_SCALE}, .flags=FLAGS, .unit="draw"},
+{ "full",  "draw every pixel for sample directly", 0, 
AV_OPT_TYPE_CONST, {.i64=DRAW_FULL},  .flags=FLAGS, .unit="draw"},
 { NULL }
 };
 
-- 
2.7.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegenc - reject unsupported audio streams

2019-04-25 Thread Ali KIZIL
Gyan , 24 Nis 2019 Çar, 07:30 tarihinde şunu yazdı:

>
>
> On 24-04-2019 03:30 AM, Carl Eugen Hoyos wrote:
> > 2019-04-22 13:00 GMT+02:00, Gyan :
> >> On 22-04-2019 01:15 PM, Gyan wrote:
> >>>
> >>> On 22-04-2019 12:30 PM, Carl Eugen Hoyos wrote:
> > Am 20.04.2019 um 11:31 schrieb Gyan :
> >
> >
> > Old patch that was never applied. Rebased.
>  Please return patch_welcome for mlp and truehd.
> >>> Will do.
>  Wasn’t there another comment (not by me): “Why
>  can’t .codec_tag be used?”
> >>> There's no codec_tag member set. This patch is just
> >>> to disallow an invalid muxing to proceed.
> > Wasn't the argument that this is possible with codec_tag?
>
> Not in the present state. If you want to add a codec_tag, that's a
> separate patch.
>
> >> Revised.
> > What about aac?
>
> There's no provision to mux AAC, at present. On demux, the stream is
> detected as mp2.
>
> > And can't you wait more than a few hours for a review?
> This patch is 14 months old, except for the one change you requested.
> And all the patch does is enforce the existing limitations.
>
> Gyan
> ___
>

There are also Dolby Codecs (ac3 & eac3). Will it also throw error for
these codecs ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/dashenc: Add option for calculting pkt duration

2019-04-25 Thread Jun Li
On Wed, Apr 24, 2019 at 11:07 PM Jeyapal, Karthick 
wrote:

>
> On 4/24/19 11:30 PM, Jun Li wrote:
> > On Sun, Apr 21, 2019 at 5:51 PM Jun Li  wrote:
> >
> >> Fix #7144.
> >> The current packet duration calculation is heuristic, which uses the
> >> historical durtion as current duration. This commit adds the option
> >> to buffer one packet and calcuate its duration when next packet arrives.
> Thanks for sending this patch. Here is opinion about this approach.
> Even when the next packet arrives you cannot calculate its duration
> reliably from pts or dts in muxer side.
> For example, when there are B-frames and variable frame rate this method
> of calculating duration from Next packet's DTS won't work.
> I believe that this issue should be fixed at the demuxer side before the
> raw stream passes thru an encoder.
> A raw stream's PTS from the capture device is guaranteed to be in-order
> and hence a demuxer can calculate its duration reliably from the next
> packet's PTS.
> Once it passes thru an encoder the frames could get out-of-order due to
> B-frames and using PTS on the muxer could give wrong duration for VFR.
> Basically, this method is also a heuristic method.
> Maybe it fixes the ticket you mentioned for that particular input(Maybe no
> B frames). But it won't work for all inputs.
> >> Obviously it adds one frame latency, which might be significant for
> >> VFR live content, so expose it as an option for user to choose.
> >> ---
> >>  doc/muxers.texi   |  4 
> >>  libavformat/dashenc.c | 44 +--
> >>  2 files changed, 46 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >> index ee99ef621e..76954877a6 100644
> >> --- a/doc/muxers.texi
> >> +++ b/doc/muxers.texi
> >> @@ -321,6 +321,10 @@ This is an experimental feature.
> >>  @item -master_m3u8_publish_rate @var{master_m3u8_publish_rate}
> >>  Publish master playlist repeatedly every after specified number of
> >> segment intervals.
> >>
> >> +@item -skip_estimate_pkt_duration
> >> +If this flag is set, packet duration will be calcuated as the diff of
> the
> >> current and next packet timestamp. The option is not for constant frame
> rate
> >> +content because heuristic estimation will be accurate in this case.
> >> Default value is 0.
> >> +
> >>  @end table
> >>
> >>  @anchor{framecrc}
> >> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >> index 5f1333e436..f89d68a51b 100644
> >> --- a/libavformat/dashenc.c
> >> +++ b/libavformat/dashenc.c
> >> @@ -101,6 +101,7 @@ typedef struct OutputStream {
> >>  double availability_time_offset;
> >>  int total_pkt_size;
> >>  int muxer_overhead;
> >> +AVPacket* prev_pkt;
> >>  } OutputStream;
> >>
> >>  typedef struct DASHContext {
> >> @@ -145,6 +146,7 @@ typedef struct DASHContext {
> >>  int ignore_io_errors;
> >>  int lhls;
> >>  int master_publish_rate;
> >> +int skip_estiamte_pkt_duration;
> >>  int nr_of_streams_to_flush;
> >>  int nr_of_streams_flushed;
> >>  } DASHContext;
> >> @@ -1559,7 +1561,7 @@ static int dash_flush(AVFormatContext *s, int
> final,
> >> int stream)
> >>  } else {
> >>  snprintf(os->full_path, sizeof(os->full_path), "%s%s",
> >> c->dirname, os->initfile);
> >>  }
> >> -
> >> +
> >>  ret = flush_dynbuf(c, os, &range_length);
> >>  if (ret < 0)
> >>  break;
> >> @@ -1643,7 +1645,7 @@ static int dash_flush(AVFormatContext *s, int
> final,
> >> int stream)
> >>  return ret;
> >>  }
> >>
> >> -static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
> >> +static int dash_write_packet_internal(AVFormatContext *s, AVPacket
> *pkt)
> >>  {
> >>  DASHContext *c = s->priv_data;
> >>  AVStream *st = s->streams[pkt->stream_index];
> >> @@ -1789,11 +1791,47 @@ static int dash_write_packet(AVFormatContext *s,
> >> AVPacket *pkt)
> >>  return ret;
> >>  }
> >>
> >> +static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
> >> +{
> >> +DASHContext *c = s->priv_data;
> >> +if (!c->skip_estiamte_pkt_duration)
> >> +return dash_write_packet_internal(s, pkt);
> >> +
> >> +AVStream *st = s->streams[pkt->stream_index];
> >> +OutputStream *os = &c->streams[pkt->stream_index];
> >> +int ret = 0;
> >> +
> >> +if (os->prev_pkt) {
> >> +if (!os->prev_pkt->duration && pkt->dts >= os->prev_pkt->dts)
> >> +os->prev_pkt->duration = pkt->dts - os->prev_pkt->dts;
> >> +ret = dash_write_packet_internal(s, os->prev_pkt);
> >> +av_packet_unref(os->prev_pkt);
> >> +if (av_packet_ref(os->prev_pkt, pkt)) {
> >> +av_log(s, AV_LOG_ERROR, "Failed to set up a reference to
> >> current packet, lost one packet for muxing.\n");
> >> +av_packet_free(&os->prev_pkt);
> >> +}
> >> +} else {
> >> +os->prev_pkt = av_packet_clone(pkt);
> >> +}
> >> +return ret;
> >> +}
> >> +
> >>