Re: [FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va
On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote:
> On Tue, 13 Dec 2016 14:19:35 +0100
> Steve Lhomme wrote:
>
>> From: Steve Lhomme
>>
>> The code is similar to ffmpeg_dxva2. The decoded output needs to be copied
>> into
>> a staging texture that can be accessed by the CPU as the decoder texture
>> can't
>> be accessed by the CPU.
>> ---
>> Makefile | 1 +
>> configure | 14 ++
>> ffmpeg.h | 2 +
>> ffmpeg_d3d11va.c | 416 +++
>> ffmpeg_opt.c | 3 +
>> libavutil/Makefile | 3 +
>> libavutil/hwcontext.c | 3 +
>> libavutil/hwcontext.h | 1 +
>> libavutil/hwcontext_d3d11va.c | 436
>> +
>> libavutil/hwcontext_d3d11va.h | 74 +++
>> libavutil/hwcontext_internal.h | 1 +
>> libavutil/version.h| 2 +-
>> 12 files changed, 955 insertions(+), 1 deletion(-)
>> create mode 100644 ffmpeg_d3d11va.c
>> create mode 100644 libavutil/hwcontext_d3d11va.c
>> create mode 100644 libavutil/hwcontext_d3d11va.h
>>
>> diff --git a/Makefile b/Makefile
>> index 8aa72fd..a48d471 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -38,6 +38,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>> endif
>> OBJS-ffmpeg-$(CONFIG_CUVID) += ffmpeg_cuvid.o
>> OBJS-ffmpeg-$(HAVE_DXVA2_LIB) += ffmpeg_dxva2.o
>> +OBJS-ffmpeg-$(HAVE_D3D11VA_LIB) += ffmpeg_d3d11va.o
>> OBJS-ffmpeg-$(HAVE_VDPAU_X11) += ffmpeg_vdpau.o
>> OBJS-ffserver += ffserver_config.o
>>
>> diff --git a/configure b/configure
>> index 9dfd006..dea8339 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2050,6 +2050,8 @@ HAVE_LIST="
>> $TYPES_LIST
>> atomics_native
>> dos_paths
>> +d3d11va_lib
>> +d3d11vaapi_cobj
>> dxva2_lib
>> dxva2api_cobj
>> libc_msvcrt
>> @@ -6037,6 +6039,15 @@ enabled dxva2api_h &&
>> int main(void) { IDirectXVideoDecoder *o = NULL;
>> IDirectXVideoDecoder_Release(o); return 0; }
>> EOF
>>
>> +enabled d3d11_h &&
>> +check_cc <> +#define _WIN32_WINNT 0x0600
>> +#define COBJMACROS
>> +#include
>> +#include
>> +int main(void) { ID3D11VideoDevice *o = NULL; ID3D11VideoDevice_Release(o);
>> return 0; }
>> +EOF
>> +
>> enabled vaapi &&
>> check_lib va/va.h vaInitialize -lva ||
>> disable vaapi
>> @@ -6368,6 +6379,9 @@ if test $target_os = "haiku"; then
>> disable posix_memalign
>> fi
>>
>> +enabled_all d3d11va d3d11vaapi_cobj &&
>> +enable d3d11va_lib
>> +
>> enabled_all dxva2 dxva2api_cobj CoTaskMemFree &&
>> prepend ffmpeg_libs $($ldflags_filter "-lole32") &&
>> enable dxva2_lib
>> diff --git a/ffmpeg.h b/ffmpeg.h
>> index ebe5bf0..a12701e 100644
>> --- a/ffmpeg.h
>> +++ b/ffmpeg.h
>> @@ -61,6 +61,7 @@ enum HWAccelID {
>> HWACCEL_NONE = 0,
>> HWACCEL_AUTO,
>> HWACCEL_VDPAU,
>> +HWACCEL_D3D11VA,
>> HWACCEL_DXVA2,
>> HWACCEL_VDA,
>> HWACCEL_VIDEOTOOLBOX,
>> @@ -633,6 +634,7 @@ int ifilter_parameters_from_decoder(InputFilter
>> *ifilter, const AVCodecContext *
>> int ffmpeg_parse_options(int argc, char **argv);
>>
>> int vdpau_init(AVCodecContext *s);
>> +int d3d11va_init(AVCodecContext *s);
>> int dxva2_init(AVCodecContext *s);
>> int vda_init(AVCodecContext *s);
>> int videotoolbox_init(AVCodecContext *s);
>> diff --git a/ffmpeg_d3d11va.c b/ffmpeg_d3d11va.c
>> new file mode 100644
>> index 000..f6f8186
>> --- /dev/null
>> +++ b/ffmpeg_d3d11va.c
>> @@ -0,0 +1,416 @@
>> +/*
>> + * 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
>> +
>> +#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
>> +#undef _WIN32_WINNT
>> +#define _WIN32_WINNT 0x0600
>> +#endif
>> +#define COBJMACROS
>> +
>> +#include
>> +
>> +#include
>> +
>> +#include "ffmpeg.h"
>> +
>> +#include "libavcodec/d3d11va.h"
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/buffer.h"
>> +#include "libavutil/frame.h"
>> +#include "libavutil/imgutils.h"
>> +#include "libavutil/pixfmt.h"
>> +
>> +#include "libavutil/hwcontext.h"
>> +#include "libavutil/hwcontext_d3d11va.h"
>> +
>> +/* define all the GUIDs used directly here,
>> +
Re: [FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va
On Wed, Dec 14, 2016 at 10:30 AM, Stève Lhomme wrote:
>>
>> I'm pretty much against this, since it duplicates the profile selection
>> code all over again, even if it could be shared. (And this code should
>> be in libavcodec in the first place.) Someone adding such code would
>> have to refactor ffmpeg_d3d11va too.
>
> I'm not sure how this relates to the line above. d3d11va and dxva2 are
> definitely not the same thing. On mobile you do not have DXVA2 at all
> but D3D11(VA) is present. There must be a way to have one without the
> other.
>
The point wm4 was making is that it should share a bunch of the code
with dxva2 (ie. the guid selection, for example, and whatever is
appropriate), instead of just duplicating it.
And on top of that, maybe even have it in avcodec since every
implementation needs a GUID -> codec mapping somewhere.
>>> +ZeroMemory(&viewDesc, sizeof(viewDesc));
>>> +viewDesc.DecodeProfile = decoderDesc.Guid;
>>> +viewDesc.ViewDimension = D3D11_VDOV_DIMENSION_TEXTURE2D;
>>> +for (i=0; iinitial_pool_size; i++)
>>> +{
>>> +hr =
>>> ID3D11VideoDevice_CreateVideoDecoderOutputView(device_hwctx->video_device,
>>> +
>>> (ID3D11Resource*) p_texture,
>>> +&viewDesc,
>>> +
>>> (ID3D11VideoDecoderOutputView**) &s->surfaces_internal[i]);
>>> +if (FAILED(hr)) {
>>> +av_log(ctx, AV_LOG_ERROR, "Could not create the decoder output
>>> %d\n", i);
>>> +while (--i >= 0) {
>>> +
>>> ID3D11VideoDecoderOutputView_Release(s->surfaces_internal[i]);
>>> +s->surfaces_internal[i] = NULL;
>>> +}
>>> +ID3D11Texture2D_Release(p_texture);
>>> +ID3D11Device_Release(d3d11_device);
>>> +return AVERROR_UNKNOWN;
>>> +}
>>> +}
>>> +ID3D11Texture2D_Release(p_texture);
>>> +
>>> +texDesc.ArraySize = 1;
>>> +texDesc.Usage = D3D11_USAGE_STAGING;
>>> +texDesc.BindFlags = 0;
>>> +texDesc.CPUAccessFlags = D3D11_CPU_ACCESS_READ;
>>
>> Doesn't this exclude upload?
>
> I only too decoding in consideration. Since it's a staging texture,
> adding ACCESS_WRITE is possible. When mapping the surface to the CPU
> I'll need to adjust the flags.
The hwcontext should indeed be universal for both download and upload,
even if its only used for download in the first step.
>>> +static int d3d11va_device_create(AVHWDeviceContext *ctx, const char
>>> *device,
>>> + AVDictionary *opts, int flags)
>>> +{
>>> +AVD3D11VADeviceContext *device_hwctx = ctx->hwctx;
>>> +D3D11VADevicePriv *priv;
>>> +
>>> +HRESULT hr;
>>> +PFN_D3D11_CREATE_DEVICE createD3D;
>>> +IDXGIAdapter *pAdapter = NULL;
>>> +UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
>>> +/* if the DirectX SDK is installed creationFlags |=
>>> D3D11_CREATE_DEVICE_DEBUG; */
>>> +
>>> +if (device) {
>>> +HMODULE dxgilib = dlopen("dxgi.dll", 0);
>>
>> Using dlopen instead of LoadLibrary is just odd.
>
> I used exactly what is used in other parts of the DXVA2 code. If it
> exists I suppose there's a reason for that.
ffmpeg has wrappers around LoadLibrary with some extra security
checks, and they mimick the dlopen API, IIRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] omadec: fix overflows during bit rate calculation
On Wed, Dec 14, 2016 at 01:02:41 +0100, Andreas Cadhalpun wrote: > On 13.12.2016 08:11, Paul B Mahol wrote: > >> -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048; > >> +st->codecpar->bit_rate= samplerate * framesize / 256; > > Why multiply with 8 when dividing by a multiple of 8 directly afterwards? > That's just a waste of computational resources. I can only explain the term with "readability" (e.g. "number of bytes times 8 is number of bits, divided by 2048 is the rate"). If you bracket the (8 / 2048), it would avoid the overflow, and the compiler should evaluate the term to that constant 256 anyway, right? (Just if anyone cares about the presumed readability.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va
On Wed, 14 Dec 2016 09:30:35 +
Stève Lhomme wrote:
> On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote:
> > On Tue, 13 Dec 2016 14:19:35 +0100
> > Steve Lhomme wrote:
> >
> > I'm pretty much against this, since it duplicates the profile selection
> > code all over again, even if it could be shared. (And this code should
> > be in libavcodec in the first place.) Someone adding such code would
> > have to refactor ffmpeg_d3d11va too.
>
> I'm not sure how this relates to the line above. d3d11va and dxva2 are
> definitely not the same thing. On mobile you do not have DXVA2 at all
> but D3D11(VA) is present. There must be a way to have one without the
> other.
Yeah, but selection of the decoder GUIDs is very similar between both
APIs. It can definitely be shared (we do this in mpv). There's
absolutely no reason to copy-paste that stuff from ffmpeg_dxva2.c into
ffmpeg_d3d11va.c.
As for how libavcodec can do provide this part, see the Libav/avconv
vaapi support (none of that is in ffmpeg yet).
> >> diff --git a/libavutil/Makefile b/libavutil/Makefile
> >> index 9841645..9b8ce22 100644
> >> --- a/libavutil/Makefile
> >> +++ b/libavutil/Makefile
> >> @@ -34,6 +34,7 @@ HEADERS = adler32.h
> >>\
> >>hmac.h\
> >>hwcontext.h \
> >>hwcontext_cuda.h \
> >> + hwcontext_d3d11va.h \
> >>hwcontext_dxva2.h \
> >>hwcontext_qsv.h \
> >>hwcontext_vaapi.h \
> >> @@ -156,6 +157,7 @@ OBJS = adler32.o
> >> \
> >> OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o \
> >>
> >> OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
> >> +OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o
> >> OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
> >> OBJS-$(CONFIG_QSV) += hwcontext_qsv.o
> >> OBJS-$(CONFIG_LZO) += lzo.o
> >> @@ -170,6 +172,7 @@ SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
> >>
> >> SKIPHEADERS-$(HAVE_CUDA_H) += hwcontext_cuda.h
> >> SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda_internal.h
> >> +SKIPHEADERS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.h
> >> SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
> >> SKIPHEADERS-$(CONFIG_QSV) += hwcontext_qsv.h
> >> SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
> >> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> >> index 615f1f7..a9db84b 100644
> >> --- a/libavutil/hwcontext.c
> >> +++ b/libavutil/hwcontext.c
> >> @@ -32,6 +32,9 @@ static const HWContextType *hw_table[] = {
> >> #if CONFIG_CUDA
> >> &ff_hwcontext_type_cuda,
> >> #endif
> >> +#if CONFIG_D3D11VA
> >> +&ff_hwcontext_type_d3d11va,
> >> +#endif
> >> #if CONFIG_DXVA2
> >> &ff_hwcontext_type_dxva2,
> >> #endif
> >> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> >> index 785da09..e29dc67 100644
> >> --- a/libavutil/hwcontext.h
> >> +++ b/libavutil/hwcontext.h
> >> @@ -28,6 +28,7 @@ enum AVHWDeviceType {
> >> AV_HWDEVICE_TYPE_VDPAU,
> >> AV_HWDEVICE_TYPE_CUDA,
> >> AV_HWDEVICE_TYPE_VAAPI,
> >> +AV_HWDEVICE_TYPE_D3D11VA,
> >> AV_HWDEVICE_TYPE_DXVA2,
> >> AV_HWDEVICE_TYPE_QSV,
> >> };
> >> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> >> new file mode 100644
> >> index 000..6ac1019
> >> --- /dev/null
> >> +++ b/libavutil/hwcontext_d3d11va.c
> >> @@ -0,0 +1,436 @@
> >> +/*
> >> + * 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
> >> +
> >> +#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
> >> +#undef _WIN32_WINNT
> >> +#define _WIN32_WINNT 0x0600
> >> +#endif
> >> +#define COBJMACROS
> >> +
> >> +#include
> >> +#incl
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On Wed, Dec 14, 2016 at 08:46:28AM +0100, Paul B Mahol wrote:
> On 12/14/16, Michael Niedermayer wrote:
> > On Tue, Dec 13, 2016 at 10:23:48PM +0100, Martin Vignali wrote:
> >> 2016-11-24 21:35 GMT+01:00 Martin Vignali :
> >>
> >> > Hello
> >> >
> >> > New patchs in attach
> >> >
> >> > I changed the dimensions check, the check is now :
> >> >
> >> > if ((s->height > 3) && (s->avctx->strict_std_compliance >
> >> > FF_COMPLIANCE_EXPERIMENTAL)) {
> >> > av_log(s->avctx, AV_LOG_ERROR,
> >> >"Height > 3 is experimental, add "
> >> >"'-strict %d' if you want to try to decode the
> >> > picture.\n",
> >> >FF_COMPLIANCE_EXPERIMENTAL);
> >> > return AVERROR_EXPERIMENTAL;
> >> > }
> >> >
> >> > s->width = bytestream2_get_be32(&s->gb);
> >> > if ((s->width > 3) && (s->avctx->strict_std_compliance >
> >> > FF_COMPLIANCE_EXPERIMENTAL)) {
> >> > av_log(s->avctx, AV_LOG_ERROR,
> >> >"Width > 3 is experimental, add "
> >> >"'-strict %d' if you want to try to decode the
> >> > picture.\n",
> >> >FF_COMPLIANCE_EXPERIMENTAL);
> >> > return AVERROR_EXPERIMENTAL;
> >> > }
> >> >
> >> >
> >> > and change the line_size variable (in PSD Context) to uint_64 (because
> >> > now, width can be > 3 if -strict set to experimental)
> >> >
> >> > I will send a patch for fate test in another discussion.
> >> >
> >> > Martin
> >> >
> >>
> >> Ping
> >
> > applied
>
> Without minor bumps.
bumped
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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 1/3] omadec: fix overflows during bit rate calculation
On Wed, Dec 14, 2016 at 1:02 AM, Andreas Cadhalpun wrote: > On 13.12.2016 08:11, Paul B Mahol wrote: >> On 12/13/16, Andreas Cadhalpun wrote: >>> Signed-off-by: Andreas Cadhalpun >>> --- >>> libavformat/omadec.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/libavformat/omadec.c b/libavformat/omadec.c >>> index 6e476db..e7751d0 100644 >>> --- a/libavformat/omadec.c >>> +++ b/libavformat/omadec.c >>> @@ -365,7 +365,7 @@ static int oma_read_header(AVFormatContext *s) >>> st->codecpar->channels= 2; >>> st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO; >>> st->codecpar->sample_rate = samplerate; >>> -st->codecpar->bit_rate= st->codecpar->sample_rate * framesize * >>> 8 / 1024; >>> +st->codecpar->bit_rate= st->codecpar->sample_rate * framesize / >>> 128; >>> >>> /* fake the ATRAC3 extradata >>> * (wav format, makes stream copy to wav work) */ >>> @@ -398,7 +398,7 @@ static int oma_read_header(AVFormatContext *s) >>> return AVERROR_INVALIDDATA; >>> } >>> st->codecpar->sample_rate = samplerate; >>> -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048; >>> +st->codecpar->bit_rate= samplerate * framesize / 256; >>> avpriv_set_pts_info(st, 64, 1, samplerate); >>> break; >>> case OMA_CODECID_MP3: >> >> Shouldn't using 8LL or similar be more future-proof? > > Why multiply with 8 when dividing by a multiple of 8 directly afterwards? > That's just a waste of computational resources. > If sample_rate and/or framesize get larger in the future, a cast can be added. > The compiler should be able to optimize such things out and it may add clarity to what the code is doing. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va
On Tue, 13 Dec 2016 14:19:35 +0100
Steve Lhomme wrote:
> +static int d3d11va_transfer_data(AVHWFramesContext *ctx, AVFrame *dst,
> + const AVFrame *src)
> +{
> +ID3D11VideoDecoderOutputView *surface;
> +D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESCsurfaceDesc;
> +D3D11_TEXTURE2D_DESC dstDesc;
> +D3D11_MAPPED_SUBRESOURCE LockedRect;
> +ID3D11Resource *pTexture;
> +HRESULThr;
> +AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
> +D3D11VAFramesContext *s = ctx->internal->priv;
> +
> +uint8_t *surf_data[4] = { NULL };
> +int surf_linesize[4] = { 0 };
> +int i;
> +
> +int download = !!src->hw_frames_ctx;
> +
> +surface = (ID3D11VideoDecoderOutputView*)(download ? src->data[3] :
> dst->data[3]);
> +
> +ID3D11VideoDecoderOutputView_GetDesc(surface, &surfaceDesc);
> +ID3D11VideoDecoderOutputView_GetResource(surface, &pTexture);
> +
> +ID3D11DeviceContext_CopySubresourceRegion(s->d3d11_context,
> (ID3D11Resource*)frames_hwctx->staging_texture,
> +0, 0, 0, 0,
> +(ID3D11Resource*)pTexture, surfaceDesc.Texture2D.ArraySlice,
> +NULL);
> +ID3D11Resource_Release(pTexture);
> +
> +hr = ID3D11DeviceContext_Map(s->d3d11_context,
> (ID3D11Resource*)frames_hwctx->staging_texture,
> + 0, D3D11_MAP_READ, 0, &LockedRect);
> +if (FAILED(hr)) {
> +av_log(ctx, AV_LOG_ERROR, "Unable to lock D3D11VA surface %lx\n",
> hr);
> +return AVERROR_UNKNOWN;
> +}
> +
> +for (i = 0; download ? dst->data[i] : src->data[i]; i++)
> +surf_linesize[i] = LockedRect.RowPitch;
> +
> +ID3D11Texture2D_GetDesc(frames_hwctx->staging_texture, &dstDesc);
> +av_image_fill_pointers(surf_data, ctx->sw_format, dstDesc.Height,
> + (uint8_t*)LockedRect.pData, surf_linesize);
> +
> +if (download) {
> +av_image_copy(dst->data, dst->linesize, surf_data, surf_linesize,
> + ctx->sw_format, src->width, src->height);
> +} else {
> +av_image_copy(surf_data, surf_linesize, src->data, src->linesize,
> + ctx->sw_format, src->width, src->height);
> +}
> +
> +ID3D11DeviceContext_Unmap(s->d3d11_context,
> (ID3D11Resource*)frames_hwctx->staging_texture, 0);
> +
> +return 0;
> +}
Missed this part during the first review, but: the staging_texture use
should be either mutex-protected, or there should be a pool of staging
textures.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] tiff: fix overflows when calling av_readuce
On Wed, Dec 14, 2016 at 12:57:12AM +0100, Andreas Cadhalpun wrote:
> On 13.12.2016 01:32, Michael Niedermayer wrote:
> > On Tue, Dec 13, 2016 at 12:50:19AM +0100, Andreas Cadhalpun wrote:
> >> The arguments of av_reduce are signed, so the cast to uint64_t is
> >> misleading.
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavcodec/tiff.c | 11 +--
> >> 1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> >> index 4721e94..12ef419 100644
> >> --- a/libavcodec/tiff.c
> >> +++ b/libavcodec/tiff.c
> >> @@ -772,9 +772,16 @@ static void set_sar(TiffContext *s, unsigned tag,
> >> unsigned num, unsigned den)
> >> int offset = tag == TIFF_YRES ? 2 : 0;
> >> s->res[offset++] = num;
> >> s->res[offset] = den;
> >> -if (s->res[0] && s->res[1] && s->res[2] && s->res[3])
> >> +if (s->res[0] && s->res[1] && s->res[2] && s->res[3]) {
> >> +uint64_t num = s->res[2] * (uint64_t)s->res[1];
> >> +uint64_t den = s->res[0] * (uint64_t)s->res[3];
> >> +if (num > INT64_MAX || den > INT64_MAX) {
> >> +num = num >> 1;
> >> +den = den >> 1;
> >> +}
> >
> > this can make one of them 0, in fact i think even if they arent 0
> > the sample_aspect_ratio can be after reduce
> > should they be checked after all that instead of before ?
>
> I've added a check for !s->avctx->sample_aspect_ratio.den after av_reduce.
> The check before is still necessary to prevent sample_aspect_ratio from
> becoming negative.
>
> Best regards,
> Andreas
>
> tiff.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
> 96297593c98fcbce7395cb13627fae080f1e2cbc
> 0001-tiff-fix-overflows-when-calling-av_reduce.patch
> From 3cd8cb663d762bc15694e285ea48cdb8e9abfd4b Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Tue, 13 Dec 2016 00:43:21 +0100
> Subject: [PATCH] tiff: fix overflows when calling av_reduce
>
> The arguments of av_reduce are signed, so the cast to uint64_t is misleading.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/tiff.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] cafdec: prevent overflow during bit rate calculation
On Wed, Dec 14, 2016 at 01:58:17AM +0100, Andreas Cadhalpun wrote: > Signed-off-by: Andreas Cadhalpun > --- > libavformat/cafdec.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ARM fate
On Tue, Dec 13, 2016 at 08:35:43PM +0100, Thilo Borgmann wrote: > Am 12.12.16 um 22:18 schrieb Michael Niedermayer: > > Hi all > > > > The panda arm board iam using as fate client for fate.ffmpeg.org seems > > not really able to handle the load. > > Iam not sure why, but increasing number of fate tests, branches it > > tests and compiler/option cases probably are the primary reason. > > I already dropped half the branches it tests but it still needs > > apparently on the order of a week for a single pass. > > > > It would make alot of sense if more people could help here and run > > some arm fate clients so that stuff gets tested more regularly and > > with less latency > > I'm currently setting up another FATE on a dragonboard (Cortex-A53). ok > (And maintaining all my other clients) i see 2 fate clients with comment "TB", didnt you have more clients? the 2 fail http://fatebeta.ffmpeg.org/report/aarch64-bo/20161214010115 fails build http://fate.ffmpeg.org/history.cgi?slot=armv7-ios802-clang fails all tests except one and never did better since march 2015 according to the history on the webpage [...] -- 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 v3] Added Turing codec interface for ffmpeg
> Missing error handling, and maybe overflow handling. Also, we don't use > malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we > do this (it doesn't have much of a justification for realloc at least), but > it's > probably better to be consistent. Ok, point taken on the av_* functions. On the handling bit, I was thinking to flag the error via av_log and then call exit_program(1), after, of course, having released the memory allocated up to that point. Would that be ok? > > Does the "s" field have any purpose? It seems to be redundant with the > other fields. It has. It points to the position in the options buffer which is going to be filled with the command line being parsed. So it's not redundant. - http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg
On Wed, Dec 14, 2016 at 3:23 PM, Matteo Naccari wrote: >> Missing error handling, and maybe overflow handling. Also, we don't use >> malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we >> do this (it doesn't have much of a justification for realloc at least), but >> it's >> probably better to be consistent. > > Ok, point taken on the av_* functions. On the handling bit, I was thinking to > flag the error via av_log and then call exit_program(1), after, of course, > having released the memory allocated up to that point. Would that be ok? > Calling exit or abort from a library is never ok. Just return error codes back to the avcodec framework and let it handle the error instead of exiting right here. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg
On Wed, 14 Dec 2016 14:23:05 + Matteo Naccari wrote: > > Missing error handling, and maybe overflow handling. Also, we don't use > > malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we > > do this (it doesn't have much of a justification for realloc at least), but > > it's > > probably better to be consistent. > > Ok, point taken on the av_* functions. On the handling bit, I was thinking to > flag the error via av_log and then call exit_program(1), after, of course, > having released the memory allocated up to that point. Would that be ok? Of course this would be not ok. We never flag errors via av_log (how would this even work). We also don't call exit() in the libraries, if you mean this. Or maybe you're talking about ffmpeg.c - no, ffmpeg.c is not the only API user, and of course not all API users should be updated to do some weird h264_turing codec error handling. You do what all other codecs in libavcodec also do: return an error code to the caller, and maybe log an error message (not in obscure OOM cases, probably). > > > > Does the "s" field have any purpose? It seems to be redundant with the > > other fields. > > It has. It points to the position in the options buffer which is going to be > filled with the command line being parsed. So it's not redundant. Then what does buffer_filled do? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] doc/filters: drawtext: add example of printing texts on same baseline
Height of canvas produced by drawtext varies depending on symbols in
text, so add example for printing separate texts aligned horizontally.
Wording suggested by Lou Logan
Signed-off-by: Andrey Utkin
---
Changes in v2:
* Taken the wording of example and description Lou proposed
* Added mention of @var{max_glyph_a} to "Note that..." phrase
(is the markup used for this correct?)
* Slightly edited commit message for clarity of meaning
(dimensions vary -> height varies)
doc/filters.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 3ae3c46d26..97ff517054 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7135,6 +7135,14 @@ FOD=5 # fade out duration
ffplay -f lavfi
"color,drawtext=text=TEST:fontsize=50:fontfile=FreeSerif.ttf:fontcolor_expr=ff%@{eif:
clip(255*(1*between(t\\, $DS + $FID\\, $DE - $FOD) + ((t -
$DS)/$FID)*between(t\\, $DS\\, $DS + $FID) + (-(t - $DE)/$FOD)*between(t\\, $DE
- $FOD\\, $DE) )\\, 0\\, 255) : x: 2 @}"
@end example
+@item
+Horizontally align multiple separate texts. Note that @var{max_glyph_a} and the
+@option{fontsize} value are included in the @option{y} offset.
+@example
+drawtext=fontfile=FreeSans.ttf:text=DOG:fontsize=24:x=10:y=20+24-max_glyph_a,
+drawtext=fontfile=FreeSans.ttf:text=cow:fontsize=24:x=80:y=20+24-max_glyph_a
+@end example
+
@end itemize
For more information about libfreetype, check:
--
2.11.0.rc2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf Of Michael Niedermayer > Sent: Tuesday, December 13, 2016 2:28 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable > openh264 load balancing. > > On Thu, Dec 01, 2016 at 03:52:55PM -0500, Gregory J. Wolfe wrote: > > The libopenh264 library allows the client to enable or disable > > load balancing when running multi-threaded. When enabled, the > > slice sizes are dynamically adjusted in order to use the > > multiple threads more efficiently. However, this can also lead > > to valid but slightly different results from run to run. > > Disabling load balancing prevents dynamic slice adjustment and > > yields repeatable results when running multi-threaded, which can > > be important when running test cases. > > > > Signed-off-by: Gregory J. Wolfe > > --- > > libavcodec/libopenh264enc.c | 8 > > 1 file changed, 8 insertions(+) > > Commit messages should start with the part that is changes like > libavcodec/libopenh264enc: ... > > please see the developer docs, if you haven't read them Sorry about that. Before submitting I carefully reviewed the "Submitting patches" and "patch submission checklist" sections, but neglected to also go back and review the "Development Policy" section where it talks about "area changed: ..." in the commit message. Will fix and resubmit. Suggestion: Add to the patch checklist section a reference back to this information (to remind infrequent patch submitters like me who forget stuff from the last time we submitted a patch). Greg W. > > thx > > [...] > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg
On Wed, Dec 14, 2016 at 14:23:05 +, Matteo Naccari wrote: > Ok, point taken on the av_* functions. On the handling bit, I was > thinking to flag the error via av_log and then call exit_program(1), > after, of course, having released the memory allocated up to that > point. Would that be ok? Certainly not, as exit_program() is for the programs, and neither available for nor acceptable in a library. In the library, you need to provide "exit" paths, and pass proper return/error codes through the functions and to the API. (Use of av_log(): Yes, where appropriate.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: fix linking with MSVC when using --disable-optimizations
From: Steve Lhomme
Without any optimization flags, MSVC does no dead code elimination (DCE) at
all, even for the most trivial cases. DCE is a prerequisite for building ffmpeg
correctly, otherwise there are undefined references to functions for other
architectures and disabled components.
-Os -Og is the minimal optimization flags for MSVC that does include DCE. It
warns that -Og will be removed but it doesn't work without. -O1 includes these
flags and some other ones not necessary to link properly.
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 9dfd006..1a8a05c 100755
--- a/configure
+++ b/configure
@@ -4087,6 +4087,7 @@ probe_cc(){
_DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
_cflags_speed="-O2"
_cflags_size="-O1"
+_cflags_noopt="-Os -Og"
if $_cc -nologo- 2>&1 | grep -q Linker; then
_ld_o='-out:$@'
else
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] Added Turing codec interface for ffmpeg
- This patch contains the changes to interface the Turing codec
(http://turingcodec.org/) with ffmpeg. The patch was modified to address
the comments in the review as follows:
- Added a pkg-config file to list all dependencies required by
libturing. This should address the issue pointed out by Hendrik
Leppkes on Fri 18/11/2016
- As per suggestions of wm4, two functions (add_option and
finalise_options) have been created. The former appends new options
while the latter sets up the argv array of pointers to char*
accordingly. add_option re-allocates the buffer for options using
av_realloc
- Additionally, both these functions handle the errors in case the
memory wasn't allocated correctly
- malloc|free|realloc have been substituted with their corresponding
av_{malloc|free|realloc} version
- Check on bit-depth has been removed since the ffmpeg already casts
the right pix_fmt and bit depth
- pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
---
LICENSE.md | 1 +
configure | 5 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libturing.c | 305 +
5 files changed, 313 insertions(+)
create mode 100644 libavcodec/libturing.c
diff --git a/LICENSE.md b/LICENSE.md
index 640633c..86e5371 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -85,6 +85,7 @@ The following libraries are under GPL:
- frei0r
- libcdio
- librubberband
+- libturing
- libvidstab
- libx264
- libx265
diff --git a/configure b/configure
index 9dfd006..2cc84e9 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
--enable-libssh enable SFTP protocol via libssh [no]
--enable-libtesseractenable Tesseract, needed for ocr filter [no]
--enable-libtheora enable Theora encoding via libtheora [no]
+ --enable-libturing enable H.265/HEVC encoding via libturing [no]
--enable-libtwolame enable MP2 encoding via libtwolame [no]
--enable-libv4l2 enable libv4l2/v4l-utils [no]
--enable-libvidstab enable video stabilization using vid.stab [no]
@@ -1560,6 +1561,7 @@ EXTERNAL_LIBRARY_LIST="
libssh
libtesseract
libtheora
+libturing
libtwolame
libv4l2
libvidstab
@@ -2855,6 +2857,7 @@ libspeex_decoder_deps="libspeex"
libspeex_encoder_deps="libspeex"
libspeex_encoder_select="audio_frame_queue"
libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
libtwolame_encoder_deps="libtwolame"
libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
libvorbis_decoder_deps="libvorbis"
@@ -5126,6 +5129,7 @@ die_license_disabled gpl frei0r
die_license_disabled gpl libcdio
die_license_disabled gpl librubberband
die_license_disabled gpl libsmbclient
+die_license_disabled gpl libturing
die_license_disabled gpl libvidstab
die_license_disabled gpl libx264
die_license_disabled gpl libx265
@@ -5784,6 +5788,7 @@ enabled libssh&& require_pkg_config libssh
libssh/sftp.h sftp_init
enabled libspeex && require_pkg_config speex speex/speex.h
speex_decoder_init -lspeex
enabled libtesseract && require_pkg_config tesseract tesseract/capi.h
TessBaseAPICreate
enabled libtheora && require libtheora theora/theoraenc.h th_info_init
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h
turing_version
enabled libtwolame&& require libtwolame twolame.h twolame_init
-ltwolame &&
{ check_lib twolame.h
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 23e41dd..6b3b2ba 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -881,6 +881,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER) += libspeexdec.o
OBJS-$(CONFIG_LIBSPEEX_ENCODER) += libspeexenc.o
OBJS-$(CONFIG_LIBTHEORA_ENCODER) += libtheoraenc.o
OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
+OBJS-$(CONFIG_LIBTURING_ENCODER) += libturing.o
OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
OBJS-$(CONFIG_LIBVORBIS_DECODER) += libvorbisdec.o
OBJS-$(CONFIG_LIBVORBIS_ENCODER) += libvorbisenc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index bbcecce..2c499db 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -611,6 +611,7 @@ void avcodec_register_all(void)
REGISTER_ENCDEC (LIBSPEEX, libspeex);
REGISTER_ENCODER(LIBTHEORA, libtheora);
REGISTER_ENCODER(LIBTWOLAME,libtwolame);
+REGISTER_ENCODER(LIBTURING, libturing);
REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
REGISTER_ENCDEC (LIBVORBIS, libvorbis);
REGISTER_ENCDEC (LIBVPX_VP8,libvpx_vp8);
diff --git a/libavcodec/libturin
Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg
> > It has. It points to the position in the options buffer which is going to be > filled with the command line being parsed. So it's not redundant. > > Then what does buffer_filled do? It keeps track on the number of characters written in the options buffer so far. I appreciate this could have been computed on the fly by doing: option_ctx->s - option_ctx->options but I though the code would have been more readable this way. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable openh264 load balancing.
On Wed, Dec 14, 2016 at 03:11:45PM +, Gregory J Wolfe wrote: > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf Of Michael Niedermayer > > Sent: Tuesday, December 13, 2016 2:28 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH] Allow client to enable/disable > > openh264 load balancing. > > > > On Thu, Dec 01, 2016 at 03:52:55PM -0500, Gregory J. Wolfe wrote: > > > The libopenh264 library allows the client to enable or disable > > > load balancing when running multi-threaded. When enabled, the > > > slice sizes are dynamically adjusted in order to use the > > > multiple threads more efficiently. However, this can also lead > > > to valid but slightly different results from run to run. > > > Disabling load balancing prevents dynamic slice adjustment and > > > yields repeatable results when running multi-threaded, which can > > > be important when running test cases. > > > > > > Signed-off-by: Gregory J. Wolfe > > > --- > > > libavcodec/libopenh264enc.c | 8 > > > 1 file changed, 8 insertions(+) > > > > Commit messages should start with the part that is changes like > > libavcodec/libopenh264enc: ... > > > > please see the developer docs, if you haven't read them > > Sorry about that. Before submitting I carefully reviewed the > "Submitting patches" and "patch submission checklist" sections, > but neglected to also go back and review the "Development > Policy" section where it talks about "area changed: ..." in the > commit message. Will fix and resubmit. > > Suggestion: Add to the patch checklist section a reference back > to this information (to remind infrequent patch submitters like me > who forget stuff from the last time we submitted a patch). you can send a patch to improve the patch submission checklist its in doc/developer.texi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] doc/filters: drawtext: add example of printing texts on same baseline
On Wed, 14 Dec 2016 14:37:47 +, Andrey Utkin wrote:
> * Added mention of @var{max_glyph_a} to "Note that..." phrase
>(is the markup used for this correct?)
It's basically author's preference since the usage in the docs is
mixed and inconsistent, and we don't have any specific guidelines or
rules regarding usage of Texinfo "commands". However, this list may be
helpful:
What mostly matters is that commands, options, values, etc are
presented in a way that differentiates them from descriptive text, and
that usage is consistent. So for consistency I changed it to @option,
and it seems more like an option to me than a "metasyntactic variable".
(If someone wants to volunteer to clean up the Texinfo commands in the
docs that would certainly be welcome, but I think it would be a boring
and tedious task.)
> doc/filters.texi | 8
> 1 file changed, 8 insertions(+)
Applied. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/libopenh264enc: Allow client to enable/disable openh264 load balancing.
The libopenh264 library allows the client to enable or disable
load balancing when running multi-threaded. When enabled, the
slice sizes are dynamically adjusted in order to use the
multiple threads more efficiently. However, this can also lead
to valid but slightly different results from run to run.
Disabling load balancing prevents dynamic slice adjustment and
yields repeatable results when running multi-threaded, which can
be important when running test cases.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 648f59b..e84de27 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -47,6 +47,7 @@ typedef struct SVCContext {
int skip_frames;
int skipped;
int cabac;
+int load_balancing;
} SVCContext;
#define OFFSET(x) offsetof(SVCContext, x)
@@ -71,6 +72,7 @@ static const AVOption options[] = {
{ "max_nal_size", "set maximum NAL size in bytes", OFFSET(max_nal_size),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ "allow_skip_frames", "allow skipping frames to hit the target bitrate",
OFFSET(skip_frames), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "cabac", "Enable cabac", OFFSET(cabac), AV_OPT_TYPE_INT, { .i64 = 0 },
0, 1, VE },
+{ "load_balancing", "enable/disable dynamic slice adjustment for efficient
use of multiple threads; if enabled, can produce valid but slightly different
results from run to run", OFFSET(load_balancing), AV_OPT_TYPE_BOOL, { .i64 = -1
}, 0, 1, VE },
{ NULL }
};
@@ -150,6 +152,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
param.iLoopFilterDisableIdc = !s->loopfilter;
param.iEntropyCodingModeFlag = 0;
param.iMultipleThreadIdc = avctx->thread_count;
+#if OPENH264_VER_AT_LEAST(1, 6)
+param.bUseLoadBalancing = s->load_balancing; // default is
enabled; -1 means not specified by client
+#else
+if ( s->load_balancing != -1 )
+av_log(avctx, AV_LOG_WARNING, "load_balancing = %d specified, but not
supported prior to libopenh264 v1.6\n", s->load_balancing);
+#endif
if (s->profile && !strcmp(s->profile, "main"))
param.iEntropyCodingModeFlag = 1;
else if (!s->profile && s->cabac)
--
2.5.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ARM fate
Am 14.12.16 um 13:56 schrieb Michael Niedermayer: > On Tue, Dec 13, 2016 at 08:35:43PM +0100, Thilo Borgmann wrote: >> Am 12.12.16 um 22:18 schrieb Michael Niedermayer: >>> Hi all >>> >>> The panda arm board iam using as fate client for fate.ffmpeg.org seems >>> not really able to handle the load. >>> Iam not sure why, but increasing number of fate tests, branches it >>> tests and compiler/option cases probably are the primary reason. >>> I already dropped half the branches it tests but it still needs >>> apparently on the order of a week for a single pass. >>> >>> It would make alot of sense if more people could help here and run >>> some arm fate clients so that stuff gets tested more regularly and >>> with less latency >> >> I'm currently setting up another FATE on a dragonboard (Cortex-A53). > > ok > > >> (And maintaining all my other clients) > > i see 2 fate clients with comment "TB", didnt you have more > clients? > the 2 fail > http://fatebeta.ffmpeg.org/report/aarch64-bo/20161214010115 fails build > > http://fate.ffmpeg.org/history.cgi?slot=armv7-ios802-clang fails all tests > except one and never did better since march 2015 according to the history > on the webpage I tend to have two and an iPhone that never completely worked. Except for the iPhone I'm sure to update the others soon as well. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/libopenh264enc: Save FFmpeg colorspace info in openh264 video files.
As of version 1.6, libopenh264 saves (in the output video file)
information about the color primaries, transfer characteristics,
and color matrix used when the video pixel data was created.
This patch sets the required libopenh264 data structures using
the FFmpeg colorspace information so that video players will
know how to properly decode video files created using FFmpeg
and libopenh264.
Signed-off-by: Gregory J. Wolfe
---
libavcodec/libopenh264enc.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index e84de27..d8a7ea3 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -205,6 +205,67 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
+#if OPENH264_VER_AT_LEAST(1, 6)
+// set video signal type information
+param.sSpatialLayers[0].bVideoSignalTypePresent = true;
+param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF; // default; choices are
VF_: COMPONENT, PAL, NTSC, SECAM, MAC, UNDEF
+param.sSpatialLayers[0].bFullRange = avctx->color_range ==
AVCOL_RANGE_JPEG;
+param.sSpatialLayers[0].bColorDescriptionPresent = true;
+// These switches are intended to filter out all but the values supported
by libopenh264.
+// An unsupported value causes the associated quantity to be set to
"unspecified" and a
+// warning message to be issued.
+switch (avctx->color_primaries) {
+case AVCOL_PRI_BT709:param.sSpatialLayers[0].uiColorPrimaries
= CP_BT709; break;
+case AVCOL_PRI_UNSPECIFIED: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF; break;
+case AVCOL_PRI_BT470M: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470M;break;
+case AVCOL_PRI_BT470BG: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT470BG; break;
+case AVCOL_PRI_SMPTE170M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE170M; break;
+case AVCOL_PRI_SMPTE240M:param.sSpatialLayers[0].uiColorPrimaries
= CP_SMPTE240M; break;
+case AVCOL_PRI_FILM: param.sSpatialLayers[0].uiColorPrimaries
= CP_FILM; break;
+case AVCOL_PRI_BT2020: param.sSpatialLayers[0].uiColorPrimaries
= CP_BT2020;break;
+default: param.sSpatialLayers[0].uiColorPrimaries
= CP_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported color primaries value %d
was specified;"
+" color primaries value has been set to \"unspecified\"\n",
avctx->color_primaries);
+break;
+}
+switch (avctx->color_trc) {
+case AVCOL_TRC_BT709:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT709;break;
+case AVCOL_TRC_UNSPECIFIED:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;break;
+case AVCOL_TRC_GAMMA22:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470M; break;
+case AVCOL_TRC_GAMMA28:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT470BG; break;
+case AVCOL_TRC_SMPTE170M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE170M;break;
+case AVCOL_TRC_SMPTE240M:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_SMPTE240M;break;
+case AVCOL_TRC_LINEAR:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LINEAR; break;
+case AVCOL_TRC_LOG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG100; break;
+case AVCOL_TRC_LOG_SQRT:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_LOG316; break;
+case AVCOL_TRC_IEC61966_2_4:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_4; break;
+case AVCOL_TRC_BT1361_ECG:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT1361E; break;
+case AVCOL_TRC_IEC61966_2_1:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_IEC61966_2_1; break;
+case AVCOL_TRC_BT2020_10:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_10;break;
+case AVCOL_TRC_BT2020_12:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_BT2020_12;break;
+default:
param.sSpatialLayers[0].uiTransferCharacteristics = TRC_UNDEF;
+av_log(avctx, AV_LOG_WARNING, "Unsupported transfer characteristics
value %d was specified;"
+" transfer characteristics value has been set to
\"unspecified\"\n", avctx->color_trc);
+break;
+}
+switch (avctx->colorspace) {
+case AVCOL_SPC_RGB: param.sSpatialLayers[0].uiColorMatrix
= CM_GBR; break;
+case AVCOL_SPC_BT709:param.sSpatialLayers[0].uiColorMatrix
= CM_BT709; break;
+case AVCOL_SPC_UNSPECIFIED: param.sSpatialLayers[0].uiColorMatrix
= CM_UNDEF; break;
+case AVCOL_SPC_FCC:
[FFmpeg-devel] one bug of getting wrong sample rate when receiving rtmp stream
Hi, I found one bug, where ffmpeg functions can't get precise audio sample rate when receiving rtmp stream. 1st method: If avformat_open_input() and avformat_find_stream_info() is used to parse rtmp stream, audio sample rate can be calculated correctly. 2nd method: But if av_format_set_audio_codec() is used just like ffmpeg program does before avformat_open_input() and avformat_find_stream_info(), ffmpeg functions can't calculate precise sample rate. For example, if there is one audio rtmp stream, where sample rate is 48000Hz and audio codec is aac. If aac codec is preset by using av_format_set_audio_codec(), ffmpeg will return wrong sample rate of 44100 Hz. The reason is that rtmp stream should be sent to flv demuxer, which only support four kinds of sample rate and doesn't support 48000Hz. Therefore, ffmpeg functions can't get correct sample rate by using the 2nd method. Is it a bug? how to fix it? Thanks Regards Andrew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264 encode profile
On 14/12/16 01:55, Jun Zhao wrote:
> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
> From: Yi A Wang
> Date: Tue, 13 Dec 2016 10:50:54 +0800
> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
> encode profile
>
> add h264 encode profile option and update the docs, for avc
> constrained baseline, disable B frames base on H.264 spec Annex A.2.1
>
> Signed-off-by: Jun Zhao
> Signed-off-by: Yi A Wang
> ---
> doc/codecs.texi| 8
> libavcodec/options_table.h | 5 -
> libavcodec/vaapi_encode_h264.c | 5 +
> 3 files changed, 17 insertions(+), 1 deletion(-)
Notwithstanding the below, this should probably be two patches (one for
options/docs, one for VAAPI).
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index 9a3a56d..9ee9061 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -893,6 +893,14 @@ Possible values:
>
> @item dts_hd_ma
>
> +@item hevc_main10
> +
> +@item h264_constrained_baseline
> +
> +@item h264_main
> +
> +@item h264_high
> +
> @end table
>
> @item level @var{integer} (@emph{encoding,audio,video})
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 3fe7925..94b2d9b 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -395,7 +395,10 @@ static const AVOption avcodec_options[] = {
> {"mpeg4_core", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_CORE },
> INT_MIN, INT_MAX, V|E, "profile"},
> {"mpeg4_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_MAIN },
> INT_MIN, INT_MAX, V|E, "profile"},
> {"mpeg4_asp", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
> -{"main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 },
> INT_MIN, INT_MAX, V|E, "profile"},
This table is part of the public API of libavcodec, you can't remove things
from it like this.
> +{"hevc_main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10
> }, INT_MIN, INT_MAX, V|E, "profile"},
> +{"h264_constrained_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_PROFILE_H264_CONSTRAINED_BASELINE}, INT_MIN, INT_MAX, V|E, "profile"},
> +{"h264_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_MAIN},
> INT_MIN, INT_MAX, V|E, "profile"},
> +{"h264_high", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_HIGH},
> INT_MIN, INT_MAX, V|E, "profile"},
This seems reasonable, but I'd like to hear from other people why there is only
a small subset of video profiles there already? Confusingly, the libx264,
nvenc and videotoolbox encoders all have private options (also called
"profile") which implement exactly the same thing where they could be using the
generic one (were it to support suitable options).
If the change is desirable, it should probably get the full set of profiles
corresponding to FF_PROFILE_H264_* values rather than just a restricted set
coming from what VAAPI exposes. (Also deprecate the anomalous "main10" and add
the H.265 profiles properly as well, I guess?)
> {"level", NULL, OFFSET(level), AV_OPT_TYPE_INT, {.i64 = FF_LEVEL_UNKNOWN },
> INT_MIN, INT_MAX, V|A|E, "level"},
> {"unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_LEVEL_UNKNOWN }, INT_MIN,
> INT_MAX, V|A|E, "level"},
> {"lowres", "decode at 1= 1/2, 2=1/4, 3=1/8 resolutions", OFFSET(lowres),
> AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, V|A|D},
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 69cc483..5f37770 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -1190,6 +1190,11 @@ static av_cold int
> vaapi_encode_h264_init(AVCodecContext *avctx)
> switch (avctx->profile) {
> case FF_PROFILE_H264_CONSTRAINED_BASELINE:
> ctx->va_profile = VAProfileH264ConstrainedBaseline;
> +if (avctx->max_b_frames != 0) {
> +avctx->max_b_frames = 0;
> +av_log(avctx, AV_LOG_WARNING, "H.264 constrained baseline "
> + "profile don't support encode B frame.\n");
..." doesn't support encoding B frames.\n", maybe
> +}
I guess this makes sense. It's not really a bitstream restriction, though,
only a conformance one - you can perfectly well make a usable stream with
profile_idc 66 which contains B frames (though only decodable with an extended
or main profile decoder), and indeed the i965 encoder is happy to do so.
Should that matter?
> break;
> case FF_PROFILE_H264_BASELINE:
> ctx->va_profile = VAProfileH264Baseline;
In any case, the restriction applies to baseline profile as well as constrained
baseline.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264 encode profile
On Thu, Dec 15, 2016 at 12:02 AM, Mark Thompson wrote:
> On 14/12/16 01:55, Jun Zhao wrote:
>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>> From: Yi A Wang
>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
>> encode profile
>>
>> add h264 encode profile option and update the docs, for avc
>> constrained baseline, disable B frames base on H.264 spec Annex A.2.1
>>
>> Signed-off-by: Jun Zhao
>> Signed-off-by: Yi A Wang
>> ---
>> doc/codecs.texi| 8
>> libavcodec/options_table.h | 5 -
>> libavcodec/vaapi_encode_h264.c | 5 +
>> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> Notwithstanding the below, this should probably be two patches (one for
> options/docs, one for VAAPI).
>
>
>> diff --git a/doc/codecs.texi b/doc/codecs.texi
>> index 9a3a56d..9ee9061 100644
>> --- a/doc/codecs.texi
>> +++ b/doc/codecs.texi
>> @@ -893,6 +893,14 @@ Possible values:
>>
>> @item dts_hd_ma
>>
>> +@item hevc_main10
>> +
>> +@item h264_constrained_baseline
>> +
>> +@item h264_main
>> +
>> +@item h264_high
>> +
>> @end table
>>
>> @item level @var{integer} (@emph{encoding,audio,video})
>> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
>> index 3fe7925..94b2d9b 100644
>> --- a/libavcodec/options_table.h
>> +++ b/libavcodec/options_table.h
>> @@ -395,7 +395,10 @@ static const AVOption avcodec_options[] = {
>> {"mpeg4_core", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_CORE },
>> INT_MIN, INT_MAX, V|E, "profile"},
>> {"mpeg4_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_MAIN },
>> INT_MIN, INT_MAX, V|E, "profile"},
>> {"mpeg4_asp", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
>> -{"main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 },
>> INT_MIN, INT_MAX, V|E, "profile"},
>
> This table is part of the public API of libavcodec, you can't remove things
> from it like this.
>
>> +{"hevc_main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_HEVC_MAIN_10 }, INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_constrained_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_H264_CONSTRAINED_BASELINE}, INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_MAIN},
>> INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_high", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_HIGH},
>> INT_MIN, INT_MAX, V|E, "profile"},
>
> This seems reasonable, but I'd like to hear from other people why there is
> only a small subset of video profiles there already? Confusingly, the
> libx264, nvenc and videotoolbox encoders all have private options (also
> called "profile") which implement exactly the same thing where they could be
> using the generic one (were it to support suitable options).
>
> If the change is desirable, it should probably get the full set of profiles
> corresponding to FF_PROFILE_H264_* values rather than just a restricted set
> coming from what VAAPI exposes. (Also deprecate the anomalous "main10" and
> add the H.265 profiles properly as well, I guess?)
>
The reason for private profiles is quite simply that you don't want to
type "hevc_main10", but just "main10", for example. On top of that,
how far do you take this, do you put every single codecs profiles into
the shared table? Or just the ones where we have multiple encoders?
What if they don't support the same profiles? You wouldn't have any
easy way to get a list of thigns it does support (which you could do
with private options)
It gets complicated fast.
I would argue that vaapi should just follow the trend and use its own
private profiles, unless we decide to change all of them one day.
Until that point, if someone wanted, they could factor the profile
lists out of current code and share them in a header/c file somewhere
to be able to be reused.
Unfortunately I didn't pay attention when main10 was added, or that
might have been avoided, as its inconsistent with any other options we
have in there and the only hevc profile.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643950
From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Fri, 2 Dec 2016 18:10:39 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643950
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2a69890..7254505 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -739,6 +739,8 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb, MOVAtom atom)
title_size = atom.size - 24;
if (title_size > 0) {
+if (title_size >= UINT_MAX)
+return AVERROR_INVALIDDATA;
title_str = av_malloc(title_size + 1); /* Add null terminator */
if (!title_str)
return AVERROR(ENOMEM);
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643951
From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Tue, 6 Dec 2016 12:33:08 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643951
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7254505..e506d20 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4393,6 +4393,8 @@ static int mov_read_uuid(MOVContext *c, AVIOContext *pb, MOVAtom atom)
} else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
uint8_t *buffer;
size_t len = atom.size - sizeof(uuid);
+if (len >= UINT_MAX)
+return AVERROR_INVALIDDATA;
buffer = av_mallocz(len + 1);
if (!buffer) {
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in mov_read_{senc, saiz, udta_string}()
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643952
From 8622f9398e7c89a664c4c2ceff9d35b89ff17bb5 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Tue, 6 Dec 2016 12:54:23 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in
mov_read_{senc,saiz,udta_string}()
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643952
---
libavformat/mov.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e506d20..87ad91a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -404,7 +404,7 @@ retry:
return ret;
} else if (!key && c->found_hdlr_mdta && c->meta_keys) {
uint32_t index = AV_RB32(&atom.type);
-if (index < c->meta_keys_count) {
+if (index < c->meta_keys_count && index > 0) {
key = c->meta_keys[index];
} else {
av_log(c->fc, AV_LOG_WARNING,
@@ -4502,8 +4502,8 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
avio_rb32(pb);/* entries */
-if (atom.size < 8) {
-av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" too small\n", atom.size);
+if (atom.size < 8 || atom.size > UINT_MAX) {
+av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" invalid\n", atom.size);
return AVERROR_INVALIDDATA;
}
@@ -4571,6 +4571,11 @@ static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}
+if (atom.size > UINT_MAX) {
+av_log(c->fc, AV_LOG_ERROR, "saiz atom auxiliary_info_sizes size %"PRId64" invalid\n", atom.size);
+return AVERROR_INVALIDDATA;
+}
+
/* save the auxiliary info sizes as is */
data_size = atom.size - atom_header_size;
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/utils.c Protect against accessing entries[nb_entries]
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference: https://crbug.com/666770
From e91355afac548fbc7cc0cb4ecbc06dce6495df80 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Mon, 21 Nov 2016 15:54:02 -0800
Subject: [PATCH] lavf/utils.c Protect against accessing entries[nb_entries]
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference: https://crbug.com/666770
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index fb17423..b2d25eb 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1968,7 +1968,7 @@ int ff_index_search_timestamp(const AVIndexEntry *entries, int nb_entries,
m = (a + b) >> 1;
// Search for the next non-discarded packet.
-while ((entries[m].flags & AVINDEX_DISCARD_FRAME) && m < b) {
+while ((entries[m].flags & AVINDEX_DISCARD_FRAME) && m < b && m < nb_entries - 1) {
m++;
if (m == b && entries[m].timestamp >= wanted_timestamp) {
m = b - 1;
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/libopusdec.c Fix ff_vorbis_channel_layouts OOB
Similar to existing lavc/vorbisdec.c code which first checks that
avc->channels is valid for accessing ff_vorbis_channel_layouts, this
change adds protection to libopusdec.c to prevent accessing that
array with a negative index. Reference https://crbug.com/666794.
From 141e56ccf7fc56646424484d357b6c74a486d2e2 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Mon, 21 Nov 2016 17:30:50 -0800
Subject: [PATCH] lavc/libopusdec.c Fix ff_vorbis_channel_layouts OOB
Similar to existing lavc/vorbisdec.c code which first checks that
avc->channels is valid for accessing ff_vorbis_channel_layouts, this
change adds protection to libopusdec.c to prevent accessing that
array with a negative index. Reference https://crbug.com/666794.
---
libavcodec/libopusdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index acc62f1..c2c7adc 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@ -50,6 +50,10 @@ static av_cold int libopus_decode_init(AVCodecContext *avc)
avc->sample_rate= 48000;
avc->sample_fmt = avc->request_sample_fmt == AV_SAMPLE_FMT_FLT ?
AV_SAMPLE_FMT_FLT : AV_SAMPLE_FMT_S16;
+if (avc->channels <= 0) {
+av_log(avc, AV_LOG_ERROR, "Invalid number of channels\n");
+return AVERROR(EINVAL);
+}
avc->channel_layout = avc->channels > 8 ? 0 :
ff_vorbis_channel_layouts[avc->channels - 1];
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mp3dec: fix msan warning when verifying mpa header
MPEG Audio frame header must be 4 bytes. If we fail to read 4 bytes bail early to avoid Use-of-uninitialized-value msan error. Reference https://crbug.com/666874. From 5ed6e20c09840320784c43b86b75b3ede69742f6 Mon Sep 17 00:00:00 2001 From: Chris Cunningham Date: Tue, 22 Nov 2016 13:54:50 -0800 Subject: [PATCH] mp3dec: fix msan warning when verifying mpa header MPEG Audio frame header must be 4 bytes. If we fail to read 4 bytes bail early to avoid Use-of-uninitialized-value msan error. Reference https://crbug.com/666874. --- libavformat/mp3dec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c index 291cf56..64217b2 100644 --- a/libavformat/mp3dec.c +++ b/libavformat/mp3dec.c @@ -461,7 +461,8 @@ static int check(AVIOContext *pb, int64_t pos, uint32_t *ret_header) return CHECK_SEEK_FAILED; ret = avio_read(pb, &header_buf[0], 4); -if (ret < 0) +/* We should always find four bytes for a valid mpa header. */ +if (ret < 4) return CHECK_SEEK_FAILED; header = AV_RB32(&header_buf[0]); -- 2.8.0.rc3.226.g39d4020 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/wavdec.c: Fix unresolved symbols on Mac and VS2015 Update 3
Some toolchains failed to link a dynamic library containing wavdec.c,
but with either CONFIG_SPDIF_DEMUXER or CONFIG_W64_DEMUXER disabled.
This change adds #if's to explicitly exclude code rather than depend on
toolchain code elision of same condition using "if".
Reference https://crbug.com/591845. Adapted from 2 Chromium ffmpeg
patches for code style:
b281073a7b1ccff67b2cd8ec636facceeeb82327
5d76f94a515900260f185d5949f72ed6fa4bdd94
From 77add30b68373c2862520513cb7992b03352b9af Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Wed, 14 Dec 2016 15:01:37 -0800
Subject: [PATCH] lavf/wavdec.c: Fix unresolved symbols on Mac and VS2015
Update 3
Some toolchains failed to link a dynamic library containing wavdec.c,
but with either CONFIG_SPDIF_DEMUXER or CONFIG_W64_DEMUXER disabled.
This change adds #if's to explicitly exclude code rather than depend on
toolchain code elision of same condition using "if".
Reference https://crbug.com/591845. Adapted from 2 Chromium ffmpeg
patches for code style:
b281073a7b1ccff67b2cd8ec636facceeeb82327
5d76f94a515900260f185d5949f72ed6fa4bdd94
---
libavformat/wavdec.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 7176cd6..bb250ac 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -62,7 +62,8 @@ typedef struct WAVDemuxContext {
static void set_spdif(AVFormatContext *s, WAVDemuxContext *wav)
{
-if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
+#if CONFIG_SPDIF_DEMUXER
+if (s->streams[0]->codecpar->codec_tag == 1) {
enum AVCodecID codec;
uint8_t *buf = NULL;
int len = 1<<16;
@@ -93,6 +94,7 @@ end:
av_log(s, AV_LOG_WARNING, "Cannot check for SPDIF\n");
av_free(buf);
}
+#endif /* CONFIG_SPDIF_DEMUXER */
}
#if CONFIG_WAV_DEMUXER
@@ -598,8 +600,10 @@ static int wav_read_packet(AVFormatContext *s, AVPacket *pkt)
AVStream *st;
WAVDemuxContext *wav = s->priv_data;
-if (CONFIG_SPDIF_DEMUXER && wav->spdif == 1)
+#if CONFIG_SPDIF_DEMUXER
+if (wav->spdif == 1)
return ff_spdif_read_packet(s, pkt);
+#endif /* CONFIG_SPDIF_DEMUXER */
if (wav->smv_data_ofs > 0) {
int64_t audio_dts, video_dts;
@@ -654,10 +658,14 @@ smv_out:
if (wav->ignore_length)
left = INT_MAX;
if (left <= 0) {
-if (CONFIG_W64_DEMUXER && wav->w64)
+#if CONFIG_W64_DEMUXER
+if (wav->w64)
left = find_guid(s->pb, ff_w64_guid_data) - 24;
else
left = find_tag(wav, s->pb, MKTAG('d', 'a', 't', 'a'));
+#else
+left = find_tag(wav, s->pb, MKTAG('d', 'a', 't', 'a'));
+#endif /* CONFIG_W64_DEMUXER */
if (left < 0) {
wav->audio_eof = 1;
if (wav->smv_data_ofs > 0 && !wav->smv_eof)
--
2.8.0.rc3.226.g39d4020
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] 4xm: prevent overflow during bit rate calculation
On 14.12.2016 02:46, Ronald S. Bultje wrote: > Not wanting to discourage you, but I wonder if there's really a point to > this...? These patches are prerequisites for enforcing the validity of codec parameters [1]. > I don't see how the user experience changes. Users won't see ffmpeg claiming nonsense bit rates like -1184293205235990 kb/s anymore. > This isn't specifically intended at this patch, but rather at the sort of > rabbit hole this change might lead to, I have a pretty good map of this rabbit hole (i.e. lots of samples triggering UBSan errors) and one day I might try to dig it up, but for now I'm limiting myself to the codec parameters. > which would cause the code to be uber-full of such checks, none of which > really have any significance. But maybe others disagree... Not relying on undefined behavior is a significant improvement. And doing these checks consequently where the values are set makes it possible for other code to rely on their validity without further checks. Best regards, Andreas 1: https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161026/c0151e90/attachment.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va
On Wed, 14 Dec 2016 11:44:13 +0100 wm4 wrote: > On Wed, 14 Dec 2016 09:30:35 + > Stève Lhomme wrote: > > > On Tue, Dec 13, 2016 at 2:35 PM, wm4 wrote: > > > On Tue, 13 Dec 2016 14:19:35 +0100 > > > Steve Lhomme wrote: > > > > > > > I'm pretty much against this, since it duplicates the profile > > > selection code all over again, even if it could be shared. (And > > > this code should be in libavcodec in the first place.) Someone > > > adding such code would have to refactor ffmpeg_d3d11va too. > > > > I'm not sure how this relates to the line above. d3d11va and dxva2 > > are definitely not the same thing. On mobile you do not have DXVA2 > > at all but D3D11(VA) is present. There must be a way to have one > > without the other. > > Yeah, but selection of the decoder GUIDs is very similar between both > APIs. It can definitely be shared (we do this in mpv). There's > absolutely no reason to copy-paste that stuff from ffmpeg_dxva2.c into > ffmpeg_d3d11va.c. > is having this duplication a blocker to this patch would you say? > As for how libavcodec can do provide this part, see the Libav/avconv > vaapi support (none of that is in ffmpeg yet). same question here. i am not arguing one way or the other, just asking. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] 4xm: prevent overflow during bit rate calculation
On 14.12.2016 03:54, Michael Niedermayer wrote: > On Wed, Dec 14, 2016 at 01:57:54AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/4xm.c | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] mov: prevent overflow during bit rate calculation
On 14.12.2016 04:24, Michael Niedermayer wrote:
> On Wed, Dec 14, 2016 at 01:58:35AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/mov.c | 15 ++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 6c8affc..fc0b25c 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -5887,8 +5887,15 @@ static int mov_read_header(AVFormatContext *s)
>> for (i = 0; i < s->nb_streams; i++) {
>> AVStream *st = s->streams[i];
>> MOVStreamContext *sc = st->priv_data;
>> -if (st->duration > 0)
>> +if (st->duration > 0) {
>> +if (sc->data_size > INT64_MAX / sc->time_scale / 8) {
>> +av_log(s, AV_LOG_ERROR, "Overflow during bit rate
>> calculation %"PRId64" * 8 * %d\n",
>> + sc->data_size, sc->time_scale);
>> +mov_read_close(s);
>> +return AVERROR_INVALIDDATA;
>> +}
>> st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale
>> / st->duration;
>> +}
>> }
>> }
>>
>> @@ -5897,6 +5904,12 @@ static int mov_read_header(AVFormatContext *s)
>> AVStream *st = s->streams[i];
>> MOVStreamContext *sc = st->priv_data;
>> if (sc->duration_for_fps > 0) {
>> +if (sc->data_size > INT64_MAX / sc->time_scale / 8) {
>> +av_log(s, AV_LOG_ERROR, "Overflow during bit rate
>> calculation %"PRId64" * 8 * %d\n",
>> + sc->data_size, sc->time_scale);
>> +mov_read_close(s);
>> +return AVERROR_INVALIDDATA;
>> +}
>> st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale
>> /
>> sc->duration_for_fps;
>
> maybe this can be factored somehow
This is just twice, so factoring out isn't really worth it.
(The really repetitive stuff of validating codec parameters will
be factored out properly, but that's still work in progress.)
> but either way probably ok
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] cafdec: prevent overflow during bit rate calculation
On 14.12.2016 13:36, Michael Niedermayer wrote: > On Wed, Dec 14, 2016 at 01:58:17AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/cafdec.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > probably ok Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] tiff: fix overflows when calling av_readuce
On 14.12.2016 13:34, Michael Niedermayer wrote: > On Wed, Dec 14, 2016 at 12:57:12AM +0100, Andreas Cadhalpun wrote: >> tiff.c | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> 96297593c98fcbce7395cb13627fae080f1e2cbc >> 0001-tiff-fix-overflows-when-calling-av_reduce.patch >> From 3cd8cb663d762bc15694e285ea48cdb8e9abfd4b Mon Sep 17 00:00:00 2001 >> From: Andreas Cadhalpun >> Date: Tue, 13 Dec 2016 00:43:21 +0100 >> Subject: [PATCH] tiff: fix overflows when calling av_reduce >> >> The arguments of av_reduce are signed, so the cast to uint64_t is misleading. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavcodec/tiff.c | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/flacdsp: Avoid undefined operations in non debug builds
This fixes ubsan warnings in non debug builds by using unsigned operations
in debug builds the correct signed operations are retained so that overflows
(which should not occur in valid files and may indicate problems in the DSP code
or decoder) can be detected.
Alternatively they can be changed to unsigned unconditionally, then its
not possible though to detect overflows easily if someone wants to test
the DSP code for overflows.
The 2nd alternative would be to leave the code as it is and accept that
there are undefined operations in the DSP code and that ubsan output is
full of them in some cases.
Similar changes would be needed in some other DSP routines
Suggested-by: Matt Wolenetz
Signed-off-by: Michael Niedermayer
---
libavcodec/flacdsp.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/flacdsp.c b/libavcodec/flacdsp.c
index 30b66484e8..180d4e7ba6 100644
--- a/libavcodec/flacdsp.c
+++ b/libavcodec/flacdsp.c
@@ -43,14 +43,22 @@
#define PLANAR 1
#include "flacdsp_template.c"
+// For debuging we use signed operations so overflows can be detected (by
ubsan)
+// For production we use unsigned so there are no undefined operations
+#ifdef DEBUG
+#define SUINT int
+#else
+#define SUINT unsigned
+#endif
+
static void flac_lpc_16_c(int32_t *decoded, const int coeffs[32],
int pred_order, int qlevel, int len)
{
int i, j;
for (i = pred_order; i < len - 1; i += 2, decoded += 2) {
-int c = coeffs[0];
-int d = decoded[0];
+SUINT c = coeffs[0];
+SUINT d = decoded[0];
int s0 = 0, s1 = 0;
for (j = 1; j < pred_order; j++) {
s0 += c*d;
@@ -66,7 +74,7 @@ static void flac_lpc_16_c(int32_t *decoded, const int
coeffs[32],
if (i < len) {
int sum = 0;
for (j = 0; j < pred_order; j++)
-sum += coeffs[j] * decoded[j];
+sum += coeffs[j] * (SUINT)decoded[j];
decoded[j] += sum >> qlevel;
}
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Suspected incorrect negative cts_offset handling in mp4 trun box muxing
Per spec, if cts_offset is negative, the trun box version needs to be set to 1. Yet I see no corresponding condition around this in libavformat/movenc.c; version is hardcoded to 0 and the *signed int32* typed value (track->cluster[i].cts) is written out (with a conversion to unsigned int32 with same underlying bits in call to avio.wb32()). This can cause issues in players if they follow the spec and expect a version 0 box to contain unsigned int32 cts_offset values. If ffmpeg had a negative track->cluster[i].cts value, a conformant player will interpret that value as a huge positive value (due to version 0 logic). Does ffmpeg somehow guarantee that trun cts_offsets are always positive? If not, this looks like a bug in ffmpeg mp4 muxing. (Reference https://bugs.chromium.org/p/chromium/issues/detail?id=650584#c7) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] omadec: fix overflows during bit rate calculation
On 14.12.2016 11:16, Moritz Barsnick wrote: > On Wed, Dec 14, 2016 at 01:02:41 +0100, Andreas Cadhalpun wrote: >> On 13.12.2016 08:11, Paul B Mahol wrote: -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048; +st->codecpar->bit_rate= samplerate * framesize / 256; >> >> Why multiply with 8 when dividing by a multiple of 8 directly afterwards? >> That's just a waste of computational resources. > > I can only explain the term with "readability" (e.g. "number of bytes > times 8 is number of bits, divided by 2048 is the rate"). If you > bracket the (8 / 2048), it would avoid the overflow, and the compiler > should evaluate the term to that constant 256 anyway, right? (Just if > anyone cares about the presumed readability.) Well, (8 / 2048) = 0, but one can do "/ (2048 / 8)". Attached is a version doing it that way. Do you think that's better? Best regards, Andreas >From 6bf8af5e8db1986ec1e30143a088b91041eb9ead Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Tue, 13 Dec 2016 00:35:12 +0100 Subject: [PATCH] omadec: fix overflows during bit rate calculation Signed-off-by: Andreas Cadhalpun --- libavformat/omadec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/omadec.c b/libavformat/omadec.c index 6e476db..757ae53 100644 --- a/libavformat/omadec.c +++ b/libavformat/omadec.c @@ -365,7 +365,7 @@ static int oma_read_header(AVFormatContext *s) st->codecpar->channels= 2; st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO; st->codecpar->sample_rate = samplerate; -st->codecpar->bit_rate= st->codecpar->sample_rate * framesize * 8 / 1024; +st->codecpar->bit_rate= st->codecpar->sample_rate * framesize / (1024 / 8); /* fake the ATRAC3 extradata * (wav format, makes stream copy to wav work) */ @@ -398,7 +398,7 @@ static int oma_read_header(AVFormatContext *s) return AVERROR_INVALIDDATA; } st->codecpar->sample_rate = samplerate; -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048; +st->codecpar->bit_rate= samplerate * framesize / (2048 / 8); avpriv_set_pts_info(st, 64, 1, samplerate); break; case OMA_CODECID_MP3: -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] electronicarts: prevent overflow during block alignment, calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/electronicarts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 30eb723..35a7363 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -539,7 +539,7 @@ static int ea_read_header(AVFormatContext *s)
ea->audio_codec = 0;
return 1;
}
-if (ea->bytes <= 0) {
+if (ea->bytes <= 0 || ea->bytes > INT_MAX / 8 / 2) {
av_log(s, AV_LOG_ERROR,
"Invalid number of bytes per sample: %d\n", ea->bytes);
ea->audio_codec = AV_CODEC_ID_NONE;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] genh: prevent overflow during block alignment calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/genh.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/genh.c b/libavformat/genh.c
index b683e02..5684352 100644
--- a/libavformat/genh.c
+++ b/libavformat/genh.c
@@ -74,6 +74,11 @@ static int genh_read_header(AVFormatContext *s)
case 0: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_PSX;break;
case 1:
case 11: st->codecpar->bits_per_coded_sample = 4;
+ if (st->codecpar->channels > INT_MAX / 36) {
+av_log(s, AV_LOG_ERROR, "Overflow during block alignment
calculation 36 * %d\n",
+ st->codecpar->channels);
+return AVERROR_INVALIDDATA;
+ }
st->codecpar->block_align = 36 * st->codecpar->channels;
st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_WAV;break;
case 2: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_DTK;break;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] 4xm: prevent overflow during block alignment calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/4xm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index 2758b69..308d889 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -187,6 +187,11 @@ static int parse_strk(AVFormatContext *s,
st->codecpar->bit_rate = (int64_t)st->codecpar->channels *
st->codecpar->sample_rate *
st->codecpar->bits_per_coded_sample;
+if (st->codecpar->channels && st->codecpar->bits_per_coded_sample >
INT_MAX / st->codecpar->channels) {
+av_log(s, AV_LOG_ERROR, "Overflow during block alignment calculation
%d * %d\n",
+ st->codecpar->channels, st->codecpar->bits_per_coded_sample);
+return AVERROR_INVALIDDATA;
+}
st->codecpar->block_align = st->codecpar->channels *
st->codecpar->bits_per_coded_sample;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] ircamdec: prevent overflow during block alignment, calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/ircamdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
index 59f3a49..3efc2b4 100644
--- a/libavformat/ircamdec.c
+++ b/libavformat/ircamdec.c
@@ -96,6 +96,11 @@ static int ircam_read_header(AVFormatContext *s)
}
st->codecpar->bits_per_coded_sample =
av_get_bits_per_sample(st->codecpar->codec_id);
+if (st->codecpar->channels && st->codecpar->bits_per_coded_sample >
INT_MAX / st->codecpar->channels) {
+av_log(s, AV_LOG_ERROR, "Overflow during block alignment calculation
%d * %d\n",
+ st->codecpar->bits_per_coded_sample, st->codecpar->channels);
+return AVERROR_INVALIDDATA;
+}
st->codecpar->block_align = st->codecpar->bits_per_coded_sample *
st->codecpar->channels / 8;
avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
avio_skip(s->pb, 1008);
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] nistspheredec: prevent overflow during block alignment, calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/nistspheredec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
index 782d1df..9472e47 100644
--- a/libavformat/nistspheredec.c
+++ b/libavformat/nistspheredec.c
@@ -80,6 +80,11 @@ static int nist_read_header(AVFormatContext *s)
avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
+if (st->codecpar->channels && st->codecpar->bits_per_coded_sample
> INT_MAX / st->codecpar->channels) {
+av_log(s, AV_LOG_ERROR, "Overflow during block alignment
calculation %d * %d\n",
+ st->codecpar->bits_per_coded_sample,
st->codecpar->channels);
+return AVERROR_INVALIDDATA;
+}
st->codecpar->block_align = st->codecpar->bits_per_coded_sample *
st->codecpar->channels / 8;
if (avio_tell(s->pb) > header_size)
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] pvfdec: prevent overflow during block alignment, calculation
Signed-off-by: Andreas Cadhalpun
---
libavformat/pvfdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/pvfdec.c b/libavformat/pvfdec.c
index b9f6d4f..5eecc22 100644
--- a/libavformat/pvfdec.c
+++ b/libavformat/pvfdec.c
@@ -56,6 +56,11 @@ static int pvf_read_header(AVFormatContext *s)
st->codecpar->sample_rate = sample_rate;
st->codecpar->codec_id= ff_get_pcm_codec_id(bps, 0, 1, 0x);
st->codecpar->bits_per_coded_sample = bps;
+if (bps > INT_MAX / st->codecpar->channels) {
+av_log(s, AV_LOG_ERROR, "Overflow during block alignment calculation
%d * %d\n",
+ bps, st->codecpar->channels);
+return AVERROR_INVALIDDATA;
+}
st->codecpar->block_align = bps * st->codecpar->channels / 8;
avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: Clarify doxy for av_image_check_size2()
On 11.12.2016 22:51, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavutil/imgutils.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h > index 19f34deced..40aee8b98e 100644 > --- a/libavutil/imgutils.h > +++ b/libavutil/imgutils.h > @@ -193,7 +193,8 @@ int av_image_check_size(unsigned int w, unsigned int h, > int log_offset, void *lo > > /** > * Check if the given dimension of an image is valid, meaning that all > - * bytes of the image can be addressed with a signed int. > + * bytes of a plane of an image with the specified pix_fmt can be addressed > + * with a signed int. > * > * @param w the width of the picture > * @param h the height of the picture > LGTM. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
On 15.12.2016 00:34, Matthew Wolenetz wrote:
>
> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Fri, 2 Dec 2016 18:10:39 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
>
> Core of patch is from p...@paulmehta.com
> Reference https://crbug.com/643950
> ---
> libavformat/mov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2a69890..7254505 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -739,6 +739,8 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
>
> title_size = atom.size - 24;
> if (title_size > 0) {
> +if (title_size >= UINT_MAX)
I think this should use SIZE_MAX.
> +return AVERROR_INVALIDDATA;
> title_str = av_malloc(title_size + 1); /* Add null terminator */
> if (!title_str)
> return AVERROR(ENOMEM);
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
On 15.12.2016 00:36, Matthew Wolenetz wrote:
> From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Tue, 6 Dec 2016 12:33:08 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
>
> Core of patch is from p...@paulmehta.com
> Reference https://crbug.com/643951
> ---
> libavformat/mov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7254505..e506d20 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4393,6 +4393,8 @@ static int mov_read_uuid(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
> uint8_t *buffer;
> size_t len = atom.size - sizeof(uuid);
> +if (len >= UINT_MAX)
This should also use SIZE_MAX.
> +return AVERROR_INVALIDDATA;
>
> buffer = av_mallocz(len + 1);
> if (!buffer) {
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in mov_read_{senc, saiz, udta_string}()
On 15.12.2016 00:37, Matthew Wolenetz wrote:
> From 8622f9398e7c89a664c4c2ceff9d35b89ff17bb5 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Tue, 6 Dec 2016 12:54:23 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in
> mov_read_{senc,saiz,udta_string}()
>
> Core of patch is from p...@paulmehta.com
> Reference https://crbug.com/643952
> ---
> libavformat/mov.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index e506d20..87ad91a 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -404,7 +404,7 @@ retry:
> return ret;
> } else if (!key && c->found_hdlr_mdta && c->meta_keys) {
> uint32_t index = AV_RB32(&atom.type);
> -if (index < c->meta_keys_count) {
> +if (index < c->meta_keys_count && index > 0) {
This should be in a separate patch.
> key = c->meta_keys[index];
> } else {
> av_log(c->fc, AV_LOG_WARNING,
> @@ -4502,8 +4502,8 @@ static int mov_read_senc(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>
> avio_rb32(pb);/* entries */
>
> -if (atom.size < 8) {
> -av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" too small\n",
> atom.size);
> +if (atom.size < 8 || atom.size > UINT_MAX) {
> +av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" invalid\n",
> atom.size);
> return AVERROR_INVALIDDATA;
> }
>
> @@ -4571,6 +4571,11 @@ static int mov_read_saiz(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return 0;
> }
>
> +if (atom.size > UINT_MAX) {
> +av_log(c->fc, AV_LOG_ERROR, "saiz atom auxiliary_info_sizes size
> %"PRId64" invalid\n", atom.size);
> +return AVERROR_INVALIDDATA;
> +}
> +
> /* save the auxiliary info sizes as is */
> data_size = atom.size - atom_header_size;
>
And these should also check for SIZE_MAX.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopusdec.c Fix ff_vorbis_channel_layouts OOB
On 15.12.2016 00:39, Matthew Wolenetz wrote:
> From 141e56ccf7fc56646424484d357b6c74a486d2e2 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Mon, 21 Nov 2016 17:30:50 -0800
> Subject: [PATCH] lavc/libopusdec.c Fix ff_vorbis_channel_layouts OOB
>
> Similar to existing lavc/vorbisdec.c code which first checks that
> avc->channels is valid for accessing ff_vorbis_channel_layouts, this
> change adds protection to libopusdec.c to prevent accessing that
> array with a negative index. Reference https://crbug.com/666794.
> ---
> libavcodec/libopusdec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
> index acc62f1..c2c7adc 100644
> --- a/libavcodec/libopusdec.c
> +++ b/libavcodec/libopusdec.c
> @@ -50,6 +50,10 @@ static av_cold int libopus_decode_init(AVCodecContext *avc)
> avc->sample_rate= 48000;
> avc->sample_fmt = avc->request_sample_fmt == AV_SAMPLE_FMT_FLT ?
>AV_SAMPLE_FMT_FLT : AV_SAMPLE_FMT_S16;
> +if (avc->channels <= 0) {
> +av_log(avc, AV_LOG_ERROR, "Invalid number of channels\n");
> +return AVERROR(EINVAL);
> +}
> avc->channel_layout = avc->channels > 8 ? 0 :
>ff_vorbis_channel_layouts[avc->channels - 1];
>
What version of ffmpeg is this based on?
I'm pretty sure I fixed this issue with commit
8c8f543b81aa2b50bb6a6cfd370a0061281492a3.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264 encode profile
On 2016/12/15 7:13, Hendrik Leppkes wrote:
> On Thu, Dec 15, 2016 at 12:02 AM, Mark Thompson wrote:
>> On 14/12/16 01:55, Jun Zhao wrote:
>>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>>> From: Yi A Wang
>>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>>> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
>>> encode profile
>>>
>>> add h264 encode profile option and update the docs, for avc
>>> constrained baseline, disable B frames base on H.264 spec Annex A.2.1
>>>
>>> Signed-off-by: Jun Zhao
>>> Signed-off-by: Yi A Wang
>>> ---
>>> doc/codecs.texi| 8
>>> libavcodec/options_table.h | 5 -
>>> libavcodec/vaapi_encode_h264.c | 5 +
>>> 3 files changed, 17 insertions(+), 1 deletion(-)
>>
>> Notwithstanding the below, this should probably be two patches (one for
>> options/docs, one for VAAPI).
>>
>>
>>> diff --git a/doc/codecs.texi b/doc/codecs.texi
>>> index 9a3a56d..9ee9061 100644
>>> --- a/doc/codecs.texi
>>> +++ b/doc/codecs.texi
>>> @@ -893,6 +893,14 @@ Possible values:
>>>
>>> @item dts_hd_ma
>>>
>>> +@item hevc_main10
>>> +
>>> +@item h264_constrained_baseline
>>> +
>>> +@item h264_main
>>> +
>>> +@item h264_high
>>> +
>>> @end table
>>>
>>> @item level @var{integer} (@emph{encoding,audio,video})
>>> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
>>> index 3fe7925..94b2d9b 100644
>>> --- a/libavcodec/options_table.h
>>> +++ b/libavcodec/options_table.h
>>> @@ -395,7 +395,10 @@ static const AVOption avcodec_options[] = {
>>> {"mpeg4_core", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_CORE
>>> }, INT_MIN, INT_MAX, V|E, "profile"},
>>> {"mpeg4_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_MAIN
>>> }, INT_MIN, INT_MAX, V|E, "profile"},
>>> {"mpeg4_asp", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>>> FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
>>> -{"main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 },
>>> INT_MIN, INT_MAX, V|E, "profile"},
>>
>> This table is part of the public API of libavcodec, you can't remove things
>> from it like this.
>>
>>> +{"hevc_main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>>> FF_PROFILE_HEVC_MAIN_10 }, INT_MIN, INT_MAX, V|E, "profile"},
>>> +{"h264_constrained_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>>> FF_PROFILE_H264_CONSTRAINED_BASELINE}, INT_MIN, INT_MAX, V|E, "profile"},
>>> +{"h264_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_MAIN},
>>> INT_MIN, INT_MAX, V|E, "profile"},
>>> +{"h264_high", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_HIGH},
>>> INT_MIN, INT_MAX, V|E, "profile"},
>>
>> This seems reasonable, but I'd like to hear from other people why there is
>> only a small subset of video profiles there already? Confusingly, the
>> libx264, nvenc and videotoolbox encoders all have private options (also
>> called "profile") which implement exactly the same thing where they could be
>> using the generic one (were it to support suitable options).
>>
>> If the change is desirable, it should probably get the full set of profiles
>> corresponding to FF_PROFILE_H264_* values rather than just a restricted set
>> coming from what VAAPI exposes. (Also deprecate the anomalous "main10" and
>> add the H.265 profiles properly as well, I guess?)
>>
>
> The reason for private profiles is quite simply that you don't want to
> type "hevc_main10", but just "main10", for example. On top of that,
> how far do you take this, do you put every single codecs profiles into
> the shared table? Or just the ones where we have multiple encoders?
> What if they don't support the same profiles? You wouldn't have any
> easy way to get a list of thigns it does support (which you could do
> with private options)
> It gets complicated fast.
>
> I would argue that vaapi should just follow the trend and use its own
> private profiles, unless we decide to change all of them one day.
> Until that point, if someone wanted, they could factor the profile
> lists out of current code and share them in a header/c file somewhere
> to be able to be reused.
>
> Unfortunately I didn't pay attention when main10 was added, or that
> might have been avoided, as its inconsistent with any other options we
> have in there and the only hevc profile.
>
Thanks for you clear explain, will move to private options.
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/af_atempo: fix assertion failure on empty input
Signed-off-by: Marton Balint
---
libavfilter/af_atempo.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 59b08ec..93a9c05 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -74,6 +74,7 @@ typedef struct {
* Filter state machine states
*/
typedef enum {
+YAE_NEW,
YAE_LOAD_FRAGMENT,
YAE_ADJUST_POSITION,
YAE_RELOAD_FRAGMENT,
@@ -180,7 +181,7 @@ static void yae_clear(ATempoContext *atempo)
atempo->tail = 0;
atempo->nfrag = 0;
-atempo->state = YAE_LOAD_FRAGMENT;
+atempo->state = YAE_NEW;
atempo->position[0] = 0;
atempo->position[1] = 0;
@@ -828,6 +829,9 @@ yae_apply(ATempoContext *atempo,
uint8_t *dst_end)
{
while (1) {
+if (atempo->state == YAE_NEW)
+atempo->state = YAE_LOAD_FRAGMENT;
+
if (atempo->state == YAE_LOAD_FRAGMENT) {
// load additional data for the current fragment:
if (yae_load_frag(atempo, src_ref, src_end) != 0) {
@@ -983,7 +987,7 @@ static av_cold int init(AVFilterContext *ctx)
{
ATempoContext *atempo = ctx->priv;
atempo->format = AV_SAMPLE_FMT_NONE;
-atempo->state = YAE_LOAD_FRAGMENT;
+atempo->state = YAE_NEW;
return 0;
}
@@ -1123,7 +1127,7 @@ static int request_frame(AVFilterLink *outlink)
ret = ff_request_frame(ctx->inputs[0]);
-if (ret == AVERROR_EOF) {
+if (ret == AVERROR_EOF && atempo->state != YAE_NEW) {
// flush the filter:
int n_max = atempo->ring;
int n_out;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264 encode profile
On 2016/12/15 7:02, Mark Thompson wrote:
> On 14/12/16 01:55, Jun Zhao wrote:
>> From 03030392ec2458679cdfb14802b80cbb196eae40 Mon Sep 17 00:00:00 2001
>> From: Yi A Wang
>> Date: Tue, 13 Dec 2016 10:50:54 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h264: add option to indicate the h264
>> encode profile
>>
>> add h264 encode profile option and update the docs, for avc
>> constrained baseline, disable B frames base on H.264 spec Annex A.2.1
>>
>> Signed-off-by: Jun Zhao
>> Signed-off-by: Yi A Wang
>> ---
>> doc/codecs.texi| 8
>> libavcodec/options_table.h | 5 -
>> libavcodec/vaapi_encode_h264.c | 5 +
>> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> Notwithstanding the below, this should probably be two patches (one for
> options/docs, one for VAAPI).
>
>
>> diff --git a/doc/codecs.texi b/doc/codecs.texi
>> index 9a3a56d..9ee9061 100644
>> --- a/doc/codecs.texi
>> +++ b/doc/codecs.texi
>> @@ -893,6 +893,14 @@ Possible values:
>>
>> @item dts_hd_ma
>>
>> +@item hevc_main10
>> +
>> +@item h264_constrained_baseline
>> +
>> +@item h264_main
>> +
>> +@item h264_high
>> +
>> @end table
>>
>> @item level @var{integer} (@emph{encoding,audio,video})
>> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
>> index 3fe7925..94b2d9b 100644
>> --- a/libavcodec/options_table.h
>> +++ b/libavcodec/options_table.h
>> @@ -395,7 +395,10 @@ static const AVOption avcodec_options[] = {
>> {"mpeg4_core", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_CORE },
>> INT_MIN, INT_MAX, V|E, "profile"},
>> {"mpeg4_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_MPEG4_MAIN },
>> INT_MIN, INT_MAX, V|E, "profile"},
>> {"mpeg4_asp", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
>> -{"main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 },
>> INT_MIN, INT_MAX, V|E, "profile"},
>
> This table is part of the public API of libavcodec, you can't remove things
> from it like this.
>
>> +{"hevc_main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_HEVC_MAIN_10 }, INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_constrained_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> FF_PROFILE_H264_CONSTRAINED_BASELINE}, INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_MAIN},
>> INT_MIN, INT_MAX, V|E, "profile"},
>> +{"h264_high", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_H264_HIGH},
>> INT_MIN, INT_MAX, V|E, "profile"},
>
> This seems reasonable, but I'd like to hear from other people why there is
> only a small subset of video profiles there already? Confusingly, the
> libx264, nvenc and videotoolbox encoders all have private options (also
> called "profile") which implement exactly the same thing where they could be
> using the generic one (were it to support suitable options).
>
> If the change is desirable, it should probably get the full set of profiles
> corresponding to FF_PROFILE_H264_* values rather than just a restricted set
> coming from what VAAPI exposes. (Also deprecate the anomalous "main10" and
> add the H.265 profiles properly as well, I guess?)
>
Will move to private options, tks.
>
>> {"level", NULL, OFFSET(level), AV_OPT_TYPE_INT, {.i64 = FF_LEVEL_UNKNOWN },
>> INT_MIN, INT_MAX, V|A|E, "level"},
>> {"unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_LEVEL_UNKNOWN },
>> INT_MIN, INT_MAX, V|A|E, "level"},
>> {"lowres", "decode at 1= 1/2, 2=1/4, 3=1/8 resolutions", OFFSET(lowres),
>> AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, V|A|D},
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 69cc483..5f37770 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -1190,6 +1190,11 @@ static av_cold int
>> vaapi_encode_h264_init(AVCodecContext *avctx)
>> switch (avctx->profile) {
>> case FF_PROFILE_H264_CONSTRAINED_BASELINE:
>> ctx->va_profile = VAProfileH264ConstrainedBaseline;
>> +if (avctx->max_b_frames != 0) {
>> +avctx->max_b_frames = 0;
>> +av_log(avctx, AV_LOG_WARNING, "H.264 constrained baseline "
>> + "profile don't support encode B frame.\n");
>
> ..." doesn't support encoding B frames.\n", maybe
>
>> +}
>
> I guess this makes sense. It's not really a bitstream restriction, though,
> only a conformance one - you can perfectly well make a usable stream with
> profile_idc 66 which contains B frames (though only decodable with an
> extended or main profile decoder), and indeed the i965 encoder is happy to do
> so. Should that matter?
>
I hope I can give a user case for disable B frame in
ConstrainedBaseline/Baseline:
for example, in video conference, user used the ConstrainedBaseline/Baseline
profile without B frame to reduce the encode/decode latency.
For i965 can decode the stream with
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
On 12/14/2016 10:39 PM, Andreas Cadhalpun wrote:
> On 15.12.2016 00:34, Matthew Wolenetz wrote:
>>
>> From fd878457cd55690d4a27d74411b68a30c9fb2313 Mon Sep 17 00:00:00 2001
>> From: Matt Wolenetz
>> Date: Fri, 2 Dec 2016 18:10:39 -0800
>> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
>>
>> Core of patch is from p...@paulmehta.com
>> Reference https://crbug.com/643950
>> ---
>> libavformat/mov.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 2a69890..7254505 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -739,6 +739,8 @@ static int mov_read_hdlr(MOVContext *c, AVIOContext *pb,
>> MOVAtom atom)
>>
>> title_size = atom.size - 24;
>> if (title_size > 0) {
>> +if (title_size >= UINT_MAX)
>
> I think this should use SIZE_MAX.
title_size is int64_t and SIZE_MAX is UINT64_MAX on x86_64.
>
>> +return AVERROR_INVALIDDATA;
>> title_str = av_malloc(title_size + 1); /* Add null terminator */
>> if (!title_str)
>> return AVERROR(ENOMEM);
>
> Best regards,
> Andreas
> ___
> 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] lavf/utils.c Protect against accessing entries[nb_entries]
On Wed, Dec 14, 2016 at 03:38:18PM -0800, Matthew Wolenetz wrote:
> In ff_index_search_timestamp(), if b == num_entries,
> m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
> true, then the search for the next non-discarded packet could access
> entries[nb_entries], exceeding its bounds. This change adds a protection
> against that scenario. Reference: https://crbug.com/666770
> utils.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 309ffb570701252b564cf92d8c76a57d9413d23f
> 666770-lavf-utils.c-Protect-against-accessing-entries-nb_en.patch
> From e91355afac548fbc7cc0cb4ecbc06dce6495df80 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Mon, 21 Nov 2016 15:54:02 -0800
> Subject: [PATCH] lavf/utils.c Protect against accessing entries[nb_entries]
>
> In ff_index_search_timestamp(), if b == num_entries,
> m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
> true, then the search for the next non-discarded packet could access
> entries[nb_entries], exceeding its bounds. This change adds a protection
> against that scenario. Reference: https://crbug.com/666770
> ---
> libavformat/utils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index fb17423..b2d25eb 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1968,7 +1968,7 @@ int ff_index_search_timestamp(const AVIndexEntry
> *entries, int nb_entries,
> m = (a + b) >> 1;
>
> // Search for the next non-discarded packet.
> -while ((entries[m].flags & AVINDEX_DISCARD_FRAME) && m < b) {
> +while ((entries[m].flags & AVINDEX_DISCARD_FRAME) && m < b && m <
> nb_entries - 1) {
Maybe sasi inguva can comment but i wonder if the code shouldnt
check the left side of m if nothing is found on the right
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mp3dec: fix msan warning when verifying mpa header
On Wed, Dec 14, 2016 at 03:39:59PM -0800, Matthew Wolenetz wrote: > MPEG Audio frame header must be 4 bytes. If we fail to read > 4 bytes bail early to avoid Use-of-uninitialized-value msan error. > Reference https://crbug.com/666874. > mp3dec.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > a5668a4c9770ce6875733ad96c982266f110e322 > 666874-mp3dec-fix-msan-warning-when-verifying-mpa-header.patch > From 5ed6e20c09840320784c43b86b75b3ede69742f6 Mon Sep 17 00:00:00 2001 > From: Chris Cunningham > Date: Tue, 22 Nov 2016 13:54:50 -0800 > Subject: [PATCH] mp3dec: fix msan warning when verifying mpa header > > MPEG Audio frame header must be 4 bytes. If we fail to read > 4 bytes bail early to avoid Use-of-uninitialized-value msan error. > Reference https://crbug.com/666874. > --- > libavformat/mp3dec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avfilter/af_amerge: do not guess an output channel layout
This is the right thing to do, but I am afraid this will break too many
existing filter chains. How can we implement this properly? Ideas/options:
- change it, break it, users will fix it
- add a guess_output_layout option which will be true for now, false after a
major bump, and mention this incompatible change in the next release
- add amerge2 filter, deprecate amerge filter
Signed-off-by: Marton Balint
---
libavfilter/af_amerge.c | 4 +---
tests/ref/fate/filter-amerge | 4 ++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 3bc7d89..43a2d95 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -114,9 +114,7 @@ static int query_formats(AVFilterContext *ctx)
"output layout will be determined by the number of distinct
input channels\n");
for (i = 0; i < nb_ch; i++)
s->route[i] = i;
-outlayout = av_get_default_channel_layout(nb_ch);
-if (!outlayout && nb_ch)
-outlayout = 0xULL >> (64 - nb_ch);
+outlayout = FF_COUNT2LAYOUT(nb_ch);
} else {
int *route[SWR_CH_MAX];
int c, out_ch_number = 0;
diff --git a/tests/ref/fate/filter-amerge b/tests/ref/fate/filter-amerge
index b3e5eb5..8118b4e 100644
--- a/tests/ref/fate/filter-amerge
+++ b/tests/ref/fate/filter-amerge
@@ -2,8 +2,8 @@
#media_type 0: audio
#codec_id 0: pcm_s16le
#sample_rate 0: 44100
-#channel_layout 0: 3
-#channel_layout_name 0: stereo
+#channel_layout 0: 0
+#channel_layout_name 0: 2 channels
0, 0, 0, 2048, 8192, 0x120efa65
0, 2048, 2048, 2048, 8192, 0x7b3cebf7
0, 4096, 4096, 2048, 8192, 0x0fb8ee01
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avfilter/af_amerge: properly handle unknown input layouts
Signed-off-by: Marton Balint
---
libavfilter/af_amerge.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 4a8c6d5..3bc7d89 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -93,10 +93,15 @@ static int query_formats(AVFilterContext *ctx)
av_get_channel_layout_string(buf, sizeof(buf), 0, inlayout[i]);
av_log(ctx, AV_LOG_INFO, "Using \"%s\" for input %d\n", buf, i +
1);
}
-s->in[i].nb_ch = av_get_channel_layout_nb_channels(inlayout[i]);
-if (outlayout & inlayout[i])
+s->in[i].nb_ch = FF_LAYOUT2COUNT(inlayout[i]);
+if (s->in[i].nb_ch) {
overlap++;
-outlayout |= inlayout[i];
+} else {
+s->in[i].nb_ch = av_get_channel_layout_nb_channels(inlayout[i]);
+if (outlayout & inlayout[i])
+overlap++;
+outlayout |= inlayout[i];
+}
nb_ch += s->in[i].nb_ch;
}
if (nb_ch > SWR_CH_MAX) {
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc: Fix ticket 6024
From: Pavel Koshevoy
---
libavcodec/utils.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 44ecc09..2ad96e4 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2788,8 +2788,6 @@ static int do_decode(AVCodecContext *avctx, AVPacket *pkt)
if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
ret = avcodec_decode_video2(avctx, avctx->internal->buffer_frame,
&got_frame, pkt);
-if (ret >= 0)
-ret = pkt->size;
} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
ret = avcodec_decode_audio4(avctx, avctx->internal->buffer_frame,
&got_frame, pkt);
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: fix assertion failure on empty input
On Wed, Dec 14, 2016 at 7:27 PM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavfilter/af_atempo.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index 59b08ec..93a9c05 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilter/af_atempo.c
> @@ -74,6 +74,7 @@ typedef struct {
> * Filter state machine states
> */
> typedef enum {
> +YAE_NEW,
> YAE_LOAD_FRAGMENT,
> YAE_ADJUST_POSITION,
> YAE_RELOAD_FRAGMENT,
> @@ -180,7 +181,7 @@ static void yae_clear(ATempoContext *atempo)
> atempo->tail = 0;
>
> atempo->nfrag = 0;
> -atempo->state = YAE_LOAD_FRAGMENT;
> +atempo->state = YAE_NEW;
>
> atempo->position[0] = 0;
> atempo->position[1] = 0;
> @@ -828,6 +829,9 @@ yae_apply(ATempoContext *atempo,
>uint8_t *dst_end)
> {
> while (1) {
> +if (atempo->state == YAE_NEW)
> +atempo->state = YAE_LOAD_FRAGMENT;
> +
> if (atempo->state == YAE_LOAD_FRAGMENT) {
> // load additional data for the current fragment:
> if (yae_load_frag(atempo, src_ref, src_end) != 0) {
> @@ -983,7 +987,7 @@ static av_cold int init(AVFilterContext *ctx)
> {
> ATempoContext *atempo = ctx->priv;
> atempo->format = AV_SAMPLE_FMT_NONE;
> -atempo->state = YAE_LOAD_FRAGMENT;
> +atempo->state = YAE_NEW;
> return 0;
> }
>
> @@ -1123,7 +1127,7 @@ static int request_frame(AVFilterLink *outlink)
>
> ret = ff_request_frame(ctx->inputs[0]);
>
> -if (ret == AVERROR_EOF) {
> +if (ret == AVERROR_EOF && atempo->state != YAE_NEW) {
> // flush the filter:
> int n_max = atempo->ring;
> int n_out;
I'd like to understand these changes a little better ... how can I
reproduce the problem this is trying to fix?
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
