The patch fixes overreads (and crashes) introduced in 3ad04608.
--
Christophe
From adfac6472b015e162988e2e2208e95cc87248be2 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sun, 10 Aug 2014 15:02:36 +0200
Subject: [PATCH] hevc_mvs: set candidate availabilities
They might be left
Hi,
the patch tries to validate these high-level syntax elements.
Unfortunately, it causes fuzzing to be less efficient, eg with the
sequence from ticket #3840 where no frame are decoded.
--
Christophe
From 6b60cf2968099fa4395e1e3120ab66d95d4c8709 Mon Sep 17 00:00:00 2001
From: Christophe
There are mostly issues (in order), potentially causing crashes:
- no check on the buffer left
- no reallocation when the buffer will overflow
- incorrect buffer size when encoding alpha
Christophe Gisquet (4):
proresenc_kostya: remove unneeded parameters
proresenc_kostya: report buffer
If the allocated size, despite best efforts, is too small, exit
with the appropriate error.
---
libavcodec/proresenc_kostya.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 24cb333..a70ae3c 1006
The buffer allocation may be incorrect (e.g. with an alpha plane),
and currently causes the buffer to be set to NULL by init_put_bits,
later on causing crashing.
So, detect that situation, and if detected, reallocate the buffer
and ask a sample if it happens.
Fixes ticket #2760
---
libavcodec/pr
The packet buffer allocation considered as dct-coded, while it is
actually run-coded and thus requires a larger buffer.
---
libavcodec/proresenc_kostya.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
---
libavcodec/proresenc_kostya.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 93bcde7..24cb333 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -471,7 +471,6 @@ static voi
Hi,
2014-08-12 2:34 GMT+02:00 Michael Niedermayer :
>> +if (pkt_size <= buf - orig_buf) {
>
> this isnt sufficient, there could be 1 byte space left, then the
> reallocate wouldnt run and encode_slice() would run into the extra
> padding and fail
Yeah, you're right. I have no idea
Hi,
2014-08-12 1:56 GMT+02:00 Michael Niedermayer :
>> - (2 + 2 * ctx->num_planes +
>> + (2 + 2 * FFMIN(3, ctx->num_planes) +
>
> slice_hdr_size is 2 + 2 * (ctx->num_planes - 1);
>
> is this difference intended ?
I don't know why
2014-08-12 7:56 GMT+02:00 Christophe Gisquet :
> Yeah, you're right. I have no idea how big a slice can be, as that
> seems the extra size check here. How about FF_MIN_BUFFER_SIZE ?
> Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?
Here's a patch for that,
Hi,
2014-08-12 8:10 GMT+02:00 Christophe Gisquet :
> Yeah, I'll drop it.
Done. Kostya suggested another rounding (the slice bitstreams are
byte-aligned), integrated in this patch.
--
Christophe
From 4e72ed146848b1d7b1804080f43b5d45484e3d94 Mon Sep 17 00:00:00 2001
From: Christophe
Hi,
2014-08-12 10:19 GMT+02:00 Michael Niedermayer :
> the "serious undersizing" check already depends on the assumtation
> that FF_MIN_BUFFER_SIZE is larger than a slice,
Yes, and here lies the issue: if we haven't been able to guess it
correctly previously, how likely are we to guess it correct
Hi,
2014-08-12 12:26 GMT+02:00 Michael Niedermayer :
> On Tue, Aug 12, 2014 at 11:56:21AM +0200, Christophe Gisquet wrote:
>> Hi,
>>
>> 2014-08-12 10:19 GMT+02:00 Michael Niedermayer :
>> > the "serious undersizing" check already depends on the assumtatio
Hi,
2014-08-12 12:38 GMT+02:00 Christophe Gisquet :
> I chose 2 times in the attached patch. I have no strong opinion on
> which solution is best, though reallocating was a specific request I
> got.
Forgot a parameter to the call to avpriv_request_sample, will be added later.
--
C
Hi,
2014-08-12 23:22 GMT+02:00 James Darnley :
> ---
> libavcodec/flacdsp.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> index 272cf2a..36cd904 100644
> --- a/libavcodec/flacdsp.h
> +++ b/libavcodec/flacdsp.h
> @
Hi,
the attached patch improves the decoding of ticket #3692 by following
S268M-2003.
Unfortunately, that probably means ffmpeg's dpx encoder is not
compliant to these specifications.
--
Christophe
From 4ba2ec15c9a111fb4e20523d5a8fa337bedee92d Mon Sep 17 00:00:00 2001
From: Christophe Gi
2014-08-13 9:48 GMT+02:00 Christophe Gisquet :
> Unfortunately, that probably means ffmpeg's dpx encoder is not
> compliant to these specifications.
And indeed the decoder is then no longer able to decode a file
produced by the encoder when number of bytes per line is not a
multiple of
Those fixes are intended around ticket #3692. The core of the issues is
that line starts must be aligned on a 4-byte boundary.
Christophe Gisquet (4):
dpx: use aligned line starts
dpxenc: enforce alignment requirement
dpx: abort if encrypted
dpx: fix endianess for RGB 8bits
libavcodec
SMPTE 268M-2003 specifies that each line starts at a 4-bytes boundary.
Therefore, modify correspondingly the input buffer strides and size.
Partially fixes ticket #3692: DLAD_8b_3c_big.dpx still has inverted
colors, which might be related to endianness.
---
libavcodec/dpx.c | 34 +
S268M-2003 specifies that each line start is aligned on a 4-byte boundary.
---
libavcodec/dpxenc.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index 0eb1297..059d8c6 100644
--- a/libavco
Fixes DLAD_8b_3c_big.dpx from ticket #3692
---
libavcodec/dpx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 2ad7527..d4d6833 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -232,6 +232,8 @@ static int decode_frame(AVCodecContext *avctx,
---
libavcodec/dpx.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 8cd7d73..2ad7527 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -108,6 +108,15 @@ static int decode_frame(AVCodecContext *avctx,
av_log(avctx, AV_LOG_ERROR,
Hi,
2014-08-13 18:46 GMT+02:00 Reimar Döffinger :
> More specifically: how certain is it this value is always correct?
> Failing to play an unencrypted file just because of a wrong flag (or even a
> single-bit corruption!) seems worse to me than trying to play an encrypted
> file.
> I.e. shouldn
2014-08-13 21:35 GMT+02:00 Reimar Döffinger :
> Personally I'd probably go with the missing feature and a warning
> message on top instead of the return.
Same opinion, here's an updated patch.
From 47f363c96c3dd15e7e36267ccdb338b102d40078 Mon Sep 17 00:00:00 2001
From: Christop
Hi,
2014-08-14 4:17 GMT+02:00 Michael Niedermayer :
> causes
> ./ffmpeg -icheckerboard_1080p_nuke_bigendian_12bit_alpha.dpx -f null -
> to segfault
>
> see http://samples.ffmpeg.org/image-samples/dpx_samples.zip
OK, thanks. Disclaimer, I'm not that knowledgeable in DPX, I'm just
applying the anal
Hi,
2014-08-14 9:00 GMT+02:00 Christophe Gisquet :
> 2014-08-14 4:17 GMT+02:00 Michael Niedermayer :
>> causes
>> ./ffmpeg -icheckerboard_1080p_nuke_bigendian_12bit_alpha.dpx -f null -
>> to segfault
>>
>> see http://samples.ffmpeg.org/image-samples/dpx_samples
Hi,
2014-08-14 4:30 GMT+02:00 Michael Niedermayer :
>> probably ok
>
> applied
Now that I think of it, this change causes older versions of ffmpeg to
be unable to decode the output of the fixed encoder. So:
- Should we bump eg a minor version number to let any decoder have the
possibility to dete
Hi,
2014-08-14 4:17 GMT+02:00 Michael Niedermayer :
> see http://samples.ffmpeg.org/image-samples/dpx_samples.zip
Note that the date metadata in that file does not have a valid format either.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
Hi,
2014-08-14 5:01 GMT+02:00 Michael Niedermayer :
> On Wed, Aug 13, 2014 at 10:21:54AM +0000, Christophe Gisquet wrote:
>> case 50081:
>> +avctx->pix_fmt = AV_PIX_FMT_BGR24;
>> +break;
>
> this possibly breaks decoding of
> checkerboard_1080
Hi,
2014-08-12 12:44 GMT+02:00 Christophe Gisquet :
> Forgot a parameter to the call to avpriv_request_sample, will be added later.
If there's no further comment on this option for the reallocation,
here's an updated patch.
--
Christophe
From 4ea51dc2cec915ce4c84db92febd8960bb44b6
particular because I feel unqualified for
it.
Best regards,
--
Christophe
From 7848e2eed0780d5d2b3190b90174d580257a7ec9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 13 Aug 2014 18:40:17 +0200
Subject: [PATCH] ffmpeg: fix streamcopy with side data
The issue is that, when the main p
Hi,
following the discussion in "[PATCH 2/4] dpxenc: enforce alignment
requirement", here's a bump to offer a chance to other decoders to
detect and recover from the change.
--
Christophe
From ea8003852db0e6f64ec50f2ca644c9b51247cb5f Mon Sep 17 00:00:00 2001
From: Christophe Gis
Hi,
2014-08-14 14:32 GMT+02:00 Michael Niedermayer :
> is this the patch that you wanted to send ?
> it changes dpx.c instead of version.h
Woops, attached the wrong 0001 one...
--
Christophe
From a7eb428f6a9e2175885defe22b0e082b320ef7cf Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Hi,
2014-08-14 17:14 GMT+02:00 James Darnley :
> + * This limit is used:
> + * - when CONFIG_SMALL is 0 to unroll a loop in the C template.
> + * - when SSE4 (or newer) is available on x86 to unroll a copy loop.
Does the implementer of a new dsp version really has a need for this
info
Hi,
2014-08-14 17:14 GMT+02:00 James Darnley :
> This should help to clarify the API.
OK.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
2014-08-14 17:15 GMT+02:00 James Darnley :
> The LPC encoder is not used at compression levels below 3 but the basic acodec
> test uses -compression_level 2. This adds a test using -compression_level 5,
> which is the current default.
What order is used in that case? It may be good to in fac
Hi,
2014-08-14 18:08 GMT+02:00 James Darnley :
> Minimum 1, maximum 8. Should I find out what order(s) are actually chosen?
The encoder algorithm might change and make that information useless,
but that could be useful. I fear that only checking which orders it
*tests* is insufficient: if the ds
Hi,
2014-08-14 11:48 GMT+02:00 Christophe Gisquet :
> Hi,
>
> 2014-08-14 5:01 GMT+02:00 Michael Niedermayer :
>> On Wed, Aug 13, 2014 at 10:21:54AM +0000, Christophe Gisquet wrote:
>>> case 50081:
>>> +avctx->pix_fmt = AV_PIX_FMT_BGR24;
>>&g
Hi,
2014-08-16 12:51 GMT+02:00 Michael Niedermayer :
> On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:
[...]
> i added hoger to the CC
Yes, I read that file. I sent minutes after my previous mail inquiries
to various DPX users/developers I've seen through the
tophe
From 59ea1d72b27272d2a28c680fc87b353f1a88eb36 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sun, 17 Aug 2014 09:47:46 +0200
Subject: [PATCH] gifdec: use truncated width for image manipulation
Some files seem to have an off-by-one error. In most cases, it appears to
be on the image width. Therefo
Le 13 août 2014 12:22, "Christophe Gisquet"
a écrit :
>
> Fixes DLAD_8b_3c_big.dpx from ticket #3692
> ---
> libavcodec/dpx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 2ad7527..d4d6833 100644
> ---
This change is almost cosmetical only, and reduces the changes needed to
fix the 24bps case.
---
libavcodec/alacenc.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index bc68a06..6345253 100644
--- a/libavcodec/
The raw coded bits are extracted prior to decorrelation, as is correctly
performed by the decoder, and not after.
---
libavcodec/alacenc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index 6345253..b9ad899 100644
raw MSBs.
It would possible to detect bitstreams before this change and achieve
correct decoding if need be.
Christophe Gisquet (2):
alacenc: increase predictor buffer
alacenc: fix extra bits extraction
libavcodec/alacenc.c | 35 ---
1 file changed, 24
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> It would possible to detect bitstreams before this change and achieve
> correct decoding if need be.
fate tests still pass with the changes, which means the test sample
doesn't contain the corner case involved, and not all encoded conte
Hi,
2014-08-17 20:39 GMT+02:00 Michael Niedermayer :
>> +if (width > s->screen_width) {
>> +av_log(s->avctx, AV_LOG_ERROR, "Invalid image width.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +if (left + width > s->screen_width) {
>> +/* width must be kept around
Hi,
2014-08-17 19:56 GMT+02:00 Michael Niedermayer :
> do you have a testcase with which this can be tested ?
Ticket #2768:
http://trac.ffmpeg.org/ticket/2768
shows such an issue starting at around 37xxx byte or something.
> or can the fate test be changed / extended to cover this ?
I haven't l
Hi,
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> The raw coded bits are extracted prior to decorrelation, as is correctly
> performed by the decoder, and not after.
Forgot to mention it fixes ticket #2768 (haven't checked 2497 yet), so
commit message amended.
--
Chri
t libavcodec/gifdec.c:108
Sorry for missing the obvious, indeed in those cases pw/height would
end negative...
So I have added the checks you propose and decided to shuffle them
with the others.
Updated patch attached.
--
Christophe
From a8a329b19d72405b6cc7de173e3f160be02e212d Mon Sep 17 00
Hi,
2014-08-17 19:09 GMT+02:00 Christophe Gisquet :
> It would possible to detect bitstreams before this change and achieve
> correct decoding if need be.
So after further exploration, you can't really detect this:
- there's no metadata for the alac bitstream
- the container one
o him.
--
Christophe
From d9679c80df991e98b1f00fd15f9c1c3c689ec426 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc_kostya: warn/reject on incorrect profile
This fixes the following situations:
- Reject encoding when profile sel
Hi,
2014-06-19 6:23 GMT+02:00 Michael Niedermayer :
> patch applied
Am I missing something or was it not applied?
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
this is a proposal to allow decoding incorrect files. There is no
obvious and systematic way to detect them however.
--
Christophe
From feaacb09d8660b7e8784ad4a550dda455f172e24 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 09:53:20 +0200
Subject: [PATCH] alac
2014-08-18 15:59 GMT+02:00 Christophe Gisquet :
> this is a proposal to allow decoding incorrect files. There is no
> obvious and systematic way to detect them however.
Ignore the version.h stray change in your review, I thought I had removed it.
--
Chri
2014-08-18 19:26 GMT+02:00 Christophe Gisquet :
> Hi,
And with all patches.
--
Christophe
From 89b54fbd698eb9c68f0bf30105bcaf72c5575d27 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc: force correct profile for al
Hi,
2014-08-18 13:40 GMT+02:00 Carl Eugen Hoyos :
> Christophe Gisquet gmail.com> writes:
> If a profile was set, the automatic setting should
> probably not overwrite it.
> (If this is possible.)
>
> But I consider the usecase where a user wants to encode
> alpha but
Hi,
2014-08-18 19:22 GMT+02:00 Ronald S. Bultje :
> You mean the centerpoint chroma location (top-left, top-middle,
> middle-middle, etc.) respective to the set of luma pixels?
I don't think it's only that, but it's probably only slightly longer
to implement.
For interlaced 4:2:0, each chroma fi
Hi,
2014-08-18 22:35 GMT+02:00 Michael Niedermayer :
> the "[PATCH 1/2] huffyuv: change statistics initialization"
> patch has has been applied
I thought your last "applied" message referred to the other patch in
this thread, so I'm probably the one confused here.
> is there some other patch ive
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/proresenc_kostya.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index 0f69767..1e40dcf 100
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> +int max_slice_size = (ctx->frame_size_upper_bound - 200) /
> (ctx->pictures_per_frame * ctx->slices_per_picture + 1);
Regarding the reallocation check:
pkt_size <= buf - orig_buf + 2 * max_slice_size
For last slice, pkt_size would be (N
Hi,
2014-08-19 12:31 GMT+02:00 Michael Niedermayer :
> suggested commit message:
> avcodec/proresenc_kostya: set initial max_slice_size based on
> frame_size_upper_bound
>
> If the initial max_slice_size is 0 then reallocation is disabled for the
> first
> slice.
OK.
--
Christophe
2014-08-19 12:40 GMT+02:00 Michael Niedermayer :
>> In the same fashion, shouldn't delta computation be updated to be:
>> 200 + (ctx->pictures_per_frame * ctx->slices_per_picture + 1) * etc ?
>
> yes, locally changed
Good for me then.
--
Christophe
___
---
libavcodec/wavpack.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 7c60f78..9f72ebe 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -253,6 +253,10 @@ static int wv_get_value(WavpackFrameContext *ctx,
GetBitContext *gb
bytestream2_* will not cause buffer overflow, but on the other hand,
it should be checked whether overflows have been prevented.
---
libavcodec/wavpackenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 5b8973c..46c69a3 100644
---
The decoder is reporting CRC errors instead of the prime cause of
end-of-packet. This happens with current encoder when there are a few
samples and the output buffer is undersized because its size didn't
account for headers.
Christophe Gisquet (3):
wavpack: report if there is no bits
The allocation didn't account for headers, that can be easily 79 bytes.
As a result, buffers allocated for a few samples (e.g. 5 in the original
bug) could be undersized.
Fixed ticket #2881.
---
libavcodec/wavpackenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libav
Hi,
2014-08-19 16:06 GMT+02:00 Timothy Gu :
>> +return AVERROR_INVALIDDATA;
>
> Shouldn't this be AVERROR_BUG?
This was selected as a default, not knowing exactly what to put here.
There's even a AVERROR_BUFFER_TOO_SMALL, but I though it would be used
for user-provided buffers.
--
Chris
Hi,
2014-08-19 16:20 GMT+02:00 Nicolas George :
> IMHO, the correct error depends on how sure you are that a buffer too small
> SHOULD not happen.
>
> If you are very sure, then av_assert0().
That would be it: I'm sure that, if the condition occurs and the
packet is written anyway, the file will
Hi,
2014-08-20 4:55 GMT+02:00 James Almer :
> ~15% faster than sse2
[...]
> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
> bit_depth)
> if (ARCH_X86_64) {
> c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_8_avx;
>
t for RGB and bits_per_raw_sample==12 is e.g. not rescaled
to 16bits to match its rgb48 colorspace.
One may argue that a proper solution is to reduce as often as possible
references to bits_per_raw_sample and, instead, always use the
colorspace information and to introduce new colorspaces as needed
It was added per pixel instead of per line.
---
libavcodec/dpxenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index 059d8c6..aca745b 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -159,11 +159,11 @@ static void
When input had 12 bits, it was invariably treated as packed RGB
with 12 bits per component.
---
libavcodec/dpxenc.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index aca745b..d02684b 100644
---
pnmdec currently respects the consign of rgb48 content. Instead, do not rescale
and make the bits_per_raw_sample valid and useful.
---
libavcodec/pnmdec.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index c84b6eb..36bdfe7 100644
--- a/libavcod
This allows writing actual bitdepth in RGB48 when it isn't actually 16.
---
libavcodec/pnmenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c
index e6c3635..9198ddb 100644
--- a/libavcodec/pnmenc.c
+++ b/libavcodec/pnmenc.c
@@ -84,6 +84,8 @@ static
Thanks to av_get_pix_fmt_loss, we can determine more precisely if a
conversion will incur some kind of loss. If this loss doesn't modify
in particular bitdepth, the input bitdepth can be reused for the
output.
---
ffmpeg.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ffmpeg.c b/ffm
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> +if (!(av_get_pix_fmt_loss(enc_ctx->pix_fmt,
> dec_ctx->pix_fmt, 0)
> + & (FF_LOSS_DEPTH|FF_LOSS_COLORSPACE|FF_LOSS_CHROMA))) {
If it was ever useful, this is probably wrong an
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> One may argue that a proper solution is to reduce as often as possible
> references to bits_per_raw_sample and, instead, always use the
> colorspace information and to introduce new colorspaces as needed.
I'd prefer this sol
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
make MY_FFMPE
Hi,
2014-08-20 12:25 GMT+02:00 Michael Niedermayer :
> iam probably missing something but why not add
> #define DEBUG 1
> to the specific file or header for which to enable av_dlog() ?
That's a possibility, but an example is working on aac, where you need
to do this on around 4 files.
Having them
Hi,
2014-08-20 12:19 GMT+02:00 Michael Niedermayer :
> 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 manage
both proje
Hi,
2014-08-20 17:36 GMT+02:00 James Almer :
>> 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 patch to ge
Hi,
2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos :
> Christophe Gisquet 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
---
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/vs
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
+++ b/libavcodec/hu
NUMBER_OF_BYTES-eng: 49020173From dd2edff6495c1f94746c5bff0ff3ac52717b5347 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Thu, 21 Aug 2014 01:31:53 +0200
Subject: [PATCH] hevc_ps: reorder SPS reading to allow some errors
Some streams have been found to have their VUI truncated but still decode
fine. To handle them,
Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Thu, 21 Aug 2014 12:21:07 +0200
Subject: [PATCH] imc: reject files with unfathomable sampling rates
With huge sampling rates, the table derivation method does not converge fast
enough. While fixing it using e.g. Newton-Rhapson-like methods (the curve
ld help to swallow the error.
--
Christophe
From dacdd50379af1bcb3dab2ce813124cfc577adace Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Thu, 21 Aug 2014 12:59:10 +0200
Subject: [PATCH] mov: better check dref atome validity
The size of each entry helps determining whether it would cause
Hi,
2014-08-20 11:35 GMT+02:00 James Darnley :
> (In an effort to help review...)
>
> This does move from per-pixel to per-line so if this is supposed to be
> correct then it looks good to me.
Yes, this is a bugfix that is actually independent of the intent of
the patchset.
--
Christophe
__
Hi,
2014-08-19 18:28 GMT+02:00 Christophe Gisquet :
> 2014-08-19 16:20 GMT+02:00 Nicolas George :
>> IMHO, the correct error depends on how sure you are that a buffer too small
>> SHOULD not happen.
>>
>> If you are very sure, then av_assert0().
>
> That w
Hi,
2014-08-21 14:55 GMT+02:00 Derek Buitenhuis :
> 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
2014-08-21 17:43 GMT+02:00 Michael Niedermayer :
> static int mov_skip_multiple_stsd(MOVContext *c, AVIOContext *pb,
>int codec_tag, int format,
> - int size)
> + int64_t size)
Nice catch, the "s
6ccd655bf5c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
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 VU
Hi,
2014-08-21 0:42 GMT+02:00 James Almer :
> * 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
___
ffmpe
Hi,
2014-08-09 2:45 GMT+02:00 Kieran Kunhya :
> +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 before,
Hi,
2014-08-04 15:20 GMT+02:00 Michael Niedermayer :
> cc-ing Mickael, so its not missed
Ping.
The objection was mostly that openhevc was working on some arm
optimization. That should be pretty easy even for Mickael, considering
this code:
https://github.com/OpenHEVC/FFmpeg/blob/rext/libavcodec/
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
Currently, the encoder will try to reduce it down to 15, but the
decoder will complain starting at 131072 (WV_MAX_SAMPLES). Therefore,
change the loop limit.
Fixes ticket #3881.
---
libavcodec/wavpackenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wavpacke
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
--- a/li
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
--- a/libavcod
101 - 200 of 693 matches
Mail list logo
