On Thu, 2021-08-12 at 03:22 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Thursday, 12 August 2021 04:34
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK
On Wed, 2021-08-11 at 17:22 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Soft Works
> > Sent: Tuesday, 10 August 2021 11:53
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a
> > hwdevice, sea
James Wrote:
> On 8/11/2021 10:11 AM, Kieran Kunhya wrote:
> > On Wed, 11 Aug 2021 at 13:31, James Almer wrote:
> >
> >> You can disable AVX512 at both runtime and compile time. I don't
> >> think that because there's one CPU arch out there that sees a hit in
> >> performance for one instruction
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Thursday, 12 August 2021 09:05
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK
> runtime to choose LowPower/non-LowPower modes
>
> On Thu, 2021-08-12 at 03:2
Paul Buxton (12021-08-12):
> From the point of view of someone who is currently developing a filter for
> ffmpeg and will be submitting a patch to the list for the first time, I
> think this is a great idea.Whilst following simple instructions to prepare
> and submit a patch should't be outside the
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Thursday, 12 August 2021 10:51
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> TL;DR: Do not make
>
>
> # Thanks for your proposal. Your input will not be considered because it
> # contains obvious and easily avoided flaws:
> # [x] not following mailing-list rules;
> # [x] not following coding style conventions;
> # [ ] mangled or misformatted patch;
> # [ ] problems of code hygiene;
> # [x] ba
On 2021-08-12 03:48 pm, Kieran Kunhya wrote:
# Thanks for your proposal. Your input will not be considered because it
# contains obvious and easily avoided flaws:
# [x] not following mailing-list rules;
# [x] not following coding style conventions;
# [ ] mangled or misformatted patch;
# [ ] p
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Kieran Kunhya
> Sent: Thursday, 12 August 2021 12:19
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
[..]
> It is practicall
On Wed, 04 Aug 2021 19:00:48 +0200 Niklas Haas wrote:
> +if ((sd = av_frame_get_side_data(cur->f,
> AV_FRAME_DATA_FILM_GRAIN_PARAMS))) {
> +AVFilmGrainParams *fgp = (AVFilmGrainParams *) sd->data;
> +fgp->seed = cur->poc + h->poc_offset << 5;
> +}
The order on this is wro
Kieran Kunhya (12021-08-12):
> It is practically impossible to use git send-email without running your own
> mail server and having all the problems that entails (managing spam, making
> sure you are not blacklisted etc).
You can set up a mail server configured to only accept outgoing e-mail
and r
Soft Works (12021-08-12):
> I'm using a git client that can also submit PRs to GitHub and that
> has always been fine and sufficient for hundreds of projects I've been
> working on or contributed to.
If your client can send PR to GitHub and not send e-mail, it is just
ridiculous.
Regards,
--
Soft Works (12021-08-12):
> Assuming that developers who submit patches via GitHub would be less
> skilled than those who work with a mailing list is arrogant and
> far away from reality.
Fortunately, that is not what I wrote. You could just have read my
arguments more carefully instead of subjec
On Thu, 12 Aug 2021, 13:11 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > It is practically impossible to use git send-email without running your
> own
> > mail server and having all the problems that entails (managing spam,
> making
> > sure you are not blacklisted etc).
>
> You can s
Kieran Kunhya (12021-08-12):
> Thank you for confirming you need to setup a mail server to use git
> send-email.
Can you clarify: is your problem that you do not know the difference
between a client and a server, or is is more broadly that you cannot
read sentences more than a few words long?
--
On Thu, 12 Aug 2021, 13:23 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Thank you for confirming you need to setup a mail server to use git
> > send-email.
>
> Can you clarify: is your problem that you do not know the difference
> between a client and a server, or is is more broadly
Kieran Kunhya (12021-08-12):
> Can you first clarify where this SMTP server comes from as you conveniently
> ignored this point?
I already wrote: "the SMTP server of your mail provider".
--
Nicolas George
signature.asc
Description: PGP signature
__
On Thu, 12 Aug 2021, 13:29 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Can you first clarify where this SMTP server comes from as you
> conveniently
> > ignored this point?
>
> I already wrote: "the SMTP server of your mail provider".
>
And how do the 1.5 billion Gmail users use SM
Kieran Kunhya (12021-08-12):
> And how do the 1.5 billion Gmail users use SMTP without disabling security
> features?
Do I need to do tech support for Google too?
https://support.google.com/mail/answer/7126229?hl=en
https://support.google.com/accounts/answer/185833?hl=en
--
Nicolas George
s
---
libavformat/mxf.h| 1 +
libavformat/mxfdec.c | 356 ++-
2 files changed, 351 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index fe9c52732c..cddbcb13c9 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -5
On Thu, 12 Aug 2021, at 14:35, Nicolas George wrote:
> Kieran Kunhya (12021-08-12):
> > And how do the 1.5 billion Gmail users use SMTP without disabling security
> > features?
>
> Do I need to do tech support for Google too?
No, but you can talk to people nicely.
--
Jean-Baptiste Kempf - P
On Thu, 12 Aug 2021, 13:35 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > And how do the 1.5 billion Gmail users use SMTP without disabling
> security
> > features?
>
> Do I need to do tech support for Google too?
>
> https://support.google.com/mail/answer/7126229?hl=en
> https://suppo
Jean-Baptiste Kempf (12021-08-12):
> No, but you can talk to people nicely.
Fair enough.
Can you call out Kieran too for his passive-aggressive "thank you for
confirming [the opposite of what I wrote]", please? It was not nice
either.
Regards,
--
Nicolas George
signature.asc
Description: P
Kieran Kunhya (12021-08-12):
> Thank you for confirming security features must be disabled. As you know
> email is quite important for societal records such as vaccination
> certificates and so I (and many others) will not be disabling security on
> my email account.
>
> And I won't make another o
On Thu, 12 Aug 2021, 13:41 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Thank you for confirming security features must be disabled. As you know
> > email is quite important for societal records such as vaccination
> > certificates and so I (and many others) will not be disabling sec
Kieran Kunhya (12021-08-12):
> So your walled garden that separates literally billions of people is the
> right one?
E-mail is, by construction, not a walled garden precisely because
you can use the software of your choice and interoperate with many
operators.
You have asked me to spare you a ra
On 8/12/2021 9:08 AM, Niklas Haas wrote:
On Wed, 04 Aug 2021 19:00:48 +0200 Niklas Haas wrote:
+if ((sd = av_frame_get_side_data(cur->f,
AV_FRAME_DATA_FILM_GRAIN_PARAMS))) {
+AVFilmGrainParams *fgp = (AVFilmGrainParams *) sd->data;
+fgp->seed = cur->poc + h->poc_offset << 5
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Thursday, 12 August 2021 14:18
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
>
> Soft Works (12021-
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Thursday, 12 August 2021 14:18
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> If you want to inte
On Thu, Aug 12, 2021 at 12:53:31AM -0400, maryam ebrahimzadeh wrote:
> ---
> libavcodec/vc1dec.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
This breaks fate-vc1_sa20021
--- ./tests/ref/fate/vc1_sa200212021-08-06 11:56:29.601679428 +0200
+++ tests/data/fate/vc1_sa2002
On Thu, Aug 12, 2021 at 3:45 PM wrote:
> I agree with softworkz here. There are skilled programmers who like mailing
> lists, and ones that don't. Same goes with unskilled prorammers as well. The
> times are changing and the project needs to be ready for that. Not everyone
> even likes mailing
On 8/12/2021 1:53 AM, maryam ebrahimzadeh wrote:
---
libavcodec/vc1dec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 1fb1950ade..07d60294f2 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -444,7 +444,
Besides being nicer code this also has the advantage of not making
assumptions about the internal implementation: While it is documented
that the AVFilter.inputs and AVFilter.outputs arrays are terminated
by a zeroed sentinel, one is not allowed to infer that one can just
check avfilter_pad_get_nam
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 6 +++---
libavfilter/avfilter.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 96d38803df..24bcdc6b62 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@
It is unnecessary as the number of static inputs and outputs can now
be directly read via AVFilter.nb_(in|out)puts.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/avfilter.h | 5 +
libavfilter/version.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/libavfilter/avfilter.h b/liba
August 12, 2021 8:39 AM, "Kieran Kunhya" wrote:
> On Thu, 12 Aug 2021, 13:35 Nicolas George, wrote:
>
>> Kieran Kunhya (12021-08-12):
>> And how do the 1.5 billion Gmail users use SMTP without disabling
>> security
>> features?
>>
>> Do I need to do tech support for Google too?
>>
>> https://
August 12, 2021 5:11 AM, "Soft Works" wrote:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Nicolas George
>> Sent: Thursday, 12 August 2021 10:51
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nice
August 12, 2021 4:51 AM, "Nicolas George" wrote:
> Paul Buxton (12021-08-12):
>
>> From the point of view of someone who is currently developing a filter for
>> ffmpeg and will be submitting a patch to the list for the first time, I
>> think this is a great idea.Whilst following simple instructi
On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/outdevs.texi| 6 ++
libavdevice/decklink_common.cpp | 9 +
libavdevice/decklink_common.h | 8
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink
On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
configure | 2 +-
doc/outdevs.texi| 5 +
libavdevice/decklink_common.cpp | 7 +++
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_enc_c.c
On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/outdevs.texi| 5 +
libavdevice/decklink_common.cpp | 17 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_enc_c.c| 4
4 files chang
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
ind
On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/indevs.texi | 16 +++-
doc/outdevs.texi| 16 +++-
libavdevice/decklink_common.cpp | 4 ++--
libavdevice/decklink_common.h | 11 +
On 8/12/2021 5:03 PM, Michael Niedermayer wrote:
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/frame_thre
On Thu, 12 Aug 2021, Hu Weiwen wrote:
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.
Signed-off-by: Hu Weiwen
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
On Thu, 12 Aug 2021, Hu Weiwen wrote:
"frag_start" is redundant, and every occurance can be replaced with
cluster[0].dts - start_dts
I think I can agree about this, so I think the patch should be fine,
thanks for taking the time to study it in detail!
My own mental model of the code, having
---
libavcodec/vc1dec.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 1fb1950ade..bc76a07ca6 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -444,7 +444,9 @@ static av_cold int vc1_decode_init(AVCodecCo
---
libavcodec/vp6.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
index 73822a00f9..d024370793 100644
--- a/libavcodec/vp6.c
+++ b/libavcodec/vp6.c
@@ -167,7 +167,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int
On 8/12/2021 5:46 AM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Xiang, Haihao
Sent: Thursday, 12 August 2021 09:05
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK
runtime to choose LowPower/non-LowPower modes
O
Hi,
I have a question: Is there a specific reason why AVFrame does not have
a property indicating the AVMediaType?
Instead, the type is mostly tried to be inferred from other properties, e.g.
AVMEDIA_TYPE_VIDEO when width and height are specified or channel format
in case of audio.
Though I don
> 2021年8月12日 下午10:03，Diederick C. Niehorster 写道：
>
> On Thu, Aug 12, 2021 at 3:45 PM wrote:
>> I agree with softworkz here. There are skilled programmers who like mailing
>> lists, and ones that don't. Same goes with unskilled prorammers as well. The
>> times are changing and the project nee
On Thu, Aug 12, 2021 at 09:49:01PM +0200, Marton Balint wrote:
>
>
> On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > configure | 2 +-
> > doc/outdevs.texi| 5 +
> > libavdevice/dec
On Thu, Aug 12, 2021 at 10:05:47PM +0200, Marton Balint wrote:
>
>
> On Tue, 10 Aug 2021, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/indevs.texi | 16 +++-
> > doc/outdevs.texi| 16 +
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Steven Liu
> Sent: Friday, 13 August 2021 05:01
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Steven Liu
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
>
>
> Hi
On Tue, 2021-08-10 at 09:52 +, Soft Works wrote:
> The test /libavutil/tests/hwdevice checks that when deriving a device
> from a source device and then deriving back to the type of the source
> device, the result is matching the original source device, i.e. the
> derivation mechanism doesn't c
I say leave it as is.
There's nothing stopping people from submitting a GitHub PR to the mirror repo.
If a maintainer
sees it and decides to pick it up, then they can re-post it to the ML. Imo,
that's completely up to them.
Also, git send-email takes about 2 minutes to configure. Gmail, Yahoo,
> 2021年8月13日 下午1:12，Soft Works 写道：
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Steven Liu
>> Sent: Friday, 13 August 2021 05:01
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Cc: Steven Liu
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion
On Tue, 2021-08-10 at 09:52 +, Soft Works wrote:
> The test /libavutil/tests/hwdevice checks that when deriving a device
> from a source device and then deriving back to the type of the source
> device, the result is matching the original source device, i.e. the
> derivation mechanism doesn't c
58 matches
Mail list logo
