> -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
> -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,
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 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
> -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
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 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
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.
>>
>>
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:
>
>
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 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
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
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
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
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
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
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".
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
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.
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
> >
> >
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?
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
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
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
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
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
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:
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 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,
> 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:
>>>
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:
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
> 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
>
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
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
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
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
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
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
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
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,
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
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
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
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".
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
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
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
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
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:
> -
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
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
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,
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
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"
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:
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
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):
>>
Andreas Rheinhardt (12021-07-28):
> > -if ((ret = avformat_open_input(>avf, file->url, NULL, NULL)) < 0
> > ||
> > +ret = av_dict_copy(, file->options, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +if ((ret = avformat_open_input(>avf, file->url, NULL, ))
> > < 0 ||
>
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
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
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
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
> >
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
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:
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
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
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
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
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
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
>
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
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
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
76 matches
Mail list logo
