Re: [FFmpeg-devel] [PATCH 9/9] dnxhdenc: fix scan used for bitstream generation

Hi, Le 4 oct. 2015 04:16, "Michael Niedermayer" <michae...@gmx.at> a écrit : > > On Sat, Oct 03, 2015 at 06:59:22PM +0200, Christophe Gisquet wrote: > > The functions related to bitstream reading must use the natural zigzag > > order, and not th

Re: [FFmpeg-devel] [PATCH] dnxhdenc: fix usage of discording scans

Hi, 2015-10-02 20:57 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > @@ -498,7 +498,7 @@ void dnxhd_unquantize_c(DNXHDEncContext *ctx, int16_t > *block, int n, > : ctx->cid_table->luma_weight; > > for (i = 1; i <= las

Re: [FFmpeg-devel] [PATCH 3/5] dnxhd: add CID 1270

2015-10-02 21:00 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > This a 4:4:4 10 bits profile, where image size is not fixed by the > profile, and which strays a bit outside the old frame header parsing > code. > > Fixes ticket #4581 (DNxHR is

[FFmpeg-devel] [PATCH 1/5] dnxhd: add decoder support for DNxHR

From: Jeremy James <jeremy.ja...@gmail.com> Signed-off-by: Christophe Gisquet <christophe.gisq...@gmail.com> --- libavcodec/dnxhddata.c | 7 +++ libavcodec/dnxhddec.c | 5 +++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/libavcodec/dnxhddata.c b/libavcodec

[FFmpeg-devel] [PATCH] dnxhdenc: fix usage of discording scans

Forward and inverse DCTs may not have the same permutation table, resulting in a bitstream where the AC coefficients are encoded in an unexpected order. --- libavcodec/dnxhdenc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/dnxhdenc.c

[FFmpeg-devel] [PATCH 0/5] Initial support for DNxHR

CIDs 1270 (10 & 12bits) to 1274, as produced by Avid Media Composer, have been tested. I merged and adapted a bit Jeremy's work (but it's mostly his code), hence the signing-off. Christophe Gisquet (3): isom: add support for DNxHR codec family dnxhd: add CID 1270 dnxhddec: replace som

[FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE

A series of 0 in a table can be confusing, and the corresponding checks strange, so using a macro instead of that magic is more readable. --- libavcodec/dnxhddata.c | 10 +- libavcodec/dnxhddata.h | 3 +++ libavcodec/dnxhddec.c | 6 -- 3 files changed, 12 insertions(+), 7

[FFmpeg-devel] [PATCH 3/5] dnxhd: add CID 1270

This a 4:4:4 10 bits profile, where image size is not fixed by the profile, and which strays a bit outside the old frame header parsing code. Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is). --- libavcodec/dnxhddata.c | 23 + libavcodec/dnxhddec.c |

[FFmpeg-devel] [PATCH 4/5] dnxhd: add better support for CIDs 1270 to 1274

From: Jeremy James <jeremy.ja...@gmail.com> These are DNxHR profiles with the following properties: - Variable size in a profile, requiring variable-sized macroblock table - Variable bitdepth, up to 12 bits Signed-off-by: Christophe Gisquet <christophe.gisq...@gmail.com> ---

[FFmpeg-devel] [PATCH 2/5] isom: add support for DNxHR codec family

This is actually similar to DNxHD. --- libavformat/isom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/isom.c b/libavformat/isom.c index eff04ff..e55738b 100644 --- a/libavformat/isom.c +++ b/libavformat/isom.c @@ -240,6 +240,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {

Re: [FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

crashes due to mishandling of code around execute2 The speed of slice-threading is equivalent to frame-threading, which makes the later less attractive. Several decoders forgo implementing it. -- Christophe From 354a8e016e1e10a4288534782104479aae3e62a9 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <

Re: [FFmpeg-devel] [PATCH 6/7] dnxhddata: deduplicate table

Hi, 2015-09-27 10:09 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > CID 1256 chroma table is the same as luma table for CID 1235 and 1256, > which is consistent with the content being (normally) RGB. Please ignore for now. --

[FFmpeg-devel] [PATCH 0/7] dnxhddec cleanup

Nothing major, mostly related to error reporting. Christophe Gisquet (7): dnxhddec: remove unused qscale parameter dnxhddec: simplify block parsing calls dnxhddec: check and report bitstream errors dnxhddec: use unsafe bitstream reader dnxhddec: reindent/cosmetics dnxhddata

[FFmpeg-devel] [PATCH 4/7] dnxhddec: use unsafe bitstream reader

Each line is padded by the format, and errors are now reported and stop the decoding. Around 5% speedup. --- libavcodec/dnxhddec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 8d30446..06d4780 100644 --- a/libavcodec/dnxhddec.c +++

[FFmpeg-devel] [PATCH 2/7] dnxhddec: simplify block parsing calls

Fewer arguments, less duplicated code. --- libavcodec/dnxhddec.c | 43 --- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 34cf379..007eabe 100644 --- a/libavcodec/dnxhddec.c +++

[FFmpeg-devel] [PATCH 3/7] dnxhddec: check and report bitstream errors

This only occur when an overrun in coefficient decoding is detected. --- libavcodec/dnxhddec.c | 48 ++-- 1 file changed, 34 insertions(+), 14 deletions(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 007eabe..8d30446 100644 ---

[FFmpeg-devel] [PATCH 1/7] dnxhddec: remove unused qscale parameter

--- libavcodec/dnxhddec.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index fa93407..34cf379 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -63,7 +63,7 @@ typedef struct

[FFmpeg-devel] [PATCH 6/7] dnxhddata: deduplicate table

CID 1256 chroma table is the same as luma table for CID 1235 and 1256, which is consistent with the content being (normally) RGB. CID 1244 weight tables are identica to CID 1244, but as this was not tested against a real sample, it was not added. --- libavcodec/dnxhddata.c | 16 +++-

[FFmpeg-devel] [PATCH 5/7] dnxhddec: reindent/cosmetics

--- libavcodec/dnxhddec.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 06d4780..7b96004 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -64,18 +64,18 @@ typedef struct

[FFmpeg-devel] [PATCH 7/7] dnxhddec: add my contributions

., Baptiste Coudurier * Copyright (c) 2011 MirriAd Ltd + * Copyright (c) 2015 Christophe Gisquet * * 10 bit support added by MirriAd Ltd, Joseph Artsimovich <jos...@mirriad.com> + * Slice multithreading and MB interlaced support added by Christophe Gisquet * * This file is part of

Re: [FFmpeg-devel] [PATCH 6/7] dnxhddata: deduplicate table

2015-09-28 11:21 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > Please ignore for now. The specs explicitly says it is the same for luma and chroma. Here's a patch that confidently reflects that. -- Christophe From bfbb0bdde4eee8d44d9c158e04b50fb4177c428f Mon Sep 17

Re: [FFmpeg-devel] [PATCH] hevc: fix wpp threading deadlock.

Sent from a phone so please excuse terseness. Le 20 sept. 2015 12:47, "Ronald S. Bultje" a écrit: > if (more_data < 0) { > s->tab_slice_address[ctb_addr_rs] = -1; > +avpriv_atomic_int_set(>wpp_err, 1); > +

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee

r the following people: > Michael Niedermayer > Clément Bœsch > James Almer > Paul B Mahol > Carl Eugen Hoyos > Andreas Cadhalpun > Ronald S. Bultje > wm4 > Lukasz Marek > Rostislav Pehlivanov > Hendrik Leppkes >

[FFmpeg-devel] [PATCH 2/2] fate: add chroma position scale test

The sample position is made weird and non-nominal to force catching such issues as default values or specialized operations hiding issues in corner cases. --- tests/fate/filter-video.mak | 4 tests/ref/fate/filter-scalechroma | 26 ++ 2 files changed, 30

Re: [FFmpeg-devel] [PATCH] hevc: fix WPP mode

Hi, 2015-09-23 17:06 GMT+02:00 Mickaël Raulet : > the fix looks weird to me. There is something else underlying. The issue appeared in d249e682 (not the hash I reported, for some reason). If you want to test, that commit is buggy (it causes crashes): commit 7117547 is

[FFmpeg-devel] [PATCH 0/2] dnxhddec: fix DNx100 profiles

There are 2 issues, listed in ticket #4876: - new mb header syntax, where the firt bit indicates mbaff-like handling - incorrectly scanned weight tables Christophe Gisquet (1): dnxhddec: decode and use interlace mb flag Jeremy James (1): dnxhddata: correct weight tables libavcodec

Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.

Hi, 2015-09-25 22:36 GMT+02:00 Ronald S. Bultje : > +pd_16: times 8 dd 16 In h264_intrapred_10bit.asm > +pd_32: times 8 dd 32 In h264_idct_10bit.asm And that's about anything remotely useful I have to say, as you were careful about those duplications. > +pmaxsw

[FFmpeg-devel] [PATCH 4/4] dnxhddec: parse and print adaptive color transform

Indicates a YCbCr->RGB transform at the block level. Although nothing explicitly states it, this would assume the actual content is planar RGB. Currently unsupported, but the one sequence I found using it flagged every mb that way, actually meaning the content was YCbCr, and thus best left to the

[FFmpeg-devel] [PATCH 3/4] dnxhddec: proper rule for interlaced mb flag

It currently only applies to CID 1260, but this flag is dependent on a higher-level flag located in the header. --- libavcodec/dnxhddec.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 0722aa0..82a0d3c 100644 ---

[FFmpeg-devel] [PATCH 1/4] dnxhddec: implement slice multithreading

Around 3x speedup with 4 threads. Maybe more mb lines should be batched per thread, but that's good enough for a first try. --- libavcodec/dnxhddec.c | 221 ++ 1 file changed, 133 insertions(+), 88 deletions(-) diff --git a/libavcodec/dnxhddec.c

[FFmpeg-devel] [PATCH 0/4] Misc dnxhd patches

there's actually change in the flag value, it is useless. It raises again the question of colorspace conversion in a codec when various libraries exist. Christophe Gisquet (4): dnxhddec: implement slice multithreading dnxhddec: indicate colorspace dnxhddec: proper rule for interlaced mb flag

[FFmpeg-devel] [PATCH 2/4] dnxhddec: indicate colorspace

It is supposed to only old BT.709 colorspaces. --- libavcodec/dnxhddec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index d9762e4..0722aa0 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -82,6 +82,7 @@ static av_cold int

[FFmpeg-devel] [PATCH 1/2] dnxhddec: decode and use interlace mb flag

This bit is 1 in some samples, and seems to coincide with interlaced mbs and CID1260. 2008 specs do not know about it, and maintain qscale is 11 bits. This looks oversized, but may help larger bitdepths. Currently, it leads to an obviously incorrect qscale value, meaning its syntax is shifted by

[FFmpeg-devel] [PATCH 2/2] dnxhddata: correct weight tables

orrect chroma table for CID 1256. Fixes last issue from ticket #4876. Found-by: Christophe Gisquet <christophe.gisq...@gmail.com> Signed-off-by: Christophe Gisquet <christophe.gisq...@gmail.com> --- libavcodec/dnxhddata.c | 103 +++-- 1 file chan

Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE

Hi, 2015-10-05 10:57 GMT+02:00 tim nicholson : > I thought JJ had got hold of a copy of the specs... He was quick to notice the 2014 ones do not cover DNxHR. But the bitstream doesn't seem to depart that much from the old stuff, and ffmpeg's output after this

Re: [FFmpeg-devel] [PATCH 9/9] dnxhdenc: fix scan used for bitstream generation

Hi, 2015-10-04 4:14 GMT+02:00 Michael Niedermayer : > ./ffmpeg -f lavfi -i testsrc=s=1440x1080 -vframes 1 -pix_fmt yuv422p -vcodec > dnxhd -vb 80M -flags +ildct file.mov btw this afaik uses CID 1260 which has a particular feature, MBAFF-like. While we do handle it since a few

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

Hi, 2015-12-16 4:24 GMT+01:00 James Almer : > Ping for patchset. I'll probably have a look on Sunday. But I don't expect my review to be very worthwhile, so several people can probably do a better and faster one. -- Christophe ___

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

Hi, 2016-01-06 18:32 GMT+01:00 foo86 : > dca dca2libdcadec > System 1: 0:11.90 0:11.16 0:19.73 > System 2: 0:57.00 0:55.23 1:21.33 > System 3: 7:41.31 7:00.84 13:16.70 Just to be sure, because I won't check myself: is

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

Hi, 2016-01-07 12:48 GMT+01:00 foo86 : > bench dca pcm_f32le > bench dca2 pcm_f32le > bench libdcadec pcm_s32le OK, that was mostly out of curiosity, as "dca2" has benefits surpassing such issues anyway. And the improvement is 10% for where it matters (raspberry).

Re: [FFmpeg-devel] [PATCH 2/2] swscale: add P010 input support

Hi, 2016-01-07 12:11 GMT+01:00 Hendrik Leppkes : > +static void p010LEToY_c(uint8_t *dst, const uint8_t *src, const uint8_t > *unused1, > +const uint8_t *unused2, int width, uint32_t *unused) > +{ > +int i; > +for (i = 0; i < width; i++) { > +

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

2016-01-08 17:41 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > On a side note, do you intend to do an avx version? Just did that, need a tail processing, and no gain on a(n) Haswell over a 7 minute sample. The code for reference, over your set of patches. -- Christop

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

Hi, 2016-01-08 20:16 GMT+01:00 James Almer : > Then honestly i don't think it's worth it. Maybe if we could change the > alignment to 32 bytes and making len multiple of 8 or 16, but not sure > how feasible is that. There could be a more specialized version, but of doubtful

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

Hi, 2015-12-16 4:24 GMT+01:00 James Almer : > On 12/10/2015 8:02 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/x86/hevc_sao_10bit.asm | 142 >> +++--- >> 1 file changed, 57 insertions(+), 85

Re: [FFmpeg-devel] IRC meeting

Hi, here's I think a list of things left to do. I remember saste doing it on some occasions. Please comment on whether you think I have pointed an actual action to perform. Don't mind the details for now, it's just to get the train going. 2016-05-30 10:49 GMT+02:00 Michael Niedermayer

Re: [FFmpeg-devel] IRC meeting

Hi, sorry if I'm or was confusing, I'm best-effort here. 2016-06-03 21:13 GMT+02:00 Michael Niedermayer : > > FOUR.TWO) [...] > i want some assistent to help with dayly server admin duties > most root admins we have help and contribute but are often busy > raz recently

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

Hi, 2016-05-29 21:51 GMT+02:00 Paul B Mahol : > +typedef struct Slice { > +uint32_t start; > +uint32_t size; > +} Slice; I'm not a security expert, but is there a reason for not using plain int there ? > +typedef struct MagicYUVContext { > +AVFrame*p; >

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

2016-05-30 17:50 GMT+02:00 Paul B Mahol : > On 5/30/16, Piotr Bandurski wrote: >> Hi, >> >>> patch attached. >> >> Is decoding of interlaced video supported? Because I get here invalid >> output. >> >> Also crash happens with this fuzzed file: >> >>

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

Hi, 2016-05-30 15:09 GMT+02:00 Paul B Mahol : Hi, 2016-05-30 15:09 GMT+02:00 Paul B Mahol : >> ffmpeg seems to have libavutil/qsort.h, but I don't even know how much >> effort is needed to use it here. > > Changed, doesn't help but maybe will for other archs.

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > -test lenq, lenq > -jz .end > shl lenq, 2 > add src0q, lenq > add src1q, lenq > @@ -377,5 +375,4 @@ cglobal butterflies_float, 3,3,3, src0, src1, len > mova[src0q + lenq], m0

Re: [FFmpeg-devel] [PATCH 2/3] x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly

Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > INIT_XMM sse > cglobal butterflies_float, 3,3,3, src0, src1, len > -%if ARCH_X86_64 > -movsxdlenq, lend > -%endif > -shl lenq, 2 > +shl lend, 2 All the more ok since, afaik, only WIN64 actually

Re: [FFmpeg-devel] [PATCH 3/3] x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse

Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > +shl offsetd, 2 > +add v1q, offsetq > +add v2q, offsetq > neg offsetq > -shl offsetq, 2 > -sub v1q, offsetq > -sub v2q, offsetq Lucky that we never had any crash then.

Re: [FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

> -#define YUVRGB_TABLE_HEADROOM 256 > +#define YUVRGB_TABLE_HEADROOM 512 [...] > -const int yoffs = fullRange ? 384 : 326; > +const int yoffs = fullRange ? 896 : 838; I think it's time to use that macro everywhere it is actually used without showing up. Best regards, Christophe

Re: [FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

Hi, 2016-01-14 9:41 GMT+01:00 Michael Niedermayer : > there are 2 seperate tables, the headroom in them also differs > curently, also the exact relation between input values and headroom > needed in the 2nd table depends on the yuv-rgb coefficients > > i can replace the

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

Hi, 2016-02-08 8:15 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > At this point, I'd say the encoder would better use that prefix. > That's what the attached patch does (rebased but not tested). You may > consider building on top of it for that purpose. Which I h

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

Hi, 2016-02-09 6:27 GMT+01:00 Mark Reid : [...] > I'm guessing its okay to > include "libavcodec/dnxhddata.h" in something thats in libavformat > then? movenc.c uses those prefixes too. Argh, nice catch, you can't use the the content of ff_dnxhd_headers there, which is the

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

Hi, 2016-02-08 2:31 GMT+01:00 Mark Reid : > +static int dnxhd_is_prefix(uint64_t prefix) > +{ > + if (prefix == DNXHD_HEADER_PREFIX|| > + prefix == DNXHD_HEADER_PREFIX444 || > + prefix == DNXHD_HEADER_PREFIXHR1 || > + prefix == DNXHD_HEADER_PREFIXHR2) > +

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

Hi, as a motus operandi for this review, I have no time for a proper one, or at least not fitting with John's timeframe. I'll try to close as many pending discussions, and would prefer if someone else completed the review/validation/commit. 2016-01-22 19:33 GMT+01:00 John Cox

Re: [FFmpeg-devel] [PATCH] x86/dcadec: add ff_lfe_fir1_float_{sse3, avx}

Hi, 2016-02-22 22:43 GMT+01:00 James Almer : > +.loop: > +%if cpuflag(avx) > +cvtdq2ps m4, [lfeq] > +shufpsm5, m4, m4, q0123 > +%elif cpuflag(sse2) > +movu m4, [lfeq] > +cvtdq2ps m4, m4 > +pshufdm5, m4, q0123 > +%endif > + > +.inner_loop: >

Re: [FFmpeg-devel] [PATCH] x86/dcadec: add ff_lfe_fir1_float_{sse3, avx}

Hi, > +.inner_loop: Given this precludes reusing m5, then I don't have anything more to comment, and seems ok. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

Hi, 2016-01-20 15:27 GMT+01:00 John Cox : > The by22 code gained me an overall factor of two in the abs level decode > - the gains do depend a lot on the quantity of residual - you gain a lot > more on I-frames than you do otherwise as they tend to have much longer >

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

Hi, 2016-01-19 13:46 GMT+01:00 John Cox : > I've just done a fair bit of work on hevc_cabac decode for the Rasberry > Pi2 and I think that the patch is generally applicable. Patch is > attached but you may prefer to take it from git: This work is certainly impressive, and

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

Hi, 2016-01-22 14:29 GMT+01:00 John Cox : >>This is a big slowdown on Win64 and UHD-bluray like sequences, but >>that can be switched off in that case. > > I'm a bit surprised that it generated a big slowdown - some cache must > be running just on the edge, but yes if you

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

Hi, 2016-01-21 11:45 GMT+01:00 John Cox : > Hi > > v2 of my hevc residual patch I'll review the bit not related to significant coeffs first, because I think it is the most performance-sensitive. Also there are bits that could be moved to other patches, at least some are

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

Hi, 2016-02-14 0:43 GMT+01:00 Michael Niedermayer : > i can test and commit the code, it seems everyone who wanted to > comment did comment Yes, nothing really worth postponing the patchset from my side, except maybe cleaner splitting of the bypass stuff, as agreed by the

Re: [FFmpeg-devel] [PATCH] x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format

Hi, 2016-02-14 6:49 GMT+01:00 Timothy Gu : > %if HAVE_MMX_INLINE Isn't that macro meant for C code (and in config.asm without much of a purpose)? I suspect it is not useful, but I haven't dug into that. > +; XXX some of these macros are not used right now, but they will

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

Hi, 2016-03-10 19:57 GMT+01:00 Hendrik Leppkes : > This patch (the relocations part) broke debugging mingw-w64 ffmpeg > builds with gdb, you can't set breakpoints anymore when its applied. That issue prevented me to do anything interesting for ffmpeg since then, thinking it

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

Hi, 2016-03-11 8:57 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: >> It should either be reverted or made dependent on >> --enable/disable-debug (I would favor the first, honestly, since its a >> rather ugly hack in itself). > > At the very least,

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

Hi, 2016-03-19 19:08 GMT+01:00 Ismail Donmez <ism...@i10z.com>: >> 2016-03-11 8:57 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: >>>> It should either be reverted or made dependent on >>>> --enable/disable-debug (I would favor the first, h

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

ophe From 87e4f2a42bdb5f733d104ffba7cf70f786b72a03 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christophe.gisq...@gmail.com> Date: Sat, 19 Mar 2016 14:45:23 +0100 Subject: [PATCH] mingw64: configure: disable pie with debug enabled This breaks use of gdb. --- configure | 8 ++-- 1 file changed, 6 insertions(

Re: [FFmpeg-devel] [PATCH] avcodec/wmalosslessdec: real 24bit support

Hi, 2016-04-12 22:53 GMT+02:00 Paul B Mahol : > -LLAudDSPContext dsp; ///< accelerated And later: > +static int scalarproduct_and_madd_int(int *v1, const int *v2, > + const int *v3, > +

Re: [FFmpeg-devel] [PATCH 0/6] wmalossless: fix 16bits speed regression

2016-04-29 10:50 GMT+02:00 Paul B Mahol : > Should be OK if it doesn't break anything. I'll resend the current state of this patchset for easier testing & applying. Michael ran this under valgrind with nothing popping up, and fate passes. I think the remaining thing is: is the

[FFmpeg-devel] [PATCH 0/5] wmalossless: fix 16bits speed regression v2

Patch 2 is the squashing of several previous commits, as there were no opinion on their contents nor the way to go. The SSE4 one is the final version from its last thread. The last patch in this set is new, and silences a warning that's only meaningful for 16bits content. Christophe Gisquet (5

[FFmpeg-devel] [PATCH 2/5] wmalossless: allow calling madd_int16

This is done by actually handling the cascaded LMS data as if it were int16_t, thus requiring switching at various locations the computations. --- libavcodec/wmalosslessdec.c | 146 +--- 1 file changed, 84 insertions(+), 62 deletions(-) diff --git

[FFmpeg-devel] [PATCH 1/5] fate: wma: add lossless 24bits test

--- tests/fate/lossless-audio.mak | 5 - tests/ref/fate/lossless-wma24-1 | 1 + tests/ref/fate/lossless-wma24-2 | 1 + 3 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/lossless-wma24-1 create mode 100644 tests/ref/fate/lossless-wma24-2 diff --git

[FFmpeg-devel] [PATCH 5/5] wmalossless: silence a sample request

16bits samples with CDLMS orders of 8 are currently unsupported, but have never been encountered before. However, 8 seems to be the most frequent, if not the only order used for 24bits. In that case, the dsp functions are fine with handling order that are multiples of 8, so silence the warning.

[FFmpeg-devel] [PATCH 3/5] x86: lossless audio: SSE4 madd 32bits

The unique user so far is wmalossless 24bits. The few samples tested show an order of 8, so more unrolling or an avx2 version do not make sense. Timings: 72 -> 49 cycles --- libavcodec/x86/lossless_audiodsp.asm| 31 +-- libavcodec/x86/lossless_audiodsp_init.c | 7

[FFmpeg-devel] [PATCH 4/5] lossless audio dsp: unroll

The loops are guaranteed to be at least multiples of 8, so this unrolling is safe but allows exploiting execution ports. For int32 version: 72 -> 57c. --- libavcodec/lossless_audiodsp.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

Hi, 2016-05-20 1:55 GMT+02:00 Lukasz Marek : > Is Derek revoked to commit or what? Couldn't he just commit this patch and > leave? :P I was a problem for some people, but I see they still have > problems. Let people with problems go away with they problems. Sorry if

Re: [FFmpeg-devel] [Vote] Code of Conduct

Hi, 2016-05-18 20:40 GMT+02:00 Michael Niedermayer : > Please state clearly if you agree to the text or if not. > we can extend and tune it later and do another vote if there are more > suggestions I agree to having a CoC. This text is a first step, so I'm ok with it,

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

Hi, 2016-05-20 2:38 GMT+02:00 Timothy Gu : >> > Note how it has a list of specific violations, instead of vague things like >> > "Be excellent" that the FFmpeg one has. >> > Note how it has a huge section on disciplinary procedures. [...] > I have to agree with Kieran here.

Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit

2016-05-13 11:48 GMT+02:00 foo86 : > -unsigned int v = get_unary(gb, 1, 128); > +unsigned int v = get_unary(gb, 1, get_bits_left(gb)); Not that the patch is not ok, but I have a few uneducated questions: 1) Given the get_bits_long(gb, k) afterwards, won't that code

Re: [FFmpeg-devel] [PATCH 4/4] lossless audio dsp: unroll

2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > The loops are guaranteed to be at least multiples of 8, so this > unrolling is safe but allows exploiting execution ports. > > For int32 version: 68 -> 58c. Ping? This was ok'ed by James irr

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

Hi, 2016-05-03 19:24 GMT+02:00 Hendrik Leppkes : >> +// The reference decoder ignores it, and its typical length is 0 >> +memset(put_bits_ptr(pb), 0, s->prefix_bytes); >> skip_put_bytes(pb, s->prefix_bytes); >> + > > I don't suppose we have a function to just

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

Le 3 mai 2016 22:15, "Rostislav Pehlivanov" <atomnu...@gmail.com> a écrit : > > On 3 May 2016 at 19:16, Christophe Gisquet <christophe.gisq...@gmail.com> > wrote: > > > > > > Btw, afaik, the padding is 0xFF, so expecting 0 in the buffer there &g

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

Hi, 2016-05-02 16:02 GMT+02:00 Michael Niedermayer : >> +fate-lossless-wma24-rawtile: CMD = md5 -i >> $(TARGET_SAMPLES)/lossless-audio/g2_24bit.wma -f s24le > > where can i find that file ? > i assume i should upload it ? Sorry, I thought we had discussed it in this

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

h raw pcm tiles then. -- Christophe From 584999fcce24585f989d2dc770e8c7c85aa19db7 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christophe.gisq...@gmail.com> Date: Mon, 18 Apr 2016 12:53:21 +0200 Subject: [PATCH 1/4] fate: wma: add lossless 24bits tests Should evaluate coefficients and raw pcm t

Re: [FFmpeg-devel] [PATCH 2/4] wmalossless: allow calling madd_int16

2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > This is done by actually handling the "prev_values" in the cascaded LMS data > as if it were int16_t, thus requiring switching at various locations the > computations. Patch update s

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

Hi, 2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > +fate-lossless-wma24-2: CMD = md5 -i > $(TARGET_SAMPLES)/lossless-audio/Mega_Weird_Audio_Test_24bit.wma -f s24le The recent fixes actually changed the crc for that file. Is https://trac.ffmpeg.or

[FFmpeg-devel] [PATCH 2/4] wmalossless: allow calling madd_int16

This is done by actually handling the "prev_values" in the cascaded LMS data as if it were int16_t, thus requiring switching at various locations the computations. --- libavcodec/wmalosslessdec.c | 109 +++- 1 file changed, 58 insertions(+), 51 deletions(-)

[FFmpeg-devel] [PATCH 3/4] x86: lossless audio: SSE4 madd 32bits

The unique user so far is wmalossless 24bits. The few samples tested show an order of 8, so more unrolling or an avx2 version do not make sense. Timings: 68 -> 49 cycles --- libavcodec/x86/lossless_audiodsp.asm| 33 + libavcodec/x86/lossless_audiodsp_init.c |

[FFmpeg-devel] [PATCH 0/4] wmalossless: fix 16bits speed regression v3

Due to the changes to the cascaded LMS coefficients, most of the code needed a rewrite. In particular, the SSE4 madd32 code is no longer that similar to be shared inside a macro. Christophe Gisquet (4): fate: wma: add lossless 24bits test wmalossless: allow calling madd_int16 x86: lossless

[FFmpeg-devel] [PATCH 4/4] lossless audio dsp: unroll

The loops are guaranteed to be at least multiples of 8, so this unrolling is safe but allows exploiting execution ports. For int32 version: 68 -> 58c. --- libavcodec/lossless_audiodsp.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[FFmpeg-devel] [PATCH 2/2] vc2: fate tests

--- tests/fate/vcodec.mak | 17 - tests/ref/vsynth/vsynth1-vc2-420p | 4 tests/ref/vsynth/vsynth1-vc2-420p10 | 4 tests/ref/vsynth/vsynth1-vc2-420p12 | 4 tests/ref/vsynth/vsynth1-vc2-422p | 4

[FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

The slice prefix is 0 in the reference encoder and the decoder ignores it. Writing 0 there seems like the best temporary solution. The padding could have contained uninitialized data, but reference VC2 encoders put 0xFF there, hence the memset value. Overall this allows producing bistreams with

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

Hi, 2016-05-06 2:19 GMT+02:00 Rostislav Pehlivanov : > I plan to merge the fate tests as well tomorrow or on Saturday when I'll > have time to quickly fix bugs which appear on platforms I haven't tested > the encoder on. Hopefully none, but you never know. Sure, makes sense.

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

Hi, 2016-05-04 3:06 GMT+02:00 Rostislav Pehlivanov : > vc2hqencode is not the reference encoder, vc2-reference is. It's even worse > though. Sorry, I thought authoritative could mean "from the authors", so I didn't mean it as "the" reference/"the authority". Just a good

[FFmpeg-devel] [PATCH 2/2] vc2: fate tests

--- tests/fate/vcodec.mak | 17 - tests/ref/vsynth/vsynth1-vc2-420p | 4 tests/ref/vsynth/vsynth1-vc2-420p10 | 4 tests/ref/vsynth/vsynth1-vc2-420p12 | 4 tests/ref/vsynth/vsynth1-vc2-422p | 4

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-03 19:06 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > +memset(pb->buf_ptr, 0, pad_c); Commit squashing fail, attached patch should fix that. This unfortunately requires updating the fate tests as I generated them from this squashing. -- Chr

Re: [FFmpeg-devel] [PATCH 2/2] vc2: fate tests

2016-05-03 19:06 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: [SNIP] Incorrect padding used (0 instead of 0xFF), fixed in that patch series. -- Christophe From 22ff25711062fb1ca30da1674fd622fd6f81c8e3 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christ

[FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

The slice prefix is 0 in the reference encoder and the decoder ignores it. Writing 0 there seems like the best temporary solution. The padding could have contained uninitialized data, but its standardized value is 0xFF, hence the memset value. Overall this allows producing bistreams with no

<    1   2   3   4   5   6   >