On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
BBC typo */
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
/* BBC typo */
Doesn't this patch make
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer michae...@gmx.at:
+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
On Tue, Aug 19, 2014 at 01:54:58AM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
Seems to work great with yuv deflate tiff images created with our tiff encoder
libavcodec/tiff.c | 71
+++
1 file changed, 35
On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote:
The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.
JFTR the Coverity Scan results for
On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote:
On 08/15/2014 11:53 PM, The Wanderer wrote:
It's also something the Linux kernel is still doing, with apparent
success.
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing?
On Tue, Aug 19, 2014 at 09:49:10AM +0200, Christophe Gisquet wrote:
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer michae...@gmx.at:
+int max_slice_size = (ctx-frame_size_upper_bound - 200) /
(ctx-pictures_per_frame * ctx-slices_per_picture + 1);
Regarding the reallocation
Hi,
On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej Surý wrote:
[...]
From the security viewpoint, I would be also interested if ffmpeg
has tests and what is current code coverage. That could help avoiding
regressions when doing security updates.
1. There are also other tools: llvm/clang
On Tue, Aug 19, 2014 at 12:17:59AM -0600, Pavel Koshevoy wrote:
Fixes ticket #3829
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often
Hi,
2014-08-19 12:31 GMT+02:00 Michael Niedermayer michae...@gmx.at:
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.
--
On 8/18/14, Moritz Mühlenhoff j...@inutil.org wrote:
Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same
On Fri, Jun 13, 2014 at 12:56:30AM +0200, Christophe Gisquet wrote:
Hi,
2014-06-12 0:18 GMT+02:00 Michael Niedermayer michae...@gmx.at:
i think adding a codec private option like
-non_deterministic 1
is safer than using the flags in terms of compatibility
it also would produce an error
On Tue, Aug 19, 2014 at 01:42:44PM +0200, Christophe Gisquet wrote:
Hi,
2014-08-19 12:31 GMT+02:00 Michael Niedermayer michae...@gmx.at:
suggested commit message:
avcodec/proresenc_kostya: set initial max_slice_size based on
frame_size_upper_bound
If the initial
On Tue, Aug 19, 2014 at 01:43:28PM +0200, Christophe Gisquet wrote:
2014-08-19 12:40 GMT+02:00 Michael Niedermayer michae...@gmx.at:
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
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 left
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
From: Clément Bœsch clem...@stupeflix.com
---
doc/filters.texi| 3 +++
libavfilter/avf_showwaves.c | 24 +++-
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..828f2b4 100644
--- a/doc/filters.texi
From: Clément Bœsch clem...@stupeflix.com
---
doc/filters.texi| 3 +++
libavfilter/avf_showwaves.c | 14 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 828f2b4..7939018 100644
--- a/doc/filters.texi
+++
From: Clément Bœsch clem...@stupeflix.com
---
libavfilter/avf_showwaves.c | 119 +++-
1 file changed, 74 insertions(+), 45 deletions(-)
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index e4911cc..1389e64 100644
---
On 8/19/14, Christophe Gisquet christophe.gisq...@gmail.com wrote:
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
On 8/19/14, Christophe Gisquet christophe.gisq...@gmail.com wrote:
---
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
James Almer jamrial at gmail.com writes:
+static void unpack_yuv(TiffContext *s, AVFrame *p,
+ const uint8_t *src, int lnum)
-static void unpack_yuv(TiffContext *s, AVFrame *p,
- const uint8_t *src, int lnum)
If you want you could split the moving
Clément Bœsch u at pkh.me writes:
On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
BBC typo */
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
/*
Deti Fliegl deti at fliegl.de writes:
Minor update to propagate field dominance.
At least a Changelog entry and a libavdevice version
bump are still missing, but consider waiting for a
real review.
Carl Eugen
___
ffmpeg-devel mailing list
OK I was able to reproduce the problem.
Patch looks good, see attached, FWIW.
Thanks!
-roger-
On Sat, Aug 16, 2014 at 4:17 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Fri, Aug 08, 2014 at 05:08:46PM +0800, hlszl1...@163.com wrote:
hi, all
I'm using gdigrab feature on windows, and
On Tue, Aug 19, 2014 at 01:41:49PM +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
Clément Bœsch u at pkh.me writes:
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
BBC typo */
On Tue, Aug 19, 2014 at 07:44:53AM -0600, Roger Pack wrote:
OK I was able to reproduce the problem.
Patch looks good, see attached, FWIW.
Thanks!
-roger-
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no
Le duodi 2 fructidor, an CCXXII, Christophe Gisquet a écrit :
+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
On Tue, Aug 19, 2014 at 02:50:58PM +0200, Paul B Mahol wrote:
On 8/19/14, Christophe Gisquet christophe.gisq...@gmail.com wrote:
---
libavcodec/wavpack.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 7c60f78..9f72ebe 100644
On Tue, Aug 19, 2014 at 02:50:37PM +0200, Paul B Mahol wrote:
On 8/19/14, Christophe Gisquet christophe.gisq...@gmail.com wrote:
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
Hi,
I believe the h264_mp4toannexb message could be a bit more precise, and
use the same wording as the aac_adtstoasc message.
(-bsf h264_mp4toannexb used to give me warnings that it was ambiguous
as to which stream to apply to, i.e. wanting to have the :v
specifier. But I can't reproduce that
Hi,
2014-08-19 16:20 GMT+02:00 Nicolas George geo...@nsup.org:
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,
On 19/08/14 7:07 AM, Michael Niedermayer wrote:
is photometric guranteed to match the pix_fmt ?
iam asking as i dont see that being ensured by the code but i might
be missing something
if they could mismatch, id assume it might crash
TIFF_PHOTOMETRIC_YCBCR seems to simply be a flag to signal
As of git: ea97859c8c218b83ab747a7eabcb88ca446f6751 line 1533 in
libavcodec/adpcm.c contains:
static const enum AVSampleFormat sample_fmts_s16p[] = { AV_SAMPLE_FMT_S16,
I believe it should contain:
static const enum AVSampleFormat sample_fmts_s16p[] = { AV_SAMPLE_FMT_S16P,
Note the trailing P
On Tue, Aug 19, 2014 at 01:30:24AM +0200, Carl Eugen Hoyos wrote:
Hi!
Attached patch removes a request for samples of which we already
have several that all work fine.
field_dominance can have 256 different values, do we have samples
for all ? do they even exist ?
is the st-codec-field_order
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/tiff.c | 57 +++
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d5c03e8..980aaf1 100644
--- a/libavcodec/tiff.c
+++
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/tiff.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 980aaf1..2bb7c90 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -333,9 +333,9 @@ static
On Tue, Aug 19, 2014 at 05:35:15PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/tiff.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
both patches should be ok
[...]
--
Michael GnuPG fingerprint:
On 19/08/14 6:35 PM, Michael Niedermayer wrote:
On Tue, Aug 19, 2014 at 05:35:15PM -0300, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/tiff.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
both patches should be ok
Pushed,
On Thu, 19 Jun 2014 10:06:48 -0800, Lou Logan wrote:
On Wed, 18 Jun 2014 14:16:52 +0200, Carl Eugen Hoyos wrote:
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 68fd12f..6f3c2c3 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -473,6 +473,9 @@ Set frame rate (Hz value,
Should fix CID1231988 (RESOURCE_LEAK)
Signed-off-by: Alexander Strasser eclip...@gmx.net
---
WARNING: Sorry, I only compile-tested so far.
There is one remaining thing, I am not sure of:
It looks like the variable feet could be uninitialized
at the point av_freep is called. I think it cannot,
Signed-off-by: Lou Logan l...@lrcd.com
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 23ef668..69ffa87 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -339,7 +339,7 @@ ffmpeg -i in.avi -metadata title=my title
On Mon, Aug 18, 2014 at 03:28:02PM -0300, James Almer wrote:
On 18/08/14 5:01 AM, Pierre Edouard Lepere wrote:
Hi,
here's the new version of the patch. Sorry for the delay.
James, I have not done 8-bit AVX versions because it requires unpacks that
are done differently in AVX.
Aren't
On Tue, Aug 19, 2014 at 4:20 PM, Lou Logan l...@lrcd.com wrote:
Signed-off-by: Lou Logan l...@lrcd.com
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
OK, of course.
[...]
Timothy
___
ffmpeg-devel mailing list
---
src/index | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/index b/src/index
index 40a8abf..f8224f1 100644
--- a/src/index
+++ b/src/index
@@ -36,6 +36,19 @@
News
/h1
+ a id=pr2.3.3/ah3August 20, 2014, FFmpeg 2.3.3, 2.2.7, 1.2.8/h3
+ p
+We have made
---
src/security |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/security b/src/security
index 1e0ecc7..8abf731 100644
--- a/src/security
+++ b/src/security
@@ -188,7 +188,7 @@ Fixes following vulnerabilities:
/p
pre
CVE-2014-5272,
On Tue, Aug 19, 2014 at 12:38 PM, Clément Bœsch u...@pkh.me wrote:
On Mon, Aug 18, 2014 at 06:54:55AM +0700, Muhammad Faiz wrote:
This fontcolor option uses arithmetic expression, not color value,
so color names aren't available.
Thank's
Can you suggest an alternative in the examples?
On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote:
Hello,
As a follow-up to my last patch I now factored out the floating point based
interpolation from transform.h/transform.c and applied it in the
vf_lenscorrection filter I introduced in my last patch. What I did not do is
Fixes memleak
Fixes CID1231989
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/hevc_ps.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 163c5e4..2ccce5f 100644
--- a/libavcodec/hevc_ps.c
+++
On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer michae...@gmx.at wrote:
Fixes memleak
Fixes CID1231989
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/hevc_ps.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Looks OK.
diff --git
~15% faster than sse2
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/x86/hevc_res_add.asm | 15 +++
libavcodec/x86/hevcdsp.h| 4
libavcodec/x86/hevcdsp_init.c | 4
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git
51 matches
Mail list logo
