James Almer (12021-12-14):
> You have a stream with four channels, you set up a custom order layout where
> you pick any four unused ids and call them OboeFL, OboeFR, PianoFL, PianoFR
> in u.map[], then split the streams (retaining strings and ids), pass them to
> channelmap using channelmap=map=Ob
On 12/14/2021 10:03 AM, Nicolas George wrote:
James Almer (12021-12-13):
Can't user defined names let you do that without the need to reuse the same
AVChannel value in a given layout? And for that matter, can you not set said
names within the filter itself and not in the layout?
I do not see
Anton Khirnov (12021-12-14):
> I don't see a big problem in adding stream (i.e. link-)-level side data
> to avfilter.
It is not a problem. In fact, if we were to stay with “uint64_t
channel_layout”, that is probably what we would do. But we are
discussing a new API that could be very much exactly
James Almer (12021-12-13):
> Can't user defined names let you do that without the need to reuse the same
> AVChannel value in a given layout? And for that matter, can you not set said
> names within the filter itself and not in the layout?
I do not see how they could. But as always, "I do not see
Quoting Marton Balint (2021-12-13 23:47:22)
> On Sun, 12 Dec 2021, Anton Khirnov wrote:
> >
> > So what are you proposing? In my view, such higher level information
> > should live at a higher level - e.g. in the side data. You can then
> > have a filter that reads this side data and gets you the g
On 12/13/2021 8:36 PM, Nicolas George wrote:
James Almer (12021-12-13):
To achieve this you don't need the same AVChannel value to appear several
times in the same layout. You have INT_MAX values available, so just assign
one to each of these you mentioned. No need for an abstract value "user
James Almer (12021-12-13):
> To achieve this you don't need the same AVChannel value to appear several
> times in the same layout. You have INT_MAX values available, so just assign
> one to each of these you mentioned. No need for an abstract value "user
> defined" that would then show up several t
On 12/12/2021 5:00 PM, Nicolas George wrote:
Anton Khirnov (12021-12-12):
So what are you proposing? In my view, such higher level information
should live at a higher level - e.g. in the side data. You can then
have a filter that reads this side data and gets you the group you want.
So, wha
On Sun, 12 Dec 2021, Anton Khirnov wrote:
Quoting Marton Balint (2021-12-10 01:04:57)
On Thu, 9 Dec 2021, Anton Khirnov wrote:
Quoting Nicolas George (2021-12-09 11:31:54)
Anton Khirnov (12021-12-09):
I disagree. Technical limitations that were overcome 10 years ago should
not guide ne
Anton Khirnov (12021-12-12):
> So what are you proposing? In my view, such higher level information
> should live at a higher level - e.g. in the side data. You can then
> have a filter that reads this side data and gets you the group you want.
So, what is the point of this new API if anything of
Quoting Marton Balint (2021-12-10 01:04:57)
>
>
> On Thu, 9 Dec 2021, Anton Khirnov wrote:
>
> > Quoting Nicolas George (2021-12-09 11:31:54)
> >> Anton Khirnov (12021-12-09):
> >>> I disagree. Technical limitations that were overcome 10 years ago should
> >>> not guide new API design.
> >>
> >>
On Thu, Dec 09, 2021 at 04:47:48PM +0100, Lynne wrote:
[...]
> So I'm fine with your proposal to have 16-bit enum for the channel
> ID and a 16-bit opaque. Though I'd like the opaque to be an
> uint16_t instead of int opaque : 16.
> And 16-bits does sound like enough for many channels and quite a
>
On Thu, 9 Dec 2021, Anton Khirnov wrote:
Quoting Nicolas George (2021-12-09 11:31:54)
Anton Khirnov (12021-12-09):
I disagree. Technical limitations that were overcome 10 years ago should
not guide new API design.
In the case of amerge, it was not a technical limitation, merging
several s
On Thu, Dec 9, 2021 at 5:26 PM Nicolas George wrote:
> Hendrik Leppkes (12021-12-09):
> > It sounds like thats object audio, and should be driven separately,
> > and not by the legacy channel identifiers.
>
> This is not exclusive. We have code that works with channel layouts
> right now, and it
Hendrik Leppkes (12021-12-09):
> It sounds like thats object audio, and should be driven separately,
> and not by the legacy channel identifiers.
This is not exclusive. We have code that works with channel layouts
right now, and it is important that the extensions work gracefully.
For example, if
On Thu, Dec 9, 2021 at 3:57 PM Nicolas George wrote:
>
> Hendrik Leppkes (12021-12-09):
> > What kind of sense does a frame make that contains the same channel
> > twice?
>
> Imagine an orchestra recording:
>
> Orchestra, front left
> Orchestra, front center
> Orchestra, front right
> Orchestra, l
Lynne (12021-12-09):
> So I'm fine with your proposal to have 16-bit enum for the channel
> ID and a 16-bit opaque. Though I'd like the opaque to be an
> uint16_t instead of int opaque : 16.
> And 16-bits does sound like enough for many channels and quite a
> few flags, though the silent flag shoul
9 Dec 2021, 15:57 by an...@khirnov.net:
> Quoting Lynne (2021-12-09 15:42:42)
>
>> 9 Dec 2021, 15:24 by geo...@nsup.org:
>>
>> > Anton Khirnov (12021-12-09):
>> >
>> >> I see you repeating the same two arguments:
>> >> - it was implemented like this in the past and therefore must keep
>> >> worki
Quoting Lynne (2021-12-09 15:42:42)
> 9 Dec 2021, 15:24 by geo...@nsup.org:
>
> > Anton Khirnov (12021-12-09):
> >
> >> I see you repeating the same two arguments:
> >> - it was implemented like this in the past and therefore must keep
> >> working exactly the same
> >> - it might be useful under
Hendrik Leppkes (12021-12-09):
> What kind of sense does a frame make that contains the same channel
> twice?
Imagine an orchestra recording:
Orchestra, front left
Orchestra, front center
Orchestra, front right
Orchestra, low freq
Orchestra, rear left
Orchestra, rear center
Winds, left
Winds, rig
On Thu, Dec 9, 2021 at 3:42 PM Lynne wrote:
>
> 9 Dec 2021, 15:24 by geo...@nsup.org:
>
> > Anton Khirnov (12021-12-09):
> >
> >> I see you repeating the same two arguments:
> >> - it was implemented like this in the past and therefore must keep
> >> working exactly the same
> >> - it might be us
9 Dec 2021, 15:24 by geo...@nsup.org:
> Anton Khirnov (12021-12-09):
>
>> I see you repeating the same two arguments:
>> - it was implemented like this in the past and therefore must keep
>> working exactly the same
>> - it might be useful under some vaguely specified conditions
>>
>> Neither of
Anton Khirnov (12021-12-09):
> I see you repeating the same two arguments:
> - it was implemented like this in the past and therefore must keep
> working exactly the same
> - it might be useful under some vaguely specified conditions
>
> Neither of these strikes me as a good enough reason to mak
Quoting Nicolas George (2021-12-09 14:52:40)
> Anton Khirnov (12021-12-09):
> > I fail to see how that is an advantage. You can just as well create
> > multiple instances of those single-stream filters instead of adding
> > hacks into core APIs.
>
> Please think a little further: multiple instance
Anton Khirnov (12021-12-09):
> I fail to see how that is an advantage. You can just as well create
> multiple instances of those single-stream filters instead of adding
> hacks into core APIs.
Please think a little further: multiple instances of the single-stream
filters would not have access to a
Quoting Nicolas George (2021-12-09 11:31:54)
> Anton Khirnov (12021-12-09):
> > I disagree. Technical limitations that were overcome 10 years ago should
> > not guide new API design.
>
> In the case of amerge, it was not a technical limitation, merging
> several streams into one so that they can b
Anton Khirnov (12021-12-09):
> It is not possible for them to behave "like that", because our current
> channel layout API does not support duplicated channels at all.
They behave like in the sense they output channels from several sources
in a single stream of AVFrame. They could not properly lab
Quoting Nicolas George (2021-12-08 16:08:54)
> Anton Khirnov (12021-12-08):
> We get to decide what is a valid use case and what is not. And in this
> case, since the devices and filter I quoted already behave like that,
It is not possible for them to behave "like that", because our current
channe
On Wed, Dec 8, 2021 at 4:09 PM Nicolas George wrote:
> Anton Khirnov (12021-12-08):
> > I have no idea what you mean, the CUSTOM order can have any channel at
> > any location. This was true in all versions of this API back to 2013.
>
> Ok, my memories were muddy, now I remember better: it is pos
Anton Khirnov (12021-12-08):
> I have no idea what you mean, the CUSTOM order can have any channel at
> any location. This was true in all versions of this API back to 2013.
Ok, my memories were muddy, now I remember better: it is possible, but
without (2) and (3) it is unusable: there is no point
James Almer (12021-12-08):
> What is wrong with it? All the functions returning a string in this API use
> the same signature. You pass it a pre-allocated buffer and it's filled with
> the string, truncating it if there's not enough space and letting the user
> know about it.
> I recall you were ag
Quoting Nicolas George (2021-12-08 11:55:40)
> James Almer (12021-12-07):
> > This is an updated and rebased version of the API that was sent to this
> > mailing
> > list about two years ago. It expands it with some new helpers, implements
> > some
> > changes that allows further extensibility fo
On 12/8/2021 7:55 AM, Nicolas George wrote:
James Almer (12021-12-07):
This is an updated and rebased version of the API that was sent to this mailing
list about two years ago. It expands it with some new helpers, implements some
changes that allows further extensibility for new features down
James Almer (12021-12-07):
> This is an updated and rebased version of the API that was sent to this
> mailing
> list about two years ago. It expands it with some new helpers, implements some
> changes that allows further extensibility for new features down the line, and
> finishes porting all mis
On Wed, Dec 8, 2021 at 2:07 AM James Almer wrote:
> This is an updated and rebased version of the API that was sent to this
> mailing
> list about two years ago. It expands it with some new helpers, implements
> some
> changes that allows further extensibility for new features down the line,
> an
This is an updated and rebased version of the API that was sent to this mailing
list about two years ago. It expands it with some new helpers, implements some
changes that allows further extensibility for new features down the line, and
finishes porting all missing modules and those introduced sinc
36 matches
Mail list logo
