Re: [FFmpeg-devel] [PATCH 5/5] x86: Add some additional cpuflag relations
On Fri, Jun 9, 2017 at 1:05 AM, James Darnley wrote: >Where should I put the aesni define? Between sse42 and avx. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] x86inc: Fix call with memory operands
On Fri, Jun 9, 2017 at 1:04 AM, James Darnley wrote: > libavutil/x86/x86inc.asm | 6 +- Bump the date in the header to 2017 as well. That was done in x264 as part of an earlier commit but might as well squash it into this one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
On 6/9/17, Michael Niedermayer wrote: > On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer >> >> wrote: >> >> > Signed value in >> > Unsigned >> > INTeger type >> >> [..] >> > Both SUINT and unsigned should produce identical binaries >> >> This seems to go against the rule that code should be as simple as >> possible. >> >> Unsigned is simpler than SUINT if the outcome is the same. > > You can simply add the part of my mail here as awnser that you snipped > away: > > "But it makes the code hard to understand and maintain because these > values are not positive integers but signed integers. Which for > C standard compliance need to be stored in a unsigned type." > > A type that avoids the undefinedness of signed but is semantically > signed is correct, unsigned is not. > > If understandable code and maintainable code has no value to you, > you would favour using single letter variables exclusivly and would > never use typedef. > But you do not do that. > > I fail to understand why you insist on using unsigned in place of a > more specific type, it is not the correct nor clean thing to do. If I understand correctly, the root of the problem is the undefined behavior of the compiler and the C standard. Is there any chance that FFmpeg project could initiate a change in the next C standard, so this thing would be defined? (and I guess, also define a few other similar things, like signed right shift, etc...) It is a matter of fact, that a lot of compiler-defined-things have been implemented in certain ways on most compilers and that there are plenty of programs depend on these specific implementations and break when a new compiler does things differently (clang had nice article about it). About the typedef, is SUINT a standard defined type for workarounding this specific problem? I do suspect that some of our fellow developers simply find its name ugly. Maybe they would be more welcoming if "suint32_t" like typedef is used? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
On Thu, Jun 08, 2017 at 02:02:49PM -0400, Ronald S. Bultje wrote: > Hi, > > On Thu, Jun 1, 2017 at 5:55 PM, Michael Niedermayer > wrote: > > > On Thu, Jun 01, 2017 at 07:48:38AM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Thu, Jun 1, 2017 at 2:27 AM, raymond zheng < > > raymondzheng1...@gmail.com> > > > wrote: > > > > > > > This patch is only for solving the bug introduced by chunksize has been > > > > initial set as UINT64 MAX. > > > > > > > > > > I understand. So what will happen if the server responds that the > > chunksize > > > is really actually UINT64_MAX? How do we distinguish between that and > > > chunksize being unset (which is what UINT64_MAX currently means)? We'll > > > need a flag to indicate whether chunksize is specified by the server or > > > not, right? > > > > does UINT64_MAX chunksize make sense ? > > doesnt this indicate that theres a really huge chunk ? > > or does it have some special meaning ? > > iam asking because this feels a bit odd. Could a server use > > UINT64_MAX + 1 instead of UINT64_MAX ? If so the point of failure moves > > by one in UINT64_MAX by adding a flag, or maybe i misunderstand > > > Fair enough, patch is OK then. ok, ill apply it on my next git push thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] x86: Add some additional cpuflag relations
On 2017-06-09 10:08, Henrik Gramner wrote: > On Fri, Jun 9, 2017 at 1:05 AM, James Darnley wrote: >> Where should I put the aesni define? > > Between sse42 and avx. Thank you. I will change this and the first patch to bump the date. I'll give other people about an hour to make other comments. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm
On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote: > On request by Rostislav Pehlivanov (atomnuker), I've been working on > SSE/AVX accelerated version of pvq_search(). > > The attached patch is my work so far. > > At the moment, for me, at the default bitrate > the function is 2.5 times faster than the current C version. > (My cpu is Intel Westmere class.) > The total encoding time is about 5% faster. > > I'd like some more benchmarks on different CPUs > and maybe some advises how to improve it. > (I've left some alternative methods in the code > that could be easily switched with defines, as they > may be faster on other cpu's). > (I'm also quite afraid how fast it would run on pre-Ryzen AMD CPUs) > > > The code generates 4 variants: SSE2, SSE4.2, AVX and 256bit AVX2. > I haven't tested the AVX myself on real CPU, > I used Intel SDE to develop and test them. > Rostislav (atomnuker) reported some crashes with the 256bit AVX2, > that however might be related to clang tools. > > > > > Bellow are some broad descriptions: > > The typical use of the function for the default bitrate (96kbps) is > K<=36 and N<=32. > N is the size of the input array (called vector), K is number of > pulses that should be present in the output (The sum of output > elements is K). > > In synthetic tests, the SIMD function could be 8-12 times faster with > the maximum N=176. > I've been told that bigger sizes are more common at low bitrate encodes and > will be more common with the upcoming RDO improvements. > > A short description of the function working: > 1. Loop that calculates sum (Sx) of the input elements (inX[]). The > loop is used to fill a stack allocated temp buffer (tmpX) that is > aligned to mmsize and contains absolute values of inX[i]. > > 2. Pre-Search loop. It uses K/Sx as approximation for the vector gain > and fills output vector outY[] based on it. The output is in integers, > but we use outY[] to temporally store the doubled Y values as floats. > (We need 2*Y for calculations). This loop also calculates few > parameters that are needed for the distortion calculations later (Syy= > Sum of inY[i]^2 ; Sxy=Sum inX[i]*outY[i] ) > > 3. Adding of missing pulses or Elimination of extra ones. > The C function uses variable "phase" to signal if pulses should be > added or removed, I've separated this to separate cases. The code is > shared through a macro PULSES_SEARCH . > Each case is formed by 2 loops. The outer loop is executed until we > have K pulses in the output. > The inner is calculating the distortion parameter for each element and > picking the best one. > (parallel search, combination of parallel results, update of variables). > > 4. When we are done we do one more loop, to convert outY[] to single > integer and to restore its sign (by using the original inX[]). > > 5. There is special case when Sx==0, that happens if all elements of > the input are zeroes (in theory the input should be normalized, that > means Sum of X[i]^2 == 1.0). In this case return zero output and 1.0 > as gain. > > --- > Now, I've left some defines that change the generated code. > > HADDPS_IS_FAST > PHADDD_IS_FAST > I've implemented my own horizontal sums macros, and while doing it, I > have discovered that on my CPU (Westmere class) the use of "new" > SSE4.2 instructions are not faster than using my own code for doing > the same. > It's not speed critical, since horizontal sums are used 3-4 times per > function call. > > BLENDVPS_IS_FAST > PBLENDVB_IS_FAST > I think that blend on my CPU is faster than the alternative version > that I've implemented. However I'm not sure this is true for all > CPU's, since a number of modern cpu have latency=3 and > inv_throughput=2 (that's 2 clocks until another blend could start). > > CONST_IN_X64_REG_IS_FASTER > The function is implemented so only 8 registers are used. With this > define constants used during PULSES_SEARCH are loaded in the high > registers available on X64. I could not determine if it is faster to > do so... it should be, but sometimes I got the opposite result. > I'd probably enable it in the final version. > > STALL_WRITE_FORWARDING > After the inner search finds the maximum, we add/remove pulse in > outY[i]. Writing single element (sizeof(float)=4) however could block > the long load done in the inner loop (mmsize=16). This hurts a lot > more on small vector sizes. > On Skylake the penalty is only 11 cycles, while Ryzen should have no > penalty at all. Older CPU's can have penalty of up to 200 cycles. > > SHORT_SYY_UPDATE > This define has meaning only when the STALL* is 0 (aka have the longer > code to avoid stalls). > It saves few instructions by loading old outY[] value by scalar load, > instead of using HSUMPS and some 'haddps' to calculate them. > So far it looks like the short update is always faster, but I've left > it just in case... > > USE_APPROXIMATION > This controls the method used for calculation of the distortion parameter. > "0"
Re: [FFmpeg-devel] [PATCH] Add FITS Decoder
On Thu, Jun 08, 2017 at 10:34:15PM +0530, Paras Chadha wrote:
> It supports all 2-d images alongwith bzero, bscale and blank keywords.
> RGBA images are supported as NAXIS3 = 3 or 4 i.e. Planes in RGBA order. Also
> CTYPE = 'RGB ' should be present.
> It currently does not support XTENSION keyword.
>
> Signed-off-by: Paras Chadha
> ---
> Changelog| 1 +
> doc/general.texi | 2 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h | 1 +
> libavcodec/codec_desc.c | 8 +
> libavcodec/fitsdec.c | 527
> +++
> libavcodec/version.h | 4 +-
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/img2.c | 1 +
> libavformat/img2dec.c| 10 +
> 12 files changed, 556 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/fitsdec.c
[...]
> +/**
> + * function reads the fits header and stores the values in fits_header
> pointed by header
> + * @param avctx - AVCodec context
> + * @param ptr - pointer to pointer to the data
> + * @param header - pointer to the fits_header
> + * @param end - pointer to end of packet
> + * @return 1, if calculated successfully, otherwise AVERROR_INVALIDDATA
> + */
> +static int fits_read_header(AVCodecContext *avctx, const uint8_t **ptr,
> fits_header * header, const uint8_t * end)
> +{
> +const uint8_t *ptr8 = *ptr;
> +int lines_read = 0, i, dim_no, t, data_min_found = 0, data_max_found =
> 0, ret;
> +uint64_t size=1;
> +char str_val[80];
> +double d;
> +
> +header->blank = 0;
> +header->bscale = 1.0;
> +header->bzero = 0;
> +header->rgb = 0;
> +
> +if (end - ptr8 < 80)
> +return AVERROR_INVALIDDATA;
> +
> +if (sscanf(ptr8, "SIMPLE = %c", &header->simple) != 1) {
> +av_log(avctx, AV_LOG_ERROR, "missing SIMPLE keyword\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (header->simple == 'F')
> +av_log(avctx, AV_LOG_WARNING, "not a standard FITS file\n");
> +else if (header->simple != 'T') {
> +av_log(avctx, AV_LOG_ERROR, "invalid SIMPLE value, SIMPLE = %c\n",
> header->simple);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +ptr8 += 80;
> +lines_read++;
> +
> +if (end - ptr8 < 80)
> +return AVERROR_INVALIDDATA;
> +
> +if (sscanf(ptr8, "BITPIX = %d", &header->bitpix) != 1) {
> +av_log(avctx, AV_LOG_ERROR, "missing BITPIX keyword\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +size = abs(header->bitpix) / 8;
> +ptr8 += 80;
> +lines_read++;
> +
> +if (end - ptr8 < 80)
> +return AVERROR_INVALIDDATA;
> +
> +if (sscanf(ptr8, "NAXIS = %d", &header->naxis) != 1) {
> +av_log(avctx, AV_LOG_ERROR, "missing NAXIS keyword\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (header->naxis == 0) {
> +av_log(avctx, AV_LOG_ERROR, "No image data found, NAXIS = %d\n",
> header->naxis);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (header->naxis != 2 && header->naxis != 3) {
> +av_log(avctx, AV_LOG_ERROR, "unsupported number of dimensions, NAXIS
> = %d\n", header->naxis);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +ptr8 += 80;
> +lines_read++;
> +
> +for (i = 0; i < header->naxis; i++) {
> +if (end - ptr8 < 80)
> +return AVERROR_INVALIDDATA;
> +
> +if (sscanf(ptr8, "NAXIS%d = %d", &dim_no, &header->naxisn[i]) != 2
> || dim_no != i+1) {
> +av_log(avctx, AV_LOG_ERROR, "missing NAXIS%d keyword\n", i+1);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +size *= header->naxisn[i];
> +ptr8 += 80;
> +lines_read++;
> +}
> +
> +if (end - ptr8 < 80)
> +return AVERROR_INVALIDDATA;
> +
> +while (strncmp(ptr8, "END", 3)) {
> +if (sscanf(ptr8, "BLANK = %d", &t) == 1)
> +header->blank = t;
> +else if (sscanf(ptr8, "BSCALE = %lf", &d) == 1)
> +header->bscale = d;
> +else if (sscanf(ptr8, "BZERO = %lf", &d) == 1)
> +header->bzero = d;
> +else if (sscanf(ptr8, "DATAMAX = %lf", &d) == 1) {
> +data_max_found = 1;
> +header->data_max = d;
> +}
> +else if (sscanf(ptr8, "DATAMIN = %lf", &d) == 1) {
> +data_min_found = 1;
> +header->data_min = d;
> +}
> +else if (sscanf(ptr8, "CTYPE3 = '%s '", str_val) == 1) {
what prevents a buffer overflow here ?
[...]
> +
> +static int fits_decode_frame(AVCodecContext *avctx, void *data, int
> *got_frame, AVPacket *avpkt)
> +{
> +AVFrame *p=data;
> +const uint8_t *ptr8 = avpkt->data, *end;
> +int16_t t16;
> +int32_t t32;
> +int64_t t64;
> +float tflt;
> +double tdbl;
> +int ret, i, j;
> +uint8_t *dst8;
> +uint16_t *dst16;
> +uint32_t *dst32;
> +uint64_t
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation
On 6/8/17, Ilia Valiakhmetov wrote: > vp9_diag_downright_16x16_12bpp_c: 149.0 > vp9_diag_downright_16x16_12bpp_sse2: 67.8 > vp9_diag_downright_16x16_12bpp_ssse3: 45.6 > vp9_diag_downright_16x16_12bpp_avx: 36.6 > vp9_diag_downright_16x16_12bpp_avx2: 25.5 > > ~30% faster than avx > > Signed-off-by: Ilia Valiakhmetov > --- > libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ > libavcodec/x86/vp9intrapred_16bpp.asm | 56 > +++ > 2 files changed, 58 insertions(+) > > diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c > b/libavcodec/x86/vp9dsp_init_16bpp.c > index d1b8fcd..8d1aa13 100644 > --- a/libavcodec/x86/vp9dsp_init_16bpp.c > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c > @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); > decl_ipred_fns(dc_top, 16, mmxext, sse2); > decl_ipred_fns(dc_left, 16, mmxext, sse2); > decl_ipred_fn(dl, 16, 16, avx2); > +decl_ipred_fn(dr, 16, 16, avx2); > decl_ipred_fn(dl, 32, 16, avx2); > > #define decl_ipred_dir_funcs(type) \ > @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext > *dsp) > init_fpel_func(1, 1, 64, avg, _16, avx2); > init_fpel_func(0, 1, 128, avg, _16, avx2); > init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); > +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2); > init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); > } > > diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm > b/libavcodec/x86/vp9intrapred_16bpp.asm > index 92333bc..67b98b1 100644 > --- a/libavcodec/x86/vp9intrapred_16bpp.asm > +++ b/libavcodec/x86/vp9intrapred_16bpp.asm > @@ -1170,6 +1170,62 @@ DR_FUNCS 2 > INIT_XMM avx > DR_FUNCS 2 > > +%if HAVE_AVX2_EXTERNAL > +INIT_YMM avx2 > +cglobal vp9_ipred_dr_16x16_16, 4, 6, 7, dst, stride, l, a > +movam0, [lq] ; klmnopqrstuvwxyz > +movum1, [aq-2] ; *abcdefghijklmno > +movam2, [aq] ; abcdefghijklmnop I know unaligned loads are not as slow as they used to be, but could m1 be produced by m2 and palignr? From the comment I assume you don't use the extra two bytes that you get from the load, as you mark them as "*" generic undefined values > +vperm2i128 m4, m2, m2, q2001 ; ijklmnop > +vpalignrm5, m4, m2, 2 ; bcdefghijklmnop. > +vperm2i128 m3, m0, m1, q0201 ; stuvwxyz*abcdefg > +LOWPASS 1, 2, 5 ; ABCDEFGHIJKLMNO. > +vpalignrm4, m3, m0, 2 ; lmnopqrstuvwxyz* > +vpalignrm5, m3, m0, 4 ; mnopqrstuvwxyz*a > +LOWPASS 0, 4, 5 ; LMNOPQRSTUVWXYZ# > +vperm2i128 m5, m0, m1, q0201 ; TUVWXYZ#ABCDEFGH > +DEFINE_ARGS dst, stride, stride3, stride5, dst3, cnt "cnt" doesn't seem to be used. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm
On 6/9/17, Michael Niedermayer wrote: > On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote: >> opus_pvq.c |9 >> opus_pvq.h |5 >> x86/Makefile|1 >> x86/opus_dsp_init.c | 47 +++ >> x86/opus_pvq_search.asm | 597 >> >> 5 files changed, 657 insertions(+), 2 deletions(-) >> 3b9648bea3f01dad2cf159382f0ffc2d992c84b2 >> 0001-SIMD-opus-pvq_search-implementation.patch >> From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001 >> From: Ivan Kalvachev >> Date: Thu, 8 Jun 2017 22:24:33 +0300 >> Subject: [PATCH 1/3] SIMD opus pvq_search implementation. > > seems this breaks build with mingw64, didnt investigate but it > fails with these errors: > > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): > relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > collect2: error: ld returned 1 exit status > collect2: error: ld returned 1 exit status > make: *** [ffmpeg_g.exe] Error 1 > make: *** Waiting for unfinished jobs > make: *** [ffprobe_g.exe] Error 1 const_*_edge is used on only one place is the code. Would you check if this patch fixes the issue. --- a/libavcodec/x86/opus_pvq_search.asm +++ b/libavcodec/x86/opus_pvq_search.asm @@ -419,7 +419,7 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N add Nq, r4q ; Nq = align(Nq, mmsize) sub rsp, Nq; allocate tmpX[Nq] -movups m3, [const_align_abs_edge-mmsize+r4q] ; this is the bit mask for the padded read at the end of the input +movups m3, [const_align_abs_mask+32-mmsize+r4q] ; this is the bit mask for the padded read at the end of the input lea r4q, [Nq-mmsize] ; Nq is rounded up (aligned up) to mmsize, so r4q can't become negative here, unless N=0. movups m2, [inXq + r4q] === I expected that the addresses would be pre-calculated by n/yasm as one value and indexed relative to the section start. Instead it seems that each entry is represented with its own address and offset from it. Since the offset is negative it uses all 64 bits and it makes difference if it is truncated to 32 bits. Same issue could happen with clang tools. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] x86inc: Make REP_RET identical to RET in SSSE3+ functions
Hi, On Thu, Jun 8, 2017 at 7:04 PM, James Darnley wrote: > From: Henrik Gramner > > There's no point in emitting a rep prefix before ret on modern CPUs. > --- > libavutil/x86/x86inc.asm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] tools: add sofa2wavs
Signed-off-by: Paul B Mahol
---
Makefile | 1 +
tools/Makefile| 1 +
tools/sofa2wavs.c | 79 +++
3 files changed, 81 insertions(+)
create mode 100644 tools/sofa2wavs.c
diff --git a/Makefile b/Makefile
index 685b613..a2df8b9 100644
--- a/Makefile
+++ b/Makefile
@@ -82,6 +82,7 @@ target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o
$(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
tools/cws2fws$(EXESUF): ELIBS = $(ZLIB)
+tools/sofa2wavs$(EXESUF): ELIBS = $(FF_EXTRALIBS)
tools/uncoded_frame$(EXESUF): $(FF_DEP_LIBS)
tools/uncoded_frame$(EXESUF): ELIBS = $(FF_EXTRALIBS)
tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
diff --git a/tools/Makefile b/tools/Makefile
index 3ebd361..3909e7c 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -1,4 +1,5 @@
TOOLS = qt-faststart trasher uncoded_frame
+TOOLS-$(CONFIG_LIBMYSOFA) += sofa2wavs
TOOLS-$(CONFIG_ZLIB) += cws2fws
tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
diff --git a/tools/sofa2wavs.c b/tools/sofa2wavs.c
new file mode 100644
index 000..f85e54f
--- /dev/null
+++ b/tools/sofa2wavs.c
@@ -0,0 +1,79 @@
+#include
+#include
+#include
+#include
+#include
+
+int main(int argc, char **argv)
+{
+struct MYSOFA_HRTF *hrtf;
+int sample_rate;
+int err, i, j;
+
+if (argc < 3) {
+printf("usage: %s input_SOFA_file output_directory\n", argv[0]);
+return 1;
+}
+
+hrtf = mysofa_load(argv[1], &err);
+if (!hrtf || err) {
+printf("invalid input SOFA file: %s\n", argv[1]);
+return 1;
+}
+
+if (hrtf->DataSamplingRate.elements != 1)
+goto fail;
+sample_rate = hrtf->DataSamplingRate.values[0];
+
+err = mkdir(argv[2], 0744);
+if (err)
+goto fail;
+
+err = chdir(argv[2]);
+if (err)
+goto fail;
+
+for (i = 0; i < hrtf->M; i++) {
+FILE *file;
+int bps = 32;
+int blkalign = 8;
+int bytespersec = blkalign * sample_rate;
+char filename[1024];
+int azi = hrtf->SourcePosition.values[i * 3];
+int ele = hrtf->SourcePosition.values[i * 3 + 1];
+int dis = hrtf->SourcePosition.values[i * 3 + 2];
+int size = 8 * hrtf->N;
+int offset = i * 2 * hrtf->N;
+
+snprintf(filename, sizeof(filename), "azi_%d_ele_%d_dis_%d.wav", azi,
ele, dis);
+file = fopen(filename, "w+");
+fwrite("RIFF", 4, 1, file);
+fwrite("\xFF\xFF\xFF\xFF", 4, 1, file);
+fwrite("WAVE", 4, 1, file);
+fwrite("fmt ", 4, 1, file);
+fwrite("\x10\x00\00\00", 4, 1, file);
+fwrite("\x03\x00", 2, 1, file);
+fwrite("\x02\x00", 2, 1, file);
+fwrite(&sample_rate, 4, 1, file);
+fwrite(&bytespersec, 4, 1, file);
+fwrite(&blkalign, 2, 1, file);
+fwrite(&bps, 2, 1, file);
+fwrite("data", 4, 1, file);
+fwrite(&size, 4, 1, file);
+
+for (j = 0; j < hrtf->N; j++) {
+float l, r;
+
+l = hrtf->DataIR.values[offset + j];
+r = hrtf->DataIR.values[offset + j + hrtf->N];
+fwrite(&l, 4, 1, file);
+fwrite(&r, 4, 1, file);
+}
+fclose(file);
+}
+
+fail:
+mysofa_free(hrtf);
+
+return 0;
+}
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avfilter: add native headphone spatialization filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 42 +++
libavfilter/Makefile | 1 +
libavfilter/af_headphone.c | 811 +
libavfilter/allfilters.c | 1 +
4 files changed, 855 insertions(+)
create mode 100644 libavfilter/af_headphone.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 9cc356b..603ff8a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2789,6 +2789,48 @@ Samples where the target gain does not match between
channels
@end table
@end table
+@section headphone
+
+Apply head-related transfer functions (HRTFs) to create virtual
+loudspeakers around the user for binaural listening via headphones.
+The HRTFs are provided via additional streams.
+
+The filter accepts the following options:
+
+@table @option
+@item map
+Set mapping of input streams for convolution.
+The argument is a '|'-separated list of channel names in order as they
+are given as additional stream inputs for filter.
+This also specify number of input streams. Number of input streams
+must be not less than number of channels in first stream.
+
+@item gain
+Set gain applied to audio. Value is in dB. Default is 0.
+
+@item type
+Set processing type. Can be @var{time} or @var{freq}. @var{time} is
+processing audio in time domain which is slow.
+@var{freq} is processing audio in frequency domain which is fast.
+Default is @var{freq}.
+
+@item lfe
+Set custom gain for LFE channels. Value is in dB. Default is 0.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Full example using wav files as coefficients with amovie filters for 7.1
downmix,
+each amovie filter use stereo file with IR coefficients as input.
+The files give coefficients for each position of virtual loudspeaker:
+@example
+ffmpeg -i input.wav -lavfi-complex
"amovie=azi_270_ele_0_DFC.wav[sr],amovie=azi_90_ele_0_DFC.wav[sl],amovie=azi_225_ele_0_DFC.wav[br],amovie=azi_135_ele_0_DFC.wav[bl],amovie=azi_0_ele_0_DFC.wav,asplit[fc][lfe],amovie=azi_35_ele_0_DFC.wav[fl],amovie=azi_325_ele_0_DFC.wav[fr],[a:0][fl][fr][fc][lfe][bl][br][sl][sr]headphone=FL|FR|FC|LFE|BL|BR|SL|SR"
+output.wav
+@end example
+@end itemize
+
@section highpass
Apply a high-pass filter with 3dB point frequency.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c88dfb3..04ec9b8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -92,6 +92,7 @@ OBJS-$(CONFIG_EXTRASTEREO_FILTER)+=
af_extrastereo.o
OBJS-$(CONFIG_FIREQUALIZER_FILTER) += af_firequalizer.o
OBJS-$(CONFIG_FLANGER_FILTER)+= af_flanger.o
generate_wave_table.o
OBJS-$(CONFIG_HDCD_FILTER) += af_hdcd.o
+OBJS-$(CONFIG_HEADPHONE_FILTER) += af_headphone.o
OBJS-$(CONFIG_HIGHPASS_FILTER) += af_biquads.o
OBJS-$(CONFIG_JOIN_FILTER) += af_join.o
OBJS-$(CONFIG_LADSPA_FILTER) += af_ladspa.o
diff --git a/libavfilter/af_headphone.c b/libavfilter/af_headphone.c
new file mode 100644
index 000..84b6ce5
--- /dev/null
+++ b/libavfilter/af_headphone.c
@@ -0,0 +1,811 @@
+/*
+ * Copyright (C) 2017 Paul B Mahol
+ * Copyright (C) 2013-2015 Andreas Fuchs, Wolfgang Hrauda
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/audio_fifo.h"
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/float_dsp.h"
+#include "libavutil/intmath.h"
+#include "libavutil/opt.h"
+#include "libavcodec/avfft.h"
+
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+#define TIME_DOMAIN 0
+#define FREQUENCY_DOMAIN 1
+
+typedef struct HeadphoneContext {
+const AVClass *class;
+
+char *map;
+int type;
+
+int lfe_channel;
+
+int have_coeffs;
+int eof_coeffs;
+int64_t pts;
+
+int ir_len;
+
+int mapping[64];
+
+int nb_inputs;
+
+int nb_irs;
+
+float gain;
+float lfe_gain, gain_lfe;
+
+float *ringbuffer[2];
+int write[2];
+
+int buffer_length;
+int n_fft;
+int size;
+
+int *delay[2];
+float *data_ir[2];
+float *temp_src[2];
+FFTComplex *temp_fft[2];
+
+FFTContext *fft[2], *ifft[2];
+FFTComplex *data_hrtf[2];
+
+AVFloatDSPContext *fdsp;
+struct headphone_i
Re: [FFmpeg-devel] [PATCH 3/5] x86inc: Prefer r14/r15 over r12/r13 on x86-64
Hi, On Thu, Jun 8, 2017 at 7:05 PM, James Darnley wrote: > From: Henrik Gramner > > Due to a peculiarity in the ModR/M addressing encoding, the r12 and r13 > registers sometimes requires an additional byte when used as a base > register. > > r14 and r15 doesn't have that issue, so prefer using them. > --- > libavutil/x86/x86inc.asm | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) LGTM. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: Add a pixdesc API alias name for bt2020nc color space
Hi,
On Thu, Jun 8, 2017 at 8:01 PM, Vittorio Giovara wrote:
> ---
> libavfilter/vf_colorspace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index d1e9a1c609..71ea08a20f 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -1090,6 +1090,7 @@ static const AVOption colorspace_options[] = {
> ENUM("smpte240m", AVCOL_SPC_SMPTE240M, "csp"),
> ENUM("ycgco", AVCOL_SPC_YCGCO, "csp"),
> ENUM("gbr", AVCOL_SPC_RGB, "csp"),
> +ENUM("bt2020nc",AVCOL_SPC_BT2020_NCL, "csp"),
> ENUM("bt2020ncl", AVCOL_SPC_BT2020_NCL, "csp"),
>
> { "range", "Output color range",
> --
> 2.12.0
OK, I guess.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] x86inc: Remove argument from WIN64_RESTORE_XMM
Hi, On Thu, Jun 8, 2017 at 7:05 PM, James Darnley wrote: > From: Anton Mitrofanov > > The use of rsp was pretty much hardcoded there and probably didn't work > otherwise with stack_size > 0. > --- > libavutil/x86/x86inc.asm | 19 ++- > 1 file changed, 10 insertions(+), 9 deletions(-) LGTM. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation
>I know unaligned loads are not as slow as they used to be, >but could m1 be produced by m2 and palignr? I am not sure, can you clarify your question? >From the comment I assume you don't use the extra two bytes >that you get from the load, as you mark them as "*" >generic undefined values No, those two extra bytes are actually used, that's the above/left corner pixel. If you look in the vp9dsp_template.c file, there is a macro defined diag_downright_ that's top[-1] in the body. Sorry for this ambiguous marking, but it's used in other ipred_dr functions so I decided to follow it. >"cnt" doesn't seem to be used. Yes indeed, I mislooked that, thanks. On Fri, Jun 9, 2017 at 6:03 PM, Ivan Kalvachev wrote: > On 6/8/17, Ilia Valiakhmetov wrote: > > vp9_diag_downright_16x16_12bpp_c: 149.0 > > vp9_diag_downright_16x16_12bpp_sse2: 67.8 > > vp9_diag_downright_16x16_12bpp_ssse3: 45.6 > > vp9_diag_downright_16x16_12bpp_avx: 36.6 > > vp9_diag_downright_16x16_12bpp_avx2: 25.5 > > > > ~30% faster than avx > > > > Signed-off-by: Ilia Valiakhmetov > > --- > > libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ > > libavcodec/x86/vp9intrapred_16bpp.asm | 56 > > +++ > > 2 files changed, 58 insertions(+) > > > > diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c > > b/libavcodec/x86/vp9dsp_init_16bpp.c > > index d1b8fcd..8d1aa13 100644 > > --- a/libavcodec/x86/vp9dsp_init_16bpp.c > > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c > > @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); > > decl_ipred_fns(dc_top, 16, mmxext, sse2); > > decl_ipred_fns(dc_left, 16, mmxext, sse2); > > decl_ipred_fn(dl, 16, 16, avx2); > > +decl_ipred_fn(dr, 16, 16, avx2); > > decl_ipred_fn(dl, 32, 16, avx2); > > > > #define decl_ipred_dir_funcs(type) \ > > @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext > > *dsp) > > init_fpel_func(1, 1, 64, avg, _16, avx2); > > init_fpel_func(0, 1, 128, avg, _16, avx2); > > init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); > > +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2); > > init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); > > } > > > > diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm > > b/libavcodec/x86/vp9intrapred_16bpp.asm > > index 92333bc..67b98b1 100644 > > --- a/libavcodec/x86/vp9intrapred_16bpp.asm > > +++ b/libavcodec/x86/vp9intrapred_16bpp.asm > > @@ -1170,6 +1170,62 @@ DR_FUNCS 2 > > INIT_XMM avx > > DR_FUNCS 2 > > > > +%if HAVE_AVX2_EXTERNAL > > +INIT_YMM avx2 > > +cglobal vp9_ipred_dr_16x16_16, 4, 6, 7, dst, stride, l, a > > +movam0, [lq] ; > klmnopqrstuvwxyz > > +movum1, [aq-2] ; > *abcdefghijklmno > > +movam2, [aq] ; > abcdefghijklmnop > > From the comment I assume you don't use the extra two bytes > that you get from the load, as you mark them as "*" > generic undefined values > > > +vperm2i128 m4, m2, m2, q2001 ; > ijklmnop > > +vpalignrm5, m4, m2, 2 ; > bcdefghijklmnop. > > +vperm2i128 m3, m0, m1, q0201 ; > stuvwxyz*abcdefg > > +LOWPASS 1, 2, 5 ; > ABCDEFGHIJKLMNO. > > +vpalignrm4, m3, m0, 2 ; > lmnopqrstuvwxyz* > > +vpalignrm5, m3, m0, 4 ; > mnopqrstuvwxyz*a > > +LOWPASS 0, 4, 5 ; > LMNOPQRSTUVWXYZ# > > +vperm2i128 m5, m0, m1, q0201 ; > TUVWXYZ#ABCDEFGH > > +DEFINE_ARGS dst, stride, stride3, stride5, dst3, cnt > > "cnt" doesn't seem to be used. > ___ > 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] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm
On 6/9/17, Ivan Kalvachev wrote: > On 6/9/17, Michael Niedermayer wrote: >> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote: >>> opus_pvq.c |9 >>> opus_pvq.h |5 >>> x86/Makefile|1 >>> x86/opus_dsp_init.c | 47 +++ >>> x86/opus_pvq_search.asm | 597 >>> >>> 5 files changed, 657 insertions(+), 2 deletions(-) >>> 3b9648bea3f01dad2cf159382f0ffc2d992c84b2 >>> 0001-SIMD-opus-pvq_search-implementation.patch >>> From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001 >>> From: Ivan Kalvachev >>> Date: Thu, 8 Jun 2017 22:24:33 +0300 >>> Subject: [PATCH 1/3] SIMD opus pvq_search implementation. >> >> seems this breaks build with mingw64, didnt investigate but it >> fails with these errors: >> >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' >> collect2: error: ld returned 1 exit status >> collect2: error: ld returned 1 exit status >> make: *** [ffmpeg_g.exe] Error 1 >> make: *** Waiting for unfinished jobs >> make: *** [ffprobe_g.exe] Error 1 > > > const_*_edge is used on only one place is the code. > Would you check if this patch fixes the issue. > Sorry, the patch was not tested and the variable name was not correct. This one should be fine... I hope --- a/libavcodec/x86/opus_pvq_search.asm +++ b/libavcodec/x86/opus_pvq_search.asm @@ -419,7 +419,7 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N add Nq, r4q ; Nq = align(Nq, mmsize) sub rsp, Nq; allocate tmpX[Nq] -movups m3, [const_align_abs_edge-mmsize+r4q] ; this is the bit mask for the padded read at the end of the input +movups m3, [const_float_abs_mask+32-mmsize+r4q] ; this is the bit mask for the padded read at the end of the input lea r4q, [Nq-mmsize] ; Nq is rounded up (aligned up) to mmsize, so r4q can't become negative here, unless N=0. movups m2, [inXq + r4q] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] configure: require NASM version 2.11 or newer for external x86 assembly
---
configure | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/configure b/configure
index e3941f9dfd..69bbf25bf5 100755
--- a/configure
+++ b/configure
@@ -3258,7 +3258,7 @@ pkg_config_default=pkg-config
ranlib_default="ranlib"
strip_default="strip"
version_script='--version-script'
-yasmexe_default="yasm"
+yasmexe_default="nasm"
windres_default="windres"
nvcc_default="nvcc"
nvccflags_default="-gencode arch=compute_30,code=sm_30 -O2"
@@ -5476,11 +5476,9 @@ EOF
enabled mmxext && check_inline_asm mmxext_inline '"pmaxub %mm0, %mm1"'
if ! disabled_any asm mmx yasm; then
-if check_cmd $yasmexe --version; then
-enabled x86_64 && yasm_extra="-m amd64"
-yasm_debug="-g dwarf2"
-elif check_cmd nasm -v; then
-yasmexe=nasm
+check_yasm "vdivpd zmm0{k1}{z}, zmm1, zmm3" ||
+die "nasm not found or too old, version 2.11 is now required. Use
--disable-yasm for a crippled build."
+
yasm_debug="-g -F dwarf"
if enabled x86_64; then
case "$objformat" in
@@ -5488,7 +5486,6 @@ EOF
win32) objformat=win64 ;;
esac
fi
-fi
YASMFLAGS="-f $objformat $yasm_extra"
enabled pic && append YASMFLAGS "-DPIC"
@@ -5497,12 +5494,6 @@ EOF
elf*) enabled debug && append YASMFLAGS $yasm_debug ;;
esac
-check_yasm "movbe ecx, [5]" && enable yasm ||
-die "yasm/nasm not found or too old. Use --disable-yasm for a
crippled build."
-check_yasm "vextracti128 xmm0, ymm0, 0" || disable avx2_external
-check_yasm "vpmacsdd xmm0, xmm1, xmm2, xmm3" || disable xop_external
-check_yasm "vfmaddps ymm0, ymm1, ymm2, ymm3" || disable fma4_external
-check_yasm "CPU amdnop" || disable cpunop
fi
case "$cpu" in
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] x86 external assembler requirements
I propose that we drop support for all assemblers older than NASM version 2.11. That was released on 2013-12-31 with several point releases over the following year with 2.11.08 being released on 2015-02-21. The following patch does just that. Please do not be concerned about the ZMM register use. This patch does not address the use of AVX-512 instructions. In a future patch I will add a different check for enabling/disabling AVX-512. The NASM changelog can be found here: http://www.nasm.us/doc/nasmdocc.html Releases and their dates can be seen here: http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D Other than the discussion about the oldest version to support we should discuss the command line options for configure and the internal variable names. At present they all use "yasm" somewhere. If we are to drop support for that then we should change the option names to prevent confusion. We could just change them to "nasm" and be done. We could provide compatability options. We could adopt Libav's generic "x86asm". James Darnley (1): configure: require NASM version 2.11 or newer for external x86 assembly configure | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) Brought to you by my inability to configure FFmpeg with NASM 2.13. -- 2.13.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] x86 external assembler requirements
On Fri, Jun 9, 2017 at 2:51 PM, James Darnley wrote: > I propose that we drop support for all assemblers older than NASM version > 2.11. > That was released on 2013-12-31 with several point releases over the following > year with 2.11.08 being released on 2015-02-21. > > The following patch does just that. Please do not be concerned about the ZMM > register use. This patch does not address the use of AVX-512 instructions. > In > a future patch I will add a different check for enabling/disabling AVX-512. > > The NASM changelog can be found here: > http://www.nasm.us/doc/nasmdocc.html > > Releases and their dates can be seen here: > http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D > > Other than the discussion about the oldest version to support we should > discuss > the command line options for configure and the internal variable names. At > present they all use "yasm" somewhere. If we are to drop support for that > then > we should change the option names to prevent confusion. > > We could just change them to "nasm" and be done. We could provide > compatability > options. We could adopt Libav's generic "x86asm". > > James Darnley (1): > configure: require NASM version 2.11 or newer for external x86 > assembly > > configure | 17 - > 1 file changed, 4 insertions(+), 13 deletions(-) > > Brought to you by my inability to configure FFmpeg with NASM 2.13. > Maybe you should just pick the patches from Libav, that still implement an automatic fallback to YASM if NASM is not found or too old? We would eventually get to them in the merges anyway. Many people building FFmpeg for years with YASM may not have an appropriate NASM installed, and forcing a switch here may not be ideal. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF
2017-06-05 21:18 GMT+02:00 Daniel Kucera :
> Signed-off-by: Daniel Kucera
> ---
> libavformat/cache.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/cache.c b/libavformat/cache.c
> index 6aabca2e78..66bbbf54c9 100644
> --- a/libavformat/cache.c
> +++ b/libavformat/cache.c
> @@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
> int size)
> }
>
> r = ffurl_read(c->inner, buf, size);
> -if (r == 0 && size>0) {
> +if (r == AVERROR_EOF && size>0) {
> c->is_true_eof = 1;
> av_assert0(c->end >= c->logical_pos);
> }
> @@ -263,7 +263,7 @@ resolve_eof:
> if (whence == SEEK_SET)
> size = FFMIN(sizeof(tmp), pos - c->logical_pos);
> ret = cache_read(h, tmp, size);
> -if (ret == 0 && whence == SEEK_END) {
> +if (ret == AVERROR_EOF && whence == SEEK_END) {
> av_assert0(c->is_true_eof);
> goto resolve_eof;
> }
> --
> 2.11.0
>
Reminding for review.
--
S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] libavformat/aviobuf: don't treat 0 as EOF
Signed-off-by: Daniel Kucera
---
libavformat/aviobuf.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 1667e9f08b..3705e406d9 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -556,13 +556,14 @@ static void fill_buffer(AVIOContext *s)
if (s->read_packet)
len = s->read_packet(s->opaque, dst, len);
else
-len = 0;
-if (len <= 0) {
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back can
be done without rereading data */
s->eof_reached = 1;
-if (len < 0)
-s->error = len;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
} else {
s->pos += len;
s->buf_ptr = dst;
@@ -630,13 +631,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
size)
// bypass the buffer and read data directly into buf
if(s->read_packet)
len = s->read_packet(s->opaque, buf, size);
-
-if (len <= 0) {
+ else
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back
can
be done without rereading data */
s->eof_reached = 1;
-if(len<0)
-s->error= len;
+break;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
break;
} else {
s->pos += len;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/avio: fix retry_transfer_wrapper return value on error
Signed-off-by: Daniel Kucera
---
libavformat/avio.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 1e79c9dd5c..d0cee42c39 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -393,8 +393,10 @@ static inline int retry_transfer_wrapper(URLContext *h,
uint8_t *buf,
}
av_usleep(1000);
}
-} else if (ret < 1)
-return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
+} else if (ret == AVERROR_EOF)
+return len;
+else if (ret < 0)
+return ret;
if (ret) {
fast_retries = FFMAX(fast_retries, 2);
wait_since = 0;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] x86 external assembler requirements
On 6/9/17, Hendrik Leppkes wrote: > On Fri, Jun 9, 2017 at 2:51 PM, James Darnley wrote: >> I propose that we drop support for all assemblers older than NASM version >> 2.11. >> That was released on 2013-12-31 with several point releases over the >> following >> year with 2.11.08 being released on 2015-02-21. >> >> The following patch does just that. Please do not be concerned about the >> ZMM >> register use. This patch does not address the use of AVX-512 >> instructions. In >> a future patch I will add a different check for enabling/disabling >> AVX-512. >> >> The NASM changelog can be found here: >> http://www.nasm.us/doc/nasmdocc.html >> >> Releases and their dates can be seen here: >> http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D >> >> Other than the discussion about the oldest version to support we should >> discuss >> the command line options for configure and the internal variable names. >> At >> present they all use "yasm" somewhere. If we are to drop support for that >> then >> we should change the option names to prevent confusion. >> >> We could just change them to "nasm" and be done. We could provide >> compatability >> options. We could adopt Libav's generic "x86asm". It's better to use generic name. I do not like "x86asm", as 'gnu as' also fits that description, but it is better than changing the name every time some compiler takes the lead. E.g. zasm might be the next champion of AVX512 assembly. ;) >> James Darnley (1): >> configure: require NASM version 2.11 or newer for external x86 >> assembly >> >> configure | 17 - >> 1 file changed, 4 insertions(+), 13 deletions(-) >> >> Brought to you by my inability to configure FFmpeg with NASM 2.13. >> > > Maybe you should just pick the patches from Libav, that still > implement an automatic fallback to YASM if NASM is not found or too > old? We would eventually get to them in the merges anyway. > Many people building FFmpeg for years with YASM may not have an > appropriate NASM installed, and forcing a switch here may not be > ideal. +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/htmlsubtitles: Protect very slow redundant sscanf() calls by optimized use of strchr()
On Thu, 8 Jun 2017 23:53:55 +0200
Michael Niedermayer wrote:
> Fixes Timeout
> Fixes: 2127/clusterfuzz-testcase-minimized-6595787859427328
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/htmlsubtitles.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> index 16295daa0c..ba4f269b3f 100644
> --- a/libavcodec/htmlsubtitles.c
> +++ b/libavcodec/htmlsubtitles.c
> @@ -56,6 +56,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
> const char *in)
> char *param, buffer[128], tmp[128];
> int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0;
> SrtStack stack[16];
> +const char *next_closep = NULL;
>
> stack[0].tag[0] = 0;
> strcpy(stack[0].param[PARAM_SIZE], "{\\fs}");
> @@ -83,8 +84,15 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
> const char *in)
> and all microdvd like styles such as {Y:xxx} */
> len = 0;
> an += sscanf(in, "{\\an%*1u}%n", &len) >= 0 && len > 0;
> -if ((an != 1 && (len = 0, sscanf(in, "{\\%*[^}]}%n", &len) >= 0
> && len > 0)) ||
> -(len = 0, sscanf(in, "{%*1[CcFfoPSsYy]:%*[^}]}%n", &len) >=
> 0 && len > 0)) {
> +
> +if(!next_closep || next_closep <= in) {
> +next_closep = strchr(in+1, '}');
> +if (!next_closep)
> +next_closep = in + strlen(in);
> +}
> +
> +if (*next_closep == '}' && (an != 1 && (len = 0, sscanf(in,
> "{\\%*[^}]}%n", &len) >= 0 && len > 0)) ||
> +*next_closep == '}' && (len = 0, sscanf(in,
> "{%*1[CcFfoPSsYy]:%*[^}]}%n", &len) >= 0 && len > 0)) {
> in += len - 1;
> } else
> av_bprint_chars(dst, *in, 1);
I'm not convinced that bad performance with an obscure fuzzed sample is
worth the complexity increase here.
I'd rather ask, why the heck is it using sscanf in the first place?
The existing code is certainly unreadable already. (Could you tell what
it does without staring at the scanf manpage for a while? And then
guarantee correctness/performance/security?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] tools: add sofa2wavs
On Fri, 9 Jun 2017 13:44:01 +0200 Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > Makefile | 1 + > tools/Makefile| 1 + > tools/sofa2wavs.c | 79 > +++ > 3 files changed, 81 insertions(+) > create mode 100644 tools/sofa2wavs.c > > diff --git a/Makefile b/Makefile > index 685b613..a2df8b9 100644 > --- a/Makefile > +++ b/Makefile > @@ -82,6 +82,7 @@ target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o > $(FF_DEP_LIBS) > $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) > $(LIBFUZZER_PATH) Again: if this tool is needed anyway, why not make a minimal custom file format that will make the filter nicer to use? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] vf_colorspace: Add a pixdesc API alias name for bt2020nc color space
Le primidi 21 prairial, an CCXXV, Vittorio Giovara a écrit : > ffmpeg | branch: master | Vittorio Giovara | Thu > Jun 8 20:00:19 2017 -0400| [c12e8f5f0b412fde9b0c3cf4ca7039ee82461139] | > committer: Vittorio Giovara > > vf_colorspace: Add a pixdesc API alias name for bt2020nc color space Maybe it is time to consider introducing AV_OPT_TYPE_COLORSPACE. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] tools: add sofa2wavs
On 6/9/17, wm4 wrote: > On Fri, 9 Jun 2017 13:44:01 +0200 > Paul B Mahol wrote: > >> Signed-off-by: Paul B Mahol >> --- >> Makefile | 1 + >> tools/Makefile| 1 + >> tools/sofa2wavs.c | 79 >> +++ >> 3 files changed, 81 insertions(+) >> create mode 100644 tools/sofa2wavs.c >> >> diff --git a/Makefile b/Makefile >> index 685b613..a2df8b9 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -82,6 +82,7 @@ target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o >> $(FF_DEP_LIBS) >> $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) >> $(LIBFUZZER_PATH) > > Again: if this tool is needed anyway, why not make a minimal custom > file format that will make the filter nicer to use? wav is minimal custom format, I already said that I do not want to invent new minimal format for storing HRIRs. But I will not block the patch that will do that, so feel free to post patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] tools: add sofa2wavs
On Fri, 9 Jun 2017 17:02:37 +0200 Paul B Mahol wrote: > On 6/9/17, wm4 wrote: > > On Fri, 9 Jun 2017 13:44:01 +0200 > > Paul B Mahol wrote: > > > >> Signed-off-by: Paul B Mahol > >> --- > >> Makefile | 1 + > >> tools/Makefile| 1 + > >> tools/sofa2wavs.c | 79 > >> +++ > >> 3 files changed, 81 insertions(+) > >> create mode 100644 tools/sofa2wavs.c > >> > >> diff --git a/Makefile b/Makefile > >> index 685b613..a2df8b9 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -82,6 +82,7 @@ target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o > >> $(FF_DEP_LIBS) > >>$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) > >> $(LIBFUZZER_PATH) > > > > Again: if this tool is needed anyway, why not make a minimal custom > > file format that will make the filter nicer to use? > > wav is minimal custom format, I already said that I do not want to invent new > minimal format for storing HRIRs. Even then the user has to build a quite complicated graph to feed the various wav files to the filter. For what reason? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
On Fri, 9 Jun 2017 11:34:26 +0300 Ivan Kalvachev wrote: > > If I understand correctly, the root of the problem is the undefined behavior > of the compiler and the C standard. > Is there any chance that FFmpeg project could initiate a change in the > next C standard, so this thing would be defined? > (and I guess, also define a few other similar things, like signed > right shift, etc...) > > It is a matter of fact, that a lot of compiler-defined-things have > been implemented in > certain ways on most compilers and that there are plenty of programs > depend on these > specific implementations and break when a new compiler does things differently > (clang had nice article about it). > > > About the typedef, is SUINT a standard defined type for workarounding > this specific problem? > I do suspect that some of our fellow developers simply find its name ugly. > > Maybe they would be more welcoming if > "suint32_t" like typedef is used? This thing is brain dead - not even the post year 2000 C committee would accept it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
On Fri, 9 Jun 2017 00:10:49 +0200
Michael Niedermayer wrote:
> On Sat, May 27, 2017 at 12:24:16PM +0200, wm4 wrote:
> > On Sat, 27 May 2017 03:56:42 +0200
> > Michael Niedermayer wrote:
> >
> > > On Fri, May 26, 2017 at 07:06:44PM -0400, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Fri, May 26, 2017 at 6:34 PM, Michael Niedermayer
> > > > > > > > wrote:
> > > >
> > > > > On Fri, May 26, 2017 at 06:07:35PM -0400, Ronald S. Bultje wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, May 26, 2017 at 5:50 PM, Michael Niedermayer
> > > > > > > > > > > wrote:
> > > > > >
> > > > > > > On Fri, May 26, 2017 at 11:18:12PM +0200, Hendrik Leppkes wrote:
> > > > > > >
> > > > > > > > On Fri, May 26, 2017 at 11:11 PM, Michael Niedermayer
> > > > > > > > wrote:
> > > > > > > > > On Fri, May 26, 2017 at 03:20:14PM +0100, Rostislav
> > > > > > > > > Pehlivanov
> > > > > wrote:
> > > > > > > > >> On 26 May 2017 at 12:21, wm4 wrote:
> > > > > > > > >>
> > > > > > > > >> > On Thu, 25 May 2017 16:10:49 +0200
> > > > > > > > >> > Michael Niedermayer wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Fixes:
> > > > > > > > >> > > 1735/clusterfuzz-testcase-minimized-5350472347025408
> > > > > > > > >> > >
> > > > > > > > >> > > Found-by: continuous fuzzing process
> > > > > > > https://github.com/google/oss-
> > > > > > > > >> > fuzz/tree/master/projects/ffmpeg
> > > > > > > > >> > > Signed-off-by: Michael Niedermayer
> > > > > > > > >> > >
> > > > > > > > >> > > ---
> > > > > > > > >> > > libavcodec/fft_template.c | 50
> > > > > > > > >> > > +++---
> > > > > > > > >> > -
> > > > > > > > >> > > 1 file changed, 25 insertions(+), 25 deletions(-)
> > > > > > > > >> > >
> > > > > > > > >> > > diff --git a/libavcodec/fft_template.c
> > > > > b/libavcodec/fft_template.c
> > > > > > > > >> > > index 480557f49f..e3a37e5d69 100644
> > > > > > > > >> > > --- a/libavcodec/fft_template.c
> > > > > > > > >> > > +++ b/libavcodec/fft_template.c
> > > > > > > > >> > > @@ -249,7 +249,7 @@ static void fft_calc_c(FFTContext
> > > > > > > > >> > > *s,
> > > > > > > FFTComplex *z)
> > > > > > > > >> > {
> > > > > > > > >> > >
> > > > > > > > >> > > int nbits, i, n, num_transforms, offset, step;
> > > > > > > > >> > > int n4, n2, n34;
> > > > > > > > >> > > -FFTSample tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7,
> > > > > > > > >> > > tmp8;
> > > > > > > > >> > > +SUINT tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7,
> > > > > > > > >> > > tmp8;
> > > > > > > > >> >
> > > > > > > > >> > I want this SUINT thing gone, not have more of it.
> > > > > > > > >> > ___
> > > > > > > > >> > ffmpeg-devel mailing list
> > > > > > > > >> > ffmpeg-devel@ffmpeg.org
> > > > > > > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> I agree, especially here.
> > > > > > > > >
> > > > > > > > >> Overflows should be left to happen in transforms if the
> > > > > > > > >> input is
> > > > > > > corrupt.
> > > > > > > > >
> > > > > > > > > signed int overflow is not allowed in C, if that is what you
> > > > > > > > > meant.
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Its "undefined", which means what the result will be is not
> > > > > > > > defined -
> > > > > > > > which in such a DSP function is irrelevant, if all it causes is
> > > > > > > > corrupt output ... from corrupt input.
> > > > > > >
> > > > > > > no, this is not correct.
> > > > > > > undefined behavior does not mean the effect will be limited to
> > > > > > > the output.
> > > > > > > It could cause the process to hard lockup, trigger an exception or
> > > > > > > set a flag causing errors in later unrelated code.
> > > > > >
> > > > > >
> > > > >
> > > > > > We've discussed this before, if you believe this to be exploitable,
> > > > > > why
> > > > > > allow it in our repository at all? I know of no other project that
> > > > > > even
> > > > > > remotely allows such ridiculous things. Please limit exploitable
> > > > > > code to
> > > > > > your personal tree, ffmpeg is not a rootkit.
> > > > >
> > > > > please calm down, you make all kinds of statments and implications in
> > > > > the text above which are not true.
> > > > >
> > > > > This specific code in git triggers undefined behavior, the patch fixes
> > > > > this undefined behavior.
> > > > > If that is exploitable (which i neither claim it is nor that it isnt)
> > > > > its a issue that exists before the patch but not afterwards.
> > > >
> > > >
> > >
> > > > *unsigned* removes the exploit. SUINT keeps it, and is therefore part
> > > > of a
> > > > rootkit.
> > >
> > > SUINT is defined to unsigned, if unsigned removes the issue
> > > so does SUINT.
> >
> > Then why is it
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
On 6/9/17, wm4 wrote: > On Fri, 9 Jun 2017 11:34:26 +0300 > Ivan Kalvachev wrote: > >> >> If I understand correctly, the root of the problem is the undefined >> behavior >> of the compiler and the C standard. >> Is there any chance that FFmpeg project could initiate a change in the >> next C standard, so this thing would be defined? >> (and I guess, also define a few other similar things, like signed >> right shift, etc...) >> >> It is a matter of fact, that a lot of compiler-defined-things have >> been implemented in >> certain ways on most compilers and that there are plenty of programs >> depend on these >> specific implementations and break when a new compiler does things >> differently >> (clang had nice article about it). >> >> >> About the typedef, is SUINT a standard defined type for workarounding >> this specific problem? >> I do suspect that some of our fellow developers simply find its name ugly. >> >> Maybe they would be more welcoming if >> "suint32_t" like typedef is used? > > This thing is brain dead - not even the post year 2000 C committee > would accept it. Also please stop spreading hacks to overcome various "timeouts" from those fuzzers. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] tools: add sofa2wavs
On 6/9/17, wm4 wrote: > On Fri, 9 Jun 2017 17:02:37 +0200 > Paul B Mahol wrote: > >> On 6/9/17, wm4 wrote: >> > On Fri, 9 Jun 2017 13:44:01 +0200 >> > Paul B Mahol wrote: >> > >> >> Signed-off-by: Paul B Mahol >> >> --- >> >> Makefile | 1 + >> >> tools/Makefile| 1 + >> >> tools/sofa2wavs.c | 79 >> >> +++ >> >> 3 files changed, 81 insertions(+) >> >> create mode 100644 tools/sofa2wavs.c >> >> >> >> diff --git a/Makefile b/Makefile >> >> index 685b613..a2df8b9 100644 >> >> --- a/Makefile >> >> +++ b/Makefile >> >> @@ -82,6 +82,7 @@ target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o >> >> $(FF_DEP_LIBS) >> >> $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) >> >> $(LIBFUZZER_PATH) >> > >> > Again: if this tool is needed anyway, why not make a minimal custom >> > file format that will make the filter nicer to use? >> >> wav is minimal custom format, I already said that I do not want to invent >> new >> minimal format for storing HRIRs. > > Even then the user has to build a quite complicated graph to feed the > various wav files to the filter. For what reason? To load/read/use only what is needed. And it does not need to be wavs it can be any format FFmpeg supports. Note that minimal format is possible, it would just be dump of libmysofa struct as it is stored in memory. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.
On Tue, 6 Jun 2017 11:16:01 -0700 Sasi Inguva wrote: > Fixes t/6421. If the videos starts with B frame, then the minimum composition > time as computed by stts + ctts will be non-zero. Hence we need to shift the > DTS, so that the first pts is zero. This was the intention of that > code-block. However it was subtracting by the wrong amount. > For example, for one of the videos in the bug nonFormatted.mp4 we have > stts: > sample_count duration > 960 1001 > ctts: > sample_count duration > 1 3003 > 2 0 > 1 3003 > > > The resulting composition times are : 3003, 1001, 2002, 6006, ... > The minimum composition time or PTS is 1001, which should be used to offset > DTS. However the code block was wrongly using ctts[0] which is 3003. Hence > the PTS was negative. This change computes the minimum pts encountered while > fixing the index, and then subtracts it from all the timestamps after the > edit list fixes are applied. > > fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2 > Bframes. Before this change the PTS of first two B-frames was -6006 and > -3003, and I am guessing one of them got dropped when being decoded and > remuxed to the framecrc before, and now it is not being dropped. > > Signed-off-by: Sasi Inguva > --- Applied. I added line breaks and white space to the commit message, and added links to those chromium issues. I hope that's ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/wavpack: Change wp_log2() to unsigned
Fixes: runtime error: signed integer overflow: 2143315325 + 4186162 cannot be
represented in type 'int'
Fixes: 2134/clusterfuzz-testcase-minimized-4619258405322752
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wavpack.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wavpack.h b/libavcodec/wavpack.h
index c949390f51..c670b1c1d9 100644
--- a/libavcodec/wavpack.h
+++ b/libavcodec/wavpack.h
@@ -177,7 +177,7 @@ static av_always_inline int wp_exp2(int16_t val)
return neg ? -res : res;
}
-static av_always_inline int wp_log2(int32_t val)
+static av_always_inline int wp_log2(uint32_t val)
{
int bits;
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] x86 external assembler requirements
On Fri, Jun 09, 2017 at 03:13:23PM +0200, Hendrik Leppkes wrote: > On Fri, Jun 9, 2017 at 2:51 PM, James Darnley wrote: > > I propose that we drop support for all assemblers older than NASM version > > 2.11. ubuntu 14.04 LTS has only nasm 2.10.09-1amd64 General-purpose x86 assembler https://packages.ubuntu.com/trusty/nasm [...] > Many people building FFmpeg for years with YASM may not have an > appropriate NASM installed, and forcing a switch here may not be > ideal. +1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add FITS Decoder
On Fri, Jun 9, 2017 at 3:08 AM, Martin Vignali
wrote:
> Hello,
>
> You can create a FipsContext struct to store decoding data
> instead of using Fips Header struct
> (you can take a look to other image decoder)
>
> Also you should need to split the patch for libavcodec part and libavformat
> part
>
> Nit : The coding style for if/else is
>
> if {
>
> } else {
>
> }
>
>
> Not
> if {
> }
> else {
> }
>
>
Done. Any other changes ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add FITS Decoder
All the changes mentioned above have been done.
Signed-off-by: Paras Chadha
---
Changelog | 1 +
doc/general.texi| 2 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 8 +
libavcodec/fitsdec.c| 515
libavcodec/version.h| 4 +-
libavformat/img2.c | 1 +
9 files changed, 532 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/fitsdec.c
diff --git a/Changelog b/Changelog
index ffb8b82..f04957c 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
- remove the libschroedinger encoder/decoder wrappers
- surround audio filter
- sofalizer filter switched to libmysofa
+- FITS decoder
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/doc/general.texi b/doc/general.texi
index 8f582d5..213e50e 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -591,6 +591,8 @@ following image formats are supported:
@tab Digital Picture Exchange
@item EXR @tab @tab X
@tab OpenEXR
+@item FITS @tab @tab X
+@tab FITS image format
@item JPEG @tab X @tab X
@tab Progressive JPEG is not supported.
@item JPEG 2000@tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a752f87..2451ae3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -291,6 +291,7 @@ OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
OBJS-$(CONFIG_FIC_DECODER) += fic.o
+OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o
OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flac.o
OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o flac.o
vorbis_data.o
OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4373ebd..cddffad 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -186,6 +186,7 @@ static void register_all(void)
REGISTER_ENCDEC (FFV1, ffv1);
REGISTER_ENCDEC (FFVHUFF, ffvhuff);
REGISTER_DECODER(FIC, fic);
+REGISTER_DECODER(FITS, fits);
REGISTER_ENCDEC (FLASHSV, flashsv);
REGISTER_ENCDEC (FLASHSV2, flashsv2);
REGISTER_DECODER(FLIC, flic);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 00f9c82..d46d8d1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -446,6 +446,7 @@ enum AVCodecID {
AV_CODEC_ID_MSCC,
AV_CODEC_ID_SRGC,
AV_CODEC_ID_SVG,
+AV_CODEC_ID_FITS,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index f0ca4ba..18d0ff7 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1457,6 +1457,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
AV_CODEC_PROP_LOSSLESS,
},
{
+.id= AV_CODEC_ID_FITS,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "fits",
+.long_name = NULL_IF_CONFIG_SMALL("FITS image"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
+ AV_CODEC_PROP_LOSSLESS,
+},
+{
.id= AV_CODEC_ID_GIF,
.type = AVMEDIA_TYPE_VIDEO,
.name = "gif",
diff --git a/libavcodec/fitsdec.c b/libavcodec/fitsdec.c
new file mode 100644
index 000..a2cdc43
--- /dev/null
+++ b/libavcodec/fitsdec.c
@@ -0,0 +1,515 @@
+/*
+ * FITS image decoder
+ * Copyright (c) 2017 Paras Chadha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * FITS image decoder
+ * It supports all 2-d images alongwith, bzero, bscale and blank keywords.
+ * RGBA images are supported as NAXIS3 = 3 or 4 i.e. Planes in RGBA order.
Also CTYPE = 'RGB ' should be present.
+ * It currently does not support XTENSION keyword.
+ * Also to interpret data, values are linearly scaled using min-max scaling
but not RGB images.
+ */
+
+#include "avcodec.h"
Re: [FFmpeg-devel] [PATCH] Add FITS Decoder
On Fri, Jun 9, 2017 at 4:19 PM, Michael Niedermayer
wrote:
> On Thu, Jun 08, 2017 at 10:34:15PM +0530, Paras Chadha wrote:
> > It supports all 2-d images alongwith bzero, bscale and blank keywords.
> > RGBA images are supported as NAXIS3 = 3 or 4 i.e. Planes in RGBA order.
> Also CTYPE = 'RGB ' should be present.
> > It currently does not support XTENSION keyword.
> >
> > Signed-off-by: Paras Chadha
> > ---
> > Changelog| 1 +
> > doc/general.texi | 2 +
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/avcodec.h | 1 +
> > libavcodec/codec_desc.c | 8 +
> > libavcodec/fitsdec.c | 527 ++
> +
> > libavcodec/version.h | 4 +-
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/img2.c | 1 +
> > libavformat/img2dec.c| 10 +
> > 12 files changed, 556 insertions(+), 2 deletions(-)
> > create mode 100644 libavcodec/fitsdec.c
> [...]
> > +/**
> > + * function reads the fits header and stores the values in fits_header
> pointed by header
> > + * @param avctx - AVCodec context
> > + * @param ptr - pointer to pointer to the data
> > + * @param header - pointer to the fits_header
> > + * @param end - pointer to end of packet
> > + * @return 1, if calculated successfully, otherwise AVERROR_INVALIDDATA
> > + */
> > +static int fits_read_header(AVCodecContext *avctx, const uint8_t
> **ptr, fits_header * header, const uint8_t * end)
> > +{
> > +const uint8_t *ptr8 = *ptr;
> > +int lines_read = 0, i, dim_no, t, data_min_found = 0,
> data_max_found = 0, ret;
> > +uint64_t size=1;
> > +char str_val[80];
> > +double d;
> > +
> > +header->blank = 0;
> > +header->bscale = 1.0;
> > +header->bzero = 0;
> > +header->rgb = 0;
> > +
> > +if (end - ptr8 < 80)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (sscanf(ptr8, "SIMPLE = %c", &header->simple) != 1) {
> > +av_log(avctx, AV_LOG_ERROR, "missing SIMPLE keyword\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +if (header->simple == 'F')
> > +av_log(avctx, AV_LOG_WARNING, "not a standard FITS file\n");
> > +else if (header->simple != 'T') {
> > +av_log(avctx, AV_LOG_ERROR, "invalid SIMPLE value, SIMPLE =
> %c\n", header->simple);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +ptr8 += 80;
> > +lines_read++;
> > +
> > +if (end - ptr8 < 80)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (sscanf(ptr8, "BITPIX = %d", &header->bitpix) != 1) {
> > +av_log(avctx, AV_LOG_ERROR, "missing BITPIX keyword\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +size = abs(header->bitpix) / 8;
> > +ptr8 += 80;
> > +lines_read++;
> > +
> > +if (end - ptr8 < 80)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (sscanf(ptr8, "NAXIS = %d", &header->naxis) != 1) {
> > +av_log(avctx, AV_LOG_ERROR, "missing NAXIS keyword\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +if (header->naxis == 0) {
> > +av_log(avctx, AV_LOG_ERROR, "No image data found, NAXIS =
> %d\n", header->naxis);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +if (header->naxis != 2 && header->naxis != 3) {
> > +av_log(avctx, AV_LOG_ERROR, "unsupported number of dimensions,
> NAXIS = %d\n", header->naxis);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +ptr8 += 80;
> > +lines_read++;
> > +
> > +for (i = 0; i < header->naxis; i++) {
> > +if (end - ptr8 < 80)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (sscanf(ptr8, "NAXIS%d = %d", &dim_no, &header->naxisn[i])
> != 2 || dim_no != i+1) {
> > +av_log(avctx, AV_LOG_ERROR, "missing NAXIS%d keyword\n",
> i+1);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +size *= header->naxisn[i];
> > +ptr8 += 80;
> > +lines_read++;
> > +}
> > +
> > +if (end - ptr8 < 80)
> > +return AVERROR_INVALIDDATA;
> > +
> > +while (strncmp(ptr8, "END", 3)) {
> > +if (sscanf(ptr8, "BLANK = %d", &t) == 1)
> > +header->blank = t;
> > +else if (sscanf(ptr8, "BSCALE = %lf", &d) == 1)
> > +header->bscale = d;
> > +else if (sscanf(ptr8, "BZERO = %lf", &d) == 1)
> > +header->bzero = d;
> > +else if (sscanf(ptr8, "DATAMAX = %lf", &d) == 1) {
> > +data_max_found = 1;
> > +header->data_max = d;
> > +}
> > +else if (sscanf(ptr8, "DATAMIN = %lf", &d) == 1) {
> > +data_min_found = 1;
> > +header->data_min = d;
> > +}
>
> > +else if (sscanf(ptr8, "CTYPE3 = '%s '", str_val) == 1) {
>
> what prevents a buffer overflow here ?
>
Yes you are right. I have provided an alternative code in latest patch
which prevents
Re: [FFmpeg-devel] [PATCH] Add FITS Decoder
On Fri, Jun 9, 2017 at 1:26 AM, Moritz Barsnick wrote: > On Thu, Jun 08, 2017 at 22:34:15 +0530, Paras Chadha wrote: > > +t64 = (((uint64_t) ptr8[0]) << 56) | (((uint64_t) ptr8[1]) > << 48) | (((uint64_t) ptr8[2]) << 40) | (((uint64_t) ptr8[3]) << 32) | > (ptr8[4] << 24) | (ptr8[5] << 16) | (ptr8[6] << 8) | ptr8[7]; > > I think you can (or should?) use macros such as av_be2ne64() for this, > and all the other shift-byte-placements throughout the code. (Yes, I > know that operation is doing "ne2be", but there's no macro for that, > probably because it's identical.) In addition to being shorter, they > will evaluate to pure assignments on big-endian platforms. yes, Done ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/htmlsubtitles: Protect very slow redundant sscanf() calls by optimized use of strchr()
On Fri, Jun 09, 2017 at 04:32:41PM +0200, wm4 wrote:
> On Thu, 8 Jun 2017 23:53:55 +0200
> Michael Niedermayer wrote:
>
> > Fixes Timeout
> > Fixes: 2127/clusterfuzz-testcase-minimized-6595787859427328
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/htmlsubtitles.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > index 16295daa0c..ba4f269b3f 100644
> > --- a/libavcodec/htmlsubtitles.c
> > +++ b/libavcodec/htmlsubtitles.c
> > @@ -56,6 +56,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
> > const char *in)
> > char *param, buffer[128], tmp[128];
> > int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0;
> > SrtStack stack[16];
> > +const char *next_closep = NULL;
> >
> > stack[0].tag[0] = 0;
> > strcpy(stack[0].param[PARAM_SIZE], "{\\fs}");
> > @@ -83,8 +84,15 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst,
> > const char *in)
> > and all microdvd like styles such as {Y:xxx} */
> > len = 0;
> > an += sscanf(in, "{\\an%*1u}%n", &len) >= 0 && len > 0;
> > -if ((an != 1 && (len = 0, sscanf(in, "{\\%*[^}]}%n", &len) >=
> > 0 && len > 0)) ||
> > -(len = 0, sscanf(in, "{%*1[CcFfoPSsYy]:%*[^}]}%n", &len)
> > >= 0 && len > 0)) {
> > +
> > +if(!next_closep || next_closep <= in) {
> > +next_closep = strchr(in+1, '}');
> > +if (!next_closep)
> > +next_closep = in + strlen(in);
> > +}
> > +
> > +if (*next_closep == '}' && (an != 1 && (len = 0, sscanf(in,
> > "{\\%*[^}]}%n", &len) >= 0 && len > 0)) ||
> > +*next_closep == '}' && (len = 0, sscanf(in,
> > "{%*1[CcFfoPSsYy]:%*[^}]}%n", &len) >= 0 && len > 0)) {
> > in += len - 1;
> > } else
> > av_bprint_chars(dst, *in, 1);
>
> I'm not convinced that bad performance with an obscure fuzzed sample is
> worth the complexity increase here.
If we want to make ff_htmlmarkup_to_ass() not go into near infinite
loops with crafted data then this or a equivalent change is likely
needed.
>
> I'd rather ask, why the heck is it using sscanf in the first place?
I suspect the use of scanf is fewer lines of code than the alternative
but iam not the author of this, i dont know for sure why it was written
as it was.
> The existing code is certainly unreadable already. (Could you tell what
> it does without staring at the scanf manpage for a while? And then
> guarantee correctness/performance/security?)
I know the scanf syntax well enough to not need the manpage much,
but i was toying around with the idea of replacing the scanf already.
I can do that if people want but it will be more code than the scanf
based one. Also the next_closep based code is needed as it is even
without scanf().
What that code does is prevent searching the closing '}' repeatly
for each byte which is very slow if its done for nearly every single
byte in a long string.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
Hello Marton, On Tue, Jun 6, 2017 at 5:45 PM, Marton Balint wrote: > As far as I remember multiple side data of the same type is not something we > wanted to support. Why do you need it? Can't a single AV_FRAME_DATA_A53_CC > side data packet contain many CC entries? Could you please expand on where this was discussed? Is there any design documentation for side data infrastructure that's been introduced into ffmpeg? Is there some list of other known design constraints/limitations? While I agree it would be great to simply say that you should never have multiple side data items of the same type, I'm not sure how realistic that is. It would be helpful if I could better understand the rationale in that thinking. I'm starting a rather large project which will likely stretch the design for side data in order to support a variety of other ancillary data protocols (e.g. SCTE-104, SMPTE 2038, etc), and it would be great to better understand where the constraints are (so I can either plan to address those issues, or if too significant then choose a different multimedia framework to work with before making a significant investment building out a bunch of features in ffmpeg). Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.
That's great. Thanks. On Jun 9, 2017 9:24 AM, "wm4" wrote: > On Tue, 6 Jun 2017 11:16:01 -0700 > Sasi Inguva wrote: > > > Fixes t/6421. If the videos starts with B frame, then the minimum > composition time as computed by stts + ctts will be non-zero. Hence we need > to shift the DTS, so that the first pts is zero. This was the intention of > that code-block. However it was subtracting by the wrong amount. > > For example, for one of the videos in the bug nonFormatted.mp4 we have > > stts: > > sample_count duration > > 960 1001 > > ctts: > > sample_count duration > > 1 3003 > > 2 0 > > 1 3003 > > > > > > The resulting composition times are : 3003, 1001, 2002, 6006, ... > > The minimum composition time or PTS is 1001, which should be used to > offset DTS. However the code block was wrongly using ctts[0] which is 3003. > Hence the PTS was negative. This change computes the minimum pts > encountered while fixing the index, and then subtracts it from all the > timestamps after the edit list fixes are applied. > > > > fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2 > Bframes. Before this change the PTS of first two B-frames was -6006 and > -3003, and I am guessing one of them got dropped when being decoded and > remuxed to the framecrc before, and now it is not being dropped. > > > > Signed-off-by: Sasi Inguva > > --- > > Applied. I added line breaks and white space to the commit message, and > added links to those chromium issues. I hope that's ok. > ___ > 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] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation
Signed-off-by: Ilia Valiakhmetov --- libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ libavcodec/x86/vp9intrapred_16bpp.asm | 56 +++ 2 files changed, 58 insertions(+) diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c b/libavcodec/x86/vp9dsp_init_16bpp.c index d1b8fcd..8d1aa13 100644 --- a/libavcodec/x86/vp9dsp_init_16bpp.c +++ b/libavcodec/x86/vp9dsp_init_16bpp.c @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); decl_ipred_fns(dc_top, 16, mmxext, sse2); decl_ipred_fns(dc_left, 16, mmxext, sse2); decl_ipred_fn(dl, 16, 16, avx2); +decl_ipred_fn(dr, 16, 16, avx2); decl_ipred_fn(dl, 32, 16, avx2); #define decl_ipred_dir_funcs(type) \ @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp) init_fpel_func(1, 1, 64, avg, _16, avx2); init_fpel_func(0, 1, 128, avg, _16, avx2); init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2); init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); } diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm b/libavcodec/x86/vp9intrapred_16bpp.asm index 92333bc..7230de2 100644 --- a/libavcodec/x86/vp9intrapred_16bpp.asm +++ b/libavcodec/x86/vp9intrapred_16bpp.asm @@ -1170,6 +1170,62 @@ DR_FUNCS 2 INIT_XMM avx DR_FUNCS 2 +%if HAVE_AVX2_EXTERNAL +INIT_YMM avx2 +cglobal vp9_ipred_dr_16x16_16, 4, 4, 6, dst, stride, l, a +movam0, [lq] ; klmnopqrstuvwxyz +movum1, [aq-2] ; *abcdefghijklmno +movam2, [aq] ; abcdefghijklmnop +vperm2i128 m4, m2, m2, q2001 ; ijklmnop +vpalignrm5, m4, m2, 2 ; bcdefghijklmnop. +vperm2i128 m3, m0, m1, q0201 ; stuvwxyz*abcdefg +LOWPASS 1, 2, 5 ; ABCDEFGHIJKLMNO. +vpalignrm4, m3, m0, 2 ; lmnopqrstuvwxyz* +vpalignrm5, m3, m0, 4 ; mnopqrstuvwxyz*a +LOWPASS 0, 4, 5 ; LMNOPQRSTUVWXYZ# +vperm2i128 m5, m0, m1, q0201 ; TUVWXYZ#ABCDEFGH +DEFINE_ARGS dst, stride, stride3, stride5, dst3 +lea dst3q, [dstq+strideq*4] +lea stride3q, [strideq*3] +lea stride5q, [stride3q+strideq*2] + +vpalignrm3, m5, m0, 2 +vpalignrm4, m1, m5, 2 +mova[dst3q+stride5q*2], m3 ; 14 +mova[ dstq+stride3q*2], m4 ; 6 +vpalignrm3, m5, m0, 4 +vpalignrm4, m1, m5, 4 +sub dst3q, strideq +mova[dst3q+stride5q*2], m3 ; 13 +mova[dst3q+strideq*2 ], m4 ; 5 +mova[dst3q+stride3q*4], m0 ; 15 +vpalignrm3, m5, m0, 6 +vpalignrm4, m1, m5, 6 +mova [dstq+stride3q*4], m3 ; 12 +mova [dst3q+strideq*1], m4 ; 4 +vpalignrm3, m5, m0, 8 +vpalignrm4, m1, m5, 8 +mova [dst3q+strideq*8], m3 ; 11 +mova [dst3q+strideq*0], m4 ; 3 +vpalignrm3, m5, m0, 10 +vpalignrm4, m1, m5, 10 +mova [dstq+stride5q*2], m3 ; 10 +mova [dstq+strideq*2 ], m4 ; 2 +vpalignrm3, m5, m0, 12 +vpalignrm4, m1, m5, 12 +mova[dst3q+stride3q*2], m3 ; 9 +mova [dstq+strideq*1 ], m4 ; 1 +vpalignrm3, m5, m0, 14 +vpalignrm4, m1, m5, 14 +mova [dstq+strideq*8], m3 ; 8 +mova [dstq+strideq*0], m4 ; 0 +sub dstq, strideq +mova [dst3q+strideq*4], m5 ; 7 +mova [ dstq+strideq*0], m1 ; -1 +RET +%endif + + %macro VL_FUNCS 1 ; stack_mem_for_32x32_32bit_function cglobal vp9_ipred_vl_4x4_16, 2, 4, 3, dst, stride, l, a movifnidn aq, amp -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevc: Add support for alternative transfer characterics SEI
Signed-off-by: Vittorio Giovara
---
libavcodec/hevc_sei.c | 9 +
libavcodec/hevc_sei.h | 7 +++
libavcodec/hevcdec.c | 5 +
3 files changed, 21 insertions(+)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index f0ad84f2f4..cd55d50212 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -265,6 +265,13 @@ static int
decode_nal_sei_active_parameter_sets(HEVCSEIContext *s, GetBitContext
return 0;
}
+static int decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer *s,
GetBitContext *gb)
+{
+s->present = 1;
+s->preferred_transfer_characteristics = get_bits(gb, 8);
+return 0;
+}
+
static int decode_nal_sei_prefix(GetBitContext *gb, HEVCSEIContext *s, const
HEVCParamSets *ps,
int type, int size, void *logctx)
{
@@ -285,6 +292,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb,
HEVCSEIContext *s, const HEV
return decode_nal_sei_active_parameter_sets(s, gb, logctx);
case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
+case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
+return decode_nal_sei_alternative_transfer(&s->alternative_transfer,
gb);
default:
av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
skip_bits_long(gb, 8 * size);
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index 5645e4f5de..1b57ec 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -56,6 +56,7 @@ typedef enum {
HEVC_SEI_TYPE_REGION_REFRESH_INFO = 134,
HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO = 137,
HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
+HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS = 147,
} HEVC_SEI_Type;
typedef struct HEVCSEIPictureHash {
@@ -100,6 +101,11 @@ typedef struct HEVCSEIContentLight {
uint16_t max_pic_average_light_level;
} HEVCSEIContentLight;
+typedef struct HEVCSEIAlternativeTransfer {
+int present;
+int preferred_transfer_characteristics;
+} HEVCSEIAlternativeTransfer;
+
typedef struct HEVCSEIContext {
HEVCSEIPictureHash picture_hash;
HEVCSEIFramePacking frame_packing;
@@ -109,6 +115,7 @@ typedef struct HEVCSEIContext {
HEVCSEIMasteringDisplay mastering_display;
HEVCSEIContentLight content_light;
int active_seq_parameter_set_id;
+HEVCSEIAlternativeTransfer alternative_transfer;
} HEVCSEIContext;
struct HEVCParamSets;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 23a89345a8..955cc703cf 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2684,6 +2684,11 @@ static int set_side_data(HEVCContext *s)
s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
}
+if (s->sei.alternative_transfer.present &&
+s->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_SPC_UNSPECIFIED) {
+s->avctx->color_trc =
s->sei.alternative_transfer.preferred_transfer_characteristics;
+}
+
return 0;
}
--
2.12.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add test for -time_base option
Hi, Attached patch adds a FATE test for the -time_base option, as promised[1] (months ago). This is my first FATE patch, so please be sure to check for stupid mistakes and whatnot. I'm happy to revise it as needed. Thanks, --Michael [1]: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209432.html 0001-fate-add-test-for-time_base-option.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation
On 6/9/17, Ilia Valiakhmetov wrote: > Signed-off-by: Ilia Valiakhmetov > --- > libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ > libavcodec/x86/vp9intrapred_16bpp.asm | 56 > +++ > 2 files changed, 58 insertions(+) > > diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c > b/libavcodec/x86/vp9dsp_init_16bpp.c > index d1b8fcd..8d1aa13 100644 > --- a/libavcodec/x86/vp9dsp_init_16bpp.c > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c > @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); > decl_ipred_fns(dc_top, 16, mmxext, sse2); > decl_ipred_fns(dc_left, 16, mmxext, sse2); > decl_ipred_fn(dl, 16, 16, avx2); > +decl_ipred_fn(dr, 16, 16, avx2); > decl_ipred_fn(dl, 32, 16, avx2); > > #define decl_ipred_dir_funcs(type) \ > @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext > *dsp) > init_fpel_func(1, 1, 64, avg, _16, avx2); > init_fpel_func(0, 1, 128, avg, _16, avx2); > init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); > +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2); > init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); > } > > diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm > b/libavcodec/x86/vp9intrapred_16bpp.asm > index 92333bc..7230de2 100644 > --- a/libavcodec/x86/vp9intrapred_16bpp.asm > +++ b/libavcodec/x86/vp9intrapred_16bpp.asm > @@ -1170,6 +1170,62 @@ DR_FUNCS 2 > INIT_XMM avx > DR_FUNCS 2 > > +%if HAVE_AVX2_EXTERNAL > +INIT_YMM avx2 > +cglobal vp9_ipred_dr_16x16_16, 4, 4, 6, dst, stride, l, a [...] > +DEFINE_ARGS dst, stride, stride3, stride5, dst3 You removed one variable, so now the number of re-define-args gprs should be 5. However the cglobal above have 4 reserved registers. It used to be 4, 6, 6 Now it is 4, 4, 6 I think it should be 4, 5, 6 Do I miss something? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/mediacodecdec: switch to the new generic filtering mechanism
---
libavcodec/mediacodecdec.c | 70 --
1 file changed, 12 insertions(+), 58 deletions(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 5bdeb6c1d7..0c77a78aa9 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -41,11 +41,9 @@ typedef struct MediaCodecH264DecContext {
MediaCodecDecContext *ctx;
-AVBSFContext *bsf;
-
AVFifoBuffer *fifo;
-AVPacket filtered_pkt;
+AVPacket buffered_pkt;
} MediaCodecH264DecContext;
@@ -58,8 +56,7 @@ static av_cold int mediacodec_decode_close(AVCodecContext
*avctx)
av_fifo_free(s->fifo);
-av_bsf_free(&s->bsf);
-av_packet_unref(&s->filtered_pkt);
+av_packet_unref(&s->buffered_pkt);
return 0;
}
@@ -312,9 +309,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
const char *codec_mime = NULL;
-const char *bsf_name = NULL;
-const AVBitStreamFilter *bsf = NULL;
-
FFAMediaFormat *format = NULL;
MediaCodecH264DecContext *s = avctx->priv_data;
@@ -329,7 +323,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
#if CONFIG_H264_MEDIACODEC_DECODER
case AV_CODEC_ID_H264:
codec_mime = "video/avc";
-bsf_name = "h264_mp4toannexb";
ret = h264_set_extradata(avctx, format);
if (ret < 0)
@@ -339,7 +332,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
#if CONFIG_HEVC_MEDIACODEC_DECODER
case AV_CODEC_ID_HEVC:
codec_mime = "video/hevc";
-bsf_name = "hevc_mp4toannexb";
ret = hevc_set_extradata(avctx, format);
if (ret < 0)
@@ -410,25 +402,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
goto done;
}
-if (bsf_name) {
-bsf = av_bsf_get_by_name(bsf_name);
-if(!bsf) {
-ret = AVERROR_BSF_NOT_FOUND;
-goto done;
-}
-
-if ((ret = av_bsf_alloc(bsf, &s->bsf))) {
-goto done;
-}
-
-if (((ret = avcodec_parameters_from_context(s->bsf->par_in, avctx)) < 0) ||
-((ret = av_bsf_init(s->bsf)) < 0)) {
- goto done;
-}
-}
-
-av_init_packet(&s->filtered_pkt);
-
done:
if (format) {
ff_AMediaFormat_delete(format);
@@ -503,10 +476,10 @@ static int mediacodec_decode_frame(AVCodecContext *avctx,
void *data,
/* process buffered data */
while (!*got_frame) {
/* prepare the input data -- convert to Annex B if needed */
-if (s->filtered_pkt.size <= 0) {
-AVPacket input_pkt = { 0 };
+if (s->buffered_pkt.size <= 0) {
+AVPacket input_pkt;
-av_packet_unref(&s->filtered_pkt);
+av_packet_unref(&s->buffered_pkt);
/* no more data */
if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
@@ -514,36 +487,15 @@ static int mediacodec_decode_frame(AVCodecContext *avctx,
void *data,
ff_mediacodec_dec_decode(avctx, s->ctx, frame, got_frame,
avpkt);
}
-av_fifo_generic_read(s->fifo, &input_pkt, sizeof(input_pkt), NULL);
-
-if (s->bsf) {
-ret = av_bsf_send_packet(s->bsf, &input_pkt);
-if (ret < 0) {
-return ret;
-}
-
-ret = av_bsf_receive_packet(s->bsf, &s->filtered_pkt);
-if (ret == AVERROR(EAGAIN)) {
-goto done;
-}
-} else {
-av_packet_move_ref(&s->filtered_pkt, &input_pkt);
-}
-
-/* {h264,hevc}_mp4toannexb are used here and do not require
flushing */
-av_assert0(ret != AVERROR_EOF);
-
-if (ret < 0) {
-return ret;
-}
+av_fifo_generic_read(s->fifo, &s->buffered_pkt, sizeof(input_pkt),
NULL);
}
-ret = mediacodec_process_data(avctx, frame, got_frame,
&s->filtered_pkt);
+ret = mediacodec_process_data(avctx, frame, got_frame,
&s->buffered_pkt);
if (ret < 0)
return ret;
-s->filtered_pkt.size -= ret;
-s->filtered_pkt.data += ret;
+s->buffered_pkt.size -= ret;
+s->buffered_pkt.data += ret;
}
done:
return avpkt->size;
@@ -560,7 +512,7 @@ static void mediacodec_decode_flush(AVCodecContext *avctx)
}
av_fifo_reset(s->fifo);
-av_packet_unref(&s->filtered_pkt);
+av_packet_unref(&s->buffered_pkt);
ff_mediacodec_dec_flush(avctx, s->ctx);
}
@@ -578,6 +530,7 @@ AVCodec ff_h264_mediacodec_decoder = {
.close = mediacodec_decode_close,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
.caps_internal = FF_CODEC_CAP_SETS_PKT_DTS,
+.bsfs = "h264_mp4toannexb",
};
#endif
@@ -594,6 +547,7 @@ AVCodec ff_hevc_mediacodec_decoder = {
.close = mediacodec_decode_close,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec: switch to the new generic filtering mechanism
On 6/9/2017 7:53 PM, Matthieu Bouron wrote:
> ---
> libavcodec/mediacodecdec.c | 70
> --
> 1 file changed, 12 insertions(+), 58 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 5bdeb6c1d7..0c77a78aa9 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -41,11 +41,9 @@ typedef struct MediaCodecH264DecContext {
>
> MediaCodecDecContext *ctx;
>
> -AVBSFContext *bsf;
> -
> AVFifoBuffer *fifo;
>
> -AVPacket filtered_pkt;
> +AVPacket buffered_pkt;
>
> } MediaCodecH264DecContext;
>
> @@ -58,8 +56,7 @@ static av_cold int mediacodec_decode_close(AVCodecContext
> *avctx)
>
> av_fifo_free(s->fifo);
>
> -av_bsf_free(&s->bsf);
> -av_packet_unref(&s->filtered_pkt);
> +av_packet_unref(&s->buffered_pkt);
>
> return 0;
> }
> @@ -312,9 +309,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
>
> const char *codec_mime = NULL;
>
> -const char *bsf_name = NULL;
> -const AVBitStreamFilter *bsf = NULL;
> -
> FFAMediaFormat *format = NULL;
> MediaCodecH264DecContext *s = avctx->priv_data;
>
> @@ -329,7 +323,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
> #if CONFIG_H264_MEDIACODEC_DECODER
> case AV_CODEC_ID_H264:
> codec_mime = "video/avc";
> -bsf_name = "h264_mp4toannexb";
>
> ret = h264_set_extradata(avctx, format);
> if (ret < 0)
> @@ -339,7 +332,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
> #if CONFIG_HEVC_MEDIACODEC_DECODER
> case AV_CODEC_ID_HEVC:
> codec_mime = "video/hevc";
> -bsf_name = "hevc_mp4toannexb";
>
> ret = hevc_set_extradata(avctx, format);
> if (ret < 0)
> @@ -410,25 +402,6 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
> goto done;
> }
>
> -if (bsf_name) {
> -bsf = av_bsf_get_by_name(bsf_name);
> -if(!bsf) {
> -ret = AVERROR_BSF_NOT_FOUND;
> -goto done;
> -}
> -
> -if ((ret = av_bsf_alloc(bsf, &s->bsf))) {
> -goto done;
> -}
> -
> -if (((ret = avcodec_parameters_from_context(s->bsf->par_in, avctx)) < 0)
> ||
> -((ret = av_bsf_init(s->bsf)) < 0)) {
> - goto done;
> -}
> -}
> -
> -av_init_packet(&s->filtered_pkt);
> -
> done:
> if (format) {
> ff_AMediaFormat_delete(format);
> @@ -503,10 +476,10 @@ static int mediacodec_decode_frame(AVCodecContext
> *avctx, void *data,
> /* process buffered data */
> while (!*got_frame) {
> /* prepare the input data -- convert to Annex B if needed */
The second part of this comment can be removed.
> -if (s->filtered_pkt.size <= 0) {
> -AVPacket input_pkt = { 0 };
> +if (s->buffered_pkt.size <= 0) {
> +AVPacket input_pkt;
>
> -av_packet_unref(&s->filtered_pkt);
> +av_packet_unref(&s->buffered_pkt);
>
> /* no more data */
> if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
> @@ -514,36 +487,15 @@ static int mediacodec_decode_frame(AVCodecContext
> *avctx, void *data,
> ff_mediacodec_dec_decode(avctx, s->ctx, frame,
> got_frame, avpkt);
> }
>
> -av_fifo_generic_read(s->fifo, &input_pkt, sizeof(input_pkt),
> NULL);
> -
> -if (s->bsf) {
> -ret = av_bsf_send_packet(s->bsf, &input_pkt);
> -if (ret < 0) {
> -return ret;
> -}
> -
> -ret = av_bsf_receive_packet(s->bsf, &s->filtered_pkt);
> -if (ret == AVERROR(EAGAIN)) {
> -goto done;
> -}
> -} else {
> -av_packet_move_ref(&s->filtered_pkt, &input_pkt);
> -}
> -
> -/* {h264,hevc}_mp4toannexb are used here and do not require
> flushing */
> -av_assert0(ret != AVERROR_EOF);
> -
> -if (ret < 0) {
> -return ret;
> -}
> +av_fifo_generic_read(s->fifo, &s->buffered_pkt,
> sizeof(input_pkt), NULL);
input_pkt is unused aside from this, so why not just do
sizeof(s->buffered_pkt) instead and remove input_pkt altogether?
> }
>
> -ret = mediacodec_process_data(avctx, frame, got_frame,
> &s->filtered_pkt);
> +ret = mediacodec_process_data(avctx, frame, got_frame,
> &s->buffered_pkt);
> if (ret < 0)
> return ret;
>
> -s->filtered_pkt.size -= ret;
> -s->filtered_pkt.data += ret;
> +s->buffered_pkt.size -= ret;
> +s->buffered_pkt.data += ret;
> }
> done:
> return avpkt->size;
> @@ -560,7 +512,7 @@ static void mediacodec_decode_flush(AVCodecContext *avctx)
> }
> av_fifo_reset(s->fifo);
>
> -av_packet_unref(&s->filtered_pkt);
> +av_packet_unref(
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec: switch to the new generic filtering mechanism
On Fri, Jun 09, 2017 at 08:18:25PM -0300, James Almer wrote:
> On 6/9/2017 7:53 PM, Matthieu Bouron wrote:
> > ---
> > libavcodec/mediacodecdec.c | 70
> > --
> > 1 file changed, 12 insertions(+), 58 deletions(-)
> >
> > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > index 5bdeb6c1d7..0c77a78aa9 100644
> > --- a/libavcodec/mediacodecdec.c
> > +++ b/libavcodec/mediacodecdec.c
> > @@ -41,11 +41,9 @@ typedef struct MediaCodecH264DecContext {
> >
> > MediaCodecDecContext *ctx;
> >
> > -AVBSFContext *bsf;
> > -
> > AVFifoBuffer *fifo;
> >
> > -AVPacket filtered_pkt;
> > +AVPacket buffered_pkt;
> >
> > } MediaCodecH264DecContext;
> >
> > @@ -58,8 +56,7 @@ static av_cold int mediacodec_decode_close(AVCodecContext
> > *avctx)
> >
> > av_fifo_free(s->fifo);
> >
> > -av_bsf_free(&s->bsf);
> > -av_packet_unref(&s->filtered_pkt);
> > +av_packet_unref(&s->buffered_pkt);
> >
> > return 0;
> > }
> > @@ -312,9 +309,6 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext *avctx)
> >
> > const char *codec_mime = NULL;
> >
> > -const char *bsf_name = NULL;
> > -const AVBitStreamFilter *bsf = NULL;
> > -
> > FFAMediaFormat *format = NULL;
> > MediaCodecH264DecContext *s = avctx->priv_data;
> >
> > @@ -329,7 +323,6 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext *avctx)
> > #if CONFIG_H264_MEDIACODEC_DECODER
> > case AV_CODEC_ID_H264:
> > codec_mime = "video/avc";
> > -bsf_name = "h264_mp4toannexb";
> >
> > ret = h264_set_extradata(avctx, format);
> > if (ret < 0)
> > @@ -339,7 +332,6 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext *avctx)
> > #if CONFIG_HEVC_MEDIACODEC_DECODER
> > case AV_CODEC_ID_HEVC:
> > codec_mime = "video/hevc";
> > -bsf_name = "hevc_mp4toannexb";
> >
> > ret = hevc_set_extradata(avctx, format);
> > if (ret < 0)
> > @@ -410,25 +402,6 @@ static av_cold int
> > mediacodec_decode_init(AVCodecContext *avctx)
> > goto done;
> > }
> >
> > -if (bsf_name) {
> > -bsf = av_bsf_get_by_name(bsf_name);
> > -if(!bsf) {
> > -ret = AVERROR_BSF_NOT_FOUND;
> > -goto done;
> > -}
> > -
> > -if ((ret = av_bsf_alloc(bsf, &s->bsf))) {
> > -goto done;
> > -}
> > -
> > -if (((ret = avcodec_parameters_from_context(s->bsf->par_in, avctx)) <
> > 0) ||
> > -((ret = av_bsf_init(s->bsf)) < 0)) {
> > - goto done;
> > -}
> > -}
> > -
> > -av_init_packet(&s->filtered_pkt);
> > -
> > done:
> > if (format) {
> > ff_AMediaFormat_delete(format);
> > @@ -503,10 +476,10 @@ static int mediacodec_decode_frame(AVCodecContext
> > *avctx, void *data,
> > /* process buffered data */
> > while (!*got_frame) {
> > /* prepare the input data -- convert to Annex B if needed */
>
> The second part of this comment can be removed.
Fixed.
>
> > -if (s->filtered_pkt.size <= 0) {
> > -AVPacket input_pkt = { 0 };
> > +if (s->buffered_pkt.size <= 0) {
> > +AVPacket input_pkt;
> >
> > -av_packet_unref(&s->filtered_pkt);
> > +av_packet_unref(&s->buffered_pkt);
> >
> > /* no more data */
> > if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
> > @@ -514,36 +487,15 @@ static int mediacodec_decode_frame(AVCodecContext
> > *avctx, void *data,
> > ff_mediacodec_dec_decode(avctx, s->ctx, frame,
> > got_frame, avpkt);
> > }
> >
> > -av_fifo_generic_read(s->fifo, &input_pkt, sizeof(input_pkt),
> > NULL);
> > -
> > -if (s->bsf) {
> > -ret = av_bsf_send_packet(s->bsf, &input_pkt);
> > -if (ret < 0) {
> > -return ret;
> > -}
> > -
> > -ret = av_bsf_receive_packet(s->bsf, &s->filtered_pkt);
> > -if (ret == AVERROR(EAGAIN)) {
> > -goto done;
> > -}
> > -} else {
> > -av_packet_move_ref(&s->filtered_pkt, &input_pkt);
> > -}
> > -
> > -/* {h264,hevc}_mp4toannexb are used here and do not require
> > flushing */
> > -av_assert0(ret != AVERROR_EOF);
> > -
> > -if (ret < 0) {
> > -return ret;
> > -}
> > +av_fifo_generic_read(s->fifo, &s->buffered_pkt,
> > sizeof(input_pkt), NULL);
>
> input_pkt is unused aside from this, so why not just do
> sizeof(s->buffered_pkt) instead and remove input_pkt altogether?
Fixed. I removed input_pkt as it was a left-over of the previous code.
>
> > }
> >
> > -ret = mediacodec_process_data(avctx, frame, got_frame,
> > &s->filtered_pkt);
> > +ret = mediacodec_process_data(avctx, frame, got_frame,
> > &s->buffered_pkt);
> >
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
On 6/9/17, wm4 wrote:
> On Fri, 9 Jun 2017 00:10:49 +0200
> Michael Niedermayer wrote:
>
>> On Sat, May 27, 2017 at 12:24:16PM +0200, wm4 wrote:
>> > On Sat, 27 May 2017 03:56:42 +0200
>> > Michael Niedermayer wrote:
>> >
>> > > On Fri, May 26, 2017 at 07:06:44PM -0400, Ronald S. Bultje wrote:
>> > > > Hi,
>> > > >
>> > > > On Fri, May 26, 2017 at 6:34 PM, Michael Niedermayer
>> > > > > > > > > wrote:
>> > > >
>> > > > > On Fri, May 26, 2017 at 06:07:35PM -0400, Ronald S. Bultje wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > On Fri, May 26, 2017 at 5:50 PM, Michael Niedermayer
>> > > > > > > > > > > > wrote:
>> > > > > >
>> > > > > > > On Fri, May 26, 2017 at 11:18:12PM +0200, Hendrik Leppkes
>> > > > > > > wrote:
>> > > > > > > > On Fri, May 26, 2017 at 11:11 PM, Michael Niedermayer
>> > > > > > > > wrote:
>> > > > > > > > > On Fri, May 26, 2017 at 03:20:14PM +0100, Rostislav
>> > > > > > > > > Pehlivanov
>> > > > > wrote:
>> > > > > > > > >> On 26 May 2017 at 12:21, wm4
>> > > > > > > > >> wrote:
>> > > > > > > > >>
>> > > > > > > > >> > On Thu, 25 May 2017 16:10:49 +0200
>> > > > > > > > >> > Michael Niedermayer wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > Fixes:
>> > > > > > > > >> > > 1735/clusterfuzz-testcase-minimized-5350472347025408
>> > > > > > > > >> > >
>> > > > > > > > >> > > Found-by: continuous fuzzing process
>> > > > > > > https://github.com/google/oss-
>> > > > > > > > >> > fuzz/tree/master/projects/ffmpeg
>> > > > > > > > >> > > Signed-off-by: Michael Niedermayer
>> > > > > > > > >> > >
>> > > > > > > > >> > > ---
>> > > > > > > > >> > > libavcodec/fft_template.c | 50
>> > > > > > > > >> > > +++---
>> > > > > > > > >> > -
>> > > > > > > > >> > > 1 file changed, 25 insertions(+), 25 deletions(-)
>> > > > > > > > >> > >
>> > > > > > > > >> > > diff --git a/libavcodec/fft_template.c
>> > > > > b/libavcodec/fft_template.c
>> > > > > > > > >> > > index 480557f49f..e3a37e5d69 100644
>> > > > > > > > >> > > --- a/libavcodec/fft_template.c
>> > > > > > > > >> > > +++ b/libavcodec/fft_template.c
>> > > > > > > > >> > > @@ -249,7 +249,7 @@ static void fft_calc_c(FFTContext
>> > > > > > > > >> > > *s,
>> > > > > > > FFTComplex *z)
>> > > > > > > > >> > {
>> > > > > > > > >> > >
>> > > > > > > > >> > > int nbits, i, n, num_transforms, offset, step;
>> > > > > > > > >> > > int n4, n2, n34;
>> > > > > > > > >> > > -FFTSample tmp1, tmp2, tmp3, tmp4, tmp5, tmp6,
>> > > > > > > > >> > > tmp7, tmp8;
>> > > > > > > > >> > > +SUINT tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7,
>> > > > > > > > >> > > tmp8;
>> > > > > > > > >> >
>> > > > > > > > >> > I want this SUINT thing gone, not have more of it.
>> > > > > > > > >> > ___
>> > > > > > > > >> > ffmpeg-devel mailing list
>> > > > > > > > >> > ffmpeg-devel@ffmpeg.org
>> > > > > > > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >> I agree, especially here.
>> > > > > > > > >
>> > > > > > > > >> Overflows should be left to happen in transforms if the
>> > > > > > > > >> input is
>> > > > > > > corrupt.
>> > > > > > > > >
>> > > > > > > > > signed int overflow is not allowed in C, if that is what
>> > > > > > > > > you meant.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > > Its "undefined", which means what the result will be is not
>> > > > > > > > defined -
>> > > > > > > > which in such a DSP function is irrelevant, if all it causes
>> > > > > > > > is
>> > > > > > > > corrupt output ... from corrupt input.
>> > > > > > >
>> > > > > > > no, this is not correct.
>> > > > > > > undefined behavior does not mean the effect will be limited to
>> > > > > > > the output.
>> > > > > > > It could cause the process to hard lockup, trigger an
>> > > > > > > exception or
>> > > > > > > set a flag causing errors in later unrelated code.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > > > We've discussed this before, if you believe this to be
>> > > > > > exploitable, why
>> > > > > > allow it in our repository at all? I know of no other project
>> > > > > > that even
>> > > > > > remotely allows such ridiculous things. Please limit exploitable
>> > > > > > code to
>> > > > > > your personal tree, ffmpeg is not a rootkit.
>> > > > >
>> > > > > please calm down, you make all kinds of statments and implications
>> > > > > in
>> > > > > the text above which are not true.
>> > > > >
>> > > > > This specific code in git triggers undefined behavior, the patch
>> > > > > fixes
>> > > > > this undefined behavior.
>> > > > > If that is exploitable (which i neither claim it is nor that it
>> > > > > isnt)
>> > > > > its a issue that exists before the patch but not afterwards.
>> > > >
>> > > >
>> > >
>> > > > *unsigned* removes the exploit. SUINT keeps it, and is therefore
>> > > > part of a
>> > > > rootkit.
>> > >
>> > > SUINT is defined to unsigned, if unsigned re
Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
Hi, On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer wrote: > On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer > > > wrote: > > > > > Signed value in > > > Unsigned > > > INTeger type > > > > [..] > > > Both SUINT and unsigned should produce identical binaries > > > > This seems to go against the rule that code should be as simple as > possible. > > > > Unsigned is simpler than SUINT if the outcome is the same. > > You can simply add the part of my mail here as awnser that you snipped > away: > > "But it makes the code hard to understand and maintain because these > values are not positive integers but signed integers. Which for > C standard compliance need to be stored in a unsigned type." > > A type that avoids the undefinedness of signed but is semantically > signed is correct, unsigned is not. > > If understandable code and maintainable code has no value to you, > you would favour using single letter variables exclusivly and would > never use typedef. > But you do not do that. > > I fail to understand why you insist on using unsigned in place of a > more specific type, it is not the correct nor clean thing to do. It's not just me, it appears to be most of us. Can't you just step back at some point and be like "ok, I'll let the majority have their way"? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm
On Fri, Jun 09, 2017 at 03:07:55PM +0300, Ivan Kalvachev wrote: > On 6/9/17, Ivan Kalvachev wrote: > > On 6/9/17, Michael Niedermayer wrote: > >> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote: > >>> opus_pvq.c |9 > >>> opus_pvq.h |5 > >>> x86/Makefile|1 > >>> x86/opus_dsp_init.c | 47 +++ > >>> x86/opus_pvq_search.asm | 597 > >>> > >>> 5 files changed, 657 insertions(+), 2 deletions(-) > >>> 3b9648bea3f01dad2cf159382f0ffc2d992c84b2 > >>> 0001-SIMD-opus-pvq_search-implementation.patch > >>> From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001 > >>> From: Ivan Kalvachev > >>> Date: Thu, 8 Jun 2017 22:24:33 +0300 > >>> Subject: [PATCH 1/3] SIMD opus pvq_search implementation. > >> > >> seems this breaks build with mingw64, didnt investigate but it > >> fails with these errors: > >> > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): > >> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge' > >> collect2: error: ld returned 1 exit status > >> collect2: error: ld returned 1 exit status > >> make: *** [ffmpeg_g.exe] Error 1 > >> make: *** Waiting for unfinished jobs > >> make: *** [ffprobe_g.exe] Error 1 > > > > > > const_*_edge is used on only one place is the code. > > Would you check if this patch fixes the issue. > > > Sorry, the patch was not tested and the variable name was not correct. > This one should be fine... I hope > > --- a/libavcodec/x86/opus_pvq_search.asm > +++ b/libavcodec/x86/opus_pvq_search.asm > @@ -419,7 +419,7 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N > add Nq, r4q ; Nq = align(Nq, mmsize) > sub rsp, Nq; allocate tmpX[Nq] > > -movups m3, [const_align_abs_edge-mmsize+r4q] ; this is > the bit mask for the padded read at the end of the input > +movups m3, [const_float_abs_mask+32-mmsize+r4q] ; this > is the bit mask for the padded read at the end of the input > > lea r4q, [Nq-mmsize] ; Nq is rounded up (aligned > up) to mmsize, so r4q can't become negative here, unless N=0. > movups m2, [inXq + r4q] doesnt help libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48): relocation truncated to fit: R_X86_64_32 against `const_float_abs_mask' collect2: error: ld returned 1 exit status collect2: error: ld retur
Re: [FFmpeg-devel] [PATCH 3/3] libavformat/aviobuf: don't treat 0 as EOF
On Fri, Jun 09, 2017 at 03:49:03PM +0200, Daniel Kucera wrote:
> Signed-off-by: Daniel Kucera
> ---
> libavformat/aviobuf.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 1667e9f08b..3705e406d9 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -556,13 +556,14 @@ static void fill_buffer(AVIOContext *s)
> if (s->read_packet)
> len = s->read_packet(s->opaque, dst, len);
> else
> -len = 0;
> -if (len <= 0) {
> +len = AVERROR_EOF;
> +if (len == AVERROR_EOF) {
> /* do not modify buffer if EOF reached so that a seek back can
> be done without rereading data */
> s->eof_reached = 1;
> -if (len < 0)
> -s->error = len;
> +} else if (len < 0) {
> +s->eof_reached = 1;
> +s->error= len;
> } else {
> s->pos += len;
> s->buf_ptr = dst;
> @@ -630,13 +631,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
> size)
> // bypass the buffer and read data directly into buf
> if(s->read_packet)
> len = s->read_packet(s->opaque, buf, size);
> -
> -if (len <= 0) {
> + else
tabs are forbidden in ffmpeg git
also either this or the next patch cause fate to infinite-loop
(that is without any other patches)
if theres a dependance on the other patches please add a note about
that.
and are any changes needed in libavdevice ?
if so the ABI between them may add some more headaches
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
