> On Jan 17, 2022, at 3:07 AM, Anton Khirnov wrote:
>
> Quoting Cameron Gutman (2022-01-10 09:17:37)
>>
>>> On Jan 9, 2022, at 3:24 AM, Anton Khirnov wrote:
>>>
>>> Quoting Cameron Gutman (2022-01-03 01:33:19)
Signed-off-by: Cameron Gutman
---
libavutil/hwcontext_videotoolbo
On Mon, 17 Jan 2022, Michael Niedermayer wrote:
Hi
Trac lists 162 non closed bugs with keyword regression
https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression
Our next major release maybe will be next december
I suggest we try to reduce the number of re
On Mon, Jan 17, 2022 at 11:46:24PM +0100, Jean-Baptiste Kempf wrote:
> Heya,
>
> On Mon, 17 Jan 2022, at 23:39, Michael Niedermayer wrote:
> > Trac lists 162 non closed bugs with keyword regression
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression
> >
>
Heya,
On Mon, 17 Jan 2022, at 23:39, Michael Niedermayer wrote:
> Trac lists 162 non closed bugs with keyword regression
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression
>
> Our next major release maybe will be next december
When is 5.1.0 ? June/July?
If
Hi
Trac lists 162 non closed bugs with keyword regression
https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression
Our next major release maybe will be next december
I suggest we try to reduce the number of regression bugs, and also to
add fate tests for as many
Fixes: signed integer overflow: 15244032 * 256 cannot be represented in type
'int'
Fixes:
43504/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4865014842916864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Micha
Fixes: signed integer overflow: -9223372036854775808 - 8 cannot be represented
in type 'long'
Fixes:
43542/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5237670148702208
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Mic
Quoting Andreas Rheinhardt (2022-01-13 11:50:48)
>
> My objections to adding a separately allocated muxing context and to
> this MuxStream have not changed. Both incur unnecessary allocations
> and indirections and (in case of the latter) loops;
I cannot imagine any remotely real situation where
Hello,
I would like to ask if it makes sense to implement ZeroMQ interactive
commands for the adelay filter, from the performance and memory point of
view.
If it does make sense then is it possible to malloc/free/realloc memory
within the command processing function? Can it cause noticeable delays
From: Anton Khirnov
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate the old API working with just uint64_t bitmasks.
Expanded and completed by Vit
On Mon, 17 Jan 2022, James Almer wrote:
[...]
-static const char *get_channel_name(int channel_id)
+static const char *get_channel_name(enum AVChannel channel_id)
{
-if (channel_id < 0 || channel_id >= FF_ARRAY_ELEMS(channel_names))
+if ((unsigned) channel_id >= FF_ARRAY_ELEMS(channe
On 1/17/2022 5:18 PM, Marton Balint wrote:
On Mon, 17 Jan 2022, James Almer wrote:
You're still thinking there's a distinction, when i already told you
that there is none. I added the name field because people wanted to
give non standard channel names, and maybe also change the standar
On Mon, 17 Jan 2022, James Almer wrote:
You're still thinking there's a distinction, when i already told you that
there is none. I added the name field because people wanted to give non
standard channel names, and maybe also change the standard ones too. It's not
a label to go alongside
From: Anton Khirnov
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate the old API working with just uint64_t bitmasks.
Expanded and completed by Vit
James Almer (12022-01-17):
> It will print the whole structure, what makes you think it wont? It doesn't
> need custom names to be set to do that.
If it prints the whole structure, including the names, and if the
parsing function parses the whole result, including the names, it is
good. Anything e
On 1/17/2022 1:54 PM, Nicolas George wrote:
James Almer (12022-01-17):
Like you said below, the functions must be reciprocal, so they can't take
that field into account.
A serializaion function is supposed to serialize the whole structure. I
will not accept less.
It will print the whole s
James Almer (12022-01-17):
> Like you said below, the functions must be reciprocal, so they can't take
> that field into account.
A serializaion function is supposed to serialize the whole structure. I
will not accept less.
--
Nicolas George
signature.asc
Description: PGP signature
_
On 1/17/2022 1:50 PM, Nicolas George wrote:
James Almer (12022-01-17):
Either that, or the field is removed.
Are we discussing together to design the best API possible or are you a
dictator making threats?
Like you said below, the functions must be reciprocal, so they can't
take that fie
On 1/17/2022 1:48 PM, Nicolas George wrote:
James Almer (12022-01-17):
-map_channel works perfectly with the current bitmask API, and the new one.
Not if there are several times the same channel with different labels.
It should.
Patches are always welcome for new or updated functionality.
James Almer (12022-01-17):
> Either that, or the field is removed.
Are we discussing together to design the best API possible or are you a
dictator making threats?
The label field stays, and the parse and stringify functions must be
reciprocal of each other. The API is unacceptable otherwise.
--
James Almer (12022-01-17):
> -map_channel works perfectly with the current bitmask API, and the new one.
Not if there are several times the same channel with different labels.
It should.
--
Nicolas George
signature.asc
Description: PGP signature
__
17 Jan 2022, 16:04 by ffm...@gyani.pro:
>
>
> On 2022-01-17 08:30 pm, ffmpeg-...@ffmpeg.org wrote:
>
>> The branch, master has been updated
>> via a23b3fe406dcabfbed5f5b31f3f07362173a10cb (commit)
>> from c362eec3ccd1ebe4dafc8500b70238d96aa4ba64 (commit)
>>
>>
>> - Log
On 2022-01-17 08:30 pm, ffmpeg-...@ffmpeg.org wrote:
The branch, master has been updated
via a23b3fe406dcabfbed5f5b31f3f07362173a10cb (commit)
from c362eec3ccd1ebe4dafc8500b70238d96aa4ba64 (commit)
- Log -
commi
15 Jan 2022, 01:48 by d...@lynne.ee:
> 14 Jan 2022, 20:39 by d...@lynne.ee:
>
> Okay, the release will be officially out on 16:00 UTC+1 (CET) on Monday, the
> 17th,
> so I'll push the update to the webpage then.
>
Website updated, so I think that makes the release officially announced.
_
On 1/17/2022 10:51 AM, Nicolas George wrote:
James Almer (12022-01-17):
And they can if they want to. It has a very specific purpose and it fulfills
it.
Just be clearer in the documentation.
Please, stop asking for this. It's an incredibly niche usecase you want for
libavfilter, so you ca
Signed-off-by: Andreas Rheinhardt
---
libavformat/imfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 566a0fb792..d67c9b8898 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -200,7 +200,7 @@ static int parse
On 1/17/2022 10:56 AM, Nicolas George wrote:
James Almer (12022-01-17):
Yes, which is why I'll make describe() stop looking at the name field.
Unacceptable.
Either that, or the field is removed. The opaque field is more than
enough for your usecase. lavfi can and should use it to do ever
James Almer (12022-01-17):
> Yes, which is why I'll make describe() stop looking at the name field.
Unacceptable.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
On 1/17/2022 10:53 AM, Nicolas George wrote:
Marton Balint (12022-01-16):
Should the serializaton and unserialization functions store/parse both the
channel label and the channel designation? As far as I see right now it is
kind of inconsistent: av_channel_layout_describe_print() prints the l
Marton Balint (12022-01-16):
> Should the serializaton and unserialization functions store/parse both the
> channel label and the channel designation? As far as I see right now it is
> kind of inconsistent: av_channel_layout_describe_print() prints the label
> (if exists), not the designation, but
James Almer (12022-01-17):
> And they can if they want to. It has a very specific purpose and it fulfills
> it.
Just be clearer in the documentation.
> Please, stop asking for this. It's an incredibly niche usecase you want for
> libavfilter, so you can and should implement it there. The API is t
On 1/16/2022 8:27 AM, Nicolas George wrote:
James Almer (12022-01-12):
From: Anton Khirnov
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate th
On 1/16/2022 7:54 PM, Marton Balint wrote:
On Sun, 16 Jan 2022, Nicolas George wrote:
James Almer (12022-01-12):
From: Anton Khirnov
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc
On 1/17/2022 7:57 AM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
myp...@gmail.com
Sent: Monday, January 17, 2022 11:36 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: add tile encoding support
for VP9
On
Hi,
On Tue, Jan 11, 2022 at 9:43 AM Eran Kornblau
wrote:
> Hi all,
>
> Recently I’ve submitted a patch that adds a config option to disable the
> caching of http redirects.
> We planned this as a workaround to the fact there’s a limit on the
> expiration that can be set on S3 pre-signed URLs.
>
On Mon, Jan 17, 2022 at 6:57 PM Soft Works wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > myp...@gmail.com
> > Sent: Monday, January 17, 2022 11:36 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: a
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> myp...@gmail.com
> Sent: Monday, January 17, 2022 11:36 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: add tile encoding support
> for VP9
>
> On Mon, Jan 17, 2022 at 4:
On Mon, Jan 17, 2022 at 4:30 PM Xiang, Haihao
wrote:
>
> On Thu, 2022-01-13 at 13:45 +0800, Haihao Xiang wrote:
> > Add -tile_rows and -tile_cols options to specify the number of tile
> > rows and columns
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > v2: add option descriptions in the doc
> >
>
Quoting Cameron Gutman (2022-01-10 09:17:37)
>
> > On Jan 9, 2022, at 3:24 AM, Anton Khirnov wrote:
> >
> > Quoting Cameron Gutman (2022-01-03 01:33:19)
> >> Signed-off-by: Cameron Gutman
> >> ---
> >> libavutil/hwcontext_videotoolbox.c | 25 +
> >> 1 file changed, 25 ins
On Thu, 2022-01-13 at 13:45 +0800, Haihao Xiang wrote:
> Add -tile_rows and -tile_cols options to specify the number of tile
> rows and columns
>
> Signed-off-by: Haihao Xiang
> ---
> v2: add option descriptions in the doc
>
> doc/encoders.texi | 6 ++
> libavcodec/qsvenc.c | 4
On Wed, 2022-01-12 at 16:36 +0800, Haihao Xiang wrote:
> Enables HEVC Screen Content Coding extension support on ICL+ platform
>
> Signed-off-by: Haihao Xiang
> ---
> v2: rebased it against the latest master and added scc to the doc
>
> doc/encoders.texi| 3 +++
> libavcodec/qsvenc.c
On Wed, 2022-01-12 at 12:50 +0800, Haihao Xiang wrote:
> The SDK may insert picture timing SEI for hevc and the code to set mfx
> parameter has been added in qsvenc, however the corresponding option is
> missing in the hevc option array
>
> Reviewed-by: Limin Wang
> Signed-off-by: Haihao Xiang
>
42 matches
Mail list logo
