Anton Khirnov (12020-02-25):
> As far as I can tell, the Apple API linked above does not support that
> either. The way of describing the channel layout is given by
> mChannelLayoutTag, which can be either
> - kAudioChannelLayoutTag_UseChannelBitmap, which is effectively
> equivalent to our
Hendrik Leppkes (12020-02-25):
> Standards designed by committee like all this MPEG stuff are full of
> features that noone uses. Its usually indicative of the following
> replacement standard dumping them again. Instead, they threw in a
> bunch of new things of questionable use that will
Quoting Nicolas George (2020-02-25 12:47:03)
> Anton Khirnov (12020-02-19):
> > Thanks for the links. As far as I can tell this can be mapped to the
> > proposed API just fine
>
> Except for the user interface part, as I already pointed: if there are
> several times the same channel, the API
On Tue, Feb 25, 2020 at 12:47 PM Nicolas George wrote:
> >(except for signalling precise speaker
> > coordinates, which I don't think anything uses).
>
> I think somebody uses it, because somebody felt the need to include it
> in the standard. Therefore, we need to support
Anton Khirnov (12020-02-19):
> Thanks for the links. As far as I can tell this can be mapped to the
> proposed API just fine
Except for the user interface part, as I already pointed: if there are
several times the same channel, the API needs to provide a standard way
for the user to specify one.
Quoting Marton Balint (2020-02-18 23:54:56)
>
>
> On Tue, 18 Feb 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2020-02-05 19:55:24)
> >>
> >>
> >> On Tue, 7 Jan 2020, Anton Khirnov wrote:
> >>
> >> > Quoting Nicolas George (2019-12-31 16:17:49)
> >> >> Anton Khirnov (12019-12-29):
On Tue, 18 Feb 2020, Anton Khirnov wrote:
Quoting Marton Balint (2020-02-05 19:55:24)
On Tue, 7 Jan 2020, Anton Khirnov wrote:
> Quoting Nicolas George (2019-12-31 16:17:49)
>> Anton Khirnov (12019-12-29):
>> > I do not agree. Duplicated channels in a layout are expected to be a
>> >
Quoting Marton Balint (2020-02-05 19:55:24)
>
>
> On Tue, 7 Jan 2020, Anton Khirnov wrote:
>
> > Quoting Nicolas George (2019-12-31 16:17:49)
> >> Anton Khirnov (12019-12-29):
>
> >> > I do not agree. Duplicated channels in a layout are expected to be a
> >> > fringe thing and how you handle
On Tue, 7 Jan 2020, Anton Khirnov wrote:
Quoting Nicolas George (2019-12-31 16:17:49)
Anton Khirnov (12019-12-29):
> I do not agree. Duplicated channels in a layout are expected to be a
> fringe thing and how you handle them highly depends on the specific use
> case. I expect a typical
On 2/1/20, Nicolas George wrote:
> Anton Khirnov (12020-01-28):
>> That makes no sense. The filter cannot "have needs" when the current API
>> does not support the use case you have in mind (which is good). The
>> filter can either be modified to allow multiple inputs or a new filter
>> can be
Anton Khirnov (12020-01-28):
> That makes no sense. The filter cannot "have needs" when the current API
> does not support the use case you have in mind (which is good). The
> filter can either be modified to allow multiple inputs or a new filter
> can be added.
It makes perfect sense: I know
Quoting Nicolas George (2020-01-14 17:07:56)
> Anton Khirnov (12020-01-14):
> > No. If you want to mix multiple streams, then your mixing filter should
> > support multiple streams. It is certainly in no way "natural" or correct
> > to invent a scheme for stream multiplexing through channel
On 1/14/20, Nicolas George wrote:
> Anton Khirnov (12020-01-14):
>> No. If you want to mix multiple streams, then your mixing filter should
>> support multiple streams. It is certainly in no way "natural" or correct
>> to invent a scheme for stream multiplexing through channel layouts.
>
> You
Anton Khirnov (12020-01-14):
> No. If you want to mix multiple streams, then your mixing filter should
> support multiple streams. It is certainly in no way "natural" or correct
> to invent a scheme for stream multiplexing through channel layouts.
You could argue that if the channel layout API
Quoting Nicolas George (2020-01-14 15:53:26)
> Anton Khirnov (12020-01-13):
> > You still did not say which filters those are, why do they need to
> > create streams with duplicate channels, or for that matter how they can
> > even do so when the current API does not support it.
>
> The one that
Quoting Nicolas George (2020-01-14 15:46:17)
> Anton Khirnov (12020-01-12):
> > Your explanation does not make sense to me. Checking for negative values
> > is not guarding against overflow, it's "checking after the fact whether
> > overflow occurred". Any such checks, whether signed or unsigned,
Anton Khirnov (12020-01-13):
> You still did not say which filters those are, why do they need to
> create streams with duplicate channels, or for that matter how they can
> even do so when the current API does not support it.
The one that comes to mind immediately is amerge, which is meant to be
Anton Khirnov (12020-01-12):
> Your explanation does not make sense to me. Checking for negative values
> is not guarding against overflow, it's "checking after the fact whether
> overflow occurred". Any such checks, whether signed or unsigned, are
> necessarily invalid and broken (hence the
Quoting Nicolas George (2020-01-12 14:33:19)
> Anton Khirnov (12020-01-07):
> > Why would such filters exist and why would we accept them? I do not see
> > how can there be a clean user interface for a broken and undefined use
> > case.
>
> They are already there, they work very well, and people
Quoting Nicolas George (2020-01-12 14:28:06)
> Anton Khirnov (12020-01-07):
> > How is it any better in the unsigned case? You do a well-defined
> > unsigned overflow and end up with an invalid channel count (which might
> > even look sane).
>
> I explained this: you can guard against defined
Anton Khirnov (12020-01-07):
> This API is the simplest way I could think of that achieves the desired
> goals (bundling the channel count+layout together, allowing arbitrary
> channel counts, ambisonic,...). Most things doable with the current API
> are just as simple in the new one.
What I am
Anton Khirnov (12020-01-07):
> How is it any better in the unsigned case? You do a well-defined
> unsigned overflow and end up with an invalid channel count (which might
> even look sane).
I explained this: you can guard against defined behaviors, not against
undefined behaviors, because the
Quoting Nicolas George (2019-12-31 15:01:03)
> Anton Khirnov (12019-12-29):
> > Maybe I missed something, but I am not aware of the UB-ness of signed
> > overflow being a practical problem. Typically, your computation will
> > return a meaningless result. You would get a similarly meaningless
> >
Quoting Nicolas George (2019-12-31 16:17:49)
> Anton Khirnov (12019-12-29):
> > In the API namespace (function names) or the parameter names? For the
> > latter, it can be changed at any time without problem and I don't really
> > care much. For the former, the header is called channel_layout and
Anton Khirnov (12019-12-29):
> In the API namespace (function names) or the parameter names? For the
> latter, it can be changed at any time without problem and I don't really
> care much. For the former, the header is called channel_layout and I'd
> lean towards keeping that aligned with the
Anton Khirnov (12019-12-29):
> Maybe I missed something, but I am not aware of the UB-ness of signed
> overflow being a practical problem. Typically, your computation will
> return a meaningless result. You would get a similarly meaningless
> result from the analogous perfectly well-defined
Quoting Nicolas George (2019-12-07 21:25:53)
> Anton Khirnov (12019-12-06):
> > 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
Quoting Nicolas George (2019-12-17 20:20:00)
> Hi.
>
> Anton Khirnov (12019-12-10):
> > I disagree. I think I have a fair amount of skill and experience as a C
> > developer, but I still get hit by those issues frequently. It's extra
> > trouble for only theoretical gain.
>
> I concede this to
Hi.
Anton Khirnov (12019-12-10):
> I disagree. I think I have a fair amount of skill and experience as a C
> developer, but I still get hit by those issues frequently. It's extra
> trouble for only theoretical gain.
I concede this to you, except for the last sentence: I do not agree that
the
Quoting Nicolas George (2019-12-09 20:34:45)
> Michael Niedermayer (12019-12-09):
> > mixing unsigned and signed int of course works if one is aware of
> > * what is signed, what is unsigned
> > * exact semantics of expressions mixing them
> > * does not miss any corner cases
>
> I think it is
Michael Niedermayer (12019-12-09):
> mixing unsigned and signed int of course works if one is aware of
> * what is signed, what is unsigned
> * exact semantics of expressions mixing them
> * does not miss any corner cases
I think it is reasonable to demand from FFmpeg developers that they know
On Mon, Dec 09, 2019 at 12:36:11AM +0100, Nicolas George wrote:
> Michael Niedermayer (12019-12-09):
> > One problem with unsigned is that in expressions you cannot have negative
> > values, nor can you compare to negative values without casting to signed.
> > That has some risk for producing
Michael Niedermayer (12019-12-09):
> One problem with unsigned is that in expressions you cannot have negative
> values, nor can you compare to negative values without casting to signed.
> That has some risk for producing unexpected behavior bugs
>
> for example
> if (ch >= s->nb_channels) {
>
On Sat, Dec 07, 2019 at 09:25:53PM +0100, Nicolas George wrote:
> Anton Khirnov (12019-12-06):
> > 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.
> >
Anton Khirnov (12019-12-06):
> 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.
>
>
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 Vittorio Giovara .
36 matches
Mail list logo
