On 12/15/2021 7:55 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (1202
On 12/15/2021 6:32 PM, Marton Balint wrote:
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVCh
On Wed, 15 Dec 2021, James Almer wrote:
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate t
On 12/15/2021 7:24 AM, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate the strings instead, and not worry about their lif
James Almer (12021-12-14):
> There's "char name[16]". Bigger than a pointer (Could be 8 bytes instead,
> but then it's kinda small). The user will not have to worry about the
> lifetime of anything then.
I find the fixed-size limiting. Please seriously consider the
alternative: AVChannelLayout is
On Tue, 14 Dec 2021, James Almer wrote:
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate the strings instead, and not worry about their lifetime, they
can
provide the layout with a cu
On Wed, 15 Dec 2021, Marton Balint wrote:
On Tue, 14 Dec 2021, James Almer wrote:
return channel_names[channel_id].name;
}
-static const struct {
+static inline void get_channel_str(AVBPrint *bp, const char *str,
+ enum AVChannel
On Tue, 14 Dec 2021, James Almer wrote:
return channel_names[channel_id].name;
}
-static const struct {
+static inline void get_channel_str(AVBPrint *bp, const char *str,
+ enum AVChannel channel_id)
+{
+ if (str)
+ av_bpri
On Tue, Dec 14, 2021 at 04:30:04PM -0300, James Almer wrote:
> On 12/14/2021 3:54 PM, Nicolas George wrote:
> > James Almer (12021-12-14):
> > > We add a const uint8_t* field to AVChannelCustom. If the user wants to
> > > allocate the strings instead, and not worry about their lifetime, they can
>
On 12/14/2021 3:54 PM, Nicolas George wrote:
James Almer (12021-12-14):
We add a const uint8_t* field to AVChannelCustom. If the user wants to
allocate the strings instead, and not worry about their lifetime, they can
provide the layout with a custom free() function that will take care of
cleani
James Almer (12021-12-14):
> We add a const uint8_t* field to AVChannelCustom. If the user wants to
> allocate the strings instead, and not worry about their lifetime, they can
> provide the layout with a custom free() function that will take care of
> cleaning anything they came up with on uninit(
On 12/14/2021 9:53 AM, Nicolas George wrote:
James Almer (12021-12-14):
You could attach it dynamically allocated strings too, and to prevent the
need for the module allocating them to outlive the layout, we could add an
opaque pointer to AVChannelLayout (not AVChannelCustom) and a user set
f
Lynne (12021-12-14):
> Ah, okay, I understand.
> Does this mean you'd be okay with letting us choose, as long as your
> requirements are satisfied?
Of course I am okay with a solution where my requirements are satisfied.
But I cannot say if they are before seeing the solution you propose, and
othe
14 Dec 2021, 15:23 by geo...@nsup.org:
> Lynne (12021-12-14):
>
>> I think this discussion would go a lot quicker if we could discuss this
>> on IRC, would you and Nicolas mind joining and pinging me and elenril
>> so we could settle the details?
>>
>
> Yes, I would mind; more: I cannot; I have ot
Anton Khirnov (12021-12-14):
> A transcoder that is not aware of opaque IDs can just blindly copy them
> as the data travels along the chain. Same with side data those IDs refer
> to. Callers who want to do something nontrivial with them will of course
> have to be aware of them, but that's the cas
Lynne (12021-12-14):
> I think this discussion would go a lot quicker if we could discuss this
> on IRC, would you and Nicolas mind joining and pinging me and elenril
> so we could settle the details?
Yes, I would mind; more: I cannot; I have other things claiming my time.
And I believe people wh
14 Dec 2021, 09:32 by c...@passwd.hu:
>
>
> On Tue, 14 Dec 2021, Lynne wrote:
>
>> 14 Dec 2021, 02:13 by c...@passwd.hu:
>>
>>>
>>>
>>> On Tue, 7 Dec 2021, James Almer wrote:
>>>
>>> I would like to attach some extendable, possibly per-channel metadata to
>>> the channel layout. I'd rather put it
Quoting Nicolas George (2021-12-14 14:15:05)
> Anton Khirnov (12021-12-14):
> > The same thing happening to channel layouts is something we very much do
> > not want IMO. Opaque IDs referring to higher-layer side data allows
> > implementing the same capabilities without stuffing complexity in plac
Anton Khirnov (12021-12-14):
> The same thing happening to channel layouts is something we very much do
> not want IMO. Opaque IDs referring to higher-layer side data allows
> implementing the same capabilities without stuffing complexity in places
> it doesn't belong.
Opaque IDs only work for app
James Almer (12021-12-14):
> You could attach it dynamically allocated strings too, and to prevent the
> need for the module allocating them to outlive the layout, we could add an
> opaque pointer to AVChannelLayout (not AVChannelCustom) and a user set
> free() call back to pass that pointer to, on
On 12/14/2021 5:27 AM, Marton Balint wrote:
On Mon, 13 Dec 2021, James Almer wrote:
On 12/13/2021 10:13 PM, Marton Balint wrote:
On Tue, 7 Dec 2021, James Almer wrote:
From: Anton Khirnov
[...]
-static const char *get_channel_name(int channel_id)
+static const char *get_ch
Quoting Marton Balint (2021-12-14 02:13:00)
> > + *
> > + * Copying an AVChannelLayout via assigning is forbidden,
> > + * av_channel_layout_copy() must be used. instead (and its return value
> > should
> > + * be checked)
> > + *
> > + * No new fields may be added to it without a major version bu
On Tue, 14 Dec 2021, Lynne wrote:
14 Dec 2021, 02:13 by c...@passwd.hu:
On Tue, 7 Dec 2021, James Almer wrote:
I would like to attach some extendable, possibly per-channel metadata to the
channel layout. I'd rather put it into AVChannelLayout, so native layouts could
also have metadata
On Mon, 13 Dec 2021, James Almer wrote:
On 12/13/2021 10:13 PM, Marton Balint wrote:
On Tue, 7 Dec 2021, James Almer wrote:
From: Anton Khirnov
[...]
-static const char *get_channel_name(int channel_id)
+static const char *get_channel_name(enum AVChannel channel_id)
{
-
14 Dec 2021, 02:13 by c...@passwd.hu:
>
>
> On Tue, 7 Dec 2021, James Almer wrote:
>
> I would like to attach some extendable, possibly per-channel metadata to the
> channel layout. I'd rather put it into AVChannelLayout, so native layouts
> could also have metadata. This must be dynamically all
On 12/13/2021 10:13 PM, Marton Balint wrote:
On Tue, 7 Dec 2021, James Almer wrote:
From: Anton Khirnov
[...]
-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(
On Tue, 7 Dec 2021, James Almer wrote:
From: Anton Khirnov
[...]
-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))
-return NULL;
+if (
On 12/9/2021 8:31 PM, Marton Balint wrote:
On Fri, 10 Dec 2021, Hendrik Leppkes wrote:
On Fri, Dec 10, 2021 at 12:06 AM Marton Balint wrote:
On Thu, 9 Dec 2021, Anton Khirnov wrote:
Quoting Lynne (2021-12-08 13:57:45)
8 Dec 2021, 13:16 by an...@khirnov.net:
Quoting Lynne (2021-12-
On Fri, 10 Dec 2021, Hendrik Leppkes wrote:
On Fri, Dec 10, 2021 at 12:06 AM Marton Balint wrote:
On Thu, 9 Dec 2021, Anton Khirnov wrote:
Quoting Lynne (2021-12-08 13:57:45)
8 Dec 2021, 13:16 by an...@khirnov.net:
Quoting Lynne (2021-12-08 10:02:34)
8 Dec 2021, 02:06 by jamr...@g
On Fri, Dec 10, 2021 at 12:06 AM Marton Balint wrote:
>
>
>
> On Thu, 9 Dec 2021, Anton Khirnov wrote:
>
> > Quoting Lynne (2021-12-08 13:57:45)
> >> 8 Dec 2021, 13:16 by an...@khirnov.net:
> >>
> >>> Quoting Lynne (2021-12-08 10:02:34)
> >>>
> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>
>
On Thu, 9 Dec 2021, Anton Khirnov wrote:
Quoting Lynne (2021-12-08 13:57:45)
8 Dec 2021, 13:16 by an...@khirnov.net:
Quoting Lynne (2021-12-08 10:02:34)
8 Dec 2021, 02:06 by jamr...@gmail.com:
From: Anton Khirnov
The new API is more extensible and allows for custom layouts.
More accu
Lynne (12021-12-09):
> "reserved" rather than "opaque"?
> 16 bits for both? Could you keep the id as a plain (32-bit, on
> a sane compiler) enum, since we may need to add flags, one
> never knows, and make the opaque field a plain uint32_t?
> 64-bits per channel overall isn't too bad.
You wanted a
Quoting Lynne (2021-12-09 12:21:14)
> 9 Dec 2021, 11:14 by an...@khirnov.net:
>
> > Quoting Lynne (2021-12-08 13:53:52)
> >
> >> That's not a goal, it's anti-goal, and a cause for hysterical raisin
> >> picking in the future.
> >> Having an instantly debuggable structure rather than one that
> >>
9 Dec 2021, 14:12 by an...@khirnov.net:
> Quoting Lynne (2021-12-08 13:57:45)
>
>> 8 Dec 2021, 13:16 by an...@khirnov.net:
>>
>> > Quoting Lynne (2021-12-08 10:02:34)
>> >
>> >> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>> >>
>> >> > From: Anton Khirnov
>> >> >
>> >> > The new API is more extensibl
Quoting Lynne (2021-12-08 13:57:45)
> 8 Dec 2021, 13:16 by an...@khirnov.net:
>
> > Quoting Lynne (2021-12-08 10:02:34)
> >
> >> 8 Dec 2021, 02:06 by jamr...@gmail.com:
> >>
> >> > From: Anton Khirnov
> >> >
> >> > The new API is more extensible and allows for custom layouts.
> >> > More accurate
On 12/9/2021 8:21 AM, Lynne wrote:
9 Dec 2021, 11:14 by an...@khirnov.net:
Quoting Lynne (2021-12-08 13:53:52)
That's not a goal, it's anti-goal, and a cause for hysterical raisin
picking in the future.
Having an instantly debuggable structure rather than one that
Instantly debuggable s
9 Dec 2021, 11:14 by an...@khirnov.net:
> Quoting Lynne (2021-12-08 13:53:52)
>
>> That's not a goal, it's anti-goal, and a cause for hysterical raisin
>> picking in the future.
>> Having an instantly debuggable structure rather than one that
>>
>
> Instantly debuggable structure?
>
> Again: very
Quoting Lynne (2021-12-08 13:53:52)
> That's not a goal, it's anti-goal, and a cause for hysterical raisin
> picking in the future.
> Having an instantly debuggable structure rather than one that
Instantly debuggable structure?
Again: very very little code needs to store actual AVChannels. In the
8 Dec 2021, 14:10 by h.lepp...@gmail.com:
> On Wed, Dec 8, 2021 at 1:54 PM Lynne wrote:
>
>>
>> 8 Dec 2021, 13:19 by an...@khirnov.net:
>>
>> > Quoting Marton Balint (2021-12-08 11:55:37)
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >> > 8 Dec 2021, 11:06 by c...@passwd.hu:
>>
On Wed, Dec 8, 2021 at 1:54 PM Lynne wrote:
>
> 8 Dec 2021, 13:19 by an...@khirnov.net:
>
> > Quoting Marton Balint (2021-12-08 11:55:37)
> >
> >>
> >>
> >> On Wed, 8 Dec 2021, Lynne wrote:
> >>
> >> > 8 Dec 2021, 11:06 by c...@passwd.hu:
> >> >
> >> >>
> >> >>
> >> >> On Wed, 8 Dec 2021, Lynne wr
8 Dec 2021, 13:16 by an...@khirnov.net:
> Quoting Lynne (2021-12-08 10:02:34)
>
>> 8 Dec 2021, 02:06 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
>>
8 Dec 2021, 13:19 by an...@khirnov.net:
> Quoting Marton Balint (2021-12-08 11:55:37)
>
>>
>>
>> On Wed, 8 Dec 2021, Lynne wrote:
>>
>> > 8 Dec 2021, 11:06 by c...@passwd.hu:
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>> >>>
>> >>
Quoting Marton Balint (2021-12-08 11:55:37)
>
>
> On Wed, 8 Dec 2021, Lynne wrote:
>
> > 8 Dec 2021, 11:06 by c...@passwd.hu:
> >
> >>
> >>
> >> On Wed, 8 Dec 2021, Lynne wrote:
> >>
> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
> >>>
> On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
>
Quoting Lynne (2021-12-08 10:02:34)
> 8 Dec 2021, 02:06 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
Lynne (12021-12-08):
> Consider adding a 25-byte or so of a description field string here that
> would also be copied if the frame/layout is copied?
> That way, users can assign a description label to each channel,
> for example labeling each channel in a 255 channel custom layout
> Opus stream use
On Wed, 8 Dec 2021, Lynne wrote:
8 Dec 2021, 11:06 by c...@passwd.hu:
On Wed, 8 Dec 2021, Lynne wrote:
8 Dec 2021, 10:22 by h.lepp...@gmail.com:
On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
8 Dec 2021, 02:06 by jamr...@gmail.com:
+enum AVChannel {
+///< Invalid channel inde
8 Dec 2021, 11:06 by c...@passwd.hu:
>
>
> On Wed, 8 Dec 2021, Lynne wrote:
>
>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>>
>>> On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
>>>
8 Dec 2021, 02:06 by jamr...@gmail.com:
>
> +enum AVChannel {
> +///< Invalid channel i
8 Dec 2021, 11:13 by c...@passwd.hu:
>
>
> On Wed, 8 Dec 2021, Lynne wrote:
>
>> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>>
>>>
>>> +enum AVChannel {
>>> +///< Invalid channel index
>>> +AV_CHAN_NONE = -1,
>>> +AV_CHAN_FRONT_LEFT,
>>>
>>
>> No, not the pixfmt mistake again. Set AV_CHAN
On Wed, 8 Dec 2021, Lynne wrote:
8 Dec 2021, 02:06 by jamr...@gmail.com:
+enum AVChannel {
+///< Invalid channel index
+AV_CHAN_NONE = -1,
+AV_CHAN_FRONT_LEFT,
No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a
On Wed, 8 Dec 2021, Lynne wrote:
8 Dec 2021, 10:22 by h.lepp...@gmail.com:
On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
8 Dec 2021, 02:06 by jamr...@gmail.com:
+enum AVChannel {
+///< Invalid channel index
+AV_CHAN_NONE = -1,
+AV_CHAN_FRONT_LEFT,
No, not the pixfmt mis
8 Dec 2021, 10:22 by h.lepp...@gmail.com:
> On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
>
>>
>> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>>
>> >
>> > +enum AVChannel {
>> > +///< Invalid channel index
>> > +AV_CHAN_NONE = -1,
>> > +AV_CHAN_FRONT_LEFT,
>> >
>>
>> No, not the pixfmt mis
On Wed, Dec 8, 2021 at 10:14 AM Lynne wrote:
>
> 8 Dec 2021, 02:06 by jamr...@gmail.com:
>
> >
> > +enum AVChannel {
> > +///< Invalid channel index
> > +AV_CHAN_NONE = -1,
> > +AV_CHAN_FRONT_LEFT,
> >
>
> No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
> the rest can follow.
8 Dec 2021, 02:06 by jamr...@gmail.com:
>
> +enum AVChannel {
> +///< Invalid channel index
> +AV_CHAN_NONE = -1,
> +AV_CHAN_FRONT_LEFT,
>
No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
the rest can follow. Or keep AV_CHAN_NONE to -1
and add a new AV_CHAN_UNSPECIFIED as 0.
8 Dec 2021, 02:06 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 j
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
56 matches
Mail list logo
