Hi,
the goal is to have av_dlog output something for the recompiled files.
How are you doing it? I edit config.mak but when eg rebasing and
recompiling, this may cause a lot of files to have av_dlog active and
cause massive spamage.
If it's not easy, could it be something like:
rm the object
Hi,
2014-08-20 12:19 GMT+02:00 Michael Niedermayer michae...@gmx.at:
iam happy with either, just please dont do and post both solutions
as then i cannot apply either as i have to expect libav to apply
the other causing conflicts
To summarize without aggravating anyone: I don't think I can
Hi,
2014-08-20 17:36 GMT+02:00 James Almer jamr...@gmail.com:
Does avx = ARCH_X86_64 (didn't know) ? Otherwise the reg count seems
fine, meaning the condition is unneeded.
No, AVX does not imply x86_64. The reg count for these is currently 12 xmm
regs,
meaning x86_64 only.
I'll send a
Hi,
2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos ceho...@ag.or.at:
Christophe Gisquet christophe.gisquet at gmail.com writes:
Depending on the input and/or filters, you sometime
have an input or output pixel format like rgb48le(12
bpc). Unfortunately, most often, the 12 bpc
information
---
tests/fate/vcodec.mak| 4 +++-
tests/ref/vsynth/vsynth1-huffyuvbgra | 4
tests/ref/vsynth/vsynth2-huffyuvbgra | 4
tests/ref/vsynth/vsynth3-huffyuvbgra | 4
4 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/vsynth/vsynth1-huffyuvbgra
Commit deadcf5e broke it, and fate didn't catch it.
Christophe Gisquet (2):
fate: add test for old (v1) huffyuv and rgba
huffyuvdec: fix old (v1) rgba
libavcodec/huffyuvdec.c | 17 -
tests/fate/vcodec.mak| 4 +++-
tests/ref/vsynth/vsynth1
Commit deadcf5e misplaced a hunk.
Fixes ticket #3877.
---
libavcodec/huffyuvdec.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e4e5ea0..bc5ad15 100644
--- a/libavcodec/huffyuvdec.c
+++
to swallow the error.
--
Christophe
From dacdd50379af1bcb3dab2ce813124cfc577adace Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Thu, 21 Aug 2014 12:59:10 +0200
Subject: [PATCH] mov: better check dref atome validity
The size of each entry helps determining
Hi,
2014-08-21 14:55 GMT+02:00 Derek Buitenhuis derek.buitenh...@gmail.com:
On 8/21/2014 12:09 PM, Christophe Gisquet wrote:
I'm not sure it is the best fix, but I don't think this could happen
in any valid file, nor it would help to swallow the error.
Perhaps off-topic, but the source drop
2014-08-21 17:43 GMT+02:00 Michael Niedermayer michae...@gmx.at:
static int mov_skip_multiple_stsd(MOVContext *c, AVIOContext *pb,
int codec_tag, int format,
- int size)
+ int64_t size)
Nice
:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Thu, 21 Aug 2014 18:57:18 +0200
Subject: [PATCH] hevc_ps: check overflow and test alternate syntax
Some streams were found to have what appeared to be truncated SPS.
Their syntax seem to be valid at least until the end of the VUI
Hi,
2014-08-21 0:42 GMT+02:00 James Almer jamr...@gmail.com:
* Reduced xmm register count to 7 (As such they are now enabled for x86_32).
* Removed four movdqa (affects the sse2 version only).
* pxor is now used to clear m0 only once.
OK.
--
Christophe
Hi,
2014-08-09 2:45 GMT+02:00 Kieran Kunhya kier...@obe.tv:
+AVFrameSideData *sd =
+av_frame_new_side_data(cur-f,
+ AV_FRAME_DATA_AFD, 1);
+if (!sd)
+return;
You're not responsible for what has already been committed
Another batch of different issues.
Christophe Gisquet (4):
wavpackenc: fix number of samples per block
wavpackenc: make assert more thorough
wavpack: check number of channels
wavpackenc: reset trailer info on block encoding
libavcodec/wavpack.c| 5 -
libavcodec/wavpackenc.c | 7
It was only validating that normal data wasn't filling the buffer.
However, extra data may be written afterwards.
---
libavcodec/wavpackenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 169836a..299a035 100644
---
This means container and codec disagree. The codec is supposed to
know better so this could be an error instead.
---
libavcodec/wavpack.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 9f72ebe..1ad3901 100644
---
In some cases, in particular if several blocks are needed because of
the channel layout (e.g. 2.1), the information used to write the
trailing bits terminating the sample data was not reset.
This would cause potential desync on the decoder, although decoded
samples were actually mostly fine.
Hi,
2014-08-22 1:21 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
Maybe all that side data stuff should be moved to the end of the
function first (but before the last thread-related line), and fixed,
then you also add this hunk there?
Not a good thing to do either, after
Hi,
following [PATCH] h264: Move AFD to side data to match MPEG-2, it
was mentioned making sidedata allocation failures non-fatal.
This patch is a proposal for this.
--
Christophe
From 7092da22cf0efbdb0988810bd30c279d18388fdc Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq
, but
it is vastly simpler to modify the above cases to not use pextrw.
This is done in 2 steps:
- Fix width of 12 to do 8+4 instead of 6+6;
- Modify the store macros for width 2 and 6 by passing data through
a GPR (alas at the cost for some functions of a supplementary GPR).
Christophe Gisquet (2):
x86
In some cases, 2 or 3 calls are performed to functions for unusual
widths. Instead, perform 2 calls for different widths to split the
workload.
The 8+16 and 4+8 widths for respectively 8 and more than 8 bits can't
be processed that way without modifications: some calls use unaligned
buffers, and
Hi,
2014-08-23 17:01 GMT+02:00 James Almer jamr...@gmail.com:
There's a PACK macro in lavfi/x86/yasm-16.asm that does this without
intrinsics.
You meant yadif-16, right?
Timothy
Oops, yes i meant that :P
I expect it to be needed for the weighted pred functions, so I'll
split it from
Hi,
2014-08-23 17:16 GMT+02:00 James Almer jamr...@gmail.com:
What do you mean by duplicated? That tables for 10 and 12 are?
[...]
I was talking about the opt suffix since both the ssse3 and sse4 tables will
be the same.
Oh ok, in case we have to instantiate sse4 versions. Because at the
Hi,
2014-08-23 17:48 GMT+02:00 Mickaël Raulet mrau...@gmail.com:
For avx2 I have some to push to the trunk, I did merge it yesterday with
all recent changes. But I don t remember what those tables looks like.
Well, my point was hypothetical, but I guess this means some conflicts
are to be
The only sse4 instruction is pextrw, which is used on rather minor
functions for small blocks. Therefore use whichever GPR is available
to extract the output word.
Before (sse4), for block_w == 6:
4627 decicycles in epel_uni, 16377 runs, 7 skips
7422 decicycles in epel_bi, 65501 runs, 35 skips
---
libavcodec/x86/hevc_mc.asm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index e2236ec..9ce6bd1 100644
--- a/libavcodec/x86/hevc_mc.asm
+++ b/libavcodec/x86/hevc_mc.asm
@@ -890,7 +890,7 @@ cglobal
Hi,
2014-08-24 12:13 GMT+02:00 Carl Eugen Hoyos ceho...@ag.or.at:
[...]
-if( avctx-bits_per_raw_sample )
+if ( avctx-bits_per_raw_sample
+ av_pix_fmt_desc_get(avctx-pix_fmt)-comp[0].depth_minus1 7)
maxdepth = (1 avctx-bits_per_raw_sample) - 1;
So
codecs
(dpx comes to mind) would have to implement it, up to getting it
slightly wrong.
2014-08-24 13:25 GMT+02:00 Carl Eugen Hoyos ceho...@ag.or.at:
Christophe Gisquet christophe.gisquet at gmail.com writes:
ljpeg 36bits from #2966 and having the actual
bits_per_raw_sample value
The sample
Hi,
2014-08-25 6:41 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
The colorspace is supposed to be authoritative.
If it says 16 bit, then showing it as 16 bit must work properly.
The only intention of bits_per_raw_sample is to indicate that there is no
point in storing some of the
, which are atypical for YUV 4:2:0. It
might be a resampling bug.
Christophe Gisquet (3):
huffyuvenc: write last odd sample
huffyuvdec: decode the last odd sample
huffyuv: fix 34x34 checksums
libavcodec/huffyuvdec.c| 26 +++--
libavcodec/huffyuvenc.c
If width is odd, last sample wouldn't be written.
---
libavcodec/huffyuvenc.c | 61 +
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
index fd6f570..c7e69d5 100644
---
---
libavcodec/huffyuvdec.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index bc5ad15..1df77e0 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -660,11 +660,9 @@ static void
Hi,
2014-08-25 22:24 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
Now that the encoder and decoder have been fixed, the values changed,
and make more sense (eg the PSNR/std dev).
---
This patch lacks a fate:, and is actually for ffvhuff.
--
Christophe
From
Hi,
2014-08-24 12:21 GMT+02:00 Michael Niedermayer michae...@gmx.at:
On Sun, Aug 24, 2014 at 08:46:32AM +, Christophe Gisquet wrote:
---
libavcodec/x86/hevcdsp.h | 8 +++-
libavcodec/x86/hevcdsp_init.c | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
this seems
: Christophe Gisquet christophe.gisq...@gmail.com
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc_ks: allow auto-selecting profile
The user may not know how to select the profile, nor what he needs, in
particular to encode alpha.
Therefore, use an automatic selection as default, and warn
Hi,
Le 5 sept. 2014 00:14, James Darnley james.darn...@gmail.com a écrit :
I think I tested the same patch and for some reason it incorrectly flagged
packusdw in a macro in this tree:
https://github.com/kurosu/ffmpeg/tree/hevc_mt
I haven't yet had time to investigate where the problem is.
2014-09-06 12:40 GMT+02:00 Michael Niedermayer michae...@gmx.at:
-// Backup context in case an alternate header is detected
-if( get_bits_left(gb) = 66)
-memcpy(backup, gb, sizeof(backup));
+memcpy(backup, gb, sizeof(backup));
I know people consider obvious comments to
Justin Ruggles noticed some issues which are fixed in the following patches.
Christophe Gisquet (2):
alacenc: fix incorrect buffer use
alacenc: remove unneeded masking
libavcodec/alacenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.9.2.msysgit.0
The extra bits have already properly masked, so this was not doing anything.
---
libavcodec/alacenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index fd5bf66..4e6113b 100644
--- a/libavcodec/alacenc.c
+++ b/libavcodec/alacenc.c
2014-09-20 20:23 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
The extra bits have already properly masked, so this was not doing anything.
have already *been* masked. If the patch is ok, please amend locally.
Best regards,
Christophe
They have little to no benefit (none speedwise) and could be altogether
dropped. I'm still submitting them to give them a chance before that.
Christophe Gisquet (4):
hevc: remove unneeded buffer.
hevc: remove CodingTree
hevc: move intermediate bidir buffer
hevc: reuse edge emu buffer
---
libavcodec/hevc.c | 4 ++--
libavcodec/hevc.h | 6 +-
libavcodec/hevc_cabac.c | 2 +-
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 9317d93..4e9948f 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2107,7
---
libavcodec/hevc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 0369d8f..980d95f 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -746,7 +746,6 @@ typedef struct HEVCNAL {
} HEVCNAL;
typedef struct HEVCLocalContext {
-
Other buffers are already there.
---
libavcodec/hevc.c | 14 ++
libavcodec/hevc.h | 1 +
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 4e9948f..4860aec 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1328,7
Kind of hackish but...
---
libavcodec/hevc.c | 8
libavcodec/hevc.h | 1 -
libavcodec/hevc_cabac.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 4860aec..934abd1 100644
--- a/libavcodec/hevc.c
+++
2014-09-23 23:36 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
Other buffers are already there.
Note: if this is not applied, I think tmp should use some variant of
LOCAL_ALIGNED_16 (or 32 once avx2 gets here).
The edge_emu_buffers are big (more than 22K), but I'm not sure what
On Win64:
Before: 155576b
64765 decicycles in qpel_bi_w, 8185 runs, 7 skips
13676 decicycles in epel_bi_w, 16378 runs, 6 skips
54402 decicycles in qpel_uni_w, 1023 runs, 1 skips
12328 decicycles in epel_uni_w, 2048 runs, 0 skips
After: 94260b
65037 decicycles in qpel_bi_w, 8185 runs, 7 skips
Most functions were actually instanciated and unrolled, causing an increase
in object size.
On Win64, before: stripped object size 185404
36248 decicycles in qpel, 522688 runs, 1600 skips
39808 decicycles in qpel bi, 522920 runs, 1368 skips
6997 decicycles in epel, 1037753 runs, 10823 skips
8042
Hi,
2014-10-03 19:36 GMT+02:00 James Almer jamr...@gmail.com:
When i first tried to tackle the libswresample asm to reduce the overall
object size, the general reaction was that speed is more important than
size.
Wasn't the trade-off much worse there? (the impact here is around 1%)
Adding
Fixes ticket #3949.
--
Christophe
From 9bcaac9495d41b633010873d50ea0b7e01d9a9a4 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Thu, 9 Oct 2014 23:27:38 +0200
Subject: [PATCH] utvideoenc: properly set slice height/last line
Mimic decoder and obey sampling
the profile.
--
Christophe
From 36e0b104b303d2d9f3793d5734ddcc319eee3c2e Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Sat, 30 Aug 2014 15:04:03 +0200
Subject: [PATCH] proresenc_ks: use chroma sampling in autoselection
If the chroma planes aren't subsampled
for lzw code expansion.
--
Christophe
From 9ec9a913fbfc6238de915c360df2324c309636fb Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Sun, 12 Oct 2014 21:10:54 +0200
Subject: [PATCH] tiffenc: properly compute packet size
The bytes per row is a better indication
This is a mostly cosmetical patch in preparation for the following.
---
libavcodec/dv.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index 4b23f2a..e1e5dd9 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -186,7
is moved to the
decoder.
Christophe Gisquet (6):
dv: better split weight tables assignment
dv: use smaller type for weight tables
dv: more precise weight table for 8x8
dv: fix weight table for 2x4x8 transform
dv: increase reading bits to 10
dv: move inverse weight tables to decoder
---
libavcodec/dv.c | 4 ++--
libavcodec/dvdata.c | 12 ++--
libavcodec/dvdata.h | 12 ++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index e1e5dd9..1f04861 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -206,7
The coefficients must be in the appropriate zigzag scan order.
Also fix their values at the same time, as they were pretty wrong.
Fixes ticket #2970.
---
libavcodec/dvdata.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dvdata.c
From 356 to 348 cycles.
---
libavcodec/dv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 8a54cfe..3065806 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -90,7 +90,7 @@ enum dv_pack_type {
*/
#define DV_MAX_BPM 8
-#define
It is derived from the actual equations of the specs. In
particular, it is closer to the inverse of what the encoder uses.
fate tests accordingly updated.
---
libavcodec/dvdata.c | 16
tests/ref/lavf/dv_fmt | 6 +++---
tests/ref/vsynth/vsynth1-dv | 2
The encoder has its own tables and does not access the idct_factor
member of the DVVideoContext structure.
---
libavcodec/dv.c | 34
libavcodec/dv.h | 1 +
libavcodec/dvdata.c | 65 --
libavcodec/dvdata.h | 7
libavcodec/dvdec.c |
2014-10-25 13:19 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
Patch #3 uses mathematically more correct values, which happens to match
another dv implementation (cedocida). It does not seem to affect that
much the decoded output, as there is PSNR variations on the 3rd decimal
2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
Could you maybe add e.g. a FATE test that clearly shows the before-after
improvements?
I've tried for a small while, by swapping fields on lena and converting to
yuv42[02]p and feeding it to ffmpeg with:
-pix_fmt yuv422p -s
Hi,
2014-10-25 18:25 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote:
2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
Could you maybe add e.g. a FATE test that clearly shows the before-after
assert does not trigger here, because it is not
compiled in. Strangely I had no fate failures. Probably the tests do
not exercise some of the vlcs.
Here's an updated patch.
--
Christophe
From 8d1905d01f2974559780a6b3aac3ecd6945f7897 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq
-dv-50 fate- seek-vsynth2-dv-411
The encoder already supported slice (actually segment) threading.
--
Christophe
From b1f2ee04b003216a496c124f895da246ef4f69e9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Wed, 15 Oct 2014 18:37:34 +0200
Subject: [PATCH 2/2
Hi,
2014-10-25 20:32 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
What I meant is I would need someone to:
1) provide a command line to swap fields to produce an artificially
interlaced image
2) confirm that -flags ildct sets CODEC_FLAG_INTERLACED_DCT and does
what is needed
Hi,
2014-10-25 13:29 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
Maybe as a patch that puts it into tools?
I don't know if that's the right place, but I would kind of prefer to
have these kind of things around.
Probably overkill, but we have libavcodec/tableprint.h that has helpers
Hi,
2014-11-06 21:48 GMT+01:00 James Almer jamr...@gmail.com:
13797 decicycles in ff_float_to_int32_a_sse2, 32768 runs, 0 skips
8603 decicycles in ff_float_to_int32_a_avx2, 32766 runs, 2 skips
A couple of naïve questions (I haven't checked):
Does it increase the alignment requirement?
If yes,
Hi,
2014-11-06 23:04 GMT+01:00 James Almer jamr...@gmail.com:
No, the function checks for alignment and jumps to a branch that uses movdqu
if needed.
ff_int32_to_float_a_avx also uses ymm regs and this same macro.
OK, so nothing new here, same 32-bytes alignment.
when mulps m0, m1, [mem]
the specs.
Christophe Gisquet (4):
h264_ps: move and export aspect_ratio
h264_changesps_bsf: fix compilation
h264_changesps_bsf: add and use init
h264_changesps_bsf: allow specifying full cropping
Zongyi Zhou (2):
bitstream_filter: add an init function
h264_changesps_bsf: import code
Needed for filters that may need it, like an SPS bsf.
---
libavcodec/h264_ps.c | 26 +++---
libavcodec/h264data.h | 19 +++
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 2013670..4070490
---
libavcodec/h264_changesps_bsf.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/libavcodec/h264_changesps_bsf.c b/libavcodec/h264_changesps_bsf.c
index 5daea89..a166748 100644
--- a/libavcodec/h264_changesps_bsf.c
+++
--- a/libavcodec/h264_changesps_bsf.c
+++ b/libavcodec/h264_changesps_bsf.c
@@ -1,6 +1,7 @@
/*
* H.264 change sps filter
* Copyright (c) 2010 Zongyi Zhou zho...@os.pku.edu.cn
+ * Copyright (c) 2014 Christophe Gisquet christophe.gisq...@gmail.com
*
* This file is part of FFmpeg.
*
@@ -35,15 +36,16
Hi,
2014-11-30 4:08 GMT+01:00 Michael Niedermayer michae...@gmx.at:
this breaks ABI/API
why is what is done in init not just done in the first packet when
the args are already available ?
This seems simpler and would avoid introducing a API that is possibly
going to be deprecated once a
Hi,
2014-11-30 2:11 GMT+01:00 Carl Eugen Hoyos ceho...@ag.or.at:
Christophe Gisquet christophe.gisquet at gmail.com writes:
libavcodec/h264_changesps_bsf.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
Please merge this into the earlier patch
Hi,
2014-11-30 1:45 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
From: Zongyi Zhou zho...@os.pku.edu.cn
Mostly unverified, but seems to have been extensively tested here:
http://forum.doom9.org/showthread.php?t=152419
For the record, I don't think I'm making a good argument
2014-11-30 10:59 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
So I'm going to add a AVDictionary *bsf_args to OutputStream.
That dictionary lookup seems negligible to the amount of work done overall.
Done in the attached patch. I've edited the documentation also to
reflect
Hi,
2014-11-30 10:29 GMT+01:00 Carl Eugen Hoyos ceho...@ag.or.at:
I completely agree and would only squash this one
(because it fixes compilationn) but not the next
one (that wasn't written by the original author).
Agreed, dropping that patch and squashing with the import patch.
--
2014-11-30 1:45 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
From: Zongyi Zhou zho...@os.pku.edu.cn
Squashed and updated patch attached.
From a49425e6af4e3e488c390d94d8f86c5d1745dda3 Mon Sep 17 00:00:00 2001
From: Zongyi Zhou zho...@os.pku.edu.cn
Date: Sat, 29 Nov 2014 15:04:37
Hi,
2014-11-30 12:11 GMT+01:00 Michael Niedermayer michae...@gmx.at:
This very slightly improves quality at the expense of 96kb more memory for
tables
I'm not concerned by this case, but maybe put that under CONFIG_SMALL
or something related?
Also, out of curiosity rather than concern:
2014-11-30 13:03 GMT+01:00 Michael Niedermayer michae...@gmx.at:
not really, no,
that was also why i posted a patch for this, i wasnt sure this is
worth the extra table size
No strong opinion here, I don't think the increased memory/potential
speed impact are critical, in particular for this
Hi,
now that we can pass bsf arguments through the command-line, it's
worth updating the documentation for it.
--
Christophe
From 4cd13dd05bb654ee311109c7289155ca82be5121 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Sun, 30 Nov 2014 11:59:22 +0100
Subject
Hi,
2014-12-02 13:51 GMT+01:00 Benoit Fouet benoit.fo...@free.fr:
Signed-off-by: Christophe Gisquet christophe.gisq...@gmail.com
Signed-off-by: Benoit Fouet benoit.fo...@gmail.com
While I suggested that the change be written like this, I didn't think
long about that specific code, and overall
76ddca41e1f4ab4df348b64ddbf63c58153c8c50 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Tue, 2 Dec 2014 14:31:49 +0100
Subject: [PATCH] pngdsp x86: use unaligned access
For test images manually generated to contain onlu up prediction,
timing results:
8380x3032255x185
)
cw_len, but the next parsing step, inverse_quant_coeff, does not even
check what's left.
--
Christophe
From 90b5642bd53b24f66f1c36c070b4c490dd72a6cf Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Wed, 3 Dec 2014 23:52:52 +0100
Subject: [PATCH] imc: make issue non
Hi,
2014-12-05 1:20 GMT+01:00 Dominique Leroux dominique.ler...@autodesk.com:
Found and fixed an artifact in the last column of decoded RGBA 64-bits PNG
images.
The code was dealing with a SIMD-optimized version of the function without
taking into account that we can have RGB/RGBA images
Hi,
2014-12-10 8:11 GMT+01:00 Michael Niedermayer michae...@gmx.at:
These fix failures of --enable-xmm-clobber-test
Some old patches around the ml were I think trying to fix some of the
macros, from where the superfluous regs are coming from.
I guess being thorough with the ABI is better,
Hi,
2014-12-13 13:17 GMT+01:00 Michael Niedermayer michae...@gmx.at:
i remember such patches faintly too, was there one that wasnt
applied ?
Not your fault, mine actually, as I lost interest in that code. I
think there were compilations issues iirc. That and multiple things
(like gpr usage)
Hi,
Le 19 déc. 2014 07:28, Titov, Alexey alexey.ti...@amd.com a écrit :
Hi Michael,
Here is the patch. I attached a zip of this patch in the last email, but
it was probably stripped off.
Let me know how I can help.
[...]
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index
Hi,
2015-02-04 6:13 GMT+01:00 Michael Niedermayer michae...@gmx.at:
On Wed, Feb 04, 2015 at 12:55:48AM -0300, James Almer wrote:
From: Seppo Tomperi seppo.tomp...@vtt.fi
---
libavcodec/hevc_filter.c | 3 ++-
libavcodec/hevcdsp.c | 5 +++--
libavcodec/hevcdsp.h |
Hi,
2015-02-04 4:55 GMT+01:00 James Almer jamr...@gmail.com:
[...]
Ok, no need to resend a refreshed patch if patch 2/6 changes.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
2015-02-04 21:14 GMT+01:00 James Almer jamr...@gmail.com:
On 04/02/15 9:39 AM, Christophe Gisquet wrote:
Are the first number for each case from before you split out the
restore part? Otherwise, that's gruesome.
The benchmarks were done with every patch up to this one applied, so yes
Hi,
2015-02-04 2:05 GMT+01:00 Michael Niedermayer michae...@gmx.at:
applied the cherry picked code and the update
James mentioned this issue:
http://fate.ffmpeg.org/report.cgi?time=20150205015545slot=x86_64-archlinux-gcc-valgrindundef
This looks like a missing free:
==15442==at 0x4C2C526:
: [PATCH] x86: hevc_mc: remove non necessary moves
Signed-off-by: Christophe Gisquet christophe.gisq...@gmail.com
---
libavcodec/x86/hevc_mc.asm | 48 +-
1 file changed, 18 insertions(+), 30 deletions(-)
diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec
Hi,
2015-02-02 13:32 GMT+01:00 Michael Niedermayer michae...@gmx.at:
On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
hmm, is there a reason not to take the original commit unchanged ?
I was hoping to reduce the difference to openhevc so that we also
are able to merge
Hi,
2015-02-06 1:28 GMT+01:00 James Almer jamr...@gmail.com:
Many (But not all) of the functions calling these macros have free regs where
max_pixels_%2
and zero (or in that case a simple pxor m*, m*) could be stored.
It'll probably be faster than reloading these constants inside a loop.
It may contain garbage at the end, and zeroing allows using DSP
with longer loops.
---
libavcodec/wmalosslessdec.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index e6e3476..557b6b9
Their intent was to make the DSP work with wmalossless pro.
The later was fixed to work with the DSP.
---
libavcodec/lossless_audiodsp.h | 3 ++-
libavcodec/x86/lossless_audiodsp_init.c | 26 ++
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git
wmalossless by having padded buffers, so as
to be able to use again 16-wide DSP, then restore the 16-wide
constrain in them.
Christophe Gisquet (2):
wmalossless: reset lms_update
lavc/lossless_audiodsp: revert various commits
libavcodec/lossless_audiodsp.h | 3 ++-
libavcodec
Hi,
2015-02-05 20:20 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
+%define pw_10 ff_pw_2048
Fixed in the attached patch.
--
Christophe
From 63a50c9fc6a053550d74435dd32ef6036b830f49 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Wed, 4 Feb
, as height is already loaded.
That's also why I didn't bother saving more gprs for the function that
already had =6 gprs used.
--
Christophe
From db70a07ccb2895a0aaadb49eef2acb7e0bedf4bb Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Thu, 5 Feb 2015 12:37:52 +0100
101 - 200 of 564 matches
Mail list logo
