Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
On 6/1/18, Robert Clove wrote: > Hi FFMPEG people, > > i have a raw dump of RTP packets and want to convert it to .h264, can it be > done via ffmpeg or needs some development ? This can not be done with ffmpeg. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
ohk, then what should i do to convert RTP packets to H.264. But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy stream.264 we get the output file as h.264 then why not ffmpeg will be able to convert packet from file to H.264 On Mon, Jun 4, 2018 at 1:28 PM, Paul B Mahol wrote: > On 6/1/18, Robert Clove wrote: > > Hi FFMPEG people, > > > > i have a raw dump of RTP packets and want to convert it to .h264, can it > be > > done via ffmpeg or needs some development ? > > This can not be done with ffmpeg. > ___ > 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 v2] avcodec/vc1: fix overlap smoothing filter for P frames
> The patch also fixes SSL0014.rcv, the only sample in this directory > that still doesn't decode bit-exact is SSL0015.rcv, I don't know if the > issue is also loopfilter-related. > > Thank you, Carl Eugen Could someone with access to the test files check the output of the Intel hardware decoder through VAAPI for file SSL0015.rcv? I am running into an issue that may be a hardware bug, but I only have Haswell platform to test on. It looks like the hardware tries to read beyond the end of the slice data and subsequently fails to output the last macroblock of the image. ffmpeg -hwaccel vaapi -i SSL0015.rcv -pix_fmt yuv420p -f framecrc - The frames of interest are frames 221 and 301. The CRCs from the reference decoder are: 0,221,221,1,38016, 0x0c2f9de6 0,301,301,1,38016, 0x6877442f My Haswell gives: 0,221,221,1,38016, 0xd8709e80 0,301,301,1,38016, 0x20bd44e7 Thanks, Jerome ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
On Mon, Jun 04, 2018 at 01:57:36PM +0530, Robert Clove wrote: > ohk, then what should i do to convert RTP packets to H.264. > But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy > stream.264 we get the output file as h.264 then why not ffmpeg will be able > to convert packet from file to H.264 Maybe you can replay the raw packets with tcpreplay? /* Steinar */ -- Homepage: https://www.sesse.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Mark Thompson > Sent: Monday, June 4, 2018 7:20 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter. > > On 29/05/18 06:54, Ruiling Song wrote: > > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping. > > > > An example command to use this filter with vaapi codecs: > > FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \ > > opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \ > > vaapi -i INPUT -filter_hw_device ocl -filter_complex \ > > '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ > > [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 > OUTPUT > > > > v2: > > add peak detection. > > > > Signed-off-by: Ruiling Song > > --- > > configure | 1 + > > libavfilter/Makefile | 2 + > > libavfilter/allfilters.c | 1 + > > libavfilter/colorspace_basic.c | 89 + > > libavfilter/colorspace_basic.h | 40 ++ > > libavfilter/opencl/colorspace_basic.cl | 187 ++ > > libavfilter/opencl/tonemap.cl | 278 ++ > > libavfilter/opencl_source.h| 2 + > > libavfilter/vf_tonemap_opencl.c| 655 > + > > 9 files changed, 1255 insertions(+) > > create mode 100644 libavfilter/colorspace_basic.c > > create mode 100644 libavfilter/colorspace_basic.h > > create mode 100644 libavfilter/opencl/colorspace_basic.cl > > create mode 100644 libavfilter/opencl/tonemap.cl > > create mode 100644 libavfilter/vf_tonemap_opencl.c > > This segfaults when run on CPU implementations (both AMD and Intel on > Windows) - can you check that? Maybe an out-of-bounds memory reference I am setting up the windows environment to check it, but could you show me how do you test it? So I can reproduce it. > which doesn't get noticed on a GPU. (Apologies for the terrible report - I > can > only see it on opaque proprietary drivers, where it dies on some internal > thread > with no information at all. The filter unfortunately can't run on pocl > because of > lack of R/RG support there.) Already documented in TODO list. > > Still not sure why it fails on Mali (it doesn't feel like it uses a lot of > memory so > I'm not sure what's going wrong), but it does work well on AMD on Windows. > > What set of implementations have you tested on? I have only tested Beignet + vaapi use-case. > > > diff --git a/configure b/configure > > index e52f8f8..ee3586b 100755 > > --- a/configure > > +++ b/configure > > @@ -3401,6 +3401,7 @@ tinterlace_filter_deps="gpl" > > tinterlace_merge_test_deps="tinterlace_filter" > > tinterlace_pad_test_deps="tinterlace_filter" > > tonemap_filter_deps="const_nan" > > +tonemap_opencl_filter_deps="opencl" > > unsharp_opencl_filter_deps="opencl" > > uspp_filter_deps="gpl avcodec" > > vaguedenoiser_filter_deps="gpl" > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > > index c68ef05..0915656 100644 > > --- a/libavfilter/Makefile > > +++ b/libavfilter/Makefile > > @@ -352,6 +352,8 @@ OBJS-$(CONFIG_TINTERLACE_FILTER) += > vf_tinterlace.o > > OBJS-$(CONFIG_TLUT2_FILTER) += vf_lut2.o framesync.o > > OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o framesync.o > > OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o > > +OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o > colorspace_basic.o opencl.o \ > > +opencl/tonemap.o > > opencl/colorspace_basic.o > > OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o > > OBJS-$(CONFIG_TRIM_FILTER) += trim.o > > OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o > framesync.o > > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > > index b44093d..6873bab 100644 > > --- a/libavfilter/allfilters.c > > +++ b/libavfilter/allfilters.c > > @@ -343,6 +343,7 @@ extern AVFilter ff_vf_tinterlace; > > extern AVFilter ff_vf_tlut2; > > extern AVFilter ff_vf_tmix; > > extern AVFilter ff_vf_tonemap; > > +extern AVFilter ff_vf_tonemap_opencl; > > extern AVFilter ff_vf_transpose; > > extern AVFilter ff_vf_trim; > > extern AVFilter ff_vf_unpremultiply; > > diff --git a/libavfilter/colorspace_basic.c b/libavfilter/colorspace_basic.c > > new file mode 100644 > > index 000..93f9f08 > > --- /dev/null > > +++ b/libavfilter/colorspace_basic.c > > The name of this file feels strange to me. It's common parts used by > colorspace- > related filters, so maybe just colorspace.c? Will fix it. > > > @@ -0,0 +1,89 @@ > > +/* > > + * 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 > > + * L
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself to qsv section
Signed-off-by: Zhong Li --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2172901..78f450d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -219,7 +219,7 @@ Codecs: ptx.c Ivo van Poorten qcelp*Reynaldo H. Verdejo Pinochet qdm2.c, qdm2data.hRoberto Togni - qsv* Mark Thompson + qsv* Mark Thompson, Zhong Li qtrle.c Mike Melanson ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni resample2.c Michael Niedermayer -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
Thats what i cant do, i am using the windows platform On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson < steinar+ffm...@gunderson.no> wrote: > On Mon, Jun 04, 2018 at 01:57:36PM +0530, Robert Clove wrote: > > ohk, then what should i do to convert RTP packets to H.264. > > But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy > > stream.264 we get the output file as h.264 then why not ffmpeg will be > able > > to convert packet from file to H.264 > > Maybe you can replay the raw packets with tcpreplay? > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > ___ > 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 v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
On 04.06.2018 04:55, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> configure| 1 -
> libavformat/hlsenc.c | 27 ---
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/configure b/configure
> index 22eeca22a5..a3d0f5837a 100755
> --- a/configure
> +++ b/configure
> @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
> flac_demuxer_select="flac_parser"
> hds_muxer_select="flv_muxer"
> hls_muxer_select="mpegts_muxer"
> -hls_muxer_suggest="gcrypt openssl"
> image2_alias_pix_demuxer_select="image2_demuxer"
> image2_brender_pix_demuxer_select="image2_demuxer"
> ipod_muxer_select="mov_muxer"
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2268f898b0..c04c561586 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -27,12 +27,6 @@
> #include
> #endif
>
> -#if CONFIG_GCRYPT
> -#include
> -#elif CONFIG_OPENSSL
> -#include
> -#endif
> -
> #include "libavutil/avassert.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/parseutils.h"
> @@ -569,18 +563,21 @@ fail:
> return ret;
> }
>
> +
> static int randomize(uint8_t *buf, int len)
> {
> -#if CONFIG_GCRYPT
> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> +uint32_t tmp_number[4];
> +int i = 0;
> +
> +if (len != 16)
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < 4; i++)
> +tmp_number[i] = av_get_random_seed();
> +
> +memcpy(buf, tmp_number, len);
> +
> return 0;
> -#elif CONFIG_OPENSSL
> -if (RAND_bytes(buf, len))
> -return 0;
> -#else
> -return AVERROR(ENOSYS);
> -#endif
> -return AVERROR(EINVAL);
> }
>
> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
Does av_get_random_seed() provide the same random quality level as
gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
On Mon, Jun 4, 2018 at 12:16 PM, Thomas Volkert wrote:
>
> On 04.06.2018 04:55, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> configure| 1 -
>> libavformat/hlsenc.c | 27 ---
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 22eeca22a5..a3d0f5837a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
>> flac_demuxer_select="flac_parser"
>> hds_muxer_select="flv_muxer"
>> hls_muxer_select="mpegts_muxer"
>> -hls_muxer_suggest="gcrypt openssl"
>> image2_alias_pix_demuxer_select="image2_demuxer"
>> image2_brender_pix_demuxer_select="image2_demuxer"
>> ipod_muxer_select="mov_muxer"
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 2268f898b0..c04c561586 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -27,12 +27,6 @@
>> #include
>> #endif
>>
>> -#if CONFIG_GCRYPT
>> -#include
>> -#elif CONFIG_OPENSSL
>> -#include
>> -#endif
>> -
>> #include "libavutil/avassert.h"
>> #include "libavutil/mathematics.h"
>> #include "libavutil/parseutils.h"
>> @@ -569,18 +563,21 @@ fail:
>> return ret;
>> }
>>
>> +
>> static int randomize(uint8_t *buf, int len)
>> {
>> -#if CONFIG_GCRYPT
>> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
>> +uint32_t tmp_number[4];
>> +int i = 0;
>> +
>> +if (len != 16)
>> +return AVERROR(EINVAL);
>> +
>> +for (i = 0; i < 4; i++)
>> +tmp_number[i] = av_get_random_seed();
>> +
>> +memcpy(buf, tmp_number, len);
>> +
>> return 0;
>> -#elif CONFIG_OPENSSL
>> -if (RAND_bytes(buf, len))
>> -return 0;
>> -#else
>> -return AVERROR(ENOSYS);
>> -#endif
>> -return AVERROR(EINVAL);
>> }
>>
>> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
>
> Does av_get_random_seed() provide the same random quality level as
> gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
>
I can't really comment on quality, but av_get_random_seed does not use
any cryptographic randomness sources - unless you're on Windows.
On Linux it'll read /dev/urandom or /dev/random or make up its own
seed based on time as a hash, depending on whats available.
If av_get_random_seed is supposed to be used cryptographically, it
should probably be expanded to use crypto APIs - although it being in
avutil might make that annoying linking-wise.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS
On 27.05.2018 17:20, Ricardo Constantino wrote:
> On 26 May 2018 at 19:42, Reino Wijnsma wrote:
>
>> On 23-5-2018 2:11, Reino Wijnsma wrote:
>>> On 22-4-2018 14:47, Thomas Volkert wrote:
+enabled mbedtls && { check_pkg_config mbedtls mbedtls
>> mbedtls/x509_crt.h mbedtls_x509_crt_init ||
+ check_pkg_config mbedtls mbedtls
>> mbedtls/ssl.h mbedtls_ssl_init ||
+ check_lib mbedtls mbedtls/ssl.h
>> mbedtls_ssl_init -lmbedtls ||
+ die "ERROR: mbedTLS not found"; }
>>> Now that James Almer has pushed this patch I decided to have a look as
>> well. I wanted to see if mbedtls would work for me too.
>>> I haven't made a FFmpeg build yet to test, because the excerpt above (in
>> 'configure') doesn't look right and configuring FFmpeg returns lots of
>> undefined references.
>>> First of all, there's no pkg-config file at all. Almost 3 years ago
>> someone requested it (https://github.com/ARMmbed/mbedtls/issues/228), but
>> as far as I can see it hasn't been implemented yet. So, I really don't
>> understand why you added the 2 check_pkg_config lines.
>>> Secondly, the check_lib line also needs -lmbedx509 and -lmbedcrypto!
>>>
>>> -lmbedtls, the most important one obviously, prevents a "undefined
>> reference to `mbedtls_ssl_init'", but...
>>> -lmbedx509 is also needed, because otherwise you'd get "undefined
>> reference to `mbedtls_x509_crt_init'" and several "undefined reference to
>> `mbedtls_x509_crt_[...]'".
>>> -lmbedcrypto is also needed, because otherwise you'd get LOTS of
>> "undefined reference to `mbedtls_[...]'"; from "undefined reference to
>> `mbedtls_sha256_init'" to "undefined reference to `mbedtls_pem_init'"!
>>> The following patch works for me:
>>>
>>> diff --git a/configure b/configure
>>> index 09ff0c5..6014e03 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -6111,9 +6111,7 @@ enabled libzvbi && require_pkg_config
>> libzvbi zvbi-0.2 libzvbi.h vbi_d
>>> { test_cpp_condition libzvbi.h
>> "VBI_VERSION_MAJOR > 0 || VBI_VERSION_MINOR > 2 || VBI_VERSION_MINOR == 2
>> && VBI_VERSION_MICRO >= 28" ||
>>> enabled gpl || die "ERROR: libzvbi
>> requires version 0.2.28 or --enable-gpl."; }
>>> enabled libxml2 && require_pkg_config libxml2 libxml-2.0
>> libxml2/libxml/xmlversion.h xmlCheckVersion
>>> -enabled mbedtls && { check_pkg_config mbedtls mbedtls
>> mbedtls/x509_crt.h mbedtls_x509_crt_init ||
>>> - check_pkg_config mbedtls mbedtls
>> mbedtls/ssl.h mbedtls_ssl_init ||
>>> - check_lib mbedtls mbedtls/ssl.h
>> mbedtls_ssl_init -lmbedtls ||
>>> +enabled mbedtls && { check_lib mbedtls mbedtls/ssl.h
>> mbedtls_ssl_init -lmbedtls -lmbedx509 -lmbedcrypto ||
>>> die "ERROR: mbedTLS not found"; }
>>> enabled mediacodec&& { enabled jni || die "ERROR: mediacodec
>> requires --enable-jni"; }
>>> enabled mmal && { check_lib mmal interface/mmal/mmal.h
>> mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host ||
>>> Also note that the order is important, because with -lmbedtls
>> -lmbedcrypto -lmbedx509 you'd get: "undefined reference to
>> `mbedtls_pk_parse_subpubkey'" and "undefined reference to
>> `mbedtls_pk_load_file'".
>>> (If it matters, I'm cross-compiling on Windows using Cygwin, MinGW and
>> GCC).
>>> -- Reino
>> *Ping* at Thomas Volkert, or anyone else responsible for this.
>>
>
> [..]
>
> No opinion on removing the check_pkg_config lines since they have one
> possibly coming up soon, from looking at the PRs.
Yes, see:
https://github.com/ARMmbed/mbedtls/issues/228
https://github.com/ARMmbed/mbedtls/pull/1657
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS
On 22.05.2018 00:47, James Almer wrote: > On 5/21/2018 11:15 AM, James Almer wrote: >> On 5/21/2018 8:27 AM, Thomas Volkert wrote: >>> Hi, >>> >>> On 14.05.2018 19:04, Dave Gregory wrote: Hi all, [..comparison with alternative TLS implementations..] >>> Ping. >>> >>> I still suggest to support mbedTLS in FFmpeg because it is especially >>> interesting for embedded devices. >>> >>> Best regards, >>> Thomas. >> I'll apply it later today. Thank you for the benchmarks. > Pushed after removing the hls muxer configure "suggestion" as you did > not add support for a buffer randomizer to it using mbedtls like it's > done with OpenSSL and gcrypt. > > If mbedtls has a similar function, can you look into adding it to hlsenc.c? Yes, okay. But let's see what happens in "avformat/hlsenc: reimplement randomize of hls use av_get_random_seed" before we start at this point. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] configure fix arm inline defines
Hi
Actually this is the same patch as before but master has been fixed s.t.
enabling arm inline asm no longer breaks it:
I believe there is a bug in the arm feature detection for inline asm in
configure and I have a patch for it.
Currently using a command line like:
./configure --enable-cross-compile --arch=arm --cpu=cortex-a7
--target-os=linux --cross-prefix=arm-linux-gnueabihf-
gives in config.h:
#define HAVE_ARMV5TE 1
#define HAVE_ARMV6 1
#define HAVE_ARMV6T2 1
#define HAVE_ARMV8 0
#define HAVE_NEON 1
#define HAVE_VFP 1
#define HAVE_VFPV3 1
#define HAVE_SETEND 1
...
#define HAVE_ARMV5TE_EXTERNAL 1
#define HAVE_ARMV6_EXTERNAL 1
#define HAVE_ARMV6T2_EXTERNAL 1
#define HAVE_ARMV8_EXTERNAL 0
#define HAVE_NEON_EXTERNAL 0
#define HAVE_VFP_EXTERNAL 1
#define HAVE_VFPV3_EXTERNAL 1
#define HAVE_SETEND_EXTERNAL 1
...
#define HAVE_ARMV5TE_INLINE 0
#define HAVE_ARMV6_INLINE 0
#define HAVE_ARMV6T2_INLINE 0
#define HAVE_ARMV8_INLINE 0
#define HAVE_NEON_INLINE 0
#define HAVE_VFP_INLINE 0
#define HAVE_VFPV3_INLINE 0
#define HAVE_SETEND_INLINE 0
With the patch below you get
...
#define HAVE_ARMV5TE 1
#define HAVE_ARMV6 1
#define HAVE_ARMV6T2 1
#define HAVE_ARMV8 0
#define HAVE_NEON 1
#define HAVE_VFP 1
#define HAVE_VFPV3 1
#define HAVE_SETEND 1
...
#define HAVE_ARMV5TE_EXTERNAL 1
#define HAVE_ARMV6_EXTERNAL 1
#define HAVE_ARMV6T2_EXTERNAL 1
#define HAVE_ARMV8_EXTERNAL 0
#define HAVE_NEON_EXTERNAL 0
#define HAVE_VFP_EXTERNAL 1
#define HAVE_VFPV3_EXTERNAL 1
#define HAVE_SETEND_EXTERNAL 1
...
#define HAVE_ARMV5TE_INLINE 1
#define HAVE_ARMV6_INLINE 1
#define HAVE_ARMV6T2_INLINE 1
#define HAVE_ARMV8_INLINE 0
#define HAVE_NEON_INLINE 0
#define HAVE_VFP_INLINE 1
#define HAVE_VFPV3_INLINE 1
#define HAVE_SETEND_INLINE 1
If I want to get Neon enabled as well then I need to have a --mfpu=neon
on the command line too. I'm not sure how to get it there unless I pass
it as extra flags.
This patch adds quotes around the asm that is in the __asm__ statement
Regards
John Cox
diff --git a/configure b/configure
index 22eeca22a5..4dbee8d349 100755
--- a/configure
+++ b/configure
@@ -1040,7 +1040,7 @@ EOF
check_insn(){
log check_insn "$@"
-check_inline_asm ${1}_inline "$2"
+check_inline_asm ${1}_inline "\"$2\""
check_as ${1}_external "$2"
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
[Fixed the reply order for you, please try to avoid top-posting.] On Mon, Jun 04, 2018 at 15:26:11 +0530, Robert Clove wrote: > On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson < > steinar+ffm...@gunderson.no> wrote: > > Maybe you can replay the raw packets with tcpreplay? > Thats what i cant do, i am using the windows platform Why can't you do that? You do realize that tcpreplay is available for Windows? (Albeit a bit older and "experimental".) If your raw dump happens to be PCAP, then you need some tool which can disassemble the PCAP payload - that could be Wireshark or, as mentioned, tcpreplay. If it's some other "raw" format, it depends on how it was created or captured. It could be the pure payload: https://osqa-ask.wireshark.org/questions/1062/about-rtp-raw-file How was the "raw" file created? What does ffmpeg identify the "raw" file as? This is a topic for ffmpeg-user, BTW. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
2018-06-04 18:16 GMT+08:00 Thomas Volkert :
>
> On 04.06.2018 04:55, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> configure| 1 -
>> libavformat/hlsenc.c | 27 ---
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 22eeca22a5..a3d0f5837a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
>> flac_demuxer_select="flac_parser"
>> hds_muxer_select="flv_muxer"
>> hls_muxer_select="mpegts_muxer"
>> -hls_muxer_suggest="gcrypt openssl"
>> image2_alias_pix_demuxer_select="image2_demuxer"
>> image2_brender_pix_demuxer_select="image2_demuxer"
>> ipod_muxer_select="mov_muxer"
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 2268f898b0..c04c561586 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -27,12 +27,6 @@
>> #include
>> #endif
>>
>> -#if CONFIG_GCRYPT
>> -#include
>> -#elif CONFIG_OPENSSL
>> -#include
>> -#endif
>> -
>> #include "libavutil/avassert.h"
>> #include "libavutil/mathematics.h"
>> #include "libavutil/parseutils.h"
>> @@ -569,18 +563,21 @@ fail:
>> return ret;
>> }
>>
>> +
>> static int randomize(uint8_t *buf, int len)
>> {
>> -#if CONFIG_GCRYPT
>> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
>> +uint32_t tmp_number[4];
>> +int i = 0;
>> +
>> +if (len != 16)
>> +return AVERROR(EINVAL);
>> +
>> +for (i = 0; i < 4; i++)
>> +tmp_number[i] = av_get_random_seed();
>> +
>> +memcpy(buf, tmp_number, len);
>> +
>> return 0;
>> -#elif CONFIG_OPENSSL
>> -if (RAND_bytes(buf, len))
>> -return 0;
>> -#else
>> -return AVERROR(ENOSYS);
>> -#endif
>> -return AVERROR(EINVAL);
>> }
>>
>> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
>
> Does av_get_random_seed() provide the same random quality level as
> gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
>
I think the randomize in hls is same as other module using
av_get_random_seed, so maybe use av_get_random_seed is ok here.
Thanks
Steven
>
> Best regards,
> Thomas.
> ___
> 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 v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
On Mon, Jun 04, 2018 at 12:43:41PM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 4, 2018 at 12:16 PM, Thomas Volkert wrote:
> >
> > On 04.06.2018 04:55, Steven Liu wrote:
> >> Signed-off-by: Steven Liu
> >> ---
> >> configure| 1 -
> >> libavformat/hlsenc.c | 27 ---
> >> 2 files changed, 12 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/configure b/configure
> >> index 22eeca22a5..a3d0f5837a 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
> >> flac_demuxer_select="flac_parser"
> >> hds_muxer_select="flv_muxer"
> >> hls_muxer_select="mpegts_muxer"
> >> -hls_muxer_suggest="gcrypt openssl"
> >> image2_alias_pix_demuxer_select="image2_demuxer"
> >> image2_brender_pix_demuxer_select="image2_demuxer"
> >> ipod_muxer_select="mov_muxer"
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index 2268f898b0..c04c561586 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -27,12 +27,6 @@
> >> #include
> >> #endif
> >>
> >> -#if CONFIG_GCRYPT
> >> -#include
> >> -#elif CONFIG_OPENSSL
> >> -#include
> >> -#endif
> >> -
> >> #include "libavutil/avassert.h"
> >> #include "libavutil/mathematics.h"
> >> #include "libavutil/parseutils.h"
> >> @@ -569,18 +563,21 @@ fail:
> >> return ret;
> >> }
> >>
> >> +
> >> static int randomize(uint8_t *buf, int len)
> >> {
> >> -#if CONFIG_GCRYPT
> >> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> >> +uint32_t tmp_number[4];
> >> +int i = 0;
> >> +
> >> +if (len != 16)
> >> +return AVERROR(EINVAL);
> >> +
> >> +for (i = 0; i < 4; i++)
> >> +tmp_number[i] = av_get_random_seed();
> >> +
> >> +memcpy(buf, tmp_number, len);
> >> +
> >> return 0;
> >> -#elif CONFIG_OPENSSL
> >> -if (RAND_bytes(buf, len))
> >> -return 0;
> >> -#else
> >> -return AVERROR(ENOSYS);
> >> -#endif
> >> -return AVERROR(EINVAL);
> >> }
> >>
> >> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
> >
> > Does av_get_random_seed() provide the same random quality level as
> > gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
> >
>
> I can't really comment on quality, but av_get_random_seed does not use
> any cryptographic randomness sources - unless you're on Windows.
> On Linux it'll read /dev/urandom or /dev/random or make up its own
> seed based on time as a hash, depending on whats available.
>
> If av_get_random_seed is supposed to be used cryptographically, it
> should probably be expanded to use crypto APIs - although it being in
> avutil might make that annoying linking-wise.
is it just me or does something here feel wrong, i dont mean anything
related to our code but rather the apparent general acceptance that
generation of good random numbers requires non system crypto libs.
IM(H)O its the job os the OS to provide unbiased random numbers.
the OS also has all the hardware to its disposal to gather entropy,
its in a better position to do this than a user level lib.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
On Mon, Jun 04, 2018 at 12:16:36PM +0200, Thomas Volkert wrote:
>
> On 04.06.2018 04:55, Steven Liu wrote:
> > Signed-off-by: Steven Liu
> > ---
> > configure| 1 -
> > libavformat/hlsenc.c | 27 ---
> > 2 files changed, 12 insertions(+), 16 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 22eeca22a5..a3d0f5837a 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
> > flac_demuxer_select="flac_parser"
> > hds_muxer_select="flv_muxer"
> > hls_muxer_select="mpegts_muxer"
> > -hls_muxer_suggest="gcrypt openssl"
> > image2_alias_pix_demuxer_select="image2_demuxer"
> > image2_brender_pix_demuxer_select="image2_demuxer"
> > ipod_muxer_select="mov_muxer"
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 2268f898b0..c04c561586 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -27,12 +27,6 @@
> > #include
> > #endif
> >
> > -#if CONFIG_GCRYPT
> > -#include
> > -#elif CONFIG_OPENSSL
> > -#include
> > -#endif
> > -
> > #include "libavutil/avassert.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/parseutils.h"
> > @@ -569,18 +563,21 @@ fail:
> > return ret;
> > }
> >
> > +
> > static int randomize(uint8_t *buf, int len)
> > {
> > -#if CONFIG_GCRYPT
> > -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> > +uint32_t tmp_number[4];
> > +int i = 0;
> > +
> > +if (len != 16)
> > +return AVERROR(EINVAL);
> > +
> > +for (i = 0; i < 4; i++)
> > +tmp_number[i] = av_get_random_seed();
> > +
> > +memcpy(buf, tmp_number, len);
> > +
> > return 0;
> > -#elif CONFIG_OPENSSL
> > -if (RAND_bytes(buf, len))
> > -return 0;
> > -#else
> > -return AVERROR(ENOSYS);
> > -#endif
> > -return AVERROR(EINVAL);
> > }
> >
> > static int do_encrypt(AVFormatContext *s, VariantStream *vs)
>
> Does av_get_random_seed() provide the same random quality level as
> gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
we need a (preferrably single) API to get good random numbers from.
all libs may need to access it so libavutil is probably the place for it
and av_get_random_seed() is already there ...
having a list of #if/elif/else accesing multiple sources of randomness
should if it is needed be in av_get_random_seed() not duplicated every
time a random number is needed.
on a different topic, if someone wants to improve av_get_random_seed() in a
way different from adding libs as sources of randomness
data from image sensors (v4l* for example) and PCM audio. Should be
usefull sources of entropy.
Ive seen CCD imagers of phones being used as particle detectors. So theres
seems to be some evidence behind this generating actual truely random numbers
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS
On 6/4/2018 8:15 AM, Thomas Volkert wrote: > > > On 22.05.2018 00:47, James Almer wrote: >> On 5/21/2018 11:15 AM, James Almer wrote: >>> On 5/21/2018 8:27 AM, Thomas Volkert wrote: Hi, On 14.05.2018 19:04, Dave Gregory wrote: > Hi all, > > [..comparison with alternative TLS implementations..] Ping. I still suggest to support mbedTLS in FFmpeg because it is especially interesting for embedded devices. Best regards, Thomas. >>> I'll apply it later today. Thank you for the benchmarks. >> Pushed after removing the hls muxer configure "suggestion" as you did >> not add support for a buffer randomizer to it using mbedtls like it's >> done with OpenSSL and gcrypt. >> >> If mbedtls has a similar function, can you look into adding it to hlsenc.c? > Yes, okay. > > But let's see what happens in "avformat/hlsenc: reimplement randomize of > hls use av_get_random_seed" before we start at this point. > > Best regards, > Thomas. Well, that patch would obviously make it unnecessary, so probably better that way. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavc/dolby_e: fix make checkheaders
move the the function init_tables() definitions from header file
to .c file to fix make checkheaders.
Signed-off-by: Jun Zhao
---
libavcodec/dolby_e.c | 87
libavcodec/dolby_e.h | 86 ---
2 files changed, 87 insertions(+), 86 deletions(-)
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 91a00ce..429612e 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec/dolby_e.c
@@ -681,6 +681,93 @@ static av_cold int dolby_e_close(AVCodecContext *avctx)
return 0;
}
+
+static av_cold void init_tables(void)
+{
+int i, j;
+
+for (i = 1; i < 17; i++)
+mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
+
+for (i = 2; i < 16; i++) {
+mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
+mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
+mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
+}
+
+mantissa_tab1[i][1] = 0.5f / (1 << 15);
+mantissa_tab1[i][2] = 0.75f / (1 << 15);
+mantissa_tab1[i][3] = 0.875f / (1 << 15);
+
+for (i = 1; i < 17; i++) {
+mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
+mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
+mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
+for (j = 1; j < 4; j++)
+mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f /
(1 << i + j);
+}
+
+mantissa_tab3[1][3] = 0.6875f;
+
+for (i = 0; i < 25; i++) {
+exponent_tab[i * 2] = 1.0f / (1 << i);
+exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
+}
+
+for (i = 1; i < 1024; i++)
+gain_tab[i] = exp2f((i - 960) / 64.0f);
+
+// short 1
+ff_kbd_window_init(window, 3.0f, 128);
+for (i = 0; i < 128; i++)
+window[128 + i] = window[127 - i];
+
+// start
+for (i = 0; i < 192; i++)
+window[256 + i] = start_window[i];
+
+// short 2
+for (i = 0; i < 192; i++)
+window[448 + i] = short_window2[i];
+for (i = 0; i < 64; i++)
+window[640 + i] = window[63 - i];
+
+// short 3
+for (i = 0; i < 64; i++)
+window[704 + i] = short_window3[i];
+for (i = 0; i < 192; i++)
+window[768 + i] = window[64 + i];
+
+// bridge
+for (i = 0; i < 128; i++)
+window[960 + i] = window[i];
+for (i = 0; i < 64; i++)
+window[1088 + i] = 1.0f;
+
+// long
+ff_kbd_window_init(window + 1408, 3.0f, 256);
+for (i = 0; i < 640; i++)
+window[1664 + i] = 1.0f;
+for (i = 0; i < 256; i++)
+window[2304 + i] = window[1152 + i] = window[1663 - i];
+
+// reverse start
+for (i = 0; i < 192; i++)
+window[2560 + i] = window[447 - i];
+
+// reverse short 2
+for (i = 0; i < 256; i++)
+window[2752 + i] = window[703 - i];
+
+// reverse short 3
+for (i = 0; i < 256; i++)
+window[3008 + i] = window[959 - i];
+
+// reverse bridge
+for (i = 0; i < 448; i++)
+window[3264 + i] = window[1407 - i];
+}
+
static av_cold int dolby_e_init(AVCodecContext *avctx)
{
static AVOnce init_once = AV_ONCE_INIT;
diff --git a/libavcodec/dolby_e.h b/libavcodec/dolby_e.h
index 0390233..ae04bf6 100644
--- a/libavcodec/dolby_e.h
+++ b/libavcodec/dolby_e.h
@@ -644,90 +644,4 @@ static float gain_tab[1024];
DECLARE_ALIGNED(32, static float, window)[3712];
-static av_cold void init_tables(void)
-{
-int i, j;
-
-for (i = 1; i < 17; i++)
-mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
-
-for (i = 2; i < 16; i++) {
-mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
-mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
-mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
-}
-
-mantissa_tab1[i][1] = 0.5f / (1 << 15);
-mantissa_tab1[i][2] = 0.75f / (1 << 15);
-mantissa_tab1[i][3] = 0.875f / (1 << 15);
-
-for (i = 1; i < 17; i++) {
-mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
-mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
-mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
-for (j = 1; j < 4; j++)
-mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f /
(1 << i + j);
-}
-
-mantissa_tab3[1][3] = 0.6875f;
-
-for (i = 0; i < 25; i++) {
-exponent_tab[i * 2] = 1.0f / (1 << i);
-exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
-}
-
-for (i = 1; i < 1024; i++)
-gain_tab[i] = exp2f((i - 960) / 64.0f);
-
-// short 1
-ff_kbd_window_init(window, 3.0f, 128);
-for (i = 0; i < 128; i++)
-window[128 + i] = window[127 - i];
-
-// start
-for (i = 0; i < 192; i++)
-window[256 + i] = start_window[i];
-
-// short 2
-for (i = 0; i < 192; i++)
-window[448 + i] = short_window2[i];
-for (i = 0; i < 64; i++)
-window[640 + i] = window[63 - i];
-
-// short 3
-for (i = 0; i < 64; i++)
-window[704 + i] = short_window3[i];
-
[FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: fix make checkheaders
move the the function aacsbr_tableinit definition from header file
to .c file to fix make checkheaders
Signed-off-by: Jun Zhao
---
libavcodec/aacsbr_tablegen_common.h | 12
libavcodec/aacsbr_template.c| 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aacsbr_tablegen_common.h
b/libavcodec/aacsbr_tablegen_common.h
index 8c8f6ef..8e0dd9e 100644
--- a/libavcodec/aacsbr_tablegen_common.h
+++ b/libavcodec/aacsbr_tablegen_common.h
@@ -111,16 +111,4 @@ static DECLARE_ALIGNED(32, INTFLOAT,
sbr_qmf_window_us)[640] = {
Q31( 0.8537385600f),
};
-static av_cold void aacsbr_tableinit(void)
-{
-int n;
-for (n = 1; n < 320; n++)
-sbr_qmf_window_us[320 + n] = sbr_qmf_window_us[320 - n];
-sbr_qmf_window_us[384] = -sbr_qmf_window_us[384];
-sbr_qmf_window_us[512] = -sbr_qmf_window_us[512];
-
-for (n = 0; n < 320; n++)
-sbr_qmf_window_ds[n] = sbr_qmf_window_us[2*n];
-}
-
#endif /* AVCODEC_AACSBR_TABLEGEN_COMMON_H */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 3fe78d5..821615f 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -34,6 +34,18 @@
#include "libavutil/qsort.h"
+static av_cold void aacsbr_tableinit(void)
+{
+int n;
+for (n = 1; n < 320; n++)
+sbr_qmf_window_us[320 + n] = sbr_qmf_window_us[320 - n];
+sbr_qmf_window_us[384] = -sbr_qmf_window_us[384];
+sbr_qmf_window_us[512] = -sbr_qmf_window_us[512];
+
+for (n = 0; n < 320; n++)
+sbr_qmf_window_ds[n] = sbr_qmf_window_us[2*n];
+}
+
av_cold void AAC_RENAME(ff_aac_sbr_init)(void)
{
static const struct {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: reimplement randomize of hls use av_get_random_seed
On 04.06.2018 15:38, Michael Niedermayer wrote:
> On Mon, Jun 04, 2018 at 12:16:36PM +0200, Thomas Volkert wrote:
>> On 04.06.2018 04:55, Steven Liu wrote:
>>> Signed-off-by: Steven Liu
>>> ---
>>> configure| 1 -
>>> libavformat/hlsenc.c | 27 ---
>>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 22eeca22a5..a3d0f5837a 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3127,7 +3127,6 @@ fifo_muxer_deps="threads"
>>> flac_demuxer_select="flac_parser"
>>> hds_muxer_select="flv_muxer"
>>> hls_muxer_select="mpegts_muxer"
>>> -hls_muxer_suggest="gcrypt openssl"
>>> image2_alias_pix_demuxer_select="image2_demuxer"
>>> image2_brender_pix_demuxer_select="image2_demuxer"
>>> ipod_muxer_select="mov_muxer"
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 2268f898b0..c04c561586 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -27,12 +27,6 @@
>>> #include
>>> #endif
>>>
>>> -#if CONFIG_GCRYPT
>>> -#include
>>> -#elif CONFIG_OPENSSL
>>> -#include
>>> -#endif
>>> -
>>> #include "libavutil/avassert.h"
>>> #include "libavutil/mathematics.h"
>>> #include "libavutil/parseutils.h"
>>> @@ -569,18 +563,21 @@ fail:
>>> return ret;
>>> }
>>>
>>> +
>>> static int randomize(uint8_t *buf, int len)
>>> {
>>> -#if CONFIG_GCRYPT
>>> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
>>> +uint32_t tmp_number[4];
>>> +int i = 0;
>>> +
>>> +if (len != 16)
>>> +return AVERROR(EINVAL);
>>> +
>>> +for (i = 0; i < 4; i++)
>>> +tmp_number[i] = av_get_random_seed();
>>> +
>>> +memcpy(buf, tmp_number, len);
>>> +
>>> return 0;
>>> -#elif CONFIG_OPENSSL
>>> -if (RAND_bytes(buf, len))
>>> -return 0;
>>> -#else
>>> -return AVERROR(ENOSYS);
>>> -#endif
>>> -return AVERROR(EINVAL);
>>> }
>>>
>>> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
>> Does av_get_random_seed() provide the same random quality level as
>> gcry_randomize() / RAND_bytes() / mbedtls_havege_random() ?
> we need a (preferrably single) API to get good random numbers from.
> all libs may need to access it so libavutil is probably the place for it
> and av_get_random_seed() is already there ...
>
> having a list of #if/elif/else accesing multiple sources of randomness
> should if it is needed be in av_get_random_seed() not duplicated every
> time a random number is needed.
Yes, I agree completely. The differentiation between the implementations
should be hidden behind av_get_random_seed().
But we should be careful when simplifying code at this point.
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set st->start_time for video streams explicitly.
friendly ping. thx. On Thu, May 31, 2018 at 4:26 PM Sasi Inguva wrote: > Pls find attached, the correctly signed patch > Thanks. > > On Thu, May 31, 2018 at 4:14 PM Sasi Inguva wrote: > >> Sorry. Forgot to attach the file. Pls find it attached. Also resending >> the patch signed with correct email address >> >> On Thu, May 31, 2018 at 2:14 PM Michael Niedermayer >> wrote: >> >>> On Tue, May 29, 2018 at 03:39:40PM -0700, Sasi Inguva wrote: >>> > If start_time is not set, ffmpeg takes the duration from the global >>> > movie instead of the per stream duration. >>> > Signed-off-by: Sasi Inguva < >>> is...@rodete-desktop-imager.corp.google.com> >>> > --- >>> > libavformat/mov.c| 20 +--- >>> > tests/fate/mov.mak | 4 +++ >>> > tests/ref/fate/mov-neg-firstpts-discard | 2 +- >>> > tests/ref/fate/mov-stream-shorter-than-movie | 33 >>> > 4 files changed, 54 insertions(+), 5 deletions(-) >>> > create mode 100644 tests/ref/fate/mov-stream-shorter-than-movie >>> >>> i may have missed a link to a sample file >>> >>> fate-suite//mov/mov_stream_shorter_than_movie.mov: No such file or >>> directory >>> make: *** [fate-mov-stream-shorter-than-movie] Error 1 >>> >>> >>> >>> >>> [...] >>> -- >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >>> >>> It is dangerous to be right in matters on which the established >>> authorities >>> are wrong. -- Voltaire >>> ___ >>> 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] avformat/movenc: fix recognization of cover image streams
For chapter images, the mov demux produces streams with disposition set
to attached_pic+timed_thumbnails. This patch fixes to properly recognize
streams that should be encoded as cover image (ones with only and only
attached_pic disposition set).
Signed-off-by: Timo Teräs
---
> ffmpeg should act close to what a inteligent user expects.
> For example a simple ffmpeg -i inputfile outputfile
> should produce a outputfile that results in similar presentation as the input
> when played.
>...
> It may be good to minimize the amount of exceptions for how streams are
> handled.
Agree. My question was more about the details how the disposition flags
should be handled, because there seems to be no accurate documentation.
Apparently the logic is to handle based on what demuxers produce.
This patch addresses how the cover image is detected, and should restore
earlier behaviour on copying files where demuxer supports more features
than current muxer.
This applies on top of the "[v2] avformat/movenc: properly handle cover
image codecs" patch. I can rebase the order if wanted, but it'll require
little work.
Hopefully just the above mentioned patch, and this one could be applied
in the order.
libavformat/movenc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4ba90135df..db266b7765 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -143,10 +143,17 @@ static int co64_required(const MOVTrack *track)
return 0;
}
+static int is_cover_image(const AVStream *st)
+{
+/* Eg. AV_DISPOSITION_ATTACHED_PIC | AV_DISPOSITION_TIMED_THUMBNAILS
+ * is encoded as sparse video track */
+return st && st->disposition == AV_DISPOSITION_ATTACHED_PIC;
+}
+
static int rtp_hinting_needed(const AVStream *st)
{
/* Add hint tracks for each real audio and video stream */
-if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+if (is_cover_image(st))
return 0;
return st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO ||
st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
@@ -1568,7 +1575,7 @@ static int mov_find_codec_tag(AVFormatContext *s,
MOVTrack *track)
{
int tag;
-if (track->st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+if (is_cover_image(track->st))
return ff_codec_get_tag(codec_cover_image_tags, track->par->codec_id);
if (track->mode == MODE_MP4 || track->mode == MODE_PSP)
@@ -3443,10 +3450,8 @@ static int mov_write_covr(AVIOContext *pb,
AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
MOVTrack *trk = &mov->tracks[i];
-AVStream *st = s->streams[i];
-if (!(st->disposition & AV_DISPOSITION_ATTACHED_PIC) ||
-trk->cover_image.size <= 0)
+if (!is_cover_image(trk->st) || trk->cover_image.size <= 0)
continue;
if (!pos) {
@@ -3989,15 +3994,13 @@ static int mov_write_isml_manifest(AVIOContext *pb,
MOVMuxContext *mov, AVFormat
AVStream *st = track->st;
AVDictionaryEntry *lang = av_dict_get(st->metadata, "language",
NULL,0);
-if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (track->par->codec_type == AVMEDIA_TYPE_VIDEO &&
!is_cover_image(st)) {
type = "video";
} else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO) {
type = "audio";
} else {
continue;
}
-if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
-continue;
props = (AVCPBProperties*)av_stream_get_side_data(track->st,
AV_PKT_DATA_CPB_PROPERTIES, NULL);
@@ -4657,7 +4660,7 @@ static int mov_write_ftyp_tag(AVIOContext *pb,
AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
-if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+if (is_cover_image(st))
continue;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
has_video = 1;
@@ -4807,7 +4810,7 @@ static int mov_write_identification(AVIOContext *pb,
AVFormatContext *s)
int video_streams_nb = 0, audio_streams_nb = 0, other_streams_nb = 0;
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
-if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+if (is_cover_image(st))
continue;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
video_streams_nb++;
@@ -4998,8 +5001,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
int buf_size, moov_size;
for (i = 0; i < mov->nb_streams; i++)
-if (!mov->tracks[i].entry &&
-(i >= s->nb_streams || !(s->streams[i]->disposition &
AV_DISPOSITION_ATTACHED_PIC)))
+if (!mov->tracks[i].entry && !is_cover_image(mov->tracks[i].st))
break;
/* Don't write the initial moov u
Re: [FFmpeg-devel] [PATCH v3] avcodec/vc1: fix out-of-bounds reference pixel replication
2018-05-29 14:26 GMT+02:00, Jerome Borsboom : > Out-of-bounds reference pixel replication should take into account the frame > coding mode of the reference frame(s), not the frame coding mode of the > current frame. > > Signed-off-by: Jerome Borsboom > --- > Even more corrections. The starting line must also be adjusted by one for an > opposite refence field. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavc/dolby_e: fix make checkheaders
On 6/4/2018 11:18 AM, Jun Zhao wrote:
> move the the function init_tables() definitions from header file
> to .c file to fix make checkheaders.
What compile flags are you using? checkheaders seems to work just fine
on a normal build.
http://fate.ffmpeg.org/report.cgi?time=20180604121434&slot=x86_64-archlinux-gcc-checkheaders
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/dolby_e.c | 87
>
> libavcodec/dolby_e.h | 86 ---
> 2 files changed, 87 insertions(+), 86 deletions(-)
>
> diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
> index 91a00ce..429612e 100644
> --- a/libavcodec/dolby_e.c
> +++ b/libavcodec/dolby_e.c
> @@ -681,6 +681,93 @@ static av_cold int dolby_e_close(AVCodecContext *avctx)
> return 0;
> }
>
> +
> +static av_cold void init_tables(void)
> +{
> +int i, j;
> +
> +for (i = 1; i < 17; i++)
> +mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
> +
> +for (i = 2; i < 16; i++) {
> +mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
> +mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
> +mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
> +}
> +
> +mantissa_tab1[i][1] = 0.5f / (1 << 15);
> +mantissa_tab1[i][2] = 0.75f / (1 << 15);
> +mantissa_tab1[i][3] = 0.875f / (1 << 15);
> +
> +for (i = 1; i < 17; i++) {
> +mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
> +mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
> +mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
> +for (j = 1; j < 4; j++)
> +mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f /
> (1 << i + j);
> +}
> +
> +mantissa_tab3[1][3] = 0.6875f;
> +
> +for (i = 0; i < 25; i++) {
> +exponent_tab[i * 2] = 1.0f / (1 << i);
> +exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
> +}
> +
> +for (i = 1; i < 1024; i++)
> +gain_tab[i] = exp2f((i - 960) / 64.0f);
> +
> +// short 1
> +ff_kbd_window_init(window, 3.0f, 128);
> +for (i = 0; i < 128; i++)
> +window[128 + i] = window[127 - i];
> +
> +// start
> +for (i = 0; i < 192; i++)
> +window[256 + i] = start_window[i];
> +
> +// short 2
> +for (i = 0; i < 192; i++)
> +window[448 + i] = short_window2[i];
> +for (i = 0; i < 64; i++)
> +window[640 + i] = window[63 - i];
> +
> +// short 3
> +for (i = 0; i < 64; i++)
> +window[704 + i] = short_window3[i];
> +for (i = 0; i < 192; i++)
> +window[768 + i] = window[64 + i];
> +
> +// bridge
> +for (i = 0; i < 128; i++)
> +window[960 + i] = window[i];
> +for (i = 0; i < 64; i++)
> +window[1088 + i] = 1.0f;
> +
> +// long
> +ff_kbd_window_init(window + 1408, 3.0f, 256);
> +for (i = 0; i < 640; i++)
> +window[1664 + i] = 1.0f;
> +for (i = 0; i < 256; i++)
> +window[2304 + i] = window[1152 + i] = window[1663 - i];
> +
> +// reverse start
> +for (i = 0; i < 192; i++)
> +window[2560 + i] = window[447 - i];
> +
> +// reverse short 2
> +for (i = 0; i < 256; i++)
> +window[2752 + i] = window[703 - i];
> +
> +// reverse short 3
> +for (i = 0; i < 256; i++)
> +window[3008 + i] = window[959 - i];
> +
> +// reverse bridge
> +for (i = 0; i < 448; i++)
> +window[3264 + i] = window[1407 - i];
> +}
> +
> static av_cold int dolby_e_init(AVCodecContext *avctx)
> {
> static AVOnce init_once = AV_ONCE_INIT;
> diff --git a/libavcodec/dolby_e.h b/libavcodec/dolby_e.h
> index 0390233..ae04bf6 100644
> --- a/libavcodec/dolby_e.h
> +++ b/libavcodec/dolby_e.h
> @@ -644,90 +644,4 @@ static float gain_tab[1024];
>
> DECLARE_ALIGNED(32, static float, window)[3712];
>
> -static av_cold void init_tables(void)
> -{
> -int i, j;
> -
> -for (i = 1; i < 17; i++)
> -mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
> -
> -for (i = 2; i < 16; i++) {
> -mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
> -mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
> -mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
> -}
> -
> -mantissa_tab1[i][1] = 0.5f / (1 << 15);
> -mantissa_tab1[i][2] = 0.75f / (1 << 15);
> -mantissa_tab1[i][3] = 0.875f / (1 << 15);
> -
> -for (i = 1; i < 17; i++) {
> -mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
> -mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
> -mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
> -for (j = 1; j < 4; j++)
> -mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f /
> (1 << i + j);
> -}
> -
> -mantissa_tab3[1][3] = 0.6875f;
> -
> -for (i = 0; i < 25; i++) {
> -exponent_tab[i * 2] = 1.0f / (1 << i);
> -exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
> -}
> -
> -for (i = 1; i < 1024; i++)
> -g
Re: [FFmpeg-devel] Convert Raw RTP dump to H.264
On Mon, Jun 4, 2018 at 5:12 PM, Moritz Barsnick wrote: > [Fixed the reply order for you, please try to avoid top-posting.] > > On Mon, Jun 04, 2018 at 15:26:11 +0530, Robert Clove wrote: > > On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson < > > steinar+ffm...@gunderson.no> wrote: > > > Maybe you can replay the raw packets with tcpreplay? > > Thats what i cant do, i am using the windows platform > > Why can't you do that? You do realize that tcpreplay is available for > Windows? (Albeit a bit older and "experimental".) > > If your raw dump happens to be PCAP, then you need some tool which can > disassemble the PCAP payload - that could be Wireshark or, as > mentioned, tcpreplay. > > If it's some other "raw" format, it depends on how it was created or > captured. It could be the pure payload: > https://osqa-ask.wireshark.org/questions/1062/about-rtp-raw-file > > How was the "raw" file created? > What does ffmpeg identify the "raw" file as? > > This is a topic for ffmpeg-user, BTW. > > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ffmpeg output for my file is as follows: *command:* ffmpeg.exe -i my.metadata -i mycapture.rtp output.h264 *output:* ffmpeg version N-91152-g7c333dc6a7 Copyright (c) 2000-2018 the FFmpeg developers [rtp @ 003771c0] *Protocol 'rtp' not on whitelist 'file,crypto'!my.metadata: Invalid data found when processing input* *command:* ffmpeg.exe -protocol_whitelist file,udp,rtp -i my.metadata -i mycapture.rtp output.h264 *output:* ffmpeg version N-91152-g7c333dc6a7 Copyright (c) 2000-2018 the FFmpeg developers [udp @ 003576c0] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) [udp @ 003679c0] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) Incorrect amount of SRTP params [udp @ 00342c40] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) [udp @ 0038a1c0] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) Incorrect amount of SRTP params [udp @ 0039aa40] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) [udp @ 003aad40] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) Incorrect amount of SRTP params [udp @ 003bb5c0] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) [udp @ 003cb880] 'circular_buffer_size' option was set but it is not sup ported on this build (pthread support is required) Incorrect amount of SRTP params [sdp @ 00342040] Could not find codec parameters for stream 0 (Audio: no ne, 8000 Hz, 1 channels): unknown codec Consider increasing the value for the 'analyzeduration' and 'probesize' options [sdp @ 00342040] Could not find codec parameters for stream 1 (Video: no ne, none): unknown codec Consider increasing the value for the 'analyzeduration' and 'probesize' options [sdp @ 00342040] Could not find codec parameters for stream 2 (Audio: no ne, 8000 Hz, 1 channels): unknown codec Consider increasing the value for the 'analyzeduration' and 'probesize' options [sdp @ 00342040] Could not find codec parameters for stream 3 (Video: no ne, none): unknown codec Consider increasing the value for the 'analyzeduration' and 'probesize' options Guessed Channel Layout for Input Stream #0.0 : mono Guessed Channel Layout for Input Stream #0.2 : mono Input #0, sdp, from 'my.metadata': Metadata: title : session Duration: N/A, bitrate: N/A Stream #0:0: Audio: none, 8000 Hz, mono Stream #0:1: Video: none, none, 90k tbr, 90k tbn, 90k tbc Stream #0:2: Audio: none, 8000 Hz, mono Stream #0:3: Video: none, none, 90k tbr, 90k tbn, 90k tbc mycapture.rtp: Invalid data found when processing input ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink
On Fri, 1 Jun 2018, Dave Rice wrote: On May 31, 2018, at 5:29 PM, Marton Balint wrote: On Thu, 31 May 2018, Jonathan Morley wrote: Thank you for the clarification, Dave. It might be that the Blackmagic approach to collecting timecode doesn’t work for that one source because it is in the horizontal space (HANC) instead of the vertical (VANC). I am not sure. Sadly I don’t think my solution is all encompassing, but it does seem to help in enough cases I would like to get it integrated with master. I am still a bit thrown about the initial “Unable to set timecode” error, but believe it to be initialization related. I will wait to hear back from Marton on my overall approach and see what I can do to clean that up. av_dict_set returns < 0 on error, so the condition seems wrong. As for the other error message my plan is to demote that to a debug. That is a good idea. +1 On the other hand, I believe the usefulness of this is in its current form is still very limited, because typically the first few frames are NoSignal frames, how the end user supposed to know which frame is the one with the first valid timecode? In my testing the timecode value set here has corrected been associated with the first video frame (maintaining the timecode-to-first-frame relationship as found on the source video stream). Although only having first timecode value known is limiting, I think this is still quite useful. This function also mirrors how BlackMagic Media Express and Adobe Premiere handle capturing video+timecode where only the first value is documented and all subsequent values are presumed. Could you give me an example? (e.g. ffmpeg command line?) I'd rather see a new AVPacketSideData type which will contain the timecode as a string, so you can set it frame-by-frame. Using side data for timecode would be preferable, but the possibility that a patch for that may someday arrive shouldn’t completely block this more limited patch. I would like to make sure the code works reliably even for the limited use case and no race conditions are affectig the way it works. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil/encryption_info: Add NULL checks.
On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
wrote:
>
> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
> >
> > Signed-off-by: Jacob Trimble
> > ---
> > libavutil/encryption_info.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
> > index 20a752d6b4..a48ded922c 100644
> > --- a/libavutil/encryption_info.c
> > +++ b/libavutil/encryption_info.c
> > @@ -64,6 +64,8 @@ AVEncryptionInfo *av_encryption_info_clone(const
> > AVEncryptionInfo *info)
> > {
> > AVEncryptionInfo *ret;
> >
> > +if (!info)
> > +return NULL;
> > ret = av_encryption_info_alloc(info->subsample_count,
> > info->key_id_size, info->iv_size);
> > if (!ret)
> > return NULL;
>
> > @@ -127,7 +129,7 @@ uint8_t *av_encryption_info_add_side_data(const
> > AVEncryptionInfo *info, size_t *
> > uint8_t *buffer, *cur_buffer;
> > uint32_t i;
> >
> > -if (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA < info->key_id_size ||
> > +if (!info || !size || UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA <
> > info->key_id_size ||
> > UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size <
> > info->iv_size ||
> > (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size -
> > info->iv_size) / 8 < info->subsample_count) {
> > return NULL;
> > @@ -260,7 +262,8 @@ uint8_t *av_encryption_init_info_add_side_data(const
> > AVEncryptionInitInfo *info,
> > uint8_t *buffer, *cur_buffer;
> > uint32_t i, max_size;
> >
> > -if (UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA < info->system_id_size
> > ||
> > +if (!info || !side_data_size ||
> > +UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA < info->system_id_size
> > ||
> > UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA - info->system_id_size
> > < info->data_size) {
> > return NULL;
> > }
>
> in which valid case would these be called with NULL input ?
> iam asking as this feels as if it might be a bug in teh caller
>
This was found by Chrome's ClusterFuzz, which I am not that familiar
with. I think it was just running fuzz tests directly on FFmpeg code,
so it wasn't in production code. But since this is a public method,
we should validate the input in any case.
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
> ___
> 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] libavutil/encryption_info: Add NULL checks.
2018-06-04 18:59 GMT+02:00, Jacob Trimble :
> On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
> wrote:
>>
>> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
>> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
>> >
>> > Signed-off-by: Jacob Trimble
>> > ---
>> > libavutil/encryption_info.c | 7 +--
>> > 1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
>> > index 20a752d6b4..a48ded922c 100644
>> > --- a/libavutil/encryption_info.c
>> > +++ b/libavutil/encryption_info.c
>> > @@ -64,6 +64,8 @@ AVEncryptionInfo *av_encryption_info_clone(const
>> > AVEncryptionInfo *info)
>> > {
>> > AVEncryptionInfo *ret;
>> >
>> > +if (!info)
>> > +return NULL;
>> > ret = av_encryption_info_alloc(info->subsample_count,
>> > info->key_id_size, info->iv_size);
>> > if (!ret)
>> > return NULL;
>>
>> > @@ -127,7 +129,7 @@ uint8_t *av_encryption_info_add_side_data(const
>> > AVEncryptionInfo *info, size_t *
>> > uint8_t *buffer, *cur_buffer;
>> > uint32_t i;
>> >
>> > -if (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA < info->key_id_size ||
>> > +if (!info || !size || UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA <
>> > info->key_id_size ||
>> > UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size <
>> > info->iv_size ||
>> > (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size -
>> > info->iv_size) / 8 < info->subsample_count) {
>> > return NULL;
>> > @@ -260,7 +262,8 @@ uint8_t *av_encryption_init_info_add_side_data(const
>> > AVEncryptionInitInfo *info,
>> > uint8_t *buffer, *cur_buffer;
>> > uint32_t i, max_size;
>> >
>> > -if (UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
>> > info->system_id_size ||
>> > +if (!info || !side_data_size ||
>> > +UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
>> > info->system_id_size ||
>> > UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA -
>> > info->system_id_size < info->data_size) {
>> > return NULL;
>> > }
>>
>> in which valid case would these be called with NULL input ?
>> iam asking as this feels as if it might be a bug in teh caller
>>
>
> This was found by Chrome's ClusterFuzz, which I am not that familiar
> with. I think it was just running fuzz tests directly on FFmpeg code,
> so it wasn't in production code. But since this is a public method,
> we should validate the input in any case.
How do you validate the size of C buffers in general?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink
> On Jun 4, 2018, at 12:24 PM, Marton Balint wrote: > > On Fri, 1 Jun 2018, Dave Rice wrote: > >>> On May 31, 2018, at 5:29 PM, Marton Balint wrote: >>> On Thu, 31 May 2018, Jonathan Morley wrote: Thank you for the clarification, Dave. It might be that the Blackmagic approach to collecting timecode doesn’t work for that one source because it is in the horizontal space (HANC) instead of the vertical (VANC). I am not sure. Sadly I don’t think my solution is all encompassing, but it does seem to help in enough cases I would like to get it integrated with master. I am still a bit thrown about the initial “Unable to set timecode” error, but believe it to be initialization related. I will wait to hear back from Marton on my overall approach and see what I can do to clean that up. >>> av_dict_set returns < 0 on error, so the condition seems wrong. As for the other error message my plan is to demote that to a debug. >>> That is a good idea. >> >> +1 >> >>> On the other hand, I believe the usefulness of this is in its current form >>> is still very limited, because typically the first few frames are NoSignal >>> frames, how the end user supposed to know which frame is the one with the >>> first valid timecode? >> >> In my testing the timecode value set here has corrected been associated with >> the first video frame (maintaining the timecode-to-first-frame relationship >> as found on the source video stream). Although only having first timecode >> value known is limiting, I think this is still quite useful. This function >> also mirrors how BlackMagic Media Express and Adobe Premiere handle >> capturing video+timecode where only the first value is documented and all >> subsequent values are presumed. > > Could you give me an example? (e.g. ffmpeg command line?) ./ffmpeg -timecode_format vitc2 -f decklink -draw_bars 0 -audio_input embedded -video_input sdi -format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio 3D" -c:v v210 -c:a aac output.mov This worked for me to embed a QuickTime timecode track based upon the timecode value of the first frame. If the input contained non-sequential timecode values then the timecode track would not be accurate from that point onward, but creating a timecode track based only upon the initial value is what BlackMagic Media Express and Adobe Premiere are doing anyhow. >>> I'd rather see a new AVPacketSideData type which will contain the timecode >>> as a string, so you can set it frame-by-frame. >> >> Using side data for timecode would be preferable, but the possibility that a >> patch for that may someday arrive shouldn’t completely block this more >> limited patch. > > I would like to make sure the code works reliably even for the limited use > case and no race conditions are affectig the way it works. Feel welcome to suggest any testing. I’ll have access for testing again tomorrow. Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] NVIDIA CUVID decoding issue.
Hi! I'm trying to transcode H.264 Stream to HEVC. Everything just working fine when I'm using the in-built CPU decoder, but when I turn on the Hardware-accelerated CUVID module, it throws some error with most of my streams. * **FFMPEG CMDLINE: * /root/bin/ffmpeg -hwaccel cuvid -c:v h264_cuvid -i 'udp://239.192.26.8:1234' -map 0:0:v -map 0:1:a -c:v hevc_nvenc -f mpegts test.ts [h264_cuvid @ 0x3d2b800] Video height 14 not within range from 16 to 4096 Error while opening decoder for input stream #0:0 : Invalid argument My video height with all of streams is HD or PAL resolution, so probably within that range. stream #0:0 is the video stream. I've tried to add -analyzeduration 10M -probesize 10M flags, the results same. FFREPORT file: https://1drv.ms/u/s!AlIDARy55xh44F2f_8C1TyKwxA0t *It says: * data partitioning is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [h264 @ 0x31df240] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) Sample from input: https://1drv.ms/v/s!AlIDARy55xh44F7_i2Ak_q8bmTTF The output file is empty. My FFMPEG version is the newest: 4.0 * **FFMPEG compilation parameters:* --prefix=/root/ffmpeg_build --pkg-config-flags=--static --extra-cflags='-I/root/ffmpeg_build/include -I/usr/local/cuda/include' --extra-ldflags='-L/root/ffmpeg_build/lib -L/usr/local/cuda/lib64' --extra-libs=-lpthread --bindir=/root/bin --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-cuda --enable-cuvid --enable-nvenc --enable-libnpp CUDA Version: 9.2 (Patch installed) NVIDIA Driver: 390.48 Card: NVIDIA Quadro P2000 Using Ubuntu 17.10 and I've Centos 7 server with the same parameters. If using something like this: /root/bin/ffmpeg -i 'udp://239.192.26.8:1234' -map 0:0:v -map 0:1:a -c:v hevc_nvenc -f mpegts udp://224.1.1.80:1234/ or file It runs without an issue/warning. I made a sample of a working stream too: Input: https://1drv.ms/v/s!AlIDARy55xh44GA4yH34AIke-8Op Output: https://1drv.ms/v/s!AlIDARy55xh44F-uJFXcvHsLTBw3 Sorry I can't provide the same sample, because the source stream coming from TV. Is there anything which solves this kind of error? Am I doing something wrong? Best regards: Ferenc Nánási ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Atempo limits
Hello, How are you all? We are looking to use the atempo filter for our audio files. However, the limit between 0.5 - 2x is too restrictive for us. We would like to expand the limit to 0.5x - 3x. I tried changing the range in atempo.c and the rest of the tempo filter just worked. Do you know whether there are any other aspects of the code that wouldn't work at 3x speeds? If there aren't any issues, I'll submit this as a patch via the ffmpeg contribution guidelines. Thanks, Ronak ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC] [PATCH] TensorFlow backend introduction for DNN module
2018-06-03 17:05 GMT-03:00 Pedro Arthur : > 2018-06-03 16:55 GMT-03:00 Sergey Lavrushkin : >>> My concern is when we add more models, currently we have to store 2 >>> models, one for the "native" implementation and one for the TF >>> backend. >>> There is also the case were one wants to update the weights for a >>> model, it will be necessary to update both the native and TF data. >>> Having duplicated data is much easier to get inconsistencies between >>> implementations. >> >> >> I understand the problem, but I am afraid that manual graph construction can >> take a lot of time, especially if we add something more complicated than >> srcnn, >> and the second approach passing weights in placeholders will require to >> add some logic for it in other parts of API besides model loading. >> I am thinking of another way, that is to get weights for native model from >> this binary >> tf model, if they are stored there consistently, and not specify them as >> float arrays. >> But then for each new model we need to find offsets for each weights array. > Ok, we can keep it until we find a reasonable solution. If there are nothing else to be addressed I'll push it by tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avdevice/decklink_dec: use std::atomic for decklink_input_callback refcounting
Also remove the callback from the context, and add proper error handling.
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.h | 1 -
libavdevice/decklink_dec.cpp | 35 ++-
2 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 57ee7d1d68..f416134b8a 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -56,7 +56,6 @@ struct decklink_ctx {
IDeckLinkConfiguration *cfg;
IDeckLinkAttributes *attr;
decklink_output_callback *output_callback;
-decklink_input_callback *input_callback;
/* DeckLink mode information */
BMDTimeValue bmd_tb_den;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 897fca1003..974ee1d94c 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -596,8 +596,7 @@ public:
virtual HRESULT STDMETHODCALLTYPE
VideoInputFrameArrived(IDeckLinkVideoInputFrame*, IDeckLinkAudioInputPacket*);
private:
-ULONG m_refCount;
-pthread_mutex_t m_mutex;
+std::atomic _refs;
AVFormatContext *avctx;
decklink_ctx*ctx;
int no_video;
@@ -605,42 +604,30 @@ private:
int64_t initial_audio_pts;
};
-decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) :
m_refCount(0)
+decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) :
_refs(1)
{
avctx = _avctx;
decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
ctx = (struct decklink_ctx *)cctx->ctx;
no_video = 0;
initial_audio_pts = initial_video_pts = AV_NOPTS_VALUE;
-pthread_mutex_init(&m_mutex, NULL);
}
decklink_input_callback::~decklink_input_callback()
{
-pthread_mutex_destroy(&m_mutex);
}
ULONG decklink_input_callback::AddRef(void)
{
-pthread_mutex_lock(&m_mutex);
-m_refCount++;
-pthread_mutex_unlock(&m_mutex);
-
-return (ULONG)m_refCount;
+return ++_refs;
}
ULONG decklink_input_callback::Release(void)
{
-pthread_mutex_lock(&m_mutex);
-m_refCount--;
-pthread_mutex_unlock(&m_mutex);
-
-if (m_refCount == 0) {
+int ret = --_refs;
+if (!ret)
delete this;
-return 0;
-}
-
-return (ULONG)m_refCount;
+return ret;
}
static int64_t get_pkt_pts(IDeckLinkVideoInputFrame *videoFrame,
@@ -966,6 +953,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
struct decklink_ctx *ctx;
class decklink_allocator *allocator;
+class decklink_input_callback *input_callback;
AVStream *st;
HRESULT result;
char fname[1024];
@@ -1056,8 +1044,13 @@ av_cold int ff_decklink_read_header(AVFormatContext
*avctx)
goto error;
}
-ctx->input_callback = new decklink_input_callback(avctx);
-ctx->dli->SetCallback(ctx->input_callback);
+input_callback = new decklink_input_callback(avctx);
+ret = (ctx->dli->SetCallback(input_callback) == S_OK ? 0 :
AVERROR_EXTERNAL);
+input_callback->Release();
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Cannot set input callback\n");
+goto error;
+}
allocator = new decklink_allocator();
ret = (ctx->dli->SetVideoInputFrameMemoryAllocator(allocator) == S_OK ? 0
: AVERROR_EXTERNAL);
--
2.16.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: use a custom memory allocator
The default memory allocator is limited in the max number of frames available,
and therefore caused frame drops if the frames were not freed fast enough.
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 50
1 file changed, 50 insertions(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 510637676c..897fca1003 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -21,6 +21,9 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
+using std::atomic;
+
/* Include internal.h first to avoid conflict between winsock.h (used by
* DeckLink headers) and winsock2.h (used by libavformat) in MSVC++ builds */
extern "C" {
@@ -98,6 +101,44 @@ static VANCLineNumber vanc_line_numbers[] = {
{bmdModeUnknown, 0, -1, -1, -1}
};
+class decklink_allocator : public IDeckLinkMemoryAllocator
+{
+public:
+decklink_allocator(): _refs(1) { }
+virtual ~decklink_allocator() { }
+
+// IDeckLinkMemoryAllocator methods
+virtual HRESULT STDMETHODCALLTYPE AllocateBuffer(unsigned int
bufferSize, void* *allocatedBuffer)
+{
+void *buf = av_malloc(bufferSize + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!buf)
+return E_OUTOFMEMORY;
+*allocatedBuffer = buf;
+return S_OK;
+}
+virtual HRESULT STDMETHODCALLTYPE ReleaseBuffer(void* buffer)
+{
+av_free(buffer);
+return S_OK;
+}
+virtual HRESULT STDMETHODCALLTYPE Commit() { return S_OK; }
+virtual HRESULT STDMETHODCALLTYPE Decommit() { return S_OK; }
+
+// IUnknown methods
+virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID iid, LPVOID
*ppv) { return E_NOINTERFACE; }
+virtual ULONG STDMETHODCALLTYPE AddRef(void) { return ++_refs; }
+virtual ULONG STDMETHODCALLTYPE Release(void)
+{
+int ret = --_refs;
+if (!ret)
+delete this;
+return ret;
+}
+
+private:
+std::atomic _refs;
+};
+
extern "C" {
static void decklink_object_free(void *opaque, uint8_t *data)
{
@@ -924,6 +965,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
{
struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
struct decklink_ctx *ctx;
+class decklink_allocator *allocator;
AVStream *st;
HRESULT result;
char fname[1024];
@@ -1017,6 +1059,14 @@ av_cold int ff_decklink_read_header(AVFormatContext
*avctx)
ctx->input_callback = new decklink_input_callback(avctx);
ctx->dli->SetCallback(ctx->input_callback);
+allocator = new decklink_allocator();
+ret = (ctx->dli->SetVideoInputFrameMemoryAllocator(allocator) == S_OK ? 0
: AVERROR_EXTERNAL);
+allocator->Release();
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Cannot set custom memory allocator\n");
+goto error;
+}
+
if (mode_num == 0 && !cctx->format_code) {
if (decklink_autodetect(cctx) < 0) {
av_log(avctx, AV_LOG_ERROR, "Cannot Autodetect input stream or No
signal\n");
--
2.16.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] fftools/ffmpeg: fix for all forced key frames when 'copyts' is enabled
On Sun, May 06, 2018 at 10:38:59PM +0530, vdi...@akamai.com wrote: > From: Vishwanath Dixit > > Forced key frames generation functionality was assuming the first PTS > value as zero, but, when 'copyts' is enabled, the first PTS can be any > big number. This was eventually forcing all the frames as key frames. > To resolve this issue, update has been made to use first input pts as > reference pts. > --- > fftools/ffmpeg.c | 6 +- > fftools/ffmpeg.h | 1 + > fftools/ffmpeg_opt.c | 1 + > 3 files changed, 7 insertions(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Use the same name for stereo3d frame/packet side data
---
libavutil/frame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 00215ac29a..deb9b6f334 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -819,7 +819,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
switch(type) {
case AV_FRAME_DATA_PANSCAN: return "AVPanScan";
case AV_FRAME_DATA_A53_CC: return "ATSC A53 Part 4 Closed
Captions";
-case AV_FRAME_DATA_STEREO3D:return "Stereoscopic 3d metadata";
+case AV_FRAME_DATA_STEREO3D:return "Stereo 3D";
case AV_FRAME_DATA_MATRIXENCODING: return "AVMatrixEncoding";
case AV_FRAME_DATA_DOWNMIX_INFO:return "Metadata relevant to a downmix
procedure";
case AV_FRAME_DATA_REPLAYGAIN: return "AVReplayGain";
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil/encryption_info: Add NULL checks.
On Mon, Jun 4, 2018 at 10:46 AM Carl Eugen Hoyos wrote:
>
> 2018-06-04 18:59 GMT+02:00, Jacob Trimble :
> > On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
> > wrote:
> >>
> >> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
> >> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
> >> >
> >> > Signed-off-by: Jacob Trimble
> >> > ---
> >> > libavutil/encryption_info.c | 7 +--
> >> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
> >> > index 20a752d6b4..a48ded922c 100644
> >> > --- a/libavutil/encryption_info.c
> >> > +++ b/libavutil/encryption_info.c
> >> > @@ -64,6 +64,8 @@ AVEncryptionInfo *av_encryption_info_clone(const
> >> > AVEncryptionInfo *info)
> >> > {
> >> > AVEncryptionInfo *ret;
> >> >
> >> > +if (!info)
> >> > +return NULL;
> >> > ret = av_encryption_info_alloc(info->subsample_count,
> >> > info->key_id_size, info->iv_size);
> >> > if (!ret)
> >> > return NULL;
> >>
> >> > @@ -127,7 +129,7 @@ uint8_t *av_encryption_info_add_side_data(const
> >> > AVEncryptionInfo *info, size_t *
> >> > uint8_t *buffer, *cur_buffer;
> >> > uint32_t i;
> >> >
> >> > -if (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA < info->key_id_size ||
> >> > +if (!info || !size || UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA <
> >> > info->key_id_size ||
> >> > UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size <
> >> > info->iv_size ||
> >> > (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size -
> >> > info->iv_size) / 8 < info->subsample_count) {
> >> > return NULL;
> >> > @@ -260,7 +262,8 @@ uint8_t *av_encryption_init_info_add_side_data(const
> >> > AVEncryptionInitInfo *info,
> >> > uint8_t *buffer, *cur_buffer;
> >> > uint32_t i, max_size;
> >> >
> >> > -if (UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
> >> > info->system_id_size ||
> >> > +if (!info || !side_data_size ||
> >> > +UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
> >> > info->system_id_size ||
> >> > UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA -
> >> > info->system_id_size < info->data_size) {
> >> > return NULL;
> >> > }
> >>
> >> in which valid case would these be called with NULL input ?
> >> iam asking as this feels as if it might be a bug in teh caller
> >>
> >
> > This was found by Chrome's ClusterFuzz, which I am not that familiar
> > with. I think it was just running fuzz tests directly on FFmpeg code,
> > so it wasn't in production code. But since this is a public method,
> > we should validate the input in any case.
>
> How do you validate the size of C buffers in general?
>
I'm not sure I understand your comment. You can't verify the length
of buffers unless the size is given to the method. These functions do
accept the size and verify that the data is valid for the given size.
Since we are verifying the data and the size we are given, we should
be checking for NULL as well.
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil/encryption_info: Add NULL checks.
2018-06-04 23:07 GMT+02:00, Jacob Trimble :
> On Mon, Jun 4, 2018 at 10:46 AM Carl Eugen Hoyos wrote:
>>
>> 2018-06-04 18:59 GMT+02:00, Jacob Trimble
>> :
>> > On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
>> > wrote:
>> >>
>> >> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
>> >> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
>> >> >
>> >> > Signed-off-by: Jacob Trimble
>> >> > ---
>> >> > libavutil/encryption_info.c | 7 +--
>> >> > 1 file changed, 5 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/libavutil/encryption_info.c
>> >> > b/libavutil/encryption_info.c
>> >> > index 20a752d6b4..a48ded922c 100644
>> >> > --- a/libavutil/encryption_info.c
>> >> > +++ b/libavutil/encryption_info.c
>> >> > @@ -64,6 +64,8 @@ AVEncryptionInfo *av_encryption_info_clone(const
>> >> > AVEncryptionInfo *info)
>> >> > {
>> >> > AVEncryptionInfo *ret;
>> >> >
>> >> > +if (!info)
>> >> > +return NULL;
>> >> > ret = av_encryption_info_alloc(info->subsample_count,
>> >> > info->key_id_size, info->iv_size);
>> >> > if (!ret)
>> >> > return NULL;
>> >>
>> >> > @@ -127,7 +129,7 @@ uint8_t *av_encryption_info_add_side_data(const
>> >> > AVEncryptionInfo *info, size_t *
>> >> > uint8_t *buffer, *cur_buffer;
>> >> > uint32_t i;
>> >> >
>> >> > -if (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA < info->key_id_size ||
>> >> > +if (!info || !size || UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA <
>> >> > info->key_id_size ||
>> >> > UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size <
>> >> > info->iv_size ||
>> >> > (UINT32_MAX - FF_ENCRYPTION_INFO_EXTRA - info->key_id_size -
>> >> > info->iv_size) / 8 < info->subsample_count) {
>> >> > return NULL;
>> >> > @@ -260,7 +262,8 @@ uint8_t
>> >> > *av_encryption_init_info_add_side_data(const
>> >> > AVEncryptionInitInfo *info,
>> >> > uint8_t *buffer, *cur_buffer;
>> >> > uint32_t i, max_size;
>> >> >
>> >> > -if (UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
>> >> > info->system_id_size ||
>> >> > +if (!info || !side_data_size ||
>> >> > +UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA <
>> >> > info->system_id_size ||
>> >> > UINT32_MAX - FF_ENCRYPTION_INIT_INFO_EXTRA -
>> >> > info->system_id_size < info->data_size) {
>> >> > return NULL;
>> >> > }
>> >>
>> >> in which valid case would these be called with NULL input ?
>> >> iam asking as this feels as if it might be a bug in teh caller
>> >>
>> >
>> > This was found by Chrome's ClusterFuzz, which I am not that familiar
>> > with. I think it was just running fuzz tests directly on FFmpeg code,
>> > so it wasn't in production code. But since this is a public method,
>> > we should validate the input in any case.
>>
>> How do you validate the size of C buffers in general?
>
> I'm not sure I understand your comment. You can't verify the
> length of buffers unless the size is given to the method.
If we can't verify the size of the buffer (where both overread
and overwrite at least can have catastrophic impact) why
is it a good idea to check if the user passed an actual pointer
(as is required) or NULL as argument (where NULL typically
has limited impact)?
> These functions do accept the size and verify that the data
> is valid for the given size.
I may misunderstand the code but it looks to me as if the
given size is only checked because the needed space is
not necessarily known in advance / most functions do not
check.
> Since we are verifying the data and the size we are
> given, we should be checking for NULL as well.
Why?
(As we cannot check for the worse case anyway.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/amrwbdec: Fix division by 0 in find_hb_gain()
On Sun, Jun 03, 2018 at 02:44:45AM +0200, Michael Niedermayer wrote: > This restructures the code slightly toward D_UTIL_dec_synthesis() > > Fixes: > 7420/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AMRWB_fuzzer-6577305112543232 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/amrwbdec.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Atempo limits
On 06/04/2018 12:09 PM, Ronak wrote: Hello, How are you all? We are looking to use the atempo filter for our audio files. However, the limit between 0.5 - 2x is too restrictive for us. We would like to expand the limit to 0.5x - 3x. I tried changing the range in atempo.c and the rest of the tempo filter just worked. Going below 0.5 is likely not going to sound good. Going above 2.0 should be fine. The reason for current [0.5, 2.0] range is mostly for symmetry. atempo=0.5 followed by atempo=2.0 should sound like original audio. This should also point you to an alternative solution -- put 2 atempo filters one after another to achieve tempo greater than 2 (atempo=2.0,atempo=1.5), or like this: ffmpeg -i /scratch/Music/02\ Feeling\ Good.mp3 -af 'atempo=sqrt(3.0),atempo=sqrt(3.0)' -y /tmp/tempo-3x.wav Pavel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Atempo limits
On Mon, Jun 4, 2018, at 10:09 AM, Ronak wrote: > > We are looking to use the atempo filter for our audio files. However, > the limit between 0.5 - 2x is too restrictive for us. We would like to > expand the limit to 0.5x - 3x. Consider using the rubberband filter instead if atempo is too simple or restrictive. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavc/dolby_e: fix make checkheaders
2018-06-04 22:52 GMT+08:00 James Almer :
> On 6/4/2018 11:18 AM, Jun Zhao wrote:
>> move the the function init_tables() definitions from header file
>> to .c file to fix make checkheaders.
>
> What compile flags are you using? checkheaders seems to work just fine
> on a normal build.
> http://fate.ffmpeg.org/report.cgi?time=20180604121434&slot=x86_64-archlinux-gcc-checkheaders
>
>
I guess I give an inaccurate commit message, more accurate commits
message is "fix make checkheaders warning", will update the commit
message
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/dolby_e.c | 87
>>
>> libavcodec/dolby_e.h | 86
>> ---
>> 2 files changed, 87 insertions(+), 86 deletions(-)
>>
>> diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
>> index 91a00ce..429612e 100644
>> --- a/libavcodec/dolby_e.c
>> +++ b/libavcodec/dolby_e.c
>> @@ -681,6 +681,93 @@ static av_cold int dolby_e_close(AVCodecContext *avctx)
>> return 0;
>> }
>>
>> +
>> +static av_cold void init_tables(void)
>> +{
>> +int i, j;
>> +
>> +for (i = 1; i < 17; i++)
>> +mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
>> +
>> +for (i = 2; i < 16; i++) {
>> +mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
>> +mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
>> +mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
>> +}
>> +
>> +mantissa_tab1[i][1] = 0.5f / (1 << 15);
>> +mantissa_tab1[i][2] = 0.75f / (1 << 15);
>> +mantissa_tab1[i][3] = 0.875f / (1 << 15);
>> +
>> +for (i = 1; i < 17; i++) {
>> +mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
>> +mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
>> +mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
>> +for (j = 1; j < 4; j++)
>> +mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f
>> / (1 << i + j);
>> +}
>> +
>> +mantissa_tab3[1][3] = 0.6875f;
>> +
>> +for (i = 0; i < 25; i++) {
>> +exponent_tab[i * 2] = 1.0f / (1 << i);
>> +exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
>> +}
>> +
>> +for (i = 1; i < 1024; i++)
>> +gain_tab[i] = exp2f((i - 960) / 64.0f);
>> +
>> +// short 1
>> +ff_kbd_window_init(window, 3.0f, 128);
>> +for (i = 0; i < 128; i++)
>> +window[128 + i] = window[127 - i];
>> +
>> +// start
>> +for (i = 0; i < 192; i++)
>> +window[256 + i] = start_window[i];
>> +
>> +// short 2
>> +for (i = 0; i < 192; i++)
>> +window[448 + i] = short_window2[i];
>> +for (i = 0; i < 64; i++)
>> +window[640 + i] = window[63 - i];
>> +
>> +// short 3
>> +for (i = 0; i < 64; i++)
>> +window[704 + i] = short_window3[i];
>> +for (i = 0; i < 192; i++)
>> +window[768 + i] = window[64 + i];
>> +
>> +// bridge
>> +for (i = 0; i < 128; i++)
>> +window[960 + i] = window[i];
>> +for (i = 0; i < 64; i++)
>> +window[1088 + i] = 1.0f;
>> +
>> +// long
>> +ff_kbd_window_init(window + 1408, 3.0f, 256);
>> +for (i = 0; i < 640; i++)
>> +window[1664 + i] = 1.0f;
>> +for (i = 0; i < 256; i++)
>> +window[2304 + i] = window[1152 + i] = window[1663 - i];
>> +
>> +// reverse start
>> +for (i = 0; i < 192; i++)
>> +window[2560 + i] = window[447 - i];
>> +
>> +// reverse short 2
>> +for (i = 0; i < 256; i++)
>> +window[2752 + i] = window[703 - i];
>> +
>> +// reverse short 3
>> +for (i = 0; i < 256; i++)
>> +window[3008 + i] = window[959 - i];
>> +
>> +// reverse bridge
>> +for (i = 0; i < 448; i++)
>> +window[3264 + i] = window[1407 - i];
>> +}
>> +
>> static av_cold int dolby_e_init(AVCodecContext *avctx)
>> {
>> static AVOnce init_once = AV_ONCE_INIT;
>> diff --git a/libavcodec/dolby_e.h b/libavcodec/dolby_e.h
>> index 0390233..ae04bf6 100644
>> --- a/libavcodec/dolby_e.h
>> +++ b/libavcodec/dolby_e.h
>> @@ -644,90 +644,4 @@ static float gain_tab[1024];
>>
>> DECLARE_ALIGNED(32, static float, window)[3712];
>>
>> -static av_cold void init_tables(void)
>> -{
>> -int i, j;
>> -
>> -for (i = 1; i < 17; i++)
>> -mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
>> -
>> -for (i = 2; i < 16; i++) {
>> -mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
>> -mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
>> -mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
>> -}
>> -
>> -mantissa_tab1[i][1] = 0.5f / (1 << 15);
>> -mantissa_tab1[i][2] = 0.75f / (1 << 15);
>> -mantissa_tab1[i][3] = 0.875f / (1 << 15);
>> -
>> -for (i = 1; i < 17; i++) {
>> -mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
>> -mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
>> -mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
>> -for (j = 1; j < 4; j++)
>> -mantissa_tab3[i][j
[FFmpeg-devel] [PATCH 1/3] avcodec/truemotion2: Fix overflow in tm2_apply_deltas()
Fixes: signed integer overflow: 1077952576 + 1077952576 cannot be represented
in type 'int'
Fixes:
7712/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5056281753681920
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/truemotion2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index f7dbe047c7..b689efdb99 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -451,7 +451,7 @@ static inline int GET_TOK(TM2Context *ctx,int type)
/* common operations - add deltas to 4x4 block of luma or 2x2 blocks of chroma
*/
static inline void tm2_apply_deltas(TM2Context *ctx, int* Y, int stride, int
*deltas, int *last)
{
-int ct, d;
+unsigned ct, d;
int i, j;
for (j = 0; j < 4; j++){
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/shorten: Check non COMM chunk len before skip in decode_aiff_header()
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type
'int'
Fixes:
8024/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SHORTEN_fuzzer-5109204648984576
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/shorten.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/shorten.c b/libavcodec/shorten.c
index 49af6beec6..ae0cdfe09d 100644
--- a/libavcodec/shorten.c
+++ b/libavcodec/shorten.c
@@ -234,11 +234,11 @@ static int decode_aiff_header(AVCodecContext *avctx,
const uint8_t *header,
while (bytestream2_get_le32(&gb) != MKTAG('C', 'O', 'M', 'M')) {
len = bytestream2_get_be32(&gb);
-bytestream2_skip(&gb, len + (len & 1));
-if (len < 0 || bytestream2_get_bytes_left(&gb) < 18) {
+if (len < 0 || bytestream2_get_bytes_left(&gb) < 18LL + len + (len&1))
{
av_log(avctx, AV_LOG_ERROR, "no COMM chunk found\n");
return AVERROR_INVALIDDATA;
}
+bytestream2_skip(&gb, len + (len & 1));
}
len = bytestream2_get_be32(&gb);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/mjpegdec: Fix integer overflow in ljpeg_decode_rgb_scan()
Fixes: signed integer overflow: 32768 + 2147450880 cannot be represented in
type 'int'
Fixes:
7885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5298834394578944
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 22ca69f841..d1dca84d36 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1078,7 +1078,7 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
return -1;
left[i] = buffer[mb_x][i] =
-mask & (pred + (dc * (1 << point_transform)));
+mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
if (s->restart_interval && !--s->restart_count) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Atempo limits
Thanks. Is it okay if I push a patch for this? How high of a limit does the algorithm support today? Sent from my iPhone > On Jun 4, 2018, at 8:00 PM, Pavel Koshevoy wrote: > >> On 06/04/2018 12:09 PM, Ronak wrote: >> Hello, >> >> How are you all? >> >> We are looking to use the atempo filter for our audio files. However, the >> limit between 0.5 - 2x is too restrictive for us. We would like to expand >> the limit to 0.5x - 3x. >> >> I tried changing the range in atempo.c and the rest of the tempo filter just >> worked. >> > > Going below 0.5 is likely not going to sound good. Going above 2.0 should be > fine. The reason for current [0.5, 2.0] range is mostly for symmetry. > atempo=0.5 followed by atempo=2.0 should sound like original audio. This > should also point you to an alternative solution -- put 2 atempo filters one > after another to achieve tempo greater than 2 (atempo=2.0,atempo=1.5), or > like this: > > ffmpeg -i /scratch/Music/02\ Feeling\ Good.mp3 -af > 'atempo=sqrt(3.0),atempo=sqrt(3.0)' -y /tmp/tempo-3x.wav > > Pavel. > > ___ > 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] Atempo limits
We did consider rubberband, but the audio quality is too poor. The audio has echo artifacts in it that makes it sound robotic. Sent from my iPhone > On Jun 4, 2018, at 8:32 PM, Lou Logan wrote: > >> On Mon, Jun 4, 2018, at 10:09 AM, Ronak wrote: >> >> We are looking to use the atempo filter for our audio files. However, >> the limit between 0.5 - 2x is too restrictive for us. We would like to >> expand the limit to 0.5x - 3x. > > Consider using the rubberband filter instead if atempo is too simple or > restrictive. > ___ > 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] Atempo limits
On 06/04/2018 08:35 PM, Ronak Patel wrote: Thanks. Is it okay if I push a patch for this? How high of a limit does the algorithm support today? I don't think there is an upper limit... Post a patch here for review. See http://www.ffmpeg.org/developer.html#Submitting-patches-1 Pavel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
