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
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
__
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
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 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 will not make one up for them.
Deprecate th
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 the old API working with just uint64_t
13 Jan 2022, 02:49 by jamr...@gmail.com:
> 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
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
21 matches
Mail list logo
