On 2024-04-27 22:14 +0200, Timo Rothenpieler wrote:
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 8101b4fce6..89af5f75e7 100755
> --- a/configure
> +++ b/configure
> @@ -5036,7 +5036,12 @@ probe_cc(){
> else
On 2024-04-14 21:24 +0200, Nicolas George wrote:
> Nicolas George (12024-04-14):
> > Either we find options to make ffplay display frames as fast as
> > possible, or we must document to the user that no adequate replacement
> > exists.
>
> Please add “-vf setpts=0”. It still has a little more
When piping ffmpeg into ffplay both programs write a status line in
the terminal. That causes flickering and invisibility of one or the
other status line.
As compromise set ffplay log level to warning, so it doesn't show
the status line.
The user is usually testing ffmpeg command lines and
On 2024-04-24 22:26 +0200, Timo Rothenpieler wrote:
> On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
> > On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> > > ---
> > > tests/fate.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> ---
> tests/fate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/fate.sh b/tests/fate.sh
> index c5ee18de80..4081e865ae 100755
> --- a/tests/fate.sh
> +++ b/tests/fate.sh
> @@ -30,14 +30,14 @@ lock(){
>
When piping ffmpeg into ffplay both programs write a status line in
the terminal. That causes flickering and invisibility of one or the
other status line.
As compromise set ffplay log level to warning, so it doesn't show
the status line.
The user is usually testing ffmpeg command lines and
On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote:
>
> On Wed, 28 Feb 2024, at 18:55, James Almer wrote:
> > On 2/28/2024 10:31 AM, J. Dekker wrote:
> >>
> >> Michael Niedermayer writes:
> >>
> >>> [[PGP Signed Part:Undecided]]
> >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
>
On 2024-01-29 19:42 +0100, Anton Khirnov wrote:
[...]
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -887,6 +887,10 @@ For example, to set PTS equal to DTS (not recommended if
> B-frames are involved):
> ffmpeg -i INPUT -c:a copy -bsf:a setts=pts=DTS out.mkv
> @end
On 2023-12-14 01:47 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> [...]
> > Honestly I don't see how this could be done in ffmpeg CLI without
> > disgusting hacks, but before that the question is:
>
On 2023-11-30 00:14 +0100, Michael Niedermayer wrote:
> On Tue, Nov 28, 2023 at 02:23:13PM +0100, Anton Khirnov wrote:
> > For the record, I've edited the vote description to make it more clear.
> > It now looks like this:
> >
> > Five people from the list below will become the members of the
Hi Martin,
patch looks technically good to me.
On 2023-11-27 17:46 +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :
> > This can be useful if doing testing of uncommon CPU extensions by
> > running tests with QEMU (by configuring with
On 2023-11-26 10:18 +0100, Anton Khirnov wrote:
> Set pushed.
>
> The general_assembly.pl script should now be usable as the authoritative
> source for GA members.
The patches mostly LGTM.
My Perl knowledge in general is really mostly from 20 years ago.
So if there is any Perl-ish devil in the
gt; FFmpeg)
> Moritz Barsnick(Member of the 2020 GA but was not on jbs list)
> Lauri Kasanen (Linux / PowerPC maintainer)
> Dale Curtis(14 commits in 2020 was in the 2020-GA)
> Alexander Strasser (Root admin, just recently reported that he could not vote
> even
Hi Anton!
On 2023-11-09 13:15 +0100, Anton Khirnov wrote:
> Quoting Alexander Strasser (2023-11-06 16:56:55)
> > On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> > > Yo,
> > >
> > > Time is up, results are here:
> > > https://vote.ffmpeg.org/
On 2023-11-08 17:58 -0500, Vittorio Giovara wrote:
> On Wed, Nov 8, 2023 at 3:46 PM Alexander Strasser wrote:
>
> > On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > > > On Mon, Oct 30, 2023 at 02:11:27P
On 2023-11-09 11:13 +0100, Anton Khirnov wrote:
> Quoting Alexander Strasser (2023-11-08 21:55:10)
> > On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > > > On Mon, Oct 30, 2023 at 02:11:27PM +
On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote:
> > > Section 7.4.4 of the MPEG-2 specifications requires that the
> > > last bit of the last coefficient be toggled so that
On 2023-10-16 00:49 +0200, Michael Niedermayer wrote:
> This explains how to request refunds and what can be funded by SPI
>
> Co-Author: Stefano Sabatini
> ---
> doc/spi.txt | 73 +
> 1 file changed, 73 insertions(+)
> create mode 100644
Hi all,
hi J-B!
On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> Yo,
>
> Time is up, results are here:
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf
Should I have been mailed about this vote?
I'm pretty sure I could vote in 2020. Or am I just missing something?
On 2021-05-16 21:18 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser (2021-05-15 20:20:30)
[...]
> >
> > Returning to the code I quoted before now and stating my
> > understanding of if now.
> >
> > def write__AMF_date(time)
> > write__UI8
Hi Anton!
On 2021-05-14 10:09 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser (2021-05-12 01:04:28)
> >
> > If the timezone data of an AMF 0 date type is non-zero, include that
> > information as UTC offset in hours and minutes.
> > ---
>
On 2021-05-11 17:51 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser (2021-05-10 15:35:02)
> > On 2021-05-10 10:22 +0200, Anton Khirnov wrote:
> > > Export them in UTC, not the local timezone. This way the output is
> > > the same everywhere. The timezone inf
On 2021-05-10 10:22 +0200, Anton Khirnov wrote:
> Export them in UTC, not the local timezone. This way the output is
> the same everywhere. The timezone information stored in the file is
> still ignored, since there seems to be no simple way to export it
> correctly.
>
> Format them according to
First about this discussion in general:
There is a reason this is tagged RFC and the other thread is called
proposal. I hope we can go on with the vivid discussions while keeping
in mind that it is not yet narrowed down and nothing is decided.
Always constraining all ideas, is not a good way to
Hi Jim!
On 2020-08-22 14:09 -0700, Jim DeLaHunt wrote:
> On Fri Aug 21 15:35:38 EEST 2020, Nicolas George wrote:
> > 1. What would you think about putting the documentation for
> > libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi …
> > 2. What would you think about switching from
Hi all,
hi Paul!
Shouldn't it have been also reflected in the commit's metadata,
author or message, that the encoder was originally written by
Todd Kirby and David Adler?
Did you base it on the version from Jaikrishnan Menon?
If yes, I think it should have been mentioned in the commit message
On 2020-08-22 12:59 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-15):
> > If I'm not mistaken that reason for the rewrite didn't make
> > it into the commit message:
>
> You are right. The reason for the complete rewrite was that the original
> code was compl
Hi Nicolas,
hi Clement!
Wow the discussion gets up to speed quickly :)
Thanks for bringing up all those good points!
I'm intentionally top-posting, because I want to say something
concerning the points you discuss below. Though I couldn't find
a good way to do it in a comment style, so instead
On 2020-08-21 14:35 +0200, Nicolas George wrote:
> 1. What would you think about putting the documentation for
>libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
>of into huge doc/filters.texi (25k lines!)? And same for codecs,
>formats, etc.
>
>We can adopt this
On 2020-08-21 15:02 +0200, Jean-Baptiste Kempf wrote:
>
>
> On Fri, 21 Aug 2020, at 14:35, Nicolas George wrote:
> > 2. What would you think about switching from texinfo to a small basic
> >subset of HTML for new documentation?
> >
> >I think most of us are much more familiar with HTML
On 2020-08-21 14:32 +0200, Clément Bœsch wrote:
> On Tue, Aug 18, 2020 at 11:43:29PM +0200, Michael Niedermayer wrote:
> > On Tue, Aug 18, 2020 at 10:45:50PM +0200, Clément Bœsch wrote:
> > > On Tue, Aug 11, 2020 at 02:19:01PM +0200, Clément Bœsch wrote:
> > > [...]
> > > > +FATE_SUBTITLES-$(call
On 2020-08-21 20:46 +1000, Alex Pokotilo wrote:
> On Fri, Aug 21, 2020 at 7:54 PM Nicolas George wrote:
> >
> > Alex Pokotilo (12020-08-21):
> > > From b3739e33fa04a9292dc6584bd2f31460aa53d478 Mon Sep 17 00:00:00 2001
> > > From: Alex Pokotilo
> > > Date: Fri, 21 Aug 2020 09:14:37 +
> > >
Hi Mark,
thanks for your opinion on this!
On 2020-08-20 23:35 +0100, Mark Thompson wrote:
> On 20/08/2020 22:20, Alexander Strasser wrote:
> > Please pardon me for bringing this up in the context of this patch.
> > No objections or particular opinion regarding this instance of
On 2020-08-20 19:49 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-17):
> > I think the pendulum can swing in both direction here. So the overall
> > effect is not clear to me. E.g. one developer may think
> >
> > "hey what's this -> i need to
On 2020-08-20 22:32 +0200, Michael Niedermayer wrote:
> On Thu, Aug 20, 2020 at 12:46:12PM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > On Wed, Aug 19, 2020 at 12:00:37AM +0200, Andreas Rheinhardt wrote:
> > >> Signed-off-by: Andreas Rheinhardt
> > >> ---
> > >> The memleak can
On 2020-08-20 01:10 +, Guo, Yejun wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Alexander Strasser
> > Sent: 2020年8月20日 4:06
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH V4
Hi Yejun!
On 2020-08-18 23:08 +0800, Guo, Yejun wrote:
> Signed-off-by: Guo, Yejun
> ---
> v3: use AVOption
> v4: don't add new file dnn_common.h/c
>
> libavfilter/dnn/dnn_backend_openvino.c | 50
> +-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff
Hi Paul,
sorry, forgot to reply to this...
On 2020-08-15 12:55 +0200, Paul B Mahol wrote:
> On 8/15/20, Alexander Strasser wrote:
> > On 2020-08-14 20:22 +0100, Derek Buitenhuis wrote:
> >> On 14/08/2020 20:13, Paul B Mahol wrote:
> >> > What specific insults in th
On 2020-08-16 23:12 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-16):
> > I dislike the negative name too, because like mentioned by Marton it
> > doesn't work well with overriding the option to turn it off.
> >
> > On one hand for this optio
Hi Nicolas!
On 2020-08-16 23:03 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-16):
> > This was uncalled for and not nice at all!
>
> I will be correct, but I'm done being nice with him.
It was an unneeded accusation. Thanks for trying to not repeat those.
> &
Hi Zane,
sorry for this late remark.
On 2020-08-09 23:45 +, Zane van Iperen wrote:
> Only when the user hasn't manually specified one.
> Matches the original files more closely.
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_asf.c | 20 +---
> 1 file changed,
On 2020-08-13 22:32 +0200, Michael Niedermayer wrote:
> On Wed, Aug 12, 2020 at 08:58:30PM +0200, Alexander Strasser wrote:
> > On 2020-08-09 14:56 +0200, Michael Niedermayer wrote:
[...]
> > >
> > > lib user
> > >
> > > > If I'm not mi
On 2020-08-16 18:27 +0200, Nicolas George wrote:
> Marton Balint (12020-08-16):
> > Can we find a shorter name for the option? E.g. simply call the option
> > auto_conversion_filters and the user can use -noauto_conversion_filters to
> > disable it... In the next patch with the current name you
On 2020-08-16 18:39 +0200, Nicolas George wrote:
> Paul B Mahol (12020-08-16):
> > I do not like long name either.
>
> And do you have a better reason than the fact that it comes from me?
This was uncalled for and not nice at all!
It's neither good for you nor the community.
There is nothing
Hi Derek,
hi all!
On 2020-08-14 20:22 +0100, Derek Buitenhuis wrote:
> On 14/08/2020 20:13, Paul B Mahol wrote:
> >> Resending because I accidentally replied to James instead of the list.
> >> Woops.
> >>
> >> I guess it was not clear to me this is not the initial thread, since it is
> >> not
>
On 2020-08-13 00:13 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-12):
> > Stupid question: Why do we transform relative URLs at all?
> >
> > Isn't it normally supposed to work for HTTP on the server-side too?
> >
> > Many clients seem to do it. Ju
On 2020-08-14 11:34 +0200, Jean-Baptiste Kempf wrote:
> On Wed, 12 Aug 2020, at 14:38, Alexander Strasser wrote:
> > On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> > > On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > > > Definitions of non-ob
Am 14. August 2020 14:07:23 MESZ schrieb "Xu, Guangxin" :
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>Guo,
>> Yejun
>> Sent: Friday, August 14, 2020 9:50 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH V2] dnn_backend_openvino.c: parse
>options
>>
On 2020-08-09 14:56 +0200, Michael Niedermayer wrote:
> On Sun, Aug 09, 2020 at 02:24:34PM +0200, Alexander Strasser wrote:
> >
> >
> > Am 9. August 2020 12:56:53 MESZ schrieb Michael Niedermayer
> > :
> > >On Fri, Aug 07, 2020 at 11:26:58PM +0200, Alexand
Hi all!
On 2020-08-12 14:53 +, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George | Thu Jul 30
> 00:02:10 2020 +0200| [1201687da268c11459891a80ca1972aeaca8db88] | committer:
> Nicolas George
>
> lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose().
>
> Also add
On 2020-08-09 14:54 +0200, Michael Niedermayer wrote:
> On Fri, Aug 07, 2020 at 11:26:17PM +0200, Alexander Strasser wrote:
> > Snow uses the ratecontrol module, but does not expose a way to set
> > the rc_eq expression. The default expression, set in the ratecontrol
> >
On 2020-07-31 09:45 +0800, myp...@gmail.com wrote:
> On Fri, Jul 31, 2020 at 3:47 AM Alexander Strasser wrote:
> >
> > On 2020-07-30 21:18 +0800, myp...@gmail.com wrote:
> > >
> > > After repeated thinking， I can accept this solution, thx
> >
On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote:
> On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote:
> > Definitions of non-obvious data should have a short comment
> > explaining their origin.
> >
> > If the data is of mathematic
On 2020-08-09 13:13 +0200, Nicolas George wrote:
> Alexander Strasser (12020-08-09):
> > >> Andreas:
[...]
>
> > At least the aspect Mark mentioned below.
> >
> > In general I think it could be worded a bit clearer and easier to grasp.
> > Basically
Hi Zane,
thanks for addressing my comments in v3.
AFAICS you also took Andreas' feedback into account, but I didn't
check that.
No more remarks from me.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Am 9. August 2020 14:33:26 MESZ schrieb Zane van Iperen
:
>On Sun, 9 Aug 2020 09:29:16 +0200
>"Paul B Mahol" wrote:
>
>>
>> This is really bad practice.
>>
>
>Usually I'd agree. However (and I've just checked this) all file
>versions are identical.
>
>Since this is an Argonaut Games format,
Am 8. August 2020 14:52:02 MESZ schrieb Zane van Iperen
:
>On Sat, 08 Aug 2020 13:05:28 +0200
>"Alexander Strasser" wrote:
>
>> >@@ -296,8 +298,7 @@ static int argo_asf_write_header(AVFormatContext
>> >*s)
>> > ArgoASFContext *ctx
Am 9. August 2020 12:56:53 MESZ schrieb Michael Niedermayer
:
>On Fri, Aug 07, 2020 at 11:26:58PM +0200, Alexander Strasser wrote:
>> Don't pass a potential NULL pointer to av_log, instead use a default
>> in the rc_eq AVOption definitions. Now the context variable always
&g
Hi Nicolas!
Am 8. August 2020 23:26:02 MESZ schrieb Mark Thompson :
>On 08/08/2020 18:57, Nicolas George wrote:
[...]
>> Andreas:
I'm sure the following was addressed at me.
>>> Not sure I agree with your definition of Libre Software and your
>exact
>>
>> I was more trying to express the
Hi Zane!
Am 8. August 2020 10:01:07 MESZ schrieb Zane van Iperen
:
>Signed-off-by: Zane van Iperen
>---
> libavformat/argo_asf.c | 37 +++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
>diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
>index
On 2020-08-02 20:49 +0200, Michael Niedermayer wrote:
> On Sat, Aug 01, 2020 at 11:23:36PM +0200, Alexander Strasser wrote:
> > Hi Michael!
> >
> > On 2020-07-31 19:54 +0200, Michael Niedermayer wrote:
> > > On Thu, Jul 30, 2020 at 02:42:30PM +0200, Alexander Stra
Hi Nicolas!
On 2020-08-03 11:54 +0200, Nicolas George wrote:
> Nicolas George (12020-07-31):
> > Something like this would be acceptable:
> >
> > /* Reverse-engineered by encoding various files with the reference
> >encoder. */
> >
> > Reluctance to give this little information is baffling to
the context too.
Signed-off-by: Alexander Strasser
---
libavcodec/mpegvideo.h | 2 +-
libavcodec/ratecontrol.c | 3 +--
libavcodec/snowenc.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 29e692f245..d2515a3bbf
options definition of rc_eq (libavcodec/mpegvideo.h), with some
minor style adjustments to be closer to the other snowenc option
initializer expressions.
Signed-off-by: Alexander Strasser
---
libavcodec/snowenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/snowenc.c b
Hi Michael!
On 2020-07-31 19:54 +0200, Michael Niedermayer wrote:
> On Thu, Jul 30, 2020 at 02:42:30PM +0200, Alexander Strasser wrote:
> > Don't pass a potential NULL pointer to av_log, instead use a default
> > in the rc_eq AVOption definitions. Now the context variable a
On 2020-07-30 21:18 +0800, myp...@gmail.com wrote:
>
> After repeated thinking， I can accept this solution, thx
Just to avoid confusion. You accept this
> > > > avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;
or this
> > If you are aiming for improving accuracy, I guess
Hi!
On 2020-07-30 12:16 +, Zane van Iperen wrote:
> On Fri, 31 Jul 2020 00:55:56 +0800
> "zongwave" wrote:
[...]
>
> > ++static av_cold int xcam_init(AVFilterContext *ctx)
> > ++{
> > ++XCAMContext *s = ctx->priv;
> > ++int ret = 0;
> > ++
> > ++s->handle =
Don't pass a potential NULL pointer to av_log, instead use a default
in the rc_eq AVOption definitions. Now the context variable always
holds a string; even if it's the default expression.
Note this also fixes the evaluation error path, where a similar
av_log references the rc_eq string from the
On 2020-07-28 20:43 +0800, zhilizhao wrote:
> > On Jul 28, 2020, at 8:02 PM, Nicolas George wrote:
> >
> > zhilizhao (12020-07-28):
> >> I think jb is referring to
> >>
> >> FILE *open_memstream(char **bufp, size_t *sizep);
> >> https://linux.die.net/man/3/open_memstream
> >>
On 2020-07-24 19:56 +0800, zhilizhao wrote:
>
>
> > On Jul 24, 2020, at 9:40 AM, myp...@gmail.com wrote:
> >
> > On Fri, Jul 24, 2020 at 4:43 AM Alexander Strasser > <mailto:eclip...@gmx.net>> wrote:
> >>
> >> On 2020-07-01 21:05 +0200, Ale
Hi Michael!
On 2020-07-24 00:11 +0200, Michael Niedermayer wrote:
> Fixes: shift exponent 128 is too large for 32-bit type 'int'
> Fixes:
> 23860/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5751138914402304
>
> Found-by: continuous fuzzing process
>
On 2020-07-22 11:56 +0200, Nicolas George wrote:
> James Almer (12020-07-20):
> > No, i'll push v3 soon if my argumentation below was not enough to
> > convince Nicolas or Michael. My intention is to use ints for the new
> > function, not to postpone committing it in any form indefinitely.
>
>
On 2020-07-01 21:05 +0200, Alexander Strasser wrote:
> On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> > Quoting Jun Zhao (2020-06-29 15:23:10)
> > > From: Jun Zhao
> > >
> > > Fix the potential overflow.
> > >
> > > Suggested
On 2020-07-19 23:38 +0200, Andreas Rheinhardt wrote:
> Alexander Strasser:
[...]
> >
> > On 2020-07-17 13:14 +0200, Andreas Rheinhardt wrote:
> >> Andreas Rheinhardt:
> >>> Signed-off-by: Andreas Rheinhardt
> >>> ---
> >>> libavformat
Hi Andriy!
On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> On Sun, 19. Jul 23:19, Alexander Strasser wrote:
> > On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> > > On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
[...]
> > > > --- a/libavdevice/xcbgrab.c
>
On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
[...]
> > Subject: [PATCH] avdevice/xcbgrab: check return values of xcb query
> > functions
> >
> > Fixes #7312, segmentation fault on close of X11 server
> >
> > xcb_query_pointer_reply() and
Hi all,
this mail thread has turned into an example of exactly what I would
not like to see in a patch discussion!
It doesn't really respect the first sentence of our code of conduct:
Be friendly and respectful towards others and third parties.
Furthermore it discourages testing, code
Hi Andreas,
no objections for the patchset as a whole.
Just for the first in the series I have some questions.
The commit message is:
avformat/au: Store strings instead of pointers to strings in array
This tells the what, but not the why.
On 2020-07-17 13:14 +0200, Andreas Rheinhardt
Hi Paul!
Only doc comments. Feel free to apply the changes when the real
review has completed.
On 2020-07-12 13:01 +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 46
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
>
381574979cb04be10c9168540310afad
> > +nv16 d3a50501d2ea8535489fd5ec49e7866d
> > nv210fdeb2cdd56cf5a7147dc273456fa217
> > nv24 193b9eadcc06ad5081609f76249b3e47
> > nv421738ad3c31c6c16e17679f5b09ce4677
> >
On 2020-07-04 23:19 -0400, Andriy Gelman wrote:
> On Sun, 05. Jul 09:37, lance.lmw...@gmail.com wrote:
> > On Sat, Jul 04, 2020 at 01:03:48PM -0400, Andriy Gelman wrote:
> > > On Mon, 29. Jun 09:26, Valery Kot wrote:
> > > > On Sun, Jun 28, 2020 at 12:03 AM Andriy Gelman
> > > > wrote:
> > > > >
Hi all!
On 2020-07-01 17:05 +0200, Anton Khirnov wrote:
> Quoting Nicolas George (2020-06-27 17:16:44)
> > Signed-off-by: Nicolas George
> > ---
> > libavutil/avrefcount_template.h | 140
> > tests/ref/fate/source | 1 +
> > 2 files changed, 141
On 2020-06-29 16:04 +0200, Jean-Baptiste Kempf wrote:
> Hello,
>
> The next step in the community voting process is to re-elect the Community
> and Technical Committees.
>
> Therefore, we need candidates.
>
> Reminders:
> The community committee is here to help smooth things down between people
Hi Anton,
hi Jun!
On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> Quoting Jun Zhao (2020-06-29 15:23:10)
> > From: Jun Zhao
> >
> > Fix the potential overflow.
> >
> > Suggested-by: Alexander Strasser
> > Signed-off-by: Jun Zhao
> > ---
On 2020-06-28 22:23 +0200, Marton Balint wrote:
>
>
> On Sun, 28 Jun 2020, Michael Niedermayer wrote:
>
> > On Sun, Jun 28, 2020 at 01:22:58PM +0100, Derek Buitenhuis wrote:
> > > On 26/06/2020 14:49, Nicolas George wrote:
> > > > Probably a good idea, but these explanation should probably go in
>
On 2020-06-28 22:44 +0200, Michael Niedermayer wrote:
> On Sun, Jun 28, 2020 at 08:13:28PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > This patch adds a pgx decoder.
> > ---
> > Changelog | 1 +
> > doc/general.texi| 2 +
> >
On 2020-06-28 21:10 +0800, myp...@gmail.com wrote:
> On Sun, Jun 28, 2020 at 5:30 AM Alexander Strasser wrote:
> >
> > On 2020-06-26 01:56 +, Jun Zhao wrote:
> > > ffmpeg | branch: master | Jun Zhao | Sun May 17
> > > 12:10:05 2020 +0800| [60d79b1
On 2020-06-26 01:56 +, Jun Zhao wrote:
> ffmpeg | branch: master | Jun Zhao | Sun May 17
> 12:10:05 2020 +0800| [60d79b1df9d4c6030010ccb0c134ede9e33158c2] | committer:
> Jun Zhao
>
> lavc/aac_ac3_parser: improve the raw AAC file bit rate calculation
>
> Now we just use one ADTS raw frame to
On 2020-06-21 21:19 +0200, Alexander Strasser wrote:
> On 2020-06-21 12:49 +, Paul B Mahol wrote:
> > ffmpeg | branch: master | Paul B Mahol | Sun Jun 21
> > 14:46:29 2020 +0200| [842bc312ade8fab82465423b22c4fbe3bee63383] |
> > committer: Paul B Mahol
> >
&g
Hi Paul!
On 2020-06-21 12:49 +, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol | Sun Jun 21
> 14:46:29 2020 +0200| [842bc312ade8fab82465423b22c4fbe3bee63383] | committer:
> Paul B Mahol
>
> avfilter/af_ladspa: check another directory for plugins
>
> >
Am 20. Juni 2020 00:23:53 MESZ schrieb Hendrik Leppkes :
>On Fri, Jun 19, 2020 at 9:58 PM Alexander Strasser
>wrote:
>>
>> How do others think about adding support for more pixel formats?
>>
>
>A new pixel format should present a clear improvement, a use-case you
Hi Valery!
On 2020-06-19 17:15 +0200, Valery Kot wrote:
> vf_edgedetect video filter implements Canny algorithm
> (https://en.wikipedia.org/wiki/Canny_edge_detector)
>
> Important part of this algo is the double threshold step: pixels above
> "high" threshold being kept, pixels below "low"
On 2020-06-19 20:41 +0200, Carl Eugen Hoyos wrote:
> Am Fr., 19. Juni 2020 um 20:33 Uhr schrieb Cristian Bicheru
> :
> >
> > On Fri, Jun 19, 2020 at 12:53 PM Carl Eugen Hoyos
> > wrote:
> > >
> > > Am Fr., 19. Juni 2020 um 18:42 Uhr schrieb :
> > > >
> > > > From: Cristian Bicheru
> > > >
> > >
Hi Nicolas!
On 2019-08-08 11:43 +0200, Nicolas George wrote:
> Andreas Håkon (12019-08-08):
> > > setpts or setts, similar to lavfi.
>
> > Then I proposse these two alternatives:
> >
> > 1) "editpts_bsf"
> > 2) "setpts_bsf"
> >
> > The "_bsf" is not real, only to differenciate (here) from other
On 2019-08-07 15:51 +, Andreas Håkon wrote:
> Hi,
>
> This new version changes the name of the filter, and implements all
> suggestions.
Sorry, I couldn't reply earlier.
Thanks for renaming; "timeshift" sounds better to me, compared to
the previous "timer".
Other suggestions which I came
On 2019-08-07 21:28 +0200, Marton Balint wrote:
>
> On Wed, 7 Aug 2019, Alexander Strasser wrote:
>
> > Hi Marton!
> >
> > Not really sure if we need the API, but it definitely looks
> > handy. Just not sure how often it will used and really result
> > in cle
Hi Andreas!
On 2019-08-05 17:25 +, Andreas Håkon wrote:
> On Monday, 5 de August de 2019 17:31, Moritz Barsnick
> wrote:
>
[...]
> > > +static const AVClass timer_class = {
> > > + .class_name = "timer",
> >
> > In about half of the existing BSFs, this would be called "timer_bsf". I
> >
On 2019-08-06 22:51 +0200, Nicolas George wrote:
> Tomas Härdin (12019-08-06):
> > I think they should. See
>
> Documenting the coding standard and changing it are different matters.
I guess a change was intended, because it should be fairly obvious
that in the current code base the described
Hi Marton!
Not really sure if we need the API, but it definitely looks
handy. Just not sure how often it will used and really result
in clearer or shorter code.
Not opposed to it though; no strong opinion on this one.
Some comments follow inline. No in depth review, just what
came to my mind
On 2019-06-25 00:08 +0200, Alexander Strasser wrote:
> On 2019-06-05 22:04 +0200, Alexander Strasser wrote:
> > From: Stephan Hilb
> >
> > Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2ff4
> > .
> >
> > For some devices (
1 - 100 of 197 matches
Mail list logo
