Hey everyone,
I posted this patch almost a month ago and got no reaction. Is there anything
else I have to/can do to get this fix merged? I’m a little bit worried that it
gets lost.
- Anselm
> Am 21.07.2021 um 20:00 schrieb Anselm Busse :
>
> This commit fixes the bug as report in https://tra
In particular, document that av_opt_copy() always disentangles
allocated options even on error; this guarantee is needed to e.g.
properly free duplicated thread contexts in libavcodec on error.
Signed-off-by: Andreas Rheinhardt
---
Missing APIchanges entry and version bump (minor or micro?).
li
Any update on this?
Kind Regards,
Dylan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> On Aug 13, 2021, at 3:00 PM, Anselm Busse wrote:
>
> Hey everyone,
>
> I posted this patch almost a month ago and got no reaction. Is there anything
> else I have to/can do to get this fix merged? I’m a little bit worried that
> it gets lost.
LGTM.
>
> - Anselm
>
>> Am 21.07.2021 um 20
Soft Works (12021-08-12):
> Yes, that's not what you wrote, but that attitude was shining out
> between the lines very clearly.
You are entirely responsible for your interpretation and all the
negative consequences it entails.
> > If you want the project to change its way of working to accommodat
From: Limin Wang
Reviewed-by: Marton Balint
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_enc.cpp| 2 ++
liba
From: Limin Wang
Reviewed-by: Marton Balint
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| 4
5 files cha
From: Limin Wang
Reviewed-by: Marton Balint
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 changed, 27 insertions(+)
di
From: Limin Wang
Reviewed-by: Marton Balint
Signed-off-by: Limin Wang
---
doc/indevs.texi | 16 +++-
doc/outdevs.texi| 16 +++-
libavdevice/decklink_common.cpp | 8 ++--
libavdevice/decklink_common.h | 11 +++
libavdevice/d
On Fri, Jul 23, 2021 at 4:31 AM Hao Guan wrote:
> Signed-off-by: Hao Guan
> ---
>
> Notes:
> I have checked out the code about other functions introduced after
> macOS 10.13 and noticed that the availability is checked during configure.
> Therefore I add the check for sRGB function too. It s
Anselm Busse (12021-08-13):
> Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc
To whoever pushed this: this is not a correct first line for a commit
message. It should have been something like:
libavc/videotoolboxenc: do not override B-frames parameter.
i.e.: first a context b
On Fri, Aug 13, 2021 at 5:39 AM "zhilizhao(赵志立)"
wrote:
>
>
> > On Aug 13, 2021, at 3:00 PM, Anselm Busse
> wrote:
> >
> > Hey everyone,
> >
> > I posted this patch almost a month ago and got no reaction. Is there
> anything else I have to/can do to get this fix merged? I’m a little bit
> worrie
> On Aug 13, 2021, at 9:12 AM, Nicolas George wrote:
>
> Anselm Busse (12021-08-13):
>> Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc
>
> To whoever pushed this: this is not a correct first line for a commit
> message. It should have been something like:
>
> libavc/vide
Dear Developers
I direct a media project involving a huge variety of online available videos.
We will analyse these videos with available and state of the art machine
learning tools, but need to pre-process the videos and bring them to a certain
standard.
We are looking for somebody to consult
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Friday, 13 August 2021 11:54
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
>
Hi Nicholas,
Thanks
On 8/10/2021 6:59 PM, James Almer wrote:
Signed-off-by: James Almer
---
Not going to bother with implementing replace for side data, since it's IMO not
worth it, but patches are welcome of course.
Missing version bump and APIchanges entry.
libavutil/frame.c | 98 +
James Almer:
> On 8/10/2021 6:59 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Not going to bother with implementing replace for side data, since
>> it's IMO not
>> worth it, but patches are welcome of course.
>>
>> Missing version bump and APIchanges entry.
>>
>> libavutil/fram
On 8/13/2021 12:22 PM, Andreas Rheinhardt wrote:
James Almer:
On 8/10/2021 6:59 PM, James Almer wrote:
Signed-off-by: James Almer
---
Not going to bother with implementing replace for side data, since
it's IMO not
worth it, but patches are welcome of course.
Missing version bump and APIchange
James Almer:
> Signed-off-by: James Almer
> ---
> Not going to bother with implementing replace for side data, since it's IMO
> not
> worth it, but patches are welcome of course.
>
> Missing version bump and APIchanges entry.
>
> libavutil/frame.c | 98 +
On 8/13/2021 12:27 PM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
Not going to bother with implementing replace for side data, since it's IMO not
worth it, but patches are welcome of course.
Missing version bump and APIchanges entry.
libavutil/frame.c | 98 +++
James Almer:
> On 8/13/2021 12:27 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Signed-off-by: James Almer
>>> ---
>>> Not going to bother with implementing replace for side data, since
>>> it's IMO not
>>> worth it, but patches are welcome of course.
>>>
>>> Missing version bump and APIchange
On Thu, Aug 12, 2021 at 05:16:30PM -0300, James Almer wrote:
> 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
Aug 10, 2021, 17:50 by d...@lynne.ee:
> 10 Aug 2021, 17:29 by andreas.rheinha...@outlook.com:
>
>> Lynne:
>>
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>>
>>> index 6b4a265457..678cb9bfa6 100644
>>>
>>> --- a/libavutil/version.h
>>>
>>> +++ b/libavutil/version.h
>>>
>>> @@ -80,7 +
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
On Fri, Aug 13, 2021 at 03:14:36PM +, Soft Works wrote:
[...]
> > You do not need anybody's permission either to set up a gateway that
> > will re-post GitHub's PR and comments to the mailing-list and
> > reciprocally
>
> I would need permission to github/ffmpeg/ffmpeg in order to set
> up the
On 8/13/2021 2:48 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 | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/frame_
Michael Niedermayer:
> Fixes: MemLeak
> Fixes: 8281
> Fixes: PoC_option158.jpg
> Fixes: CVE-2020-22037
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/frame_thread_encoder.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/frame_thread_enc
On Fri, Aug 13, 2021 at 03:22:41PM -0300, James Almer wrote:
> On 8/13/2021 2:48 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 | 10
On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: MemLeak
> > Fixes: 8281
> > Fixes: PoC_option158.jpg
> > Fixes: CVE-2020-22037
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/frame_thread_encoder.c | 10 ++
> > 1 fil
On 8/13/2021 3:51 PM, Michael Niedermayer wrote:
On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:
Michael Niedermayer:
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 10 +
Michael Niedermayer:
> On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: MemLeak
>>> Fixes: 8281
>>> Fixes: PoC_option158.jpg
>>> Fixes: CVE-2020-22037
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/frame_thread_encoder.c | 1
Aug 13, 2021, 19:47 by d...@lynne.ee:
> Aug 10, 2021, 17:50 by d...@lynne.ee:
>
>> 10 Aug 2021, 17:29 by andreas.rheinha...@outlook.com:
>>
>>> Lynne:
>>>
diff --git a/libavutil/version.h b/libavutil/version.h
index 6b4a265457..678cb9bfa6 100644
--- a/libavutil/version.h
>
August 13, 2021 11:10 AM, "Mario Winkler" wrote:
> Dear Developers
>
> I direct a media project involving a huge variety of online available videos.
> We will analyse these
> videos with available and state of the art machine learning tools, but need
> to pre-process the
> videos and bring the
On 13.08.2021 10:42, Dylan Fernando wrote:
Any update on this?
Missing license header in both new files (please re-send for this).
Missing version bump, though I can add this when pushing as well.
The code looks fine to me, though I have no experience with this
algorithm at all, so if someone
On 13.08.2021 10:42, Dylan Fernando wrote:
Any update on this?
Kind Regards,
Dylan
Also, are you sure that exp() function is correct?
The CUDA-Function exp() is defined as "double exp(double x)" and
calculates the base e exponential.
While __nvvm_ex2_approx_f reads to me like it does so fo
On Friday, 6 August 2021 7:16:33 PM AEST Brad Hards wrote:
> MISB ST 0604 and ST 2101 require user data unregistered SEI messages
> (precision timestamps and sensor identifiers) to be included. That
> currently isn't supported for libx264. This patch adds support
> for user data unregistered SEI me
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Friday, 13 August 2021 20:10
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
>
> On Fri, Aug 13,
Hi,
On Thu, Aug 12, 2021 at 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 simp
Aug 14, 2021, 02:42 by rsbul...@gmail.com:
> Hi,
>
> On Thu, Aug 12, 2021 at 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,
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ronald S.
> Bultje
> Sent: Saturday, 14 August 2021 02:43
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> Hi,
>
> On Thu, Aug 12, 2021 at 4:51
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: Saturday, 14 August 2021 03:08
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> The situation is far from perfect. In my opini
this prevents some mismatches in config values for realtime and all
intra modes, avoiding failures like:
[libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
[libaom-av1 @ ...] Additional information: g_lag_in_frames out of
range [..0]
---
libavcodec/libaomenc.c | 4 +---
1 file c
On Fri, Aug 13, 2021 at 7:11 PM James Zern wrote:
>
> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
>
The logic for default crf may need some work with -usage 2.
> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [l
> On Aug 14, 2021, at 11:27 AM, ffmpegandmahanstreamer@e.email wrote:
>
> August 13, 2021 8:42 PM, "Ronald S. Bultje" wrote:
>
>> Hi,
>>
>> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George wrote:
>>
>>> Paul Buxton (12021-08-12):
>>> From the point of view of someone who is currently developi
On Sat, Aug 14, 2021 at 9:11 AM Timo Rothenpieler
wrote:
> On 13.08.2021 10:42, Dylan Fernando wrote:
> > Any update on this?
> >
> > Kind Regards,
> > Dylan
>
> Also, are you sure that exp() function is correct?
>
> The CUDA-Function exp() is defined as "double exp(double x)" and
> calculates th
Soft Works (12021-08-14):
> The continuing attempt to declare developers who are favoring modern
> workflows and tooling as newbies and unexperienced is a really disgusting
> rhetoric.
Your misrepresentation of my statements is the really disgusting
rhetoric here.
What I have said is that newbie
46 matches
Mail list logo
