On Sun, Nov 29, 2015 at 1:21 PM, Nicolas George wrote:
> Le nonidi 9 frimaire, an CCXXIV, Clement Boesch a écrit :
>> I'd love to have most of the current documentation generated from this doc
>> though. The current redundancy is annoying/problematic.
>
> I second that. We should
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 61 +
libavfilter/Makefile | 1 +
libavfilter/af_agate.c | 170 ++-
libavfilter/allfilters.c | 1 +
4 files changed, 230 insertions(+), 3
Signed-off-by: Paul B Mahol
---
libavfilter/af_agate.c | 59 --
1 file changed, 33 insertions(+), 26 deletions(-)
diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
index b56f32e..d3f74fb 100644
---
On Wed, 25 Nov 2015 10:35:31 -0500
Alex Agranovsky wrote:
> From 4797590e11267993c3883e5037619625e1f1dadf Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky
> Date: Tue, 24 Nov 2015 00:07:34 -0500
> Subject: [PATCH 2/2] If available, use the actual
On Sun, Nov 29, 2015 at 06:39:02PM +0100, Moritz Barsnick wrote:
> Hi,
>
> On Sat, Nov 28, 2015 at 23:26:44 +0100, Paul B Mahol wrote:
>
> In addition to Ganesh's comments:
>
> > +@item amount
> > +Set modulation. Define how much of original signal is affected by the LFO.
> [...]
> > +@item
On Wed, 25 Nov 2015 10:35:31 -0500
Alex Agranovsky wrote:
> From 70a6e1b0f3d47698bf49c3c766d5472646bff71a Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky
> Date: Tue, 24 Nov 2015 00:06:14 -0500
> Subject: [PATCH 1/2] Allow mpjpeg demuxer to process
Hi,
On Sat, Nov 28, 2015 at 23:26:44 +0100, Paul B Mahol wrote:
In addition to Ganesh's comments:
> +@item amount
> +Set modulation. Define how much of original signal is affected by the LFO.
[...]
> +@item width
> +Set pulse width.
I would appreciate ranges for both od these. I would guess
2015-11-22 12:05 GMT-05:00 Ganesh Ajjanagadde :
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/af_compand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/af_compand.c b/libavfilter/af_compand.c
>
On Sun, Nov 29, 2015 at 12:45 PM, Clément Bœsch wrote:
> On Sun, Nov 29, 2015 at 06:39:02PM +0100, Moritz Barsnick wrote:
>> Hi,
>>
>> On Sat, Nov 28, 2015 at 23:26:44 +0100, Paul B Mahol wrote:
>>
>> In addition to Ganesh's comments:
>>
>> > +@item amount
>> > +Set modulation.
Le nonidi 9 frimaire, an CCXXIV, Clement Boesch a écrit :
> I'd love to have most of the current documentation generated from this doc
> though. The current redundancy is annoying/problematic.
I second that. We should make all the documentation introspectable, and
therefore usable by GUI
Attached
Before pushing this, I'd like some feedback, especially about
the implementation of point 3. I'm not sure the AAC encoder
setting the cutoff in the encoder context like this is legal or desirable.
It does work quite well, and all attempts to do it otherwise were either
very invasive or
On Sun, Nov 29, 2015 at 1:00 PM, wm4 wrote:
> On Wed, 25 Nov 2015 10:35:31 -0500
> Alex Agranovsky wrote:
>
>> From 70a6e1b0f3d47698bf49c3c766d5472646bff71a Mon Sep 17 00:00:00 2001
>> From: Alex Agranovsky
>> Date: Tue, 24 Nov
Le nonidi 9 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> I agree with this. There is another comment I would like to make on
> this note, related to a patch I have shelved for the moment:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/182802.html -
> it would be quite annoying to
On Friday 27 November 2015 09:46:48 pm Tomas Härdin wrote:
> > Ok to apply?
>
> Sure, we can take the renaming separately.
I applied the patch.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sat, Nov 28, 2015 at 05:48:57PM -0500, Rick Kern wrote:
> K coding style is implied but not listed in 'Coding Rules'.
>
> Signed-off-by: Rick Kern
> ---
> doc/developer.texi | 3 +++
> 1 file changed, 3 insertions(+)
LGTM as well. Applied, thanks!
Timothy
Le nonidi 9 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> long long is already being used in quite a few places in FFmpeg. There
> is no reason to list it as something to avoid.
IMHO, most of these places should be replaced by more adapted types. With
modern C, having long, long long or
On Fri, Nov 27, 2015 at 7:11 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> configure | 4 +---
> libavcodec/libdcadec.c | 6 +++---
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/configure b/configure
> index
On Tue, Nov 17, 2015 at 5:05 PM, Michael Niedermayer
wrote:
> On Tue, Nov 17, 2015 at 12:28:58AM +0100, Hendrik Leppkes wrote:
>> Fixes probing of truehd/mlp files with a lot of frames in between the
>> major sync frames. The spec allows a distance of up to 128 frames in
On 11/29/15, Ganesh Ajjanagadde wrote:
> On Sat, Nov 28, 2015 at 6:21 PM, Ganesh Ajjanagadde
> wrote:
>> On Sat, Nov 28, 2015 at 5:26 PM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>> [...]
>>
>>> +case
On Sun, Nov 29, 2015 at 7:36 AM, Nicolas George wrote:
> It is no longer needed since looping is not necessary.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/vf_mpdecimate.c | 14 --
> 1 file changed, 14 deletions(-)
>
>
> Passes the FATE
On Sun, Nov 29, 2015 at 7:45 AM, Paul B Mahol wrote:
> On 11/29/15, Ganesh Ajjanagadde wrote:
>> On Sat, Nov 28, 2015 at 6:21 PM, Ganesh Ajjanagadde
>> wrote:
>>> On Sat, Nov 28, 2015 at 5:26 PM, Paul B Mahol wrote:
On Sat, 28 Nov 2015 17:48:57 -0500
Rick Kern wrote:
> K coding style is implied but not listed in 'Coding Rules'.
>
> Signed-off-by: Rick Kern
> ---
> doc/developer.texi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/developer.texi
It is no longer needed since looping is not necessary.
Signed-off-by: Nicolas George
---
libavfilter/vf_mpdecimate.c | 14 --
1 file changed, 14 deletions(-)
Passes the FATE test (the one that is broken for windows).
This is the last filter that needed updatint.
On Sun, Nov 29, 2015 at 10:14 AM, Nicolas George wrote:
> Le nonidi 9 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> long long is already being used in quite a few places in FFmpeg. There
>> is no reason to list it as something to avoid.
>
> IMHO, most of these places
On 15-11-22 at 15:03, Simon Thelen wrote:
> Using -ss as an input option shifts timestamps down by the seek, so it
> doesn't have to be added to the recording time when checking whether to
> stop.
>
> Fixes #977
>
> Signed-off-by: Simon Thelen
> ---
> ffmpeg.c | 2 +-
> 1
On Thu, Nov 26, 2015 at 9:07 PM, Michael Niedermayer wrote:
> On Thu, Nov 12, 2015 at 05:10:33PM -0600, Will Kelleher wrote:
>> > Scene change detection ?
>> > and
>> > Content dependant B frame insertion
>> >
>> > And if people agree then please someone submit a patch with it
On Sun, Nov 29, 2015 at 05:01:52PM +0100, Nicolas George wrote:
> Needed after f62fe53/2c17fb6.
>
> Signed-off-by: Nicolas George
> ---
> ffserver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint:
Le nonidi 9 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> LGTM
Pushed.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
The status field can carry any error code instead of just EOF.
Also only update it through a wrapper function and provide a timestamp.
Update the few filters that used it directly.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 25 ++---
This field is used for fast comparison between link ages,
it is in AV_TIME_BASE units, in other words microseconds,
µs =~ us.
Renaming it allows a second field in link time base units.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 4 ++--
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 2 ++
libavfilter/avfilter.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index e583ec0..06a8239 100644
--- a/libavfilter/avfilter.c
+++
Applications are not supposed to mess with links,
they should close the sinks.
Furthermore, this function does not distinguish what end
of the link caused the close and does not have a timestamp.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 3 +++
1 file changed,
Instead of calling the input filter request_frame() method,
ff_request_frame() now marks the link and returns immediately.
bufferskin is changed to activate the marked filters until
a frame is obtained.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 20
On 11/29/15 1:00 PM, wm4 wrote:
On Wed, 25 Nov 2015 10:35:31 -0500
Alex Agranovsky wrote:
From 4797590e11267993c3883e5037619625e1f1dadf Mon Sep 17 00:00:00 2001
From: Alex Agranovsky
Date: Tue, 24 Nov 2015 00:07:34 -0500
Subject: [PATCH 2/2] If
The table in question is a 253 byte one. In fact, it turns out that
dynamic generation of the table results in an increased binary size.
Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
patch:
old: 62321064 libavcodec/libavcodec.so.57
new: 62320536
There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
resulted in wasted space under --enable-hardcoded-tables:
dynamic: 1318672 libavutil/libavutil.so.55
old: 1330680 libavutil/libavutil.so.55
new: 1326488 libavutil/libavutil.so.55
Minor version number is bumped.
On 11/29/2015 11:50 PM, Ganesh Ajjanagadde wrote:
> On Sun, Nov 29, 2015 at 9:45 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This
This gets rid of virtually useless hardcoded tables hackery. The reason
it is useless is that a 320 element lut is anyway placed regardless of
--enable-hardcoded-tables, from which all necessary tables are trivially
derived at runtime at very low cost:
sample benchmark (x86-64, Haswell,
Hi,
On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
wrote:
> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> resulted in wasted space under --enable-hardcoded-tables:
> dynamic: 1318672 libavutil/libavutil.so.55
> old: 1330680
On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
> wrote:
>
>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>> resulted in wasted space under --enable-hardcoded-tables:
>> dynamic:
On 11/29/15 1:16 PM, Nicolas George wrote:
Le nonidi 9 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
end = p + strlen(p) - 1;
Don't know what you are referring to here, but dereferencing is
clearly invalid. However, in order to allow common loop idioms,
pointer arithmetic one
On 11/30/2015 12:02 AM, Ganesh Ajjanagadde wrote:
> On Sun, Nov 29, 2015 at 9:58 PM, James Almer wrote:
>> On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
>>> wrote:
>>>
There was
On Saturday 28 November 2015 02:32:37 am Carl Eugen Hoyos wrote:
> Hi!
>
> Jpeg over rtp requires standard huffman tables, but the test I implemented
> was too strict. Attached patch tries to improve this, related to ticket
> #3823.
New patch attached.
Please review, Carl Eugen
diff --git
On Sun, Nov 29, 2015 at 9:58 PM, James Almer wrote:
> On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
>> wrote:
>>
>>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
Le nonidi 9 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
> Please see the updated patches attached. The trimming loop that was subject
> of the discussion had been rewritten to use indices rather than pointer
> arithmetics.
This kind of drastic change was not necessary, you can do the same
On 11/29/2015 5:32 AM, Hendrik Leppkes wrote:
> On Fri, Nov 27, 2015 at 7:11 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> configure | 4 +---
>> libavcodec/libdcadec.c | 6 +++---
>> 2 files changed, 4 insertions(+), 6
On Sun, Nov 29, 2015 at 9:45 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde
> wrote:
>>
>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>> resulted in wasted space under
Le nonidi 9 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> >> end = p + strlen(p) - 1;
> Don't know what you are referring to here, but dereferencing is
> clearly invalid. However, in order to allow common loop idioms,
> pointer arithmetic one element beyond a array (memory) range is
On Sun, Nov 29, 2015 at 01:11:07PM -0500, Ganesh Ajjanagadde wrote:
> On Sun, Nov 29, 2015 at 12:45 PM, Clément Bœsch wrote:
> > On Sun, Nov 29, 2015 at 06:39:02PM +0100, Moritz Barsnick wrote:
> >> Hi,
> >>
> >> On Sat, Nov 28, 2015 at 23:26:44 +0100, Paul B Mahol wrote:
> >>
> >>
49 matches
Mail list logo