Hi
On 10 August 2014 17:01, Matthias Urlichs wrote:
> Hi,
>
>
> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.
>
Then it becomes unreasonable for a piece of software to be compatible
with multiple version of t
On 10 August 2014 18:53, Andrew Kelley wrote:
> IMO it's not worth the effort to support multiple versions of the same
> library. If you want to use an old library, use an old version of the
> software.
In our case, we have very long release cycles. Usually only once a
year at best. We have users
This fixes ticket #3839.
--
Christophe
From 3745a3b611159f6a373785b67cbc92d4b36af44b Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sun, 10 Aug 2014 11:43:12 +0200
Subject: [PATCH] hevc: fix incorrect sao buffer size
It previously used the output, cropped size, causing overreads/writes
Hi,
the attached patch is a half-baked attempt at checking the input. I
suspect there are a lot of places where little to no validation is
performed anyway.
Maybe it would be wise to mark hevc as experimental for now ?
--
Christophe
From 65030ebd08fabce851698fa1024a042fc994ef18 Mon Sep 17 00:00
Hi,
2014-08-10 11:59 GMT+02:00 Christophe Gisquet :
> This fixes ticket #3839.
By the way, not completely sure, but that is probably exploitable (I
am not a security expert):
- indicate large cropping in the header; this will cause an overrun of
probably (max_ctb_size-1) lines (ie ~118KB for a 19
On Sun, Aug 10, 2014 at 04:17:09AM +0100, Kieran Kunhya wrote:
> The Opus decoder in particular uses optimised float_dsp functions that expect
> 32-byte alignment
> ---
> libavcodec/avcodec.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/avcodec.h b/libav
On Sun, Aug 10, 2014 at 11:59:08AM +0200, Christophe Gisquet wrote:
> This fixes ticket #3839.
>
> --
> Christophe
> hevc.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
> c80c52a6aacdb596af7c66a961a5887c4cdfb348
> 0001-hevc-fix-incorrect-sao-buffer-size.patch
> From 3745
On Sat, 09 Aug 2014 20:25:09 +0200
Andreas Cadhalpun wrote:
> Hi Kieran,
>
> On 09.08.2014 19:26, Kieran Kunhya wrote:
> > The reality is that in the current state of affairs static linking is
> > the *only* way you are guaranteed to have the features you expect and
> > avoid ABI mismatches. It'
Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> Unfortunately, FFmpeg vehemently resists against enabling lavr by
> default.
If someone cared enough, they would be making their case: posting
benchmarks, listing features present in each library but absent in the
other, comparing the APIs to see w
On Sun, 10 Aug 2014 13:25:03 +0200
Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> > Unfortunately, FFmpeg vehemently resists against enabling lavr by
> > default.
>
> If someone cared enough, they would be making their case: posting
> benchmarks, listing features prese
Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> You seem to be under the impression that this matters.
That is the only thing that matters in FFmpeg: people work on what they
consider important.
> I don't want to have to develop for two slightly similar but
> different APIs, the end. And I don'
On Sun, Aug 10, 2014 at 01:38:06PM +0200, Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> > You seem to be under the impression that this matters.
>
> That is the only thing that matters in FFmpeg: people work on what they
> consider important.
>
> > I don't want to have
On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
[...]
> ... and was designed by a larger
> group instead of libswresample which was basically one person (and
> literally appeared in git out of nowhere).
For the record:
$ git shortlog libswresample/ | grep '^[^ ]'
Alexander Strasser
Hi,
On Sun, Aug 10, 2014 at 6:04 AM, Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:
> Hi,
>
> the attached patch is a half-baked attempt at checking the input. I
> suspect there are a lot of places where little to no validation is
> performed anyway.
>
> Maybe it would be wise to mark
On 10 August 2014 13:38, Michael Niedermayer wrote:
> On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
> [...]
>
>> ... and was designed by a larger
>> group instead of libswresample which was basically one person (and
>> literally appeared in git out of nowhere).
http://git.videola
Hi!
Attached patch fixes a warning here that valgrind produces when reading the
aliaspix fate samples.
Please review, Carl Eugen
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index b9a1bcf..d70fc75 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -395,7 +395,7 @@ in
Hi,
2014-08-10 14:42 GMT+02:00 Ronald S. Bultje :
> Are we using the checked bitstream reader? If we are, we're fine already...
I think we are. On the other hand, it seems the top caller,
ff_hevc_decode_nal_vps, is never checking if we have read past the
bitstream end. Shouldn't this be checked a
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 uninitia
On 8/9/14, Daniel Oberhoff wrote:
>
> Am 08.08.2014 um 12:10 schrieb Michael Niedermayer :
>
>> On Thu, Aug 07, 2014 at 12:15:17AM +0200, Daniel Oberhoff wrote:
>>>
>>> Am 06.08.2014 um 12:12 schrieb Clement Boesch :
>>>
On Sun, Aug 03, 2014 at 06:43:18PM +0200, Daniel Oberhoff wrote:
[.
Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
> It is not mandatory(but it would be nice) to add other methods to have
> this filter included into libavfilter.
Is it really a good idea? We would end up with various interpolation /
anti-aliasing algorithms implemented in each filter that
Von meinem iPhone gesendet
> Am 10.08.2014 um 15:36 schrieb Nicolas George :
>
> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
>> It is not mandatory(but it would be nice) to add other methods to have
>> this filter included into libavfilter.
>
> Is it really a good idea? We would e
Le tridi 23 thermidor, an CCXXII, Daniel Oberhoff a écrit :
> Well, i could factor out the resampling from the Rotary filter and put it
> into a header accessible by both, would that be ok?
Common code to do the work would of course be appreciated, but what I was
saying is that, in my opinion, you
On Sun, Aug 10, 2014 at 03:16:23PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-10 14:42 GMT+02:00 Ronald S. Bultje :
> > Are we using the checked bitstream reader? If we are, we're fine already...
>
> I think we are. On the other hand, it seems the top caller,
> ff_hevc_decode_nal_vps, is
Von meinem iPhone gesendet
> Am 10.08.2014 um 15:46 schrieb Nicolas George :
>
> Le tridi 23 thermidor, an CCXXII, Daniel Oberhoff a écrit :
>> Well, i could factor out the resampling from the Rotary filter and put it
>> into a header accessible by both, would that be ok?
>
> Common code to do
Hi,
Jean-Yves Avenard:
> Including rename of constants (code enums id for example).
Another nail in libav's coffin, then.
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
> Keeping your own static version is the
On Sun, Aug 10, 2014 at 12:01 AM, Matthias Urlichs
wrote:
> Jean-Yves Avenard:
> > Including rename of constants (code enums id for example).
>
> Another nail in libav's coffin, then.
>
> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for
On Sun, Aug 10, 2014 at 1:48 AM, Jean-Yves Avenard
wrote:
> Then it becomes unreasonable for a piece of software to be compatible
> with multiple version of the same library, and support all of those.
>
IMO it's not worth the effort to support multiple versions of the same
library. If you want t
Hi,
Andrew Kelley:
> It is unreasonable to expect no incompatible changes.
When somebody renames constants, a compatibility #ifdef or two is not too
much to ask, IMHO.
> Libav is making a more concentrated effort at improving this,
> and the evolving API is a side-effect of that.
That begs the
On Sun, Aug 10, 2014 at 03:09:48PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes a warning here that valgrind produces when reading the
> aliaspix fate samples.
>
> Please review, Carl Eugen
> img2dec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 326527b2b3c49a
On Sun, Aug 10, 2014 at 03:18:26PM +0200, Christophe Gisquet wrote:
> The patch fixes overreads (and crashes) introduced in 3ad04608.
>
> --
> Christophe
> hevc_mvs.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
> 3cad460e327446b29ab1623c9b5c5f9b0c2ba008
> 0
On Sat, Aug 09, 2014 at 02:56:19PM +0200, Michael Niedermayer wrote:
> Also mark it as deprecated through its help text
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/options_table.h |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
applied
[...]
--
Michael GnuPG f
On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
> > It is not mandatory(but it would be nice) to add other methods to have
> > this filter included into libavfilter.
>
> Is it really a good idea? We would end up with variou
Hi
Le 10 août 2014 à 15:16, Christophe Gisquet a
écrit :
> Hi,
>
> 2014-08-10 14:42 GMT+02:00 Ronald S. Bultje :
>> Are we using the checked bitstream reader? If we are, we're fine already...
>
> I think we are. On the other hand, it seems the top caller,
> ff_hevc_decode_nal_vps, is never ch
Hi
Le 10 août 2014 à 15:48, Michael Niedermayer a écrit :
> On Sun, Aug 10, 2014 at 03:16:23PM +0200, Christophe Gisquet wrote:
>> Hi,
>>
>> 2014-08-10 14:42 GMT+02:00 Ronald S. Bultje :
>>> Are we using the checked bitstream reader? If we are, we're fine already...
>>
>> I think we are. On the
On Sun, 10 Aug 2014 09:43:03 +0200
Matthias Urlichs wrote:
> Hi,
>
> Andrew Kelley:
> > It is unreasonable to expect no incompatible changes.
>
> When somebody renames constants, a compatibility #ifdef or two is not too
> much to ask, IMHO.
AFAIK such a thing existed, but it's possible that th
On Sun, Aug 10, 2014 at 05:58:19PM +0200, Mickaël Raulet wrote:
> Hi
> Le 10 août 2014 à 15:48, Michael Niedermayer a écrit :
>
> > On Sun, Aug 10, 2014 at 03:16:23PM +0200, Christophe Gisquet wrote:
> >> Hi,
> >>
> >> 2014-08-10 14:42 GMT+02:00 Ronald S. Bultje :
> >>> Are we using the checked
Le tridi 23 thermidor, an CCXXII, Michael Niedermayer a écrit :
> thats not practical
> a 1024x768 image would need to be upscaled to 262144x196608 to get
> 8bit precission from a nearest neighbor resampler as basis
I am not sure this makes sense. Scaling is already an approximation, and
without g
Hi!
Attached is a new variant of "[RFC]Remove panscan side data in filters that
change the resolution". I don't know how to correctly set the information
based on the resolution change, as-is this patch works around ticket #3750 (a
regression).
Please comment, Carl Eugen
diff --git a/libavutil
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 Gisque
Von meinem iPhone gesendet
> Am 10.08.2014 um 17:50 schrieb Michael Niedermayer :
>
>> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote:
>> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
>>> It is not mandatory(but it would be nice) to add other methods to have
>>> this
On Fri, Aug 8, 2014 at 6:35 PM, Michael Niedermayer
wrote:
> On Fri, Aug 08, 2014 at 10:37:06AM -0700, Mark Reid wrote:
> > ---
> > libavformat/movenc.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/mo
---
libavformat/movenc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6a38e89..85fb2e8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1340,13 +1340,21 @@ static int mov_write_rtp_tag(AVIOCont
On Sun, Aug 10, 2014 at 07:23:33PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached is a new variant of "[RFC]Remove panscan side data in filters that
> change the resolution". I don't know how to correctly set the information
> based on the resolution change, as-is this patch works around tick
On Sun, Aug 10, 2014 at 12:01:33PM -0700, Mark Reid wrote:
> ---
> libavformat/movenc.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100
Previously pcr transmitted without payload but as part of the video stream was
not parsed.
Signed-off-by: Marton Balint
---
libavformat/mpegts.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index a2456a3..6e400a6 100
---
I have one or two little things to cleanup after this but I think I'm mostly
done. The filter is now usable from a performance point of view (not for
real-time, but it doesn't decades to process a normal sized image anymore):
Stream #0:0: Video: png, rgb24, 1445x1080, 25 tbr, 25 tbn, 25 tbc
.
Hi Reinhard,
On 10.08.2014 15:10, Reinhard Tartler wrote:
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote:
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
This is exactly what Libav is doing: The depr
On Sun, Aug 10, 2014 at 12:01 PM, Mark Reid wrote:
> ---
> libavformat/movenc.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 6a38e89..85fb2e8 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/mov
On Sun, Aug 10, 2014 at 03:02:32PM -0700, Timothy Gu wrote:
> On Sun, Aug 10, 2014 at 12:01 PM, Mark Reid wrote:
> > ---
> > libavformat/movenc.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index 6a
On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote:
>
>
> Von meinem iPhone gesendet
>
> > Am 10.08.2014 um 17:50 schrieb Michael Niedermayer :
> >
> >> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote:
> >> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
> >
The patch is inspired by something I read in the Debian discussion.
Libav and FFmpeg could be installed side by side without conflicts in
the libraries, thanks to using additional suffixes.
However development/include files are still conflicting, so I thought
of a simple configure hack to give mor
From: Luca Barbato
TODO:bump
Signed-off-by: Michael Niedermayer
---
libswresample/Makefile |1 +
libswresample/swresample.h | 61 +++
libswresample/swresample_frame.c | 158 ++
3 files changed, 220 insertions(+)
create mod
---
libavcodec/hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index cc36f97..985b013 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2280,7 +2280,7 @@ static int hls_nal_unit(HEVCContext *s)
return AVERROR_INVALI
On Sun, Aug 10, 2014 at 08:04:56PM -0400, Ronald S. Bultje wrote:
> ---
> libavcodec/hevc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out you
On Sun, Aug 10, 2014 at 07:34:17PM +0200, Christophe Gisquet wrote:
> 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
> hevc.c
On 10/08/14 8:49 PM, Michael Niedermayer wrote:
> From: Luca Barbato
>
> TODO:bump
APIChanges entry as well
>
> Signed-off-by: Michael Niedermayer
> ---
> libswresample/Makefile |1 +
> libswresample/swresample.h | 61 +++
> libswresample/swresample_frame.c
From: Pascal Massimino
Thanks to Pascal Massimino and Michael Militzer for permission to use under LGPL
Signed-off-by: Michael Niedermayer
---
libavcodec/Makefile |2 +-
libavcodec/xvid_c_idct.c | 335 ++
libavcodec/xvididct.c| 60
On 11/08/14 12:18 AM, Michael Niedermayer wrote:
> From: Pascal Massimino
>
> Thanks to Pascal Massimino and Michael Militzer for permission to use under
> LGPL
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/Makefile |2 +-
> libavcodec/xvid_c_idct.c | 335
> +++
On 09/08/14 9:04 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/libavcodec.v | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/libavcodec/libavcodec.v b/libavcodec/libavcodec.v
> index be74cb3..c923cd3 100644
> --- a/libavcodec/libavcodec.v
> +++
On Mon, Aug 11, 2014 at 05:18:32AM +0200, Michael Niedermayer wrote:
> From: Pascal Massimino
>
> Thanks to Pascal Massimino and Michael Militzer for permission to use under
> LGPL
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/Makefile |2 +-
> libavcodec/xvid_c_idct.c | 33
60 matches
Mail list logo
