August 13, 2021 9:30 PM, "Soft Works" wrote:
>> -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
>>
Mike, i was told you can push this?
August 11, 2021 9:04 AM, ffmpegandmahanstreamer@e.email wrote:
> ping
>
> August 1, 2021 12:22 PM, ffmpegandmahanstreamer@e.email wrote:
>
>> Per Andreas Rheinhardt request i'm splitting the working patches in two.
>> ---
>> This cleans up the code in the dec
August 13, 2021 10:11 PM, "James Zern" wrote:
> 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
>
August 13, 2021 10:11 PM, "James Zern" wrote:
> 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
>
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 developing a filter
>> for
>> ffmpeg and will be submitting a patch to the list for the first
Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037
Signed-off-by: Michael Niedermayer
---
libavcodec/frame_thread_encoder.c | 11 +++
libavcodec/frame_thread_encoder.h | 4
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavcodec/frame_threa
Nicolas George (12021-07-24):
> Signed-off-by: Nicolas George
> ---
> libavutil/internal.h | 5 +
> 1 file changed, 5 insertions(+)
Patch series pushed after more time than expected.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
Nicolas George (12021-07-28):
> You mean make it public? I am not against it, but I would wait for a
> third opinion.
If there are no third opinion, I will stick with the conservative stance
and keep it private.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
Marton Balint (12021-07-29):
> I meant the absolute path case from Appendix B:
>
>o The minimal representation of a local file with no authority field
> and an absolute path that begins with a slash "/". For example:
>
> * "file:/path/to/file"
It is precisely what I call semi-
On Sun, Aug 01, 2021 at 04:22:28PM +, ffmpegandmahanstreamer@e.email wrote:
> Per Andreas Rheinhardt request i'm splitting the working patches in two.
And this results in a commit message like this:
Author: ffmpegandmahanstreamer@e.email
Date: Sun Aug 1 16:22:28 2021 +
Subject: [PA
On Sat, Aug 14, 2021 at 2:42 AM 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 developing a filter
> > for
> > > ffmpeg and will be submitting a patch to the list f
Nicolas George (12021-07-30):
> Andreas Rheinhardt (12021-07-29):
> > The latter statement is not true: This is public API; anyone can have
> > used it for any purpose. Your 2/5 adds a replacement for using it with
> > dvd2concat, but there are other usages, too; e.g. concatenating several
> > subf
Signed-off-by: Paul B Mahol
---
libavcodec/smc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/smc.c b/libavcodec/smc.c
index 9cd86216a2..2f43984b99 100644
--- a/libavcodec/smc.c
+++ b/libavcodec/smc.c
@@ -459,6 +459,17 @@ static int smc_decode_frame(AVCodecContext
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/smcenc.c| 557 +
3 files changed, 559 insertions(+)
create mode 100644 libavcodec/smcenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefil
Hendrik Leppkes (12021-08-14):
> As far as I can remember, the number of people that have spoken out in
> favor of continued use of the ML solution is the minority, some are
> just rather vocal about it, and the lack of a "perfect" replacement
> solution has resulted in none being implemented.
Do
Andreas Rheinhardt (12021-07-28):
> > -if ((ret = avformat_open_input(&cat->avf, file->url, NULL, NULL)) < 0
> > ||
> > +ret = av_dict_copy(&options, file->options, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +if ((ret = avformat_open_input(&cat->avf, file->url, NULL,
August 14, 2021 12:34 AM, "zhilizhao(赵志立)" wrote:
>> 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
Andreas Rheinhardt (12021-08-12):
> Up until now, an AVFilter's lists of input and output AVFilterPads
> were terminated by a sentinel and the only way for the user to get
> the length of these lists was by using avfilter_pad_count(). This
> has two drawbacks: first, sizeof(AVFilterPad) is not negl
On Fri, Aug 13, 2021 at 11:53:54PM +, Soft Works wrote:
>
>
> > -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
On Sat, Aug 14, 2021 at 10:43 AM Nicolas George wrote:
>
> Hendrik Leppkes (12021-08-14):
> > As far as I can remember, the number of people that have spoken out in
> > favor of continued use of the ML solution is the minority, some are
> > just rather vocal about it, and the lack of a "perfect" r
On Wed, 11 Aug 2021, Marton Balint wrote:
Partition struct may be reallocated, so let's store the score directly in order
to avoid use-after-free.
Also mxf->current_partition might be null when reading some local tags.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 31
Hendrik Leppkes (12021-08-14):
> I can only judge based on past discussion, and have no insight into
> those that have never taken part in it.
>
> One more factor to consider in this line of thought however is, as
> Ronald already stated as well, how many developers might have
> contributed more,
The upper limit of strlen(streamid) is 512. Use a larger buffer for
future proof, for example, deal with percent-encoding.
---
libavformat/libsrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index e5701625b8..a66c85d3a2 100644
--
From: Niklas Haas
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5dbe6c319d693355be44df2e17a0b8bf
Signed-off-by: Niklas Haas
---
libavcodec/h264_sei.c | 2
From: Niklas Haas
>From SMPTE RDD 5-2006, the grain seed is to be computed from the
following definition of `pic_offset`:
> When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
> follows:
> - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
> where:
> - PicOrder
From: Niklas Haas
This could arguably also be a vf, but I decided to put it here since
decoders are technically required to apply film grain during the output
step, and I would rather want to avoid requiring users insert the
correct film grain synthesis filter on their own.
The code, while in C,
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
f
ffmpegandmahanstreamer (12021-08-14):
> Once again this proves the superioity of the graphical stuff.
Start with not top-posting and we may take your opinion on the
superiority of stuff seriously.
--
Nicolas George
signature.asc
Description: PGP signature
ffmpegandmahanstreamer (12021-08-14):
> I top post only when i want to reply to the message as a whole.
The rules of the list are clear: DO NOT TOP-POST
> Bottom (literally, like way bottom) posting is worse than top posting,
> because then you need to scroll all the way down.
Then be extra-res
PING
___
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 14.08.2021 07:49, Dylan Fernando wrote:
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(doubl
On Fri, 13. Aug 23:53, Soft Works wrote:
>
>
> > -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
On 14.08.2021 07:49, Dylan Fernando wrote:
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(doubl
On 8/14/2021 8:36 AM, Niklas Haas wrote:
From: Niklas Haas
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allow
Nicolas George:
> Andreas Rheinhardt (12021-08-12):
>> Up until now, an AVFilter's lists of input and output AVFilterPads
>> were terminated by a sentinel and the only way for the user to get
>> the length of these lists was by using avfilter_pad_count(). This
>> has two drawbacks: first, sizeof(AV
Paul B Mahol:
> +/**
> + * @file smcenc.c
> + * QT SMC Video Encoder by Paul B. Mahol
> + */
> +
> +#include "libavutil/avassert.h"
This file does not use any av_assert
> +#include "libavutil/common.h"
> +
> +#include "avcodec.h"
> +#include "encode.h"
> +#include "internal.h"
> +#include "bytest
Fixes: left shift of 16711968 by 8 places cannot be represented in type 'int'
Fixes:
36601/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6581933285965824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Nie
Fixes: Assertion failure
Fixes:
36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowdec.c | 8
1 f
This cleans up the code in the decode24bit and decode16bit functions by putting
it in way that expresses the true intent while making it easier to read.
---
libavcodec/truemotion1.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/libavcode
Sent new patch.
Once again this proves the superioity of the graphical stuff. The whole host of
issues in the first set of this email would have been avoided, and i wouldnt
have to create the patch all over again to fix something.
August 14, 2021 4:23 AM, "Michael Niedermayer" wrote:
> On Sun,
This cleans up the code in the decode24bit and decode16bit functions by putting
it in way that expresses the true intent while making it easier to read.
---
libavcodec/truemotion1.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/libavcode
The other patch has more subject line aligned to other devs, go to that one
instead.
August 14, 2021 7:24 AM, "ffmpegandmahanstreamer"
wrote:
> This cleans up the code in the decode24bit and decode16bit functions by
> putting it in way that
> expresses the true intent while making it easier t
> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> wrote:
>
> Fixes: Assertion failure
> Fixes:
> 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
August 14, 2021 7:43 AM, "Nicolas George" wrote:
> ffmpegandmahanstreamer (12021-08-14):
>
>> Once again this proves the superioity of the graphical stuff.
>
> Start with not top-posting and we may take your opinion on the
> superiority of stuff seriously.
I top post only when i want to reply t
On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
>
>
> > On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> > wrote:
> >
> > Fixes: Assertion failure
> > Fixes:
> > 36359/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6733238591684608
> >
> > Found-by: contin
> On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
> wrote:
>
> On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
>>
>>
>>> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
>>> wrote:
>>>
>>> Fixes: Assertion failure
>>> Fixes:
>>> 36359/clusterfuzz-testcase-minimized-f
On Sat, 14 Aug 2021, Nicolas George wrote:
Nicolas George (12021-07-30):
Andreas Rheinhardt (12021-07-29):
The latter statement is not true: This is public API; anyone can have
used it for any purpose. Your 2/5 adds a replacement for using it with
dvd2concat, but there are other usages, too
On Sat, 14 Aug 2021, at 03:13, Soft Works wrote:
> The continuing attempt to declare developers who are favoring modern
> workflows and tooling as newbies and unexperienced is a really disgusting
> rhetoric.
I agree.
Very complex projects, more complex than FFmpeg are on GitHub and Gitlab and
On Sun, 15 Aug 2021, "zhilizhao(赵志立)" wrote:
On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
wrote:
On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
wrote:
Fixes: Assertion failure
Fixes:
36359/clusterfuzz-testc
On Sat, 14. Aug 12:14, Stephen Hutchinson wrote:
> ffmpeg | branch: master | Stephen Hutchinson | Wed Jul 14
> 20:16:41 2021 -0400| [1c42fd93236e7869ef4d9fe3650dd3e951387321] | committer:
> Paul B Mahol
>
> libavformat/isom_tags.c: add ipcm to list of tags
>
> Fixes http://trac.ffmpeg.org/tick
Jean-Baptiste Kempf (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.
> I agree.
Good thing it is not what I wrote, then. I am a little disappointed that
you would mak
On Sat, Aug 14, 2021, 11:26 Nicolas George wrote:
>
> I agree. But it is important to remember that before seriously
> considering any deep change, it would be necessary to actively poll the
> silent individual-minority-work-majority.
>
Is there a mechanism to trigger such a vote? I hope the cor
Diederick C. Niehorster (12021-08-14):
> Is there a mechanism to trigger such a vote? I hope the core developers
> have one soon so the project can get moving on this.
There is a mechanism. But as I explained there:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283705.html
for this kind
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/smcenc.c| 563 +
3 files changed, 565 insertions(+)
create mode 100644 libavcodec/smcenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefil
ffmpegandmahanstreamer (12021-08-14):
> The real person winning here is Soft Works. He must be laughing right now.
> Ah, your math degree coming into work here - "if and only if" ;)
> Dont make broad generalizations however.
> Careful there. Don't you remember anything about the libav split?
Do
On Sat, Aug 14, 2021 at 7:43 PM Andriy Gelman wrote:
>
> On Sat, 14. Aug 12:14, Stephen Hutchinson wrote:
> > ffmpeg | branch: master | Stephen Hutchinson | Wed Jul
> > 14 20:16:41 2021 -0400| [1c42fd93236e7869ef4d9fe3650dd3e951387321] |
> > committer: Paul B Mahol
> >
> > libavformat/isom_tags
Nicolas George:
> Nicolas George (12021-07-30):
>> Andreas Rheinhardt (12021-07-29):
>>> The latter statement is not true: This is public API; anyone can have
>>> used it for any purpose. Your 2/5 adds a replacement for using it with
>>> dvd2concat, but there are other usages, too; e.g. concatenati
In 1c42fd93236e7869ef4d9fe3650dd3e951387321 the ipcm identifier was
added in order to demux additional raw audio from Sony MP4 files.
Unfortunately, it was not noticed that this same list is utilized
for muxing as well, thus causing ipcm to get preferred compared
to the identifier officially specif
Patch is OK, apply at will.
___
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 Sat, Aug 14, 2021 at 8:25 PM Paul B Mahol wrote:
>
> Patch is OK, apply at will.
Thanks, applied as 087fbfe5bc2272aa1cfd9f4c49438436b68a1ddc .
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
On Sat, Aug 14, 2021 at 1:13 PM ffmpegandmahanstreamer
wrote:
> August 14, 2021 1:01 PM, "Nicolas George" wrote:
>
> > ffmpegandmahanstreamer (12021-08-14):
> >
> >> The real person winning here is Soft Works. He must be laughing right
> now.
> >>
> >> Ah, your math degree coming into work
Nicolas George:
> Andreas Rheinhardt (12021-08-11):
>> The current way of doing it involves writing the ctx parameter twice.
>>
>> Signed-off-by: Andreas Rheinhardt
>
> LGTM, but it is not my area of expertise.
>
> Regards,
>
Will apply it tomorrow unless there are objections.
- Andreas
__
On Sat, 14 Aug 2021, at 11:26, Nicolas George wrote:
> Hendrik Leppkes (12021-08-14):
> > I can only judge based on past discussion, and have no insight into
> > those that have never taken part in it.
> >
> > One more factor to consider in this line of thought however is, as
> > Ronald already st
August 14, 2021 12:40 PM, "Jean-Baptiste Kempf" wrote:
> On Sat, 14 Aug 2021, at 03:13, Soft Works wrote:
>
>> The continuing attempt to declare developers who are favoring modern
>> workflows and tooling as newbies and unexperienced is a really disgusting
>> rhetoric.
>
> I agree.
>
> Very co
August 14, 2021 7:56 AM, "Nicolas George" wrote:
> ffmpegandmahanstreamer (12021-08-14):
>
>> I top post only when i want to reply to the message as a whole.
>
> The rules of the list are clear: DO NOT TOP-POST
The rules of the list also say you should be mean to others.
>
>> Bottom (literally
August 14, 2021 12:47 PM, "Nicolas George" wrote:
> Jean-Baptiste Kempf (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.
>> I agree.
>
> Good thing it is not what I
August 14, 2021 12:53 PM, "Nicolas George" wrote:
> Diederick C. Niehorster (12021-08-14):
>
>> Is there a mechanism to trigger such a vote? I hope the core developers
>> have one soon so the project can get moving on this.
>
> There is a mechanism. But as I explained there:
>
> https://ffmpeg
August 14, 2021 1:01 PM, "Nicolas George" wrote:
> ffmpegandmahanstreamer (12021-08-14):
>
>> The real person winning here is Soft Works. He must be laughing right now.
>>
>> Ah, your math degree coming into work here - "if and only if" ;)
>> Dont make broad generalizations however.
>>
>> Care
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ronald S.
> Bultje
> Sent: Saturday, 14 August 2021 19:32
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> I'm not sure I support it, I'd h
On 8/14/2021 1:55 PM, Paul B Mahol wrote:
+static int smc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+SMCContext *s = avctx->priv_data;
+const AVFrame *pict = frame;
+uint8_t *pal;
+int ret;
+
+
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Saturday, 14 August 2021 08:31
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> Soft Works (12021-08-14):
> > The con
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft Works
> Sent: Sunday, 15 August 2021 04:12
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
>
> Speaking of "reasonable" - I'm reading th
Marton Balint:
>
>
> On Sun, 15 Aug 2021, "zhilizhao(赵志立)" wrote:
>
>>
>>
>>> On Aug 14, 2021, at 11:52 PM, Michael Niedermayer
>>> wrote:
>>>
>>> On Sat, Aug 14, 2021 at 11:45:59PM +0800, "zhilizhao(赵志立)" wrote:
> On Aug 14, 2021, at 11:07 PM, Michael Niedermayer
> wrote:
>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> ffmpegandmahanstreamer
> Sent: Saturday, 14 August 2021 18:55
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> August 14, 2021 12:47 PM, "Nico
> -Original Message-
> From: ffmpeg-devel On Behalf Of Andriy
> Gelman
> Sent: Saturday, 14 August 2021 14:48
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
>
> On Fri, 13. Aug 23:53, Soft Works wro
75 matches
Mail list logo
