On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
> Stefano Sabatini wrote:
[...]
>
> The list is quite long and debunking each of the statements could take a
> lot of time.
>
> I'm going to address two historical "misrepresentations":
>
> # The change of management
>
> Michael Nied
Hi,
the attached patch fixes ticket #3538, which is an off-by-one error.
Unfortunately, I see no way of detecting it as a "correctable"
behavior and not an actual error besides that.
Maybe restricting this to actual off-by-one errors would be better, too.
--
Christophe
From 59ea1d72b27272d2a28c
On Sat, Aug 16, 2014 at 05:47:14PM -0700, Timothy Gu wrote:
> Signed-off-by: Timothy Gu
> ---
> libavfilter/vidstabutils.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its no
Le decadi 30 thermidor, an CCXXII, Michael Niedermayer a écrit :
> whats the status of this patch ?
> has it been forgotten ?
It seems it was indeed. Thanks for keeping track. I have pushed to my tree
for merging:
4f3e2f1 ffprobe: add -show_data_hash option.
Regards,
--
Nicolas George
sign
On Sun, Aug 17, 2014 at 11:33:06AM +0200, Nicolas George wrote:
> Le decadi 30 thermidor, an CCXXII, Michael Niedermayer a écrit :
> > whats the status of this patch ?
> > has it been forgotten ?
>
> It seems it was indeed. Thanks for keeping track. I have pushed to my tree
> for merging:
>
> 4f3
On 8/16/14, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/movenchint.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/movenchint.c b/libavformat/movenchint.c
> index 2602254..006aa09 100644
> --- a/libavformat/mov
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
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/
When new cookie values (with the same name as an existing cookie) are
returned in an HLS stream, the current implementation will append the
new cookie to the list of cookies. This causes FFMPEG to send multiple
cookie values for the same cookie and in some cases exceed the http
header size in some
On Sun, Aug 17, 2014 at 12:24:27PM +0200, Paul B Mahol wrote:
> On 8/16/14, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/movenchint.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/movenchint.c b/liba
Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit :
> When new cookie values (with the same name as an existing cookie) are
> returned in an HLS stream, the current implementation will append the
> new cookie to the list of cookies. This causes FFMPEG to send multiple
> cookie values for the
On Sun, 17 Aug 2014 13:29:15 +0200
Nicolas George wrote:
> Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit :
> > When new cookie values (with the same name as an existing cookie) are
> > returned in an HLS stream, the current implementation will append the
> > new cookie to the list of c
On Thu, Aug 14, 2014 at 11:05:12PM +0200, Clément Bœsch wrote:
> ---
> libavfilter/f_select.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no pl
Hi Russ,
On 16.08.2014 18:33, Russ Allbery wrote:
All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongo
On Thu, Aug 14, 2014 at 11:05:15PM +0200, Clément Bœsch wrote:
> Not that much relevant from a performance PoV because not called often.
> ---
> libavfilter/vf_fieldmatch.c | 42 ++
> 1 file changed, 22 insertions(+), 20 deletions(-)
should be ok
[...]
--
On Thu, Aug 14, 2014 at 11:05:13PM +0200, Clément Bœsch wrote:
> ~560 → ~500 decicycles
>
> This is following the comments from Michael in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160599.html
>
> Using 2 registers for accumulator didn't help. On the other hand,
> some re-ordering b
Le decadi 30 thermidor, an CCXXII, wm4 a écrit :
> AFAIK this cookie string is exposed by AVOption API, and I use it for
> setting cookies. And I don't feel like rewriting this code at all.
I do not propose to break user-visible API. You confuse it with internal
data structures.
Regards,
--
N
The current code would use any unknown attribute-value pair
as the cookie value.
RFC 6265 states that the first key-value pair is the actual
cookie, and the attribute-value pairs only start after.
With the current code:
Set-Cookie: test=good_value; path=/; dummy=42
gives this:
Cookie: dummy=42
ins
With the previous change, unknown attributes are all ignored,
as specified by the RFC.
Signed-off-by: Nicolas George
---
libavformat/http.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index bd67645..018d25c 100644
--- a/libavformat/http.c
+++ b
On Sat, Aug 16, 2014 at 05:13:53PM +0100, Kieran Kunhya wrote:
> > And do not forget the language barrier: when writing a mail, there is as
> > much time as necessary to find words. IRL, the people struggling to find
> > their words are at a clear disadvantage.
>
> We can rotate between different
On Mon, Aug 11, 2014 at 02:23:47AM +0300, Ivan Kalvachev wrote:
> 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
Hi,
Attached patch fixes decoding of this file:
http://www.datafilehost.com/d/1bde8ab0
Regards
0001-avcodec-lcldec-fix-decoding-of-YUV444-sample.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/ma
On Sun, Aug 17, 2014 at 06:27:25PM +0200, Piotr Bandurski wrote:
> Hi,
>
> Attached patch fixes decoding of this file:
>
> http://www.datafilehost.com/d/1bde8ab0
>
> Regards
> From 71bef996471551ab4ba8ff3270413c0c7cb4c6cc Mon Sep 17 00:00:00 2001
> From: Piotr Bandurski
> Date: Sun, 17 Aug 201
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
The encoder, for content having a bitdepth higher than 16, stores the
LSBs uncompressed. To do so, it performs first channel rematrixing then
extract these MSBs.
However, these 2 steps are inverted, as can be seen in the decoder, or
in the official encoder:
http://alac.macosforge.org/trac/browser/
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 content
prior to
On Sun, Aug 17, 2014 at 07:15:54PM +0200, Christophe Gisquet wrote:
> 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
>
On Sun, Aug 17, 2014 at 02:26:29PM +0200, Nicolas George wrote:
> The current code would use any unknown attribute-value pair
> as the cookie value.
> RFC 6265 states that the first key-value pair is the actual
> cookie, and the attribute-value pairs only start after.
>
> With the current code:
>
On Thu, Aug 14, 2014 at 01:19:10PM +0200, Stefano Sabatini wrote:
> On date Monday 2014-08-11 15:22:59 +0200, Clément Bœsch encoded:
> > From: Clément Bœsch
> >
> > The reasoning behind this addition is that various third party
> > applications are interested in getting some motion information ou
Le decadi 30 thermidor, an CCXXII, Michael Niedermayer a écrit :
> michaelni: oh, rly? well I know the code..
> michaelni: I can look, weblink to patches?
> michaelni: oh, those, both ok
If it means what I believe it means, then: Thanks, pushed to my tree for
merge.
Regards,
--
Nicolas Geo
On Sun, Aug 17, 2014 at 10:41:53AM +0200, Christophe Gisquet wrote:
> Hi,
>
> the attached patch fixes ticket #3538, which is an off-by-one error.
> Unfortunately, I see no way of detecting it as a "correctable"
> behavior and not an actual error besides that.
>
> Maybe restricting this to actual
On Sun, Aug 17, 2014 at 08:14:24PM +0200, Nicolas George wrote:
> Le decadi 30 thermidor, an CCXXII, Michael Niedermayer a écrit :
> > michaelni: oh, rly? well I know the code..
> > michaelni: I can look, weblink to patches?
> > michaelni: oh, those, both ok
>
> If it means what I believe it me
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.
--
Christophe
From d7ce32fdc04
The AAF SDK refers to these ULs as Legacy. These ULs are the same as the
ones found in FFmbc's version of mxf.c and the ones found in libMXF
Fixes Ticket#1554, Ticket#3100 and Ticket#3450
---
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/m
Changes since v3:
*added more details to commit message
Mark Reid (1):
added ULs for demuxing avid media composer mxf files
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
On Sun, Aug 17, 2014 at 09:47:25PM +0200, Christophe Gisquet wrote:
> 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;
> >> +}
> >>
libav brought up the point again that it doesnt like libmpcodecs.
is there anyone using the remaining libmpcodecs filters ?
most of the filters have been ported to libavfilter already.
comments?
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Sun, 17 Aug 2014 19:04:35 -0400
compn wrote:
> libav brought up the point again that it doesnt like libmpcodecs.
>
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters have been ported to libavfilter already.
>
> comments?
+1000
Nobody cares about these filters
compn mi.rr.com> writes:
> libav brought up the point again that it doesnt like
> libmpcodecs.
I don't think removing features is an option that should
be considered.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
Carl Eugen Hoyos ag.or.at> writes:
> I cannot really test but I hope attached patch
> fixes the remaining fate tests that don't work
> on remote fate targets.
If nobody has objections against the content of
the patch please commit: Neither will anybody
claim that I didn't write the patch nor
Christophe Gisquet gmail.com> writes:
> The encoder, for content having a bitdepth higher than 16,
> stores the LSBs uncompressed. To do so, it performs first
> channel rematrixing then extract these MSBs.
If this is related to ticket #2768, please mention it in the
commit message.
Thank you
On Sun, 17 Aug 2014 23:11:53 + (UTC)
Carl Eugen Hoyos wrote:
> compn mi.rr.com> writes:
>
> > libav brought up the point again that it doesnt like
> > libmpcodecs.
>
> I don't think removing features is an option that should
> be considered.
I wouldn't call these "features"; more like "
Carl Eugen Hoyos ag.or.at> writes:
> If this is related to ticket #2768, please mention it in the
> commit message.
Sorry, please disregard...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg
This fontcolor option uses arithmetic expression, not color value,
so color names aren't available.
Thank's
---
doc/filters.texi | 20 +++
libavfilter/avf_showcqt.c | 84 ++-
2 files changed, 81 insertions(+), 23 deletions(-)
diff --gi
On Sun, Aug 17, 2014 at 4:54 PM, Muhammad Faiz wrote:
> This fontcolor option uses arithmetic expression, not color value,
> so color names aren't available.
> Thank's
You should use AV_OPT_TYPE_COLOR instead of AV_OPT_TYPE_STRING to make
the color names usable. Look at how vf_drawtext is doing i
On Sun, Aug 17, 2014 at 02:26:45PM -0700, Mark Reid wrote:
> The AAF SDK refers to these ULs as Legacy. These ULs are the same as the
> ones found in FFmbc's version of mxf.c and the ones found in libMXF
> Fixes Ticket#1554, Ticket#3100 and Ticket#3450
> ---
> libavformat/mxf.c | 3 +++
> 1 file c
On 8/18/14, compn wrote:
> libav brought up the point again that it doesnt like libmpcodecs.
>
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters have been ported to libavfilter already.
They doesn't like Michael too.
They doesn't like that we merge their code.
They
On Sun, Aug 17, 2014 at 05:09:13PM +, Christophe Gisquet wrote:
> 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(-)
applied
thanks
[...]
-
On Sun, Aug 17, 2014 at 10:20:14PM +0200, Christophe Gisquet wrote:
> 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 (have
As of September 14 2012, v4l_enumstd() will return ENODATA
when a device's std field is set to 0. That is, the device
does not have a standard format. In order to properly
handle this case, v4l2_set_parameters should catch the
ENODATA code and break instead of failing.
Below is the v4l2-core comm
On Mon, Aug 18, 2014 at 10:18:35AM +0800, Andre Wolokita wrote:
> As of September 14 2012, v4l_enumstd() will return ENODATA
> when a device's std field is set to 0. That is, the device
> does not have a standard format. In order to properly
> handle this case, v4l2_set_parameters should catch the
Fixed parentheses mismatch.
Signed-off-by: Andre Wolokita fd, VIDIOC_ENUMSTD, &standard) < 0) {
ret = AVERROR(errno);
-if (ret == AVERROR(EINVAL)) {
+if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
tpf = &streamparm.pa
Pushed as 1013d8dd6967f1e776c08dc1, Thanks.
On 08/02/2014 10:40 AM, Stefano Sabatini wrote:
The new option names are more explicit.
---
doc/ffserver.conf | 4 ++--
doc/ffserver.texi | 19 ++-
ffserver.c| 10 +++---
3 files changed, 23 insertions(+), 10 deletions
Fixes ticket #3862.
As a side effect, this also fixes aac_latm in wav.
Signed-off-by: James Almer
---
Maybe a check for channels <= 0 should be also added to ff_get_wav_header()
right after the sample_rate one?
libavformat/wavdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -
On 08/16/2014 11:44 PM, wm4 wrote:
>> This reasoning may work when you have only a small amount of information
>> to read. When you are overwhelmed with it, having different places to do
>> different things is a much better approach. Sending patches to a list
>> simply doesn't scale.
>>
>> Also, wi
On 08/16/2014 11:11 PM, Nicolas George wrote:
> L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
>> Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit
>> can be configured to automatically invite the right people for review
>> based on the changed path. We recently migrate
On 08/16/2014 11:30 PM, Nicolas George wrote:
> So what about the code? Shall the FFmpeg developers discard three years of
> work and start working on libav? Or shall the libav developers accept to
> work with the code from FFmpeg that they do not like?
FFmpeg folks should rework the code to make
On 08/17/2014 07:41 PM, Andreas Cadhalpun wrote:
> Michael Niedermayer already volunteered to help with all security
> related problems of FFmpeg in Debian.
> So what should he do to relieve the impact on the security and release
> teams?
Let's say he would take the role of patching stuff in Stabl
60 matches
Mail list logo
