Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg
Dear all, We would appreciate if you could let us know the procedure and expected timeline for integration of our patch related with the Turing codec within the ffmpeg project. Thank you, All the best, Saverio -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Saverio Blasi Sent: 11 May 2017 08:21 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg Dear all, First of all thank you very much for all the help you provided with this patch. We are now at the tenth iteration, and the patch greatly improved since the first time we submitted it. In fact most of the lines of code in the current version of the patch were suggested by you or revised many times already. Regarding the implementation of the cmd parsing, as Hendrik is pointing out below, we followed other similar approaches (of other codecs). We already revised this implementation following your comments in previous iterations of this patch. At this stage, we would prefer to avoid changing again its structure and keep the implementation as it is, because this gives us more flexibility and also aligns it with other similar projects already integrated with ffmpeg. We would appreciate if you could let us know the procedure from here on for integration of this patch within the ffmpeg project. Thank you, All the best, Saverio >> Dear Michael, >> Why do you pass a single string of all options and then manually parse all options out of it instead of specifying the options each in teh AVOption array ? >>> We prefer to pass a single string so that we can be more flexible >>> how we then parse it and what to do with it. This gives us more >>> freedom in the future in case we decide to change some of the codec >>> APIs, so that we do not need to change the interface with FFmpeg. >> >> That is unacceptable. > libx264 and 265 pass options the same way, what exactly is the problem with > that? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.
---
libavcodec/cuvid.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 218be8495d..0b1710bd46 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
return;
}
-if (ctx->cudecoder) {
-ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
-ctx->cudecoder = NULL;
-}
+seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
-if (ctx->cuparser) {
-ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
-ctx->cuparser = NULL;
-}
-
-ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(&ctx->cuparser,
&ctx->cuparseinfo));
+ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, &seq_pkt));
if (ret < 0)
goto error;
+seq_pkt.flags = 0;
seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
--
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.
Am 16.05.2017 um 10:27 schrieb Wiki Wang:
> ---
> libavcodec/cuvid.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> index 218be8495d..0b1710bd46 100644
> --- a/libavcodec/cuvid.c
> +++ b/libavcodec/cuvid.c
> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
> return;
> }
>
> -if (ctx->cudecoder) {
> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
> -ctx->cudecoder = NULL;
> -}
> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>
> -if (ctx->cuparser) {
> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
> -ctx->cuparser = NULL;
> -}
> -
> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(&ctx->cuparser,
> &ctx->cuparseinfo));
> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, &seq_pkt));
> if (ret < 0)
> goto error;
>
> +seq_pkt.flags = 0;
> seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
> seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>
>
I'm not exactly sure what was the issue for this to be done this way,
but I remember there being some issue with just flushing the decoder,
hence the re-creation.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: jni no longer requires -ldl
On Sat, May 13, 2017 at 05:26:13PM +0200, Matthieu Bouron wrote:
> On Fri, May 12, 2017 at 12:14:20PM -0700, Aaron Levinson wrote:
> > On 5/12/2017 11:34 AM, Aman Gupta wrote:
> > > From: Aman Gupta
> > >
> > > this dependency was removed in 33d69a90085d30af8a292d9364b835a26565d6b9
> > > ---
> > > configure | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index 5ae5227868..ba33241a45 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -5766,8 +5766,7 @@ enabled decklink && { { check_header
> > > DeckLinkAPI.h || die "ERROR: DeckL
> > > enabled frei0r&& { check_header frei0r.h || die "ERROR:
> > > frei0r.h header not found"; }
> > > enabled gmp && require gmp gmp.h mpz_export -lgmp
> > > enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h
> > > gnutls_global_init
> > > -enabled jni && { [ $target_os = "android" ] &&
> > > check_header jni.h && enabled pthreads &&
> > > - check_lib jni "dlfcn.h" dlopen -ldl ||
> > > die "ERROR: jni not found"; }
> > > +enabled jni && { [ $target_os = "android" ] &&
> > > check_header jni.h && enabled pthreads || die "ERROR: jni not found"; }
> > > enabled ladspa&& { check_header ladspa.h || die "ERROR:
> > > ladspa.h header not found"; }
> > > enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
> > > iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
> > > enabled libass&& require_pkg_config libass ass/ass.h
> > > ass_library_init
> > >
> >
> > LGTM--I see that the use of dl was eliminated in 33d69a9 (at
> > https://github.com/FFmpeg/FFmpeg/commit/33d69a90085d30af8a292d9364b835a26565d6b9
> > ).
>
> LGTM too.
Patch applied.
Thanks,
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Do not abort process in case of bitrate deficit
On 12 May 2017 at 00:33, Даниил Чередник wrote: > Hi. > > This patch removes assert which can cause abort process in case of limited > bitrate: > > Old behaviour - abort if at least one subband has 1bit quantizer > and consumed_bits still greater than frame_bits size. It was > a bit strange - we still could reduce bits consumption by reducing > SNR for other subbands. Same strange logic with upper threshold - > stop bits allocation if at least one subband reach 26bits. > > New behaviour - if consumed_bits greater than frame_bits and all > subbands has 1 bit quantizer we restart bits allocation and allow > zero subbands. > > -- > Daniil Cherednik > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Hi, sorry for the delay. Tested the patch and it did help reduce the minimum bitrate a little, though I suppose it helps quality more. Thanks, patch applied! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFMpeg GPL license Violations by Android apps
2017-05-15 17:24 GMT+02:00 riya khanna : > Please find the list of apps here: > https://docs.google.com/spreadsheets/d/1YnBHbsYIyGxQbjpaIbU4LFjha3hx83ciKLk7htVjpT4/edit?usp=sharing As said, I believe it may be useful if you send this list - as plain text - to this mailing list. Please avoid top-posting here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc: add codec ID and description for SVG
On 8 May 2017 at 05:46, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 35df4f6ced..4bbe5179b4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -445,6 +445,7 @@ enum AVCodecID {
> AV_CODEC_ID_BITPACKED,
> AV_CODEC_ID_MSCC,
> AV_CODEC_ID_SRGC,
> +AV_CODEC_ID_SVG,
>
> /* various PCM "codecs" */
> AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 2d28f840af..8fb157cc5f 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -170,6 +170,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .props = AV_CODEC_PROP_LOSSY,
> },
> {
> +.id= AV_CODEC_ID_SVG,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "svq",
> +.long_name = NULL_IF_CONFIG_SMALL("Scalable Vector Graphics"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +.mime_types= MT("image/svg+xml"),
> +},
> +{
> .id= AV_CODEC_ID_SVQ1,
> .type = AVMEDIA_TYPE_VIDEO,
> .name = "svq1",
> --
> 2.13.0.rc1.294.g07d810a77f
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavc: add a librsvg rasterization library wrapper
On 8 May 2017 at 05:46, Rostislav Pehlivanov wrote:
> Enables rendering of SVG images. This is possible since SVG images
> still contain and specify the dimensions in pixels to which they've
> been drawn to and thus enable browsers to display them without any
> external data. Users can still override and generate images with
> arbitrary resolutions.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> configure | 4 ++
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/librsvgdec.c | 127 ++
> ++
> 4 files changed, 133 insertions(+)
> create mode 100644 libavcodec/librsvgdec.c
>
> diff --git a/configure b/configure
> index 2e1786a6fc..4f20d177a5 100755
> --- a/configure
> +++ b/configure
> @@ -245,6 +245,7 @@ External library support:
>--enable-libopenmpt enable decoding tracked files via libopenmpt
> [no]
>--enable-libopus enable Opus de/encoding via libopus [no]
>--enable-libpulseenable Pulseaudio input via libpulse [no]
> + --enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband enable rubberband needed for rubberband filter
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
>--enable-libschroedinger enable Dirac de/encoding via libschroedinger
> [no]
> @@ -1557,6 +1558,7 @@ EXTERNAL_LIBRARY_LIST="
> libopenmpt
> libopus
> libpulse
> +librsvg
> librtmp
> libschroedinger
> libshine
> @@ -2867,6 +2869,7 @@ libopenmpt_demuxer_deps="libopenmpt"
> libopus_decoder_deps="libopus"
> libopus_encoder_deps="libopus"
> libopus_encoder_select="audio_frame_queue"
> +librsvg_decoder_deps="librsvg"
> libschroedinger_decoder_deps="libschroedinger"
> libschroedinger_encoder_deps="libschroedinger"
> libshine_encoder_deps="libshine"
> @@ -5819,6 +5822,7 @@ enabled libopus && {
> }
> }
> enabled libpulse && require_pkg_config libpulse
> pulse/pulseaudio.h pa_context_new
> +enabled librsvg && require_pkg_config librsvg-2.0
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
> enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
> RTMP_Socket
> enabled librubberband && require_pkg_config "rubberband >= 1.8.1"
> rubberband/rubberband-c.h rubberband_new
> enabled libschroedinger && require_pkg_config schroedinger-1.0
> schroedinger/schro.h schro_init
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b5c8cc1f98..5829063ee8 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -550,6 +550,7 @@ OBJS-$(CONFIG_SUBVIEWER1_DECODER) += textdec.o
> ass.o
> OBJS-$(CONFIG_SUBVIEWER_DECODER) += subviewerdec.o ass.o
> OBJS-$(CONFIG_SUNRAST_DECODER) += sunrast.o
> OBJS-$(CONFIG_SUNRAST_ENCODER) += sunrastenc.o
> +OBJS-$(CONFIG_LIBRSVG_DECODER) += librsvgdec.o
> OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o svq1.o svq13.o
> h263data.o
> OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o h263data.o \
>h263.o ituh263enc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 7fcc26f2c1..425a32c924 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -319,6 +319,7 @@ static void register_all(void)
> REGISTER_DECODER(SPEEDHQ, speedhq);
> REGISTER_DECODER(SRGC, srgc);
> REGISTER_ENCDEC (SUNRAST, sunrast);
> +REGISTER_DECODER(LIBRSVG, librsvg);
> REGISTER_ENCDEC (SVQ1, svq1);
> REGISTER_DECODER(SVQ3, svq3);
> REGISTER_ENCDEC (TARGA, targa);
> diff --git a/libavcodec/librsvgdec.c b/libavcodec/librsvgdec.c
> new file mode 100644
> index 00..29b771c5a3
> --- /dev/null
> +++ b/libavcodec/librsvgdec.c
> @@ -0,0 +1,127 @@
> +/*
> + * Librsvg rasterization wrapper
> + * Copyright (c) 2017 Rostislav Pehlivanov
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "libavutil/opt.h"
> +#include "librsvg-2.0/librsvg/rsvg.h"
> +
> +typedef struct LibRSVGContext {
> +
Re: [FFmpeg-devel] [PATCH]Two patches from github
2017-05-15 12:53 GMT+02:00 wm4 : > On Mon, 15 May 2017 12:40:23 +0200 > Carl Eugen Hoyos wrote: > >> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001 >> From: Steve Kondik >> Date: Tue, 16 Dec 2014 01:37:57 -0800 >> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF >> >> * On most Android devices, CPUs can appear and disappear due to hotplug >>or CPU cluster management. Use the total number of CPUs instead so >>that multithreaded decoding is properly optimized. > > This explanation isn't really sufficient. Please suggest a better one assuming you are objecting pushing as-is. > Also not why you would want > this, or why you would want this only on Android. The explanation sounded to me as if this would be Android-only. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
On 8 May 2017 at 05:46, Rostislav Pehlivanov wrote:
> Only checks the extension and MIME type, since determining whether
> a file is SVG is difficult since they're just XML files.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/img2dec.c| 20
> 3 files changed, 22 insertions(+)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 4e169fdce5..bfba0c1cb4 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -237,6 +237,7 @@ OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) +=
> img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_PSD_PIPE_DEMUXER) += img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER) += img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_SVG_PIPE_DEMUXER) += img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
> OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 09e62c3cfc..62661d14a4 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -369,6 +369,7 @@ static void register_all(void)
> REGISTER_DEMUXER (IMAGE_PSD_PIPE,image_psd_pipe);
> REGISTER_DEMUXER (IMAGE_QDRAW_PIPE, image_qdraw_pipe);
> REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
> +REGISTER_DEMUXER (IMAGE_SVG_PIPE,image_svg_pipe);
> REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
> REGISTER_DEMUXER (IMAGE_TIFF_PIPE, image_tiff_pipe);
> REGISTER_DEMUXER (IMAGE_WEBP_PIPE, image_webp_pipe);
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index b454071168..1d532e9343 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -971,6 +971,26 @@ AVInputFormat ff_image_ ## imgname ## _pipe_demuxer =
> {\
> .raw_codec_id = codecid,\
> };
>
> +static const AVClass svg_class = {
> +.class_name = "svg demuxer",
> +.item_name = av_default_item_name,
> +.option = ff_img_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVInputFormat ff_image_svg_pipe_demuxer = {
> +.name = "svg_pipe",
> +.long_name = NULL_IF_CONFIG_SMALL("piped svg sequence"),
> +.priv_data_size = sizeof(VideoDemuxData),
> +.read_header= ff_img_read_header,
> +.read_packet= ff_img_read_packet,
> +.priv_class = &svg_class,
> +.mime_type = "image/svg+xml",
> +.extensions = "svg,svgz",
> +.flags = AVFMT_GENERIC_INDEX,
> +.raw_codec_id = AV_CODEC_ID_SVG,
> +};
> +
> IMAGEAUTO_DEMUXER(bmp, AV_CODEC_ID_BMP)
> IMAGEAUTO_DEMUXER(dds, AV_CODEC_ID_DDS)
> IMAGEAUTO_DEMUXER(dpx, AV_CODEC_ID_DPX)
> --
> 2.13.0.rc1.294.g07d810a77f
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : > Only checks the extension and MIME type, since determining whether > a file is SVG is difficult since they're just XML files. Why didn't you just add svg and svgz to the image2 extensions? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: No longer improperly freeing IDirect3DSurface9 objects
Purpose: No longer improperly freeing IDirect3DSurface9 objects in
hwcontext_dxva2.c. Added dxva2_pool_release_dummy() and using it in
call to av_buffer_create() in dxva2_pool_alloc(). Prior to this
change, av_buffer_create() was called with NULL for the third
argument, which indicates that av_buffer_default_free() should be used
to free the buffer's data. Eventually, it gets to buffer_pool_free()
and calls buf->free() on a surface object (which is
av_buffer_default_free()). This can result in a crash when the debug
version of the C-runtime is used on Windows. While it doesn't appear
to result in a crash when the release version of the C-runtime is used
on Windows, it likely results in memory corruption, since av_free() is
being called on memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson
---
libavutil/hwcontext_dxva2.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
}
}
+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
{
AVHWFramesContext *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
if (s->nb_surfaces_used < hwctx->nb_surfaces) {
s->nb_surfaces_used++;
return
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces),
dxva2_pool_release_dummy, 0, 0);
}
return NULL;
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Added line to the af_bs2b filter docs mentioning --enable-libbs2b
On 5/16/17, Leo Izen wrote:
> ---
> doc/filters.texi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 9611a41e28..a7c6063969 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1911,6 +1911,9 @@ available are filtered.
> Bauer stereo to binaural transformation, which improves headphone listening
> of
> stereo audio records.
>
> +To enable compilation of this filter you need to configure FFmpeg with
> +@code{--enable-libbs2b}.
> +
> It accepts the following parameters:
> @table @option
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: use -x instead of -wN ..@ to strip assembly files
Reduces the amount of debugging information of external asm from uselessly verbose to informative enough. --- configure | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configure b/configure index e4862f6a35..df849df14f 100755 --- a/configure +++ b/configure @@ -6185,8 +6185,7 @@ enabled rpath && add_ldlibflags -Wl,-rpath,$libdir test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic # add some strip flags -# -wN '..@*' is more selective than -x, but not available everywhere. -check_stripflags -wN \'..@*\' || check_stripflags -x +check_stripflags -x enabled neon_clobber_test && check_ldflags -Wl,--wrap,avcodec_open2 \ -- 2.13.0.303.g4ebf302169 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Two patches from github
On Tue, 16 May 2017 12:40:03 +0200 Carl Eugen Hoyos wrote: > 2017-05-15 12:53 GMT+02:00 wm4 : > > On Mon, 15 May 2017 12:40:23 +0200 > > Carl Eugen Hoyos wrote: > > > >> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001 > >> From: Steve Kondik > >> Date: Tue, 16 Dec 2014 01:37:57 -0800 > >> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF > >> > >> * On most Android devices, CPUs can appear and disappear due to hotplug > >>or CPU cluster management. Use the total number of CPUs instead so > >>that multithreaded decoding is properly optimized. > > > > This explanation isn't really sufficient. > > Please suggest a better one assuming you are objecting pushing as-is. Yes, I'm objecting. I don't have to suggest a better one - you're the one who wants to push this. > > Also not why you would want > > this, or why you would want this only on Android. > > The explanation sounded to me as if this would be Android-only. The explanation is completely insufficient. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
On 16 May 2017 at 11:57, Carl Eugen Hoyos wrote: > 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : > > Only checks the extension and MIME type, since determining whether > > a file is SVG is difficult since they're just XML files. > > Why didn't you just add svg and svgz to the image2 extensions? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > image2 doesn't use extensions, it probes. Hence why I couldn't use the macro, since it doesn't actually make lavf check the extension and probing svg is difficult (and librsvg doesn't offer support for probing). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov : > On 16 May 2017 at 11:57, Carl Eugen Hoyos wrote: > >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : >> > Only checks the extension and MIME type, since determining whether >> > a file is SVG is difficult since they're just XML files. >> >> Why didn't you just add svg and svgz to the image2 extensions? > image2 doesn't use extensions, it probes. The image2 demuxer only "probes" by looking at extensions. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
On 16 May 2017 at 12:34, Carl Eugen Hoyos wrote: > 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov : > > On 16 May 2017 at 11:57, Carl Eugen Hoyos wrote: > > > >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : > >> > Only checks the extension and MIME type, since determining whether > >> > a file is SVG is difficult since they're just XML files. > >> > >> Why didn't you just add svg and svgz to the image2 extensions? > > > image2 doesn't use extensions, it probes. > > The image2 demuxer only "probes" by looking at extensions. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I see what you mean now, pushed a patch to use the same way of probing as the rest of img2dec. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: No longer improperly freeing IDirect3DSurface9 objects
Please disregard--I will submit a new patch with a better commit message.
Aaron
On 5/16/2017 4:09 AM, Aaron Levinson wrote:
Purpose: No longer improperly freeing IDirect3DSurface9 objects in
hwcontext_dxva2.c. Added dxva2_pool_release_dummy() and using it in
call to av_buffer_create() in dxva2_pool_alloc(). Prior to this
change, av_buffer_create() was called with NULL for the third
argument, which indicates that av_buffer_default_free() should be used
to free the buffer's data. Eventually, it gets to buffer_pool_free()
and calls buf->free() on a surface object (which is
av_buffer_default_free()). This can result in a crash when the debug
version of the C-runtime is used on Windows. While it doesn't appear
to result in a crash when the release version of the C-runtime is used
on Windows, it likely results in memory corruption, since av_free() is
being called on memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson
---
libavutil/hwcontext_dxva2.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
}
}
+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
{
AVHWFramesContext *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
if (s->nb_surfaces_used < hwctx->nb_surfaces) {
s->nb_surfaces_used++;
return
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces),
dxva2_pool_release_dummy, 0, 0);
}
return NULL;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().
Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data. Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).
This can result in a crash when the debug version of the C-runtime is
used on Windows. While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson
---
libavutil/hwcontext_dxva2.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 4ed0d56..6c41788 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
}
}
+static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
+{
+// important not to free anything here--data is a surface object
+// associated with the call to CreateSurface(), and these surfaces are
+// released in dxva2_frames_uninit()
+}
+
static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
{
AVHWFramesContext *ctx = (AVHWFramesContext*)opaque;
@@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
if (s->nb_surfaces_used < hwctx->nb_surfaces) {
s->nb_surfaces_used++;
return
av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
-sizeof(*hwctx->surfaces), NULL, 0, 0);
+sizeof(*hwctx->surfaces),
dxva2_pool_release_dummy, 0, 0);
}
return NULL;
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Two patches from github
Hi, On 15/05/2017 12:40, Carl Eugen Hoyos wrote: > > 0002-avutil-Use-_SC_NPROCESSORS_CONF.patch > > > From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001 > From: Steve Kondik > Date: Tue, 16 Dec 2014 01:37:57 -0800 > Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF > > * On most Android devices, CPUs can appear and disappear due to hotplug >or CPU cluster management. Use the total number of CPUs instead so >that multithreaded decoding is properly optimized. I'm not convinced the patch below fixes the issue described above. The idea is to optimize the number of threads given the number of usable CPUs. If a user of libav* wants to make sure they use the right number, they should make sure that the CPUs are woken up prior to calling this. There are ways to force the system's power management to make sure that the number of online CPUs is maximized, and, IMHO, that should be used instead of returning the total number of CPUs on the platform. > Change-Id: I1cbf000a1bda7b3abf0a84e971e752f176857385 > --- > libavutil/cpu.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavutil/cpu.c b/libavutil/cpu.c > index 16e0c92..ab0965b 100644 > --- a/libavutil/cpu.c > +++ b/libavutil/cpu.c > @@ -282,6 +282,8 @@ int av_cpu_count(void) > > if (sysctl(mib, 2, &nb_cpus, &len, NULL, 0) == -1) > nb_cpus = 0; > +#elif defined(__ANDROID__) && HAVE_SYSCONF && defined(_SC_NPROCESSORS_CONF) > +nb_cpus = sysconf(_SC_NPROCESSORS_CONF); > #elif HAVE_SYSCONF && defined(_SC_NPROC_ONLN) > nb_cpus = sysconf(_SC_NPROC_ONLN); > #elif HAVE_SYSCONF && defined(_SC_NPROCESSORS_ONLN) > -- 1.7.10.4 -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing
2017-05-16 13:48 GMT+02:00 Rostislav Pehlivanov : > On 16 May 2017 at 12:34, Carl Eugen Hoyos wrote: > >> 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov : >> > On 16 May 2017 at 11:57, Carl Eugen Hoyos wrote: >> > >> >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : >> >> > Only checks the extension and MIME type, since determining whether >> >> > a file is SVG is difficult since they're just XML files. >> >> >> >> Why didn't you just add svg and svgz to the image2 extensions? >> >> > image2 doesn't use extensions, it probes. >> >> The image2 demuxer only "probes" by looking at extensions. > I see what you mean now, pushed a patch to use the same way of > probing as the rest of img2dec. What I meant was: "Why didn't you add svg to the file libavformat/img2.c?" Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
On Tue, 16 May 2017 05:04:36 -0700
Aaron Levinson wrote:
> Add dxva2_pool_release_dummy() and use it in call to
> av_buffer_create() in dxva2_pool_alloc().
>
> Prior to this change, av_buffer_create() was called with NULL for the
> third argument, which indicates that av_buffer_default_free() should
> be used to free the buffer's data. Eventually, it gets to
> buffer_pool_free() and calls buf->free() on a surface object (which is
> av_buffer_default_free()).
>
> This can result in a crash when the debug version of the C-runtime is
> used on Windows. While it doesn't appear to result in a crash when
> the release version of the C-runtime is used on Windows, it likely
> results in memory corruption, since av_free() is being called on
> memory that was allocated using
> IDirectXVideoAccelerationService::CreateSurface().
>
> Signed-off-by: Aaron Levinson
> ---
> libavutil/hwcontext_dxva2.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
> index 4ed0d56..6c41788 100644
> --- a/libavutil/hwcontext_dxva2.c
> +++ b/libavutil/hwcontext_dxva2.c
> @@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext *ctx)
> }
> }
>
> +static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
> +{
> +// important not to free anything here--data is a surface object
> +// associated with the call to CreateSurface(), and these surfaces are
> +// released in dxva2_frames_uninit()
> +}
> +
> static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
> {
> AVHWFramesContext *ctx = (AVHWFramesContext*)opaque;
> @@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, int
> size)
> if (s->nb_surfaces_used < hwctx->nb_surfaces) {
> s->nb_surfaces_used++;
> return
> av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used - 1],
> -sizeof(*hwctx->surfaces), NULL, 0, 0);
> +sizeof(*hwctx->surfaces),
> dxva2_pool_release_dummy, 0, 0);
> }
>
> return NULL;
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFMpeg GPL license Violations by Android apps
2017-05-16 18:32 GMT+08:00 Carl Eugen Hoyos : > 2017-05-15 17:24 GMT+02:00 riya khanna : > > Please find the list of apps here: > > https://docs.google.com/spreadsheets/d/1YnBHbsYIyGxQbjpaIbU4LFjha3hx8 > 3ciKLk7htVjpT4/edit?usp=sharing > > As said, I believe it may be useful if you send this list - as plain text > - to > this mailing list. > > Please avoid top-posting here, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > if merge similar infomation maybe better Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
2017-05-16 20:23 GMT+08:00 wm4 :
> On Tue, 16 May 2017 05:04:36 -0700
> Aaron Levinson wrote:
>
> > Add dxva2_pool_release_dummy() and use it in call to
> > av_buffer_create() in dxva2_pool_alloc().
> >
> > Prior to this change, av_buffer_create() was called with NULL for the
> > third argument, which indicates that av_buffer_default_free() should
> > be used to free the buffer's data. Eventually, it gets to
> > buffer_pool_free() and calls buf->free() on a surface object (which is
> > av_buffer_default_free()).
> >
> > This can result in a crash when the debug version of the C-runtime is
> > used on Windows. While it doesn't appear to result in a crash when
> > the release version of the C-runtime is used on Windows, it likely
> > results in memory corruption, since av_free() is being called on
> > memory that was allocated using
> > IDirectXVideoAccelerationService::CreateSurface().
> >
> > Signed-off-by: Aaron Levinson
> > ---
> > libavutil/hwcontext_dxva2.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
> > index 4ed0d56..6c41788 100644
> > --- a/libavutil/hwcontext_dxva2.c
> > +++ b/libavutil/hwcontext_dxva2.c
> > @@ -121,6 +121,13 @@ static void dxva2_frames_uninit(AVHWFramesContext
> *ctx)
> > }
> > }
> >
> > +static void dxva2_pool_release_dummy(void *opaque, uint8_t *data)
> > +{
> > +// important not to free anything here--data is a surface object
> > +// associated with the call to CreateSurface(), and these surfaces
> are
> > +// released in dxva2_frames_uninit()
> > +}
> > +
> > static AVBufferRef *dxva2_pool_alloc(void *opaque, int size)
> > {
> > AVHWFramesContext *ctx = (AVHWFramesContext*)opaque;
> > @@ -130,7 +137,7 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque,
> int size)
> > if (s->nb_surfaces_used < hwctx->nb_surfaces) {
> > s->nb_surfaces_used++;
> > return
> > av_buffer_create((uint8_t*)s->surfaces_internal[s->nb_surfaces_used
> - 1],
> > -sizeof(*hwctx->surfaces), NULL, 0, 0);
> > +sizeof(*hwctx->surfaces),
> dxva2_pool_release_dummy, 0, 0);
> > }
> >
> > return NULL;
>
> LGTM
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] 回覆: [PATCH 2/3] img2dec: .z, for piped SVG demuxing
Pz BE MpR 從我的 HTC 寄出PC - 回覆訊息 - 寄件者： "Carl Eugen Hoyos" 收件者： "FFmpeg development discussions and patches" 主旨： [FFmpeg-devel] [PATCH 2/3] img2dec: add support for piped SVG demuxing 日期： 週二, 5月 16 日, 2017 年 8:09 下午 2017-05-16 13:48 GMT+02:00 Rostislav Pehlivanov : > On 16 May 2017 at 12:34, Carl Eugen Hoyos wrote: > >> 2017-05-16 13:25 GMT+02:00 Rostislav Pehlivanov : >> > On 16 May 2017 at 11:57, Carl Eugen Hoyos wrote: >> > >> >> 2017-05-08 6:46 GMT+02:00 Rostislav Pehlivanov : >> >> > Only checks the extension and MIME type, since determining whether >> >> > a file is SVG is difficult since they're just XML files. >> >> >> >> Why didn't you just add svg and svgz to the image2 extensions? >> >> > image2 doesn't use extensions, it probes. >> >> The image2 demuxer only "probes" by looking at extensions. > I see what you mean now, pushed a patch to use the same way of > probing as the rest of img2dec. What I meant was: "Why didn't you add svg to the file libavformat/img2.c?" Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.
On May 16, 2017, at 01:32, Timo Rothenpieler wrote:
>
>> Am 16.05.2017 um 10:27 schrieb Wiki Wang:
>> ---
>> libavcodec/cuvid.c | 13 +++--
>> 1 file changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
>> index 218be8495d..0b1710bd46 100644
>> --- a/libavcodec/cuvid.c
>> +++ b/libavcodec/cuvid.c
>> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
>> return;
>> }
>>
>> -if (ctx->cudecoder) {
>> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
>> -ctx->cudecoder = NULL;
>> -}
>> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>>
>> -if (ctx->cuparser) {
>> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
>> -ctx->cuparser = NULL;
>> -}
>> -
>> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(&ctx->cuparser,
>> &ctx->cuparseinfo));
>> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser, &seq_pkt));
>> if (ret < 0)
>> goto error;
>>
>> +seq_pkt.flags = 0;
>> seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
>> seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>>
>>
>
> I'm not exactly sure what was the issue for this to be done this way,
> but I remember there being some issue with just flushing the decoder,
> hence the re-creation.
>
The issue is that when flushing for a media player, you need to drop all
frames in the pipeline too. Inserting EOS means you still have n frames
that will come out after the flush which breaks interactive seeking.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Added line to the af_bs2b filter docs mentioning --enable-libbs2b
On Tue, May 16, 2017 at 01:12:30PM +0200, Paul B Mahol wrote:
> On 5/16/17, Leo Izen wrote:
> > ---
> > doc/filters.texi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 9611a41e28..a7c6063969 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -1911,6 +1911,9 @@ available are filtered.
> > Bauer stereo to binaural transformation, which improves headphone listening
> > of
> > stereo audio records.
> >
> > +To enable compilation of this filter you need to configure FFmpeg with
> > +@code{--enable-libbs2b}.
> > +
> > It accepts the following parameters:
> > @table @option
> >
>
> lgtm
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/scpr: mask bits to prevent out of array read
On Tue, May 16, 2017 at 07:57:45AM +0200, Paul B Mahol wrote: > On 5/16/17, Michael Niedermayer wrote: > > Fixes: 1615/clusterfuzz-testcase-minimized-6625214647500800 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/scpr.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > lgtm applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cuvid: Use a dummy packet to flush cuvid.
On Tue, May 16, 2017 at 3:41 PM, Philip Langdale wrote:
> On May 16, 2017, at 01:32, Timo Rothenpieler wrote:
>>
>>> Am 16.05.2017 um 10:27 schrieb Wiki Wang:
>>> ---
>>> libavcodec/cuvid.c | 13 +++--
>>> 1 file changed, 3 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
>>> index 218be8495d..0b1710bd46 100644
>>> --- a/libavcodec/cuvid.c
>>> +++ b/libavcodec/cuvid.c
>>> @@ -1029,20 +1029,13 @@ static void cuvid_flush(AVCodecContext *avctx)
>>> return;
>>> }
>>>
>>> -if (ctx->cudecoder) {
>>> -ctx->cvdl->cuvidDestroyDecoder(ctx->cudecoder);
>>> -ctx->cudecoder = NULL;
>>> -}
>>> +seq_pkt.flags = CUVID_PKT_ENDOFSTREAM;
>>>
>>> -if (ctx->cuparser) {
>>> -ctx->cvdl->cuvidDestroyVideoParser(ctx->cuparser);
>>> -ctx->cuparser = NULL;
>>> -}
>>> -
>>> -ret = CHECK_CU(ctx->cvdl->cuvidCreateVideoParser(&ctx->cuparser,
>>> &ctx->cuparseinfo));
>>> +ret = CHECK_CU(ctx->cvdl->cuvidParseVideoData(ctx->cuparser,
>>> &seq_pkt));
>>> if (ret < 0)
>>> goto error;
>>>
>>> +seq_pkt.flags = 0;
>>> seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
>>> seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
>>>
>>>
>>
>> I'm not exactly sure what was the issue for this to be done this way,
>> but I remember there being some issue with just flushing the decoder,
>> hence the re-creation.
>>
> The issue is that when flushing for a media player, you need to drop all
> frames in the pipeline too. Inserting EOS means you still have n frames
> that will come out after the flush which breaks interactive seeking.
>
Indeed, flush should be an actual flush - discard all data and start fresh.
It should use the dummy packet "flush" at EOF, we call that operation
"draining" here, the decoder gets called with an empty packet in that
case (if it sets the delay flag, anyway).
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Disable MSA optimization for big endian arch
On Mon, Apr 24, 2017 at 05:33:22PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > Signed-off-by: Shivraj Patil > --- > configure |4 > 1 file changed, 4 insertions(+) > > diff --git a/configure b/configure > index 1e3463c..c63a48a 100755 > --- a/configure > +++ b/configure > @@ -5357,6 +5357,10 @@ elif enabled mips; then > enabled mipsdsp && check_inline_asm_flags mipsdsp '"addu.qb $t0, $t1, > $t2"' '-mdsp' > enabled mipsdspr2 && check_inline_asm_flags mipsdspr2 '"absq_s.qb $t0, > $t1"' '-mdspr2' > > +if enabled bigendian && enabled msa; then > +disable msa > +fi the order of this looks a bit odd for example there is above: enabled mipsfpu && enabled msa && check_inline_asm_flags msa '"addvi.b $w0, $w1, 1"' '-mmsa' && check_header msa.h || disable msa I think this would add -mmsa to the flags or disable msa already with the code you add msa is disabled but -mmsa is left in the flags Please correct me if iam wrong. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer
No problem. I'll resubmit the patch request. On Mon, May 15, 2017 at 9:47 PM wm4 wrote: > On Mon, 15 May 2017 17:55:28 + > Rob Meyers wrote: > > > Of course. > > > > We noticed when reading data from a named pipe the first 10 bytes would > get > > dropped. I traced this to the affected code in fill_buffer(). The > > assignment of "dst" was always set to the beginning of the buffer, and if > > it hadn't been consumed yet the data would be overwritten. We could > > reproduce this by setting up a server that writes to the named pipe in > two > > small (6 byte) messages with a 1 second gap between. Without the gap, or > if > > the data is sent as one message, there's no problem. It's in the > > accumulation of data between messages to fulfill a read that this bug is > > triggered. > > Well, that explanation should be in the commit message (with a short 70 > char summary as subject line). Not just "fixed $thing". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer
On Mon, May 15, 2017 at 05:55:28PM +, Rob Meyers wrote: > Of course. > > We noticed when reading data from a named pipe the first 10 bytes would get > dropped. from were are bytes droped ? this is the internal buffer, not something a user should touch directly. > I traced this to the affected code in fill_buffer(). The > assignment of "dst" was always set to the beginning of the buffer, and if The buffer pointer resets to the start if there is not enough space available to hold another packet. with your patch it resets either always or when the buffer is filled to the last byte randomly truncating a read. If the read function is incapable to fullfill the partial packet read that will not work out i think But i may be missing something of course > it hadn't been consumed yet the data would be overwritten. We could > reproduce this by setting up a server that writes to the named pipe in two > small (6 byte) messages with a 1 second gap between. Without the gap, or if > the data is sent as one message, there's no problem. It's in the > accumulation of data between messages to fulfill a read that this bug is > triggered. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat: data loss in message accumulation in fill_buffer()
We noticed when reading data from a named pipe the first 10 bytes
would get dropped. I traced this to the affected code in
fill_buffer(). The assignment of "dst" was always set to the beginning
of the buffer, and if it hadn't been consumed yet the data would be
overwritten. We could reproduce this by setting up a server that
writes to the named pipe in two small (6 byte) messages with a 1
second gap between. Without the gap, or if the data is sent as one
message, there's no problem. It's in the accumulation of data between
messages to fulfill a read that this bug is triggered.
---
libavformat/aviobuf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 0a7c39eacd..4e04cb79e0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum
AVIODataMarkerType typ
static void fill_buffer(AVIOContext *s)
{
-int max_buffer_size = s->max_packet_size ?
- s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size <
s->buffer_size ?
+uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer <
s->buffer_size ?
s->buf_end : s->buffer;
int len = s->buffer_size - (dst - s->buffer);
--
2.13.0.rc2.291.g57267f2277-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer
Here's a simple server we used to reproduce the problem:
#include
#include
#include
#include
#include
#define INGOING "/tmp/audio.fifo"
ssize_t write_fifo(int fd, char* msg, int size) {
ssize_t write_rc;
write_rc = write(fd, msg, size);
printf("msg '%s' write_rc = %ld\n", msg, write_rc);
if (write_rc != size) {
perror("write sent fewer bytes than expected");
}
if (write_rc == -1) {
perror("write error");
}
return write_rc;
}
int main(int argc, char *argv[]) {
mkfifo(INGOING, 0666);
printf("Welcome to server.\n");
printf("channel for reading messages to server is %s\n", INGOING);
int in_fd = open(INGOING, O_WRONLY);
if (in_fd == -1) {
perror("open error");
return 1;
}
int argi = 1;
while (argi < argc) {
char *msg = argv[argi];
int len = strlen(msg);
++argi;
write_fifo(in_fd, msg, len);
sleep(1);
}
return 0;
}
--
The command line arguments are sent as individual messages. To demonstrate
the problem I run with "abcdef ghijkl" as the args. This sends two 6 byte
messages with a short gap between.
I run ffmpeg like so:
ffmpeg -ar 1000 -ac 1 -acodec pcm_s16le -f s16le -probesize 500 -i
/tmp/audio.fifo -map_metadata -1 -vn -ac:a:0 1 -ar:a:0 1000 -codec:a:0
pcm_s16le -sn -f s16le -y -
Without my patch, you won't see all 12 bytes output, just "kl". My patch
fixes this.
The buffer is in AVIOContext. The problem with the original code was that
max_buffer_size is added to the request, to see if it's larger than another
value that is also max_buffer_size. Like, "if (A + B) < B".
On Tue, May 16, 2017 at 9:06 AM Michael Niedermayer
wrote:
> On Mon, May 15, 2017 at 05:55:28PM +, Rob Meyers wrote:
> > Of course.
> >
> > We noticed when reading data from a named pipe the first 10 bytes would
> get
> > dropped.
>
> from were are bytes droped ?
> this is the internal buffer, not something a user should touch
> directly.
>
>
> > I traced this to the affected code in fill_buffer(). The
> > assignment of "dst" was always set to the beginning of the buffer, and if
>
> The buffer pointer resets to the start if there is not enough space
> available to hold another packet.
> with your patch it resets either always or when the buffer is filled
> to the last byte randomly truncating a read.
> If the read function is incapable to fullfill the partial packet read
> that will not work out i think
> But i may be missing something of course
>
>
>
> > it hadn't been consumed yet the data would be overwritten. We could
> > reproduce this by setting up a server that writes to the named pipe in
> two
> > small (6 byte) messages with a 1 second gap between. Without the gap, or
> if
> > the data is sent as one message, there's no problem. It's in the
> > accumulation of data between messages to fulfill a read that this bug is
> > triggered.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] License consent (cinepakenc.c)
Hi I got a question from Diego via IRC about what license cinepakenc.c actually has, since the first commit message just has a message by"Rl" saying that I said it was OK but with no appropriately signed message from me. So I'm posting this just to clarify things: I consent to the original license placed on cinepakenc.c on Wed Jan 22 11:12:11 2014 +0100 (commit 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d). Just for fun I gave the encoder a try, and the output plays just fine on Windows 3.1 in dosbox-x :) My e-mail address changed a while back since I've changed employer, so MAINTAINERS should be updated to point to this one. I also don't work with MXF any longer, so a new maintainer may be needed for that /Tomas signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] License consent (cinepakenc.c)
On 5/16/2017 3:13 PM, Tomas Härdin wrote: > Hi > > I got a question from Diego via IRC about what license cinepakenc.c > actually has, since the first commit message just has a message by"Rl" > saying that I said it was OK but with no appropriately signed message > from me. So I'm posting this just to clarify things: > > I consent to the original license placed on cinepakenc.c on Wed Jan 22 > 11:12:11 2014 +0100 (commit 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d). > > Just for fun I gave the encoder a try, and the output plays just fine > on Windows 3.1 in dosbox-x :) Nice, i guess :p > > My e-mail address changed a while back since I've changed employer, so > MAINTAINERS should be updated to point to this one. I also don't work > with MXF any longer, so a new maintainer may be needed for that MAINTAINERS doesn't list email addresses, just GPG fingerprints, and the one listed for you matches the one you're still using today. If you have push access you can remove the mxfdec mention, otherwise i can do that for you. > > /Tomas > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: use -x instead of -wN ..@ to strip assembly files
On 2017-05-16 13:08, Rostislav Pehlivanov wrote: > Reduces the amount of debugging information of external asm from > uselessly verbose to informative enough. > --- > configure | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/configure b/configure > index e4862f6a35..df849df14f 100755 > --- a/configure > +++ b/configure > @@ -6185,8 +6185,7 @@ enabled rpath && add_ldlibflags -Wl,-rpath,$libdir > test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic > > # add some strip flags > -# -wN '..@*' is more selective than -x, but not available everywhere. > -check_stripflags -wN \'..@*\' || check_stripflags -x > +check_stripflags -x > > enabled neon_clobber_test && > check_ldflags -Wl,--wrap,avcodec_open2 \ > Look good. I'm in favour of this change. It does exactly what I was (partly) advocating for in my email on Friday. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing
---
libavcodec/h264_ps.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 7858361..09e2290 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
{
int aspect_ratio_info_present_flag;
unsigned int aspect_ratio_idc;
+int idx;
aspect_ratio_info_present_flag = get_bits1(gb);
@@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
sps->pic_struct_present_flag = get_bits1(gb);
if (!get_bits_left(gb))
return 0;
+
sps->bitstream_restriction_flag = get_bits1(gb);
if (sps->bitstream_restriction_flag) {
+idx = gb->index;
get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
get_ue_golomb(gb); /* max_bytes_per_pic_denom */
get_ue_golomb(gb); /* max_bits_per_mb_denom */
@@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
if (get_bits_left(gb) < 0) {
sps->num_reorder_frames = 0;
sps->bitstream_restriction_flag = 0;
+gb->index = idx;
}
if (sps->num_reorder_frames > 16U
--
2.10.2.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Decoding issue with AAC SBR from flv
Hi, I think to have found a regression into ffmpeg 3.x versions. When I try to play the file in attachment it gives inaudible output and a lot of errors from ffplay (see example below). I have tested it with ffmpeg 3.3.git and stable release 3.2.3 on Linux and Windows and it gives the same result. Though if I play it from ffmpeg version 2.8 the output is playing fine (but there are 2 errors in the logs). For information the file is extracted from a live stream. I think that the problem comes from the fact that the first packet is not a "key frame" or something like this so the decoder cannot handle it. My command is just : *ffplay aac_decoding_error.flv* And here are the error logs : [aac @ 0x9fb08820] channel element 0.3 is not allocated [aac @ 0x9fb08820] channel element 0.14 is not allocated [aac @ 0x9fb08820] Input buffer exhausted before END element found Last message repeated 1 times [aac @ 0x9fb08820] channel element 2.10 is not allocated [aac @ 0x9fb08820] Input buffer exhausted before END element found [aac @ 0x9fb08820] Sample rate index in program config element does not match the sample rate index configured by the container. [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element found [aac @ 0x9fb08820] Input buffer exhausted before END element found [aac @ 0x9fb08820] Sample rate index in program config element does not match the sample rate index configured by the container. [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element found [aac @ 0x9fb08820] Multiple frames in a packet. [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element found [aac @ 0x9fb08820] Input buffer exhausted before END element found [aac @ 0x9fb08820] channel element 1.12 is not allocated [aac @ 0x9fb08820] Input buffer exhausted before END element found [aac @ 0x9fb08820] channel element 3.14 is not allocated [aac @ 0x9fb08820] channel element 0.3 is not allocated [aac @ 0x9fb08820] skip_data_stream_element: Input buffer exhausted before END element found [aac @ 0x9fb08820] Input buffer exhausted before END element found [aac @ 0x9fb08820] channel element 0.7 is not allocated [aac @ 0x9fb08820] Input buffer exhausted before END element found ... Can someone help me for this problem? Regards *--* *Thomas JAMMET* aac_decoding_error.flv Description: video/flv ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing
On Tue, May 16, 2017 at 2:13 PM, Ivan Shmakov wrote:
> ---
> libavcodec/h264_ps.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 7858361..09e2290 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> {
> int aspect_ratio_info_present_flag;
> unsigned int aspect_ratio_idc;
> +int idx;
>
> aspect_ratio_info_present_flag = get_bits1(gb);
>
> @@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> sps->pic_struct_present_flag = get_bits1(gb);
> if (!get_bits_left(gb))
> return 0;
> +
> sps->bitstream_restriction_flag = get_bits1(gb);
> if (sps->bitstream_restriction_flag) {
> +idx = gb->index;
> get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
> get_ue_golomb(gb); /* max_bytes_per_pic_denom */
> get_ue_golomb(gb); /* max_bits_per_mb_denom */
> @@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> if (get_bits_left(gb) < 0) {
> sps->num_reorder_frames = 0;
> sps->bitstream_restriction_flag = 0;
> +gb->index = idx;
> }
>
> if (sps->num_reorder_frames > 16U
This doesn't seem right. What guarantees are that when one element
can't be parsed, anything else can?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] License consent (cinepakenc.c)
On Tue, 2017-05-16 at 15:42 -0300, James Almer wrote: > On 5/16/2017 3:13 PM, Tomas Härdin wrote: > > > > Hi > > > > I got a question from Diego via IRC about what license cinepakenc.c > > actually has, since the first commit message just has a message > > by"Rl" > > saying that I said it was OK but with no appropriately signed > > message > > from me. So I'm posting this just to clarify things: > > > > I consent to the original license placed on cinepakenc.c on Wed Jan > > 22 > > 11:12:11 2014 +0100 (commit > > 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d). > > > > Just for fun I gave the encoder a try, and the output plays just > > fine > > on Windows 3.1 in dosbox-x :) > Nice, i guess :p > > > > > > > My e-mail address changed a while back since I've changed employer, > > so > > MAINTAINERS should be updated to point to this one. I also don't > > work > > with MXF any longer, so a new maintainer may be needed for that > MAINTAINERS doesn't list email addresses, just GPG fingerprints, and > the > one listed for you matches the one you're still using today. > If you have push access you can remove the mxfdec mention, otherwise > i > can do that for you. Sure. I see I'm listed for lxfdec too, but I think I can still manage that. And the cinepak encoder has Rl listed so that's covered /Tomas signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat aviobuf: Fixed dst pointer initialization in fill_buffer
On Tue, May 16, 2017 at 04:17:45PM +, Rob Meyers wrote:
> Here's a simple server we used to reproduce the problem:
>
> #include
> #include
> #include
> #include
> #include
>
> #define INGOING "/tmp/audio.fifo"
>
> ssize_t write_fifo(int fd, char* msg, int size) {
> ssize_t write_rc;
>
> write_rc = write(fd, msg, size);
> printf("msg '%s' write_rc = %ld\n", msg, write_rc);
> if (write_rc != size) {
> perror("write sent fewer bytes than expected");
> }
> if (write_rc == -1) {
> perror("write error");
> }
>
> return write_rc;
> }
>
> int main(int argc, char *argv[]) {
> mkfifo(INGOING, 0666);
>
> printf("Welcome to server.\n");
> printf("channel for reading messages to server is %s\n", INGOING);
>
> int in_fd = open(INGOING, O_WRONLY);
> if (in_fd == -1) {
> perror("open error");
> return 1;
> }
>
> int argi = 1;
> while (argi < argc) {
> char *msg = argv[argi];
> int len = strlen(msg);
> ++argi;
>
> write_fifo(in_fd, msg, len);
> sleep(1);
> }
>
> return 0;
> }
>
> --
>
> The command line arguments are sent as individual messages. To demonstrate
> the problem I run with "abcdef ghijkl" as the args. This sends two 6 byte
> messages with a short gap between.
>
> I run ffmpeg like so:
> ffmpeg -ar 1000 -ac 1 -acodec pcm_s16le -f s16le -probesize 500 -i
> /tmp/audio.fifo -map_metadata -1 -vn -ac:a:0 1 -ar:a:0 1000 -codec:a:0
> pcm_s16le -sn -f s16le -y -
>
> Without my patch, you won't see all 12 bytes output, just "kl". My patch
> fixes this.
The patch makes it output all 12 bytes but this is more by luck than
by fixing the issue.
The issue is, well there are at least 2 issues
First the ff_id3v2_read_dict() Tries to read 10 bytes and failing to
find a id3 header seeks back.
This is buggy, it must call ffio_ensure_seekback() before it starts
any reading that it intends to seek back over.
the 2nd issue seems to be that fill_buffer() throws the larger
buffer ffio_ensure_seekback() created out too early.
I didnt investigate this deeply but something goes wrong there
and with ffio_ensure_seekback() and with the downallocation commented
the whole works and returns the 12 bytes
>
> The buffer is in AVIOContext. The problem with the original code was that
> max_buffer_size is added to the request, to see if it's larger than another
> value that is also max_buffer_size. Like, "if (A + B) < B".
It may be that the buffer size and the maximum packet size are often
the same. But they are not always the same, for example
ffio_ensure_seekback() makes them different
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Decoding issue with AAC SBR from flv
On 5/16/2017 11:11 AM, Thomas Jammet wrote: > Hi, > > I think to have found a regression into ffmpeg 3.x versions. > > When I try to play the file in attachment it gives inaudible output and a > lot of errors from ffplay (see example below). I have tested it with ffmpeg > 3.3.git and stable release 3.2.3 on Linux and Windows and it gives the same > result. > > Though if I play it from ffmpeg version 2.8 the output is playing fine (but > there are 2 errors in the logs). > > For information the file is extracted from a live stream. I think that the > problem comes from the fact that the first packet is not a "key frame" or > something like this so the decoder cannot handle it. > > My command is just : > *ffplay aac_decoding_error.flv* > > And here are the error logs : > [aac @ 0x9fb08820] channel element 0.3 is not allocated > [aac @ 0x9fb08820] channel element 0.14 is not allocated > [aac @ 0x9fb08820] Input buffer exhausted before END element found > Last message repeated 1 times > [aac @ 0x9fb08820] channel element 2.10 is not allocated > [aac @ 0x9fb08820] Input buffer exhausted before END element found > [aac @ 0x9fb08820] Sample rate index in program config element does not > match the sample rate index configured by the container. > [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element > found > [aac @ 0x9fb08820] Input buffer exhausted before END element found > [aac @ 0x9fb08820] Sample rate index in program config element does not > match the sample rate index configured by the container. > [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element > found > [aac @ 0x9fb08820] Multiple frames in a packet. > [aac @ 0x9fb08820] decode_pce: Input buffer exhausted before END element > found > [aac @ 0x9fb08820] Input buffer exhausted before END element found > [aac @ 0x9fb08820] channel element 1.12 is not allocated > [aac @ 0x9fb08820] Input buffer exhausted before END element found > [aac @ 0x9fb08820] channel element 3.14 is not allocated > [aac @ 0x9fb08820] channel element 0.3 is not allocated > [aac @ 0x9fb08820] skip_data_stream_element: Input buffer exhausted before > END element found > [aac @ 0x9fb08820] Input buffer exhausted before END element found > [aac @ 0x9fb08820] channel element 0.7 is not allocated > [aac @ 0x9fb08820] Input buffer exhausted before END element found > ... > > Can someone help me for this problem? > > Regards > > *--* > > *Thomas JAMMET* Could you open a ticket in http://trac.ffmpeg.org/ with this same information and sample? See https://ffmpeg.org/bugreports.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: data loss in message accumulation in fill_buffer()
On Tue, May 16, 2017 at 09:05:49AM -0700, Rob Meyers wrote: > We noticed when reading data from a named pipe the first 10 bytes > would get dropped. I traced this to the affected code in > fill_buffer(). The assignment of "dst" was always set to the beginning > of the buffer, and if it hadn't been consumed yet the data would be > overwritten. We could reproduce this by setting up a server that > writes to the named pipe in two small (6 byte) messages with a 1 > second gap between. Without the gap, or if the data is sent as one > message, there's no problem. It's in the accumulation of data between > messages to fulfill a read that this bug is triggered. > > --- > libavformat/aviobuf.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) as just explained in the previous thread, this is not the correct change to fix the issue (just saying so this isnt applied by mistake) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing
On Tue, May 16, 2017 at 03:13:36PM +0300, Ivan Shmakov wrote:
> ---
> libavcodec/h264_ps.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 7858361..09e2290 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> {
> int aspect_ratio_info_present_flag;
> unsigned int aspect_ratio_idc;
> +int idx;
>
> aspect_ratio_info_present_flag = get_bits1(gb);
>
> @@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> sps->pic_struct_present_flag = get_bits1(gb);
> if (!get_bits_left(gb))
> return 0;
> +
> sps->bitstream_restriction_flag = get_bits1(gb);
> if (sps->bitstream_restriction_flag) {
> +idx = gb->index;
> get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
> get_ue_golomb(gb); /* max_bytes_per_pic_denom */
> get_ue_golomb(gb); /* max_bits_per_mb_denom */
> @@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> if (get_bits_left(gb) < 0) {
> sps->num_reorder_frames = 0;
> sps->bitstream_restriction_flag = 0;
> +gb->index = idx;
Direct access to gb->index is not ok
all code directly accssing GetBitContext internals belongs in the
bitstream / get bits code.
Normally to "unread" we just duplicate the GetBitContext before
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
On 16/05/17 13:04, Aaron Levinson wrote: > Add dxva2_pool_release_dummy() and use it in call to > av_buffer_create() in dxva2_pool_alloc(). > > Prior to this change, av_buffer_create() was called with NULL for the > third argument, which indicates that av_buffer_default_free() should > be used to free the buffer's data. Eventually, it gets to > buffer_pool_free() and calls buf->free() on a surface object (which is > av_buffer_default_free()). > > This can result in a crash when the debug version of the C-runtime is > used on Windows. While it doesn't appear to result in a crash when > the release version of the C-runtime is used on Windows, it likely > results in memory corruption, since av_free() is being called on > memory that was allocated using > IDirectXVideoAccelerationService::CreateSurface(). > > Signed-off-by: Aaron Levinson > --- > libavutil/hwcontext_dxva2.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Applied. Thanks for finding this - I'm rather surprised we haven't seen more serious problems because of it. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add audio crossfeed filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 16 +
libavfilter/Makefile | 1 +
libavfilter/af_crossfeed.c | 161 +
libavfilter/allfilters.c | 1 +
4 files changed, 179 insertions(+)
create mode 100644 libavfilter/af_crossfeed.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 9611a41..2e7caf3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2248,6 +2248,22 @@ Set temperature degree in Celsius. This is the
temperature of the environment.
Default is 20.
@end table
+@section crossfeed
+Apply headphone crossfeed filter.
+
+The filter accepts the following options:
+
+@table @option
+@item strength
+Set strength of crossfeed. Default is 0.1. Allowed range is from 0 to 1.
+
+@item level_in
+Set input gain. Default is 0.9.
+
+@item level_out
+Set output gain. Default is 1.
+@end table
+
@section crystalizer
Simple algorithm to expand audio dynamic range.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f177fdb..434a989 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -81,6 +81,7 @@ OBJS-$(CONFIG_CHANNELSPLIT_FILTER) +=
af_channelsplit.o
OBJS-$(CONFIG_CHORUS_FILTER) += af_chorus.o
generate_wave_table.o
OBJS-$(CONFIG_COMPAND_FILTER)+= af_compand.o
OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER) += af_compensationdelay.o
+OBJS-$(CONFIG_CROSSFEED_FILTER) += af_crossfeed.o
OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
diff --git a/libavfilter/af_crossfeed.c b/libavfilter/af_crossfeed.c
new file mode 100644
index 000..8a9ecad
--- /dev/null
+++ b/libavfilter/af_crossfeed.c
@@ -0,0 +1,161 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+typedef struct CrossfeedContext {
+const AVClass *class;
+
+double strength;
+double level_in;
+double level_out;
+
+double a0, a1, a2;
+double b0, b1, b2;
+
+double i1, i2;
+double o1, o2;
+} CrossfeedContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layout = NULL;
+int ret;
+
+if ((ret = ff_add_format (&formats, AV_SAMPLE_FMT_DBL ))
< 0 ||
+(ret = ff_set_common_formats (ctx , formats))
< 0 ||
+(ret = ff_add_channel_layout (&layout , AV_CH_LAYOUT_STEREO))
< 0 ||
+(ret = ff_set_common_channel_layouts (ctx , layout ))
< 0 ||
+(ret = ff_set_common_samplerates (ctx , ff_all_samplerates()))
< 0)
+return ret;
+
+return 0;
+}
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+CrossfeedContext *s = ctx->priv;
+double w0 = 2 * M_PI * s->strength * 1000 / inlink->sample_rate;
+double alpha;
+
+alpha = sin(w0) / 2 * sqrt(2 * (1 / 0.707 - 1) + 2);
+
+s->a0 = 1 + alpha;
+s->a1 = -2 * cos(w0);
+s->a2 = 1 - alpha;
+s->b0 = (1 + cos(w0)) / 2;
+s->b1 = -(1 + cos(w0));
+s->b2 = (1 + cos(w0)) / 2;
+
+s->a1 /= s->a0;
+s->a2 /= s->a0;
+s->b0 /= s->a0;
+s->b1 /= s->a0;
+s->b2 /= s->a0;
+
+return 0;
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+CrossfeedContext *s = ctx->priv;
+const double *src = (const double *)in->data[0];
+const double level_in = s->level_in;
+const double level_out = s->level_out;
+AVFrame *out;
+double *dst;
+int n;
+
+if (av_frame_is_writable(in)) {
+out = in;
+} else {
+out = ff_get_audio_buffer(inlink, in->nb_samples);
+if (!out) {
+av_frame_free(&in);
+return AVERROR(ENOMEM);
+}
+av_frame_copy_props(out, in);
+}
+dst = (double *)out->data[0];
+
+for (n = 0; n < out->nb_samples; n++, src += 2, dst += 2) {
+double mid = (sr
Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers
On Sat, May 06, 2017 at 02:28:10PM -0400, Micah Galizia wrote:
> On 2017-05-05 09:28 PM, wm4 wrote:
> >On Fri, 5 May 2017 20:55:05 -0400
> >Micah Galizia wrote:
> >
> >>Signed-off-by: Micah Galizia
> >>---
> >> libavformat/hls.c | 12 ++--
> >> 1 file changed, 10 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/libavformat/hls.c b/libavformat/hls.c
> >>index bac53a4350..bda9abecfa 100644
> >>--- a/libavformat/hls.c
> >>+++ b/libavformat/hls.c
> >>@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext
> >>**pb, const char *url,
> >> ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
> >> if (ret >= 0) {
> >> // update cookies on http response with setcookies.
> >>-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> >>-update_options(&c->cookies, "cookies", u);
> >>+char *new_cookies = NULL;
> >>+
> >>+if (s->flags ^ AVFMT_FLAG_CUSTOM_IO)
> >>+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN,
> >>(uint8_t**)&new_cookies);
> >Did you mean & instead of ^?
>
> No, the original code was structured to set *u to null (and thus did
> not copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags. So
> using ^ is logically equivalent -- cookies are copied only if
> AVFMT_FLAG_CUSTOM_IO is not set.
it would also copy if another flag is set, is that intended ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int'
Fixes: 1630/clusterfuzz-testcase-minimized-6326111917047808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/takdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index 42939b4058..4cfb95a893 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -267,11 +267,11 @@ static int decode_segment(TAKDecContext *s, int8_t mode,
int32_t *decoded, int l
code = xcodes[mode - 1];
for (i = 0; i < len; i++) {
-int x = get_bits_long(gb, code.init);
+unsigned x = get_bits_long(gb, code.init);
if (x >= code.escape && get_bits1(gb)) {
x |= 1 << code.init;
if (x >= code.aescape) {
-int scale = get_unary(gb, 1, 9);
+unsigned scale = get_unary(gb, 1, 9);
if (scale == 9) {
int scale_bits = get_bits(gb, 3);
if (scale_bits > 0) {
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32
Signed-off-by: Aaron Levinson
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 7980d92..49f91ac 100755
--- a/configure
+++ b/configure
@@ -6013,10 +6013,10 @@ check_header sys/videoio.h
check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse; vfse.discrete.width
= 0;" && enable_safe struct_v4l2_frmivalenum_discrete
check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
-check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
+disabled vfwcap_indev || { require vfw32 "windows.h vfw.h"
capCreateCaptureWindow -lvfw32 &&
# check that WM_CAP_DRIVER_CONNECT is defined to the proper value
# w32api 3.12 had it defined wrong
-check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable
vfwcap_defines
+ check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT >
WM_USER" && enable vfwcap_defines; }
check_type "dshow.h" IBaseFilter
--
2.10.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32
2017-05-17 6:38 GMT+08:00 Aaron Levinson :
> Signed-off-by: Aaron Levinson
> ---
> configure | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 7980d92..49f91ac 100755
> --- a/configure
> +++ b/configure
> @@ -6013,10 +6013,10 @@ check_header sys/videoio.h
> check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse;
> vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
>
> check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
> -check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
> +disabled vfwcap_indev || { require vfw32 "windows.h vfw.h"
> capCreateCaptureWindow -lvfw32 &&
> # check that WM_CAP_DRIVER_CONNECT is defined to the proper value
> # w32api 3.12 had it defined wrong
> -check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable
> vfwcap_defines
> + check_cpp_condition vfw.h
> "WM_CAP_DRIVER_CONNECT > WM_USER" && enable vfwcap_defines; }
>
indent problem?
>
> check_type "dshow.h" IBaseFilter
>
> --
> 2.10.1.windows.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: > L'octidi 18 floréal, an CCXXV, James Almer a écrit : >> Will that complete fix be ready and be backport-enabled (AKA, no new >> API) in the coming days? > > It can. Right now, I am waiting for a comment from Hendrik, who seemed > to have objections on the principle but that I hope to have convinced. > After that, the coding is quite straightforward. I will push soon if there is no progress in that complete fix. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: If vfwcap_indev disabled, don't do vfw32 checks; if enabled, require vfw32
On 5/16/2017 4:23 PM, Steven Liu wrote:
2017-05-17 6:38 GMT+08:00 Aaron Levinson :
Signed-off-by: Aaron Levinson
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 7980d92..49f91ac 100755
--- a/configure
+++ b/configure
@@ -6013,10 +6013,10 @@ check_header sys/videoio.h
check_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse;
vfse.discrete.width = 0;" && enable_safe struct_v4l2_frmivalenum_discrete
check_lib user32 "windows.h winuser.h" GetShellWindow -luser32
-check_lib vfw32 "windows.h vfw.h" capCreateCaptureWindow -lvfw32
+disabled vfwcap_indev || { require vfw32 "windows.h vfw.h"
capCreateCaptureWindow -lvfw32 &&
# check that WM_CAP_DRIVER_CONNECT is defined to the proper value
# w32api 3.12 had it defined wrong
-check_cpp_condition vfw.h "WM_CAP_DRIVER_CONNECT > WM_USER" && enable
vfwcap_defines
+ check_cpp_condition vfw.h
"WM_CAP_DRIVER_CONNECT > WM_USER" && enable vfwcap_defines; }
indent problem?
It's not--it is aligned with "require" on the earlier line, and that
alignment is consistent with similar things in other parts of the file.
I decided to leave the comment alone though, but I could indent the
comment with the other lines if that makes more sense.
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Hi, On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz wrote: > On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: > > L'octidi 18 floréal, an CCXXV, James Almer a écrit : > >> Will that complete fix be ready and be backport-enabled (AKA, no new > >> API) in the coming days? > > > > It can. Right now, I am waiting for a comment from Hendrik, who seemed > > to have objections on the principle but that I hope to have convinced. > > After that, the coding is quite straightforward. > > I will push soon if there is no progress in that complete fix. Push what patch exactly? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje wrote: > Hi, > > On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz wrote: > >> On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: >> > L'octidi 18 floréal, an CCXXV, James Almer a écrit : >> >> Will that complete fix be ready and be backport-enabled (AKA, no new >> >> API) in the coming days? >> > >> > It can. Right now, I am waiting for a comment from Hendrik, who seemed >> > to have objections on the principle but that I hope to have convinced. >> > After that, the coding is quite straightforward. >> >> I will push soon if there is no progress in that complete fix. > > > Push what patch exactly? Push my patch (avfilter: align data frame when needed). Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Decoding issue with AAC SBR from flv
2017-05-16 16:11 GMT+02:00 Thomas Jammet : > Can someone help me for this problem? I opened ticket #6398, thank you for the sample! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers
Signed-off-by: Micah Galizia
---
libavformat/hls.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..42022690f1 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
if (ret >= 0) {
// update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(&c->cookies, "cookies", u);
+char *new_cookies = NULL;
+
+if (!(s->flags & AVFMT_FLAG_CUSTOM_IO))
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN,
(uint8_t**)&new_cookies);
+
+if (new_cookies) {
+av_free(c->cookies);
+c->cookies = new_cookies;
+}
+
av_dict_set(&opts, "cookies", c->cookies, 0);
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers
On 2017-05-16 04:57 PM, Michael Niedermayer wrote: On Sat, May 06, 2017 at 02:28:10PM -0400, Micah Galizia wrote: On 2017-05-05 09:28 PM, wm4 wrote: Did you mean & instead of ^? No, the original code was structured to set *u to null (and thus did not copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags. So using ^ is logically equivalent -- cookies are copied only if AVFMT_FLAG_CUSTOM_IO is not set. it would also copy if another flag is set, is that intended ? ... I think that is what wm4 was getting at too. That is wrong and not intended. I'll resubmit with !(a&b) which is the proper logic. Thanks, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Hi, On Tue, May 16, 2017 at 7:43 PM, Muhammad Faiz wrote: > On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje > wrote: > > Hi, > > > > On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz wrote: > > > >> On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: > >> > L'octidi 18 floréal, an CCXXV, James Almer a écrit : > >> >> Will that complete fix be ready and be backport-enabled (AKA, no new > >> >> API) in the coming days? > >> > > >> > It can. Right now, I am waiting for a comment from Hendrik, who seemed > >> > to have objections on the principle but that I hope to have convinced. > >> > After that, the coding is quite straightforward. > >> > >> I will push soon if there is no progress in that complete fix. > > > > > > Push what patch exactly? > > Push my patch (avfilter: align data frame when needed). Wasn't consensus that you should backport the new API, possibly with ff prefix, and call it in relevant places, to make sure that the code in new and old branch is identical? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On 5/16/2017 11:28 PM, Ronald S. Bultje wrote: > Hi, > > On Tue, May 16, 2017 at 7:43 PM, Muhammad Faiz wrote: > >> On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje >> wrote: >>> Hi, >>> >>> On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz wrote: >>> On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: > L'octidi 18 floréal, an CCXXV, James Almer a écrit : >> Will that complete fix be ready and be backport-enabled (AKA, no new >> API) in the coming days? > > It can. Right now, I am waiting for a comment from Hendrik, who seemed > to have objections on the principle but that I hope to have convinced. > After that, the coding is quite straightforward. I will push soon if there is no progress in that complete fix. >>> >>> >>> Push what patch exactly? >> >> Push my patch (avfilter: align data frame when needed). > > > Wasn't consensus that you should backport the new API, possibly with ff > prefix, and call it in relevant places, to make sure that the code in new > and old branch is identical? > > Ronald Yes, but as he said, if there's no progress in that complete fix, then this partial fix should be pushed instead, at least for one point release in the 3.3 branch before being replaced. For that matter, it should have happened for 3.3.1, seeing the complete fix couldn't be done in time even though it was supposed to. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] License consent (cinepakenc.c)
On 5/16/2017 5:12 PM, Tomas Härdin wrote: > On Tue, 2017-05-16 at 15:42 -0300, James Almer wrote: >> On 5/16/2017 3:13 PM, Tomas Härdin wrote: >>> >>> Hi >>> >>> I got a question from Diego via IRC about what license cinepakenc.c >>> actually has, since the first commit message just has a message >>> by"Rl" >>> saying that I said it was OK but with no appropriately signed >>> message >>> from me. So I'm posting this just to clarify things: >>> >>> I consent to the original license placed on cinepakenc.c on Wed Jan >>> 22 >>> 11:12:11 2014 +0100 (commit >>> 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d). >>> >>> Just for fun I gave the encoder a try, and the output plays just >>> fine >>> on Windows 3.1 in dosbox-x :) >> Nice, i guess :p >> >>> >>> >>> My e-mail address changed a while back since I've changed employer, >>> so >>> MAINTAINERS should be updated to point to this one. I also don't >>> work >>> with MXF any longer, so a new maintainer may be needed for that >> MAINTAINERS doesn't list email addresses, just GPG fingerprints, and >> the >> one listed for you matches the one you're still using today. >> If you have push access you can remove the mxfdec mention, otherwise >> i >> can do that for you. > > Sure. I see I'm listed for lxfdec too, but I think I can still manage > that. And the cinepak encoder has Rl listed so that's covered > > /Tomas Ok, done then. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Wed, May 17, 2017 at 10:47 AM, James Almer wrote: > On 5/16/2017 11:28 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Tue, May 16, 2017 at 7:43 PM, Muhammad Faiz wrote: >> >>> On Wed, May 17, 2017 at 6:33 AM, Ronald S. Bultje >>> wrote: Hi, On Tue, May 16, 2017 at 7:23 PM, Muhammad Faiz wrote: > On Sun, May 7, 2017 at 8:18 PM, Nicolas George wrote: >> L'octidi 18 floréal, an CCXXV, James Almer a écrit : >>> Will that complete fix be ready and be backport-enabled (AKA, no new >>> API) in the coming days? >> >> It can. Right now, I am waiting for a comment from Hendrik, who seemed >> to have objections on the principle but that I hope to have convinced. >> After that, the coding is quite straightforward. > > I will push soon if there is no progress in that complete fix. Push what patch exactly? >>> >>> Push my patch (avfilter: align data frame when needed). >> >> >> Wasn't consensus that you should backport the new API, possibly with ff >> prefix, and call it in relevant places, to make sure that the code in new >> and old branch is identical? >> >> Ronald > > Yes, but as he said, if there's no progress in that complete fix, then > this partial fix should be pushed instead, at least for one point > release in the 3.3 branch before being replaced. > For that matter, it should have happened for 3.3.1, seeing the complete > fix couldn't be done in time even though it was supposed to. Actually, one can argue that because we've already missed 3.3.1, we should wait for 3.3.2. But I can argue that master branch also has users, and keeping the crash unresolved at master branch is not good idea at all. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/graphparser: allow specifying filter@id as filter instance
See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
Parsed_filter_X is not intuitive as filter instance name and
also undocumented.
Signed-off-by: Muhammad Faiz
---
doc/filters.texi | 13 ++---
libavfilter/graphparser.c | 26 +-
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a7c6063..d2b5110 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -130,11 +130,11 @@ filterchains is represented by a list of ";"-separated
filterchain
descriptions.
A filter is represented by a string of the form:
-[@var{in_link_1}]...[@var{in_link_N}]@var{filter_name}=@var{arguments}[@var{out_link_1}]...[@var{out_link_M}]
+[@var{in_link_1}]...[@var{in_link_N}]@var{filter_name}@@@var{id}=@var{arguments}[@var{out_link_1}]...[@var{out_link_M}]
@var{filter_name} is the name of the filter class of which the
described filter is an instance of, and has to be the name of one of
-the filter classes registered in the program.
+the filter classes registered in the program optionally followed by
"@@@var{id}".
The name of the filter class is optionally followed by a string
"=@var{arguments}".
@@ -212,10 +212,11 @@ to the filtergraph description.
Here is a BNF description of the filtergraph syntax:
@example
@var{NAME} ::= sequence of alphanumeric characters and '_'
+@var{FILTER_NAME} ::= @var{NAME}["@@"@var{NAME}]
@var{LINKLABEL}::= "[" @var{NAME} "]"
@var{LINKLABELS} ::= @var{LINKLABEL} [@var{LINKLABELS}]
@var{FILTER_ARGUMENTS} ::= sequence of chars (possibly quoted)
-@var{FILTER} ::= [@var{LINKLABELS}] @var{NAME} ["="
@var{FILTER_ARGUMENTS}] [@var{LINKLABELS}]
+@var{FILTER} ::= [@var{LINKLABELS}] @var{FILTER_NAME} ["="
@var{FILTER_ARGUMENTS}] [@var{LINKLABELS}]
@var{FILTERCHAIN} ::= @var{FILTER} [,@var{FILTERCHAIN}]
@var{FILTERGRAPH} ::= [sws_flags=@var{flags};] @var{FILTERCHAIN}
[;@var{FILTERGRAPH}]
@end example
@@ -17190,6 +17191,12 @@ asendcmd=c='4.0 atempo tempo 1.5',atempo
@end example
@item
+Target a specific filter instance:
+@example
+asendcmd=c='4.0 atempo@@my tempo 1.5',atempo@@my
+@end example
+
+@item
Specify a list of drawtext and hue commands in a file.
@example
# show text in the interval 5-10
diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
index 04b4272..1405926 100644
--- a/libavfilter/graphparser.c
+++ b/libavfilter/graphparser.c
@@ -88,20 +88,36 @@ static char *parse_link_name(const char **buf, void
*log_ctx)
* @param filt_ctx put here a filter context in case of successful creation
and configuration, NULL otherwise.
* @param ctx the filtergraph context
* @param index an index which is supposed to be unique for each filter
instance added to the filtergraph
- * @param filt_name the name of the filter to create
+ * @param name the name of the filter to create, can be filter name or
filter_name\@id as instance name
* @param args the arguments provided to the filter during its initialization
* @param log_ctx the log context to use
* @return >= 0 in case of success, a negative AVERROR code otherwise
*/
static int create_filter(AVFilterContext **filt_ctx, AVFilterGraph *ctx, int
index,
- const char *filt_name, const char *args, void
*log_ctx)
+ const char *name, const char *args, void *log_ctx)
{
AVFilter *filt;
-char inst_name[30];
+char name2[30];
+const char *inst_name = NULL, *filt_name = NULL;
char *tmp_args = NULL;
-int ret;
+int ret, k;
+
+av_strlcpy(name2, name, sizeof(name2));
+
+for (k = 0; name2[k]; k++) {
+if (name2[k] == '@' && name[k+1]) {
+name2[k] = 0;
+inst_name = name;
+filt_name = name2;
+break;
+}
+}
-snprintf(inst_name, sizeof(inst_name), "Parsed_%s_%d", filt_name, index);
+if (!inst_name) {
+snprintf(name2, sizeof(name2), "Parsed_%s_%d", name, index);
+inst_name = name2;
+filt_name = name;
+}
filt = avfilter_get_by_name(filt_name);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
