Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 current API, or the new API's LAYOUT_NATIVE > - one of several predefined layouts, which can be mapped either to > LAYOUT_NATIVE or LAYOUT_CUSTOM > - kAudioChannelLayoutTag_UseChannelDescriptions, which cannot be > represented in the current API, but is effectively equivalent to the > new API's LAYOUT_CUSTOM > The AudioChannelDescription struct contains: > * AudioChannelFlags, which apply to coordinates > * three floats, which are the coordinates > * AudioChannelLabel, which is uint32 similar to our AVChannel > > I see no support for any custom free-form text labels of the kind you > want me to add. The link above does not describe an API, it describe a format. A format that can contain several channels with the FL (example) disposition. Even if there are no labels attached, users need an interface to specify one: "the first FL channel", "the second FL channel", for example. Your proposal does not have it, it needs it. > In addition to Hendrik's reply (which I agree with), support for this > can be later added through a new layout type if someone really needs it. > I see no reason to spend effort implementing functionality that is not > actually used for anything. It's the second time you propose to extend the API later like that. I am glad you realize the API you proposed is insufficient and needs extending, but I am worried that you don't realize that extending later for needs that we see now is a terrible idea. It's a terrible idea because it requires more work, and because the extension will always stay second class compared to the initial code, and unsupported in all the places in the code that will not be updated for it. Since we were lucky to see we need a way of attaching data to channels before including the API, we'll include it in the API from the start. It's too bad it will require dynamic allocation and make the handling of the structure as a whole more clumsy, but it seems it was unavoidable. We could use simply a per-channel metadata dictionary, it would allow both the speaker coordinate in this spec and the free-form label that I want. Alternatively, we can use a more typed approach, like side data. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 disappear in the > next standard once again. I agree, it's a very weak argument. But it's still infinitely superior to the absence of arguments in "I don't think anything uses". > I don't think we should be blindly following what some other group > thinks, but critically judge everything we're implementing here. I am not suggesting following anything blindly. But files using this feature can exist out there, so the question is whether to accept an API that cannot handle them without loss of information. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 needs to provide a standard way > for the user to specify one. 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 current API, or the new API's LAYOUT_NATIVE - one of several predefined layouts, which can be mapped either to LAYOUT_NATIVE or LAYOUT_CUSTOM - kAudioChannelLayoutTag_UseChannelDescriptions, which cannot be represented in the current API, but is effectively equivalent to the new API's LAYOUT_CUSTOM The AudioChannelDescription struct contains: * AudioChannelFlags, which apply to coordinates * three floats, which are the coordinates * AudioChannelLabel, which is uint32 similar to our AVChannel I see no support for any custom free-form text labels of the kind you want me to add. > > >(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 it. In addition to Hendrik's reply (which I agree with), support for this can be later added through a new layout type if someone really needs it. I see no reason to spend effort implementing functionality that is not actually used for anything. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout 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 it. > 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 disappear in the next standard once again. I don't think we should be blindly following what some other group thinks, but critically judge everything we're implementing here. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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. >(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 it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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): > >> > >> >> > 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 caller will want to disregard that > >> >> > possibility > >> >> > and just take the first channel of each semantics. > >> >> > So I do not believe a dedicated function for this makes sense. We > >> >> > could > >> >> > always add something later though, if it turns out to be necessary. > >> >> > >> >> I think you are making a mistake. I think that as soon as it will be > >> >> technically possible, we will see cases with duplicated channels. And I > >> >> know that some filters will do exactly that as soon as they are ported > >> >> to this new API. > >> > >> Quicktime also allows duplicated channels in a single audio track, this is > >> unfortunately a commonly used feature. So if a new API is introduced to > >> overcome the limitations of the existing one, supporting this should be > >> seriously considered. > > > > Can you provide a link to more information about this? I'd like to know > > the specifics about how it's handled by quicktime. And do note that this > > API does have some ammount of support for duplicated channels (though I > > still consider streams containing them to be broken). > > The 'chan' atom can hold this information: > > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP4939-CH205-SW53 > > It holds an AudioChannelLayout structure as defined in CoreAudioTypes.h: > > https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout > https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1353 > > Which can hold an AudioChannelDescription array of channel descriptions > for each channel: > > https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout > https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1335 > > Which can signal the same AudioChannelLabel for every channel in a track > if needed. Thanks for the links. As far as I can tell this can be mapped to the proposed API just fine (except for signalling precise speaker coordinates, which I don't think anything uses). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 >> > fringe thing and how you handle them highly depends on the specific use >> > case. I expect a typical caller will want to disregard that possibility >> > and just take the first channel of each semantics. >> > So I do not believe a dedicated function for this makes sense. We could >> > always add something later though, if it turns out to be necessary. >> >> I think you are making a mistake. I think that as soon as it will be >> technically possible, we will see cases with duplicated channels. And I >> know that some filters will do exactly that as soon as they are ported >> to this new API. Quicktime also allows duplicated channels in a single audio track, this is unfortunately a commonly used feature. So if a new API is introduced to overcome the limitations of the existing one, supporting this should be seriously considered. Can you provide a link to more information about this? I'd like to know the specifics about how it's handled by quicktime. And do note that this API does have some ammount of support for duplicated channels (though I still consider streams containing them to be broken). The 'chan' atom can hold this information: https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP4939-CH205-SW53 It holds an AudioChannelLayout structure as defined in CoreAudioTypes.h: https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1353 Which can hold an AudioChannelDescription array of channel descriptions for each channel: https://developer.apple.com/documentation/coreaudiotypes/audiochannellayout https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.15.sdk/System/Library/Frameworks/CoreAudioTypes.framework/Versions/A/Headers/CoreAudioBaseTypes.h#L1335 Which can signal the same AudioChannelLabel for every channel in a track if needed. There is some support for it in libavformat/mov_chan.c. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 them highly depends on the specific use > >> > case. I expect a typical caller will want to disregard that possibility > >> > and just take the first channel of each semantics. > >> > So I do not believe a dedicated function for this makes sense. We could > >> > always add something later though, if it turns out to be necessary. > >> > >> I think you are making a mistake. I think that as soon as it will be > >> technically possible, we will see cases with duplicated channels. And I > >> know that some filters will do exactly that as soon as they are ported > >> to this new API. > > Quicktime also allows duplicated channels in a single audio track, this is > unfortunately a commonly used feature. So if a new API is introduced to > overcome the limitations of the existing one, supporting this should be > seriously considered. Can you provide a link to more information about this? I'd like to know the specifics about how it's handled by quicktime. And do note that this API does have some ammount of support for duplicated channels (though I still consider streams containing them to be broken). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 caller will want to disregard that possibility > and just take the first channel of each semantics. > So I do not believe a dedicated function for this makes sense. We could > always add something later though, if it turns out to be necessary. I think you are making a mistake. I think that as soon as it will be technically possible, we will see cases with duplicated channels. And I know that some filters will do exactly that as soon as they are ported to this new API. Quicktime also allows duplicated channels in a single audio track, this is unfortunately a commonly used feature. So if a new API is introduced to overcome the limitations of the existing one, supporting this should be seriously considered. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 added. > > It makes perfect sense: I know what I planned when I wrote them, and the > plan was always that when we would replace the channel layout API, it > would be able to express duplicated channels. And we will not demand > users to learn new filters for that. > > You can continue to disregard my arguments, and getting close to being > insulting while you are at it, but you will not get me to change my mind > like that. The API, as it is, is rejected. Either we design a good API, > one that can satisfy the needs you see and the needs I see, or we keep > the current, very simple, API. No half-measure that brings all the > drawbacks and almost no benefit. Why you think you are not insulting other developers by your way of expressing your side of view. Very short sighted reasoning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 what I planned when I wrote them, and the plan was always that when we would replace the channel layout API, it would be able to express duplicated channels. And we will not demand users to learn new filters for that. You can continue to disregard my arguments, and getting close to being insulting while you are at it, but you will not get me to change my mind like that. The API, as it is, is rejected. Either we design a good API, one that can satisfy the needs you see and the needs I see, or we keep the current, very simple, API. No half-measure that brings all the drawbacks and almost no benefit. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 layouts. > > You could argue that if the channel layout API was done and the filter > was in the process of being written. But it is the other way around: the > filter exists, it has needs, the new API must adapt. 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 could argue that if the channel layout API was done and the filter > was in the process of being written. But it is the other way around: the > filter exists, it has needs, the new API must adapt. > This is pure nonsense, nothing must adapt. > Regards, > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 was done and the filter was in the process of being written. But it is the other way around: the filter exists, it has needs, the new API must adapt. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new 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 comes to mind immediately is amerge, which is meant to be > used in conjunction with pan to perform arbitrary mix between different > audio streams. It was here significantly before the fork introduced > amix, and had features that are not available there. > > With the current code, when the layouts overlap, it resorts to declaring > an unknown layout and relying on channel order after printing a warning. > But the natural way of doing it is to have repeated channels: > > [sfx][music][cmt]amerge=3 ; > pan=5.1 | FC FL FR BL BR LF > Any new channel layout API must contain provisions to handle this > pattern. 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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, are > > necessarily invalid and broken (hence the quotes). Guarding against > > overflow must always be done by checking BEFORE the operation that might > > overflow - again both for signed and unsigned. > > > > From this angle, there is no difference between using signed and > > unsigned values. The fact that in one case the overflow would have been > > UB and the other wouldn't changes nothing here. > > You are right: if the code is known to be 100% bug-free, then it makes > no difference. But even TeX's code is not known to be 100% bug-free. And > when there may be bugs, I think I have given ample proof that signed > with UB are more dangerous than unsigned with modular arithmetic. No you certainly have not. If buggy code produces an invalid channel count through overflow, then you are screwed no matter what. The fact that one of the overflows is UB and the other is not has zero impact on the fact that the channel count is unusable garbage (as I already said). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 used in conjunction with pan to perform arbitrary mix between different audio streams. It was here significantly before the fork introduced amix, and had features that are not available there. With the current code, when the layouts overlap, it resorts to declaring an unknown layout and relying on channel order after printing a warning. But the natural way of doing it is to have repeated channels: [sfx][music][cmt]amerge=3 ; pan=5.1 | FC signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 quotes). Guarding against > overflow must always be done by checking BEFORE the operation that might > overflow - again both for signed and unsigned. > > From this angle, there is no difference between using signed and > unsigned values. The fact that in one case the overflow would have been > UB and the other wouldn't changes nothing here. You are right: if the code is known to be 100% bug-free, then it makes no difference. But even TeX's code is not known to be 100% bug-free. And when there may be bugs, I think I have given ample proof that signed with UB are more dangerous than unsigned with modular arithmetic. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 use them. Their > behavior is perfectly well defined, but to give them a good user > interface requires channel names and duplication. It's too bad you > invested a lot of work while forgetting about them. 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 behaviors, not against > undefined behaviors, because the compilers are allowed to shunt the > checks, and they do. 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 quotes). Guarding against overflow must always be done by checking BEFORE the operation that might overflow - again both for signed and unsigned. From this angle, there is no difference between using signed and unsigned values. The fact that in one case the overflow would have been UB and the other wouldn't changes nothing here. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 saying is that the goals were not far enough. > Reference counting means dynamic allocation and a whole bunch of extra > complixity. I believe it is not worth it. This new API is not worth it if it does not allow a proper user interface for naming channels including when they are duplicated. > And the caller gets an extra opportunity to receive an invalid truncated > result if he doesn't go out of his way to check the result. If they chose so, it is their problem. But let us discuss that part in the other thread. > What questions about a channel layout would you consider relevant then? > > A channel layout IS - by definition - a mapping from stream indices to > semantics. 'What semantics does the n-th channel have' is one of just > two fundamental questions you can ask about a layout (the other one is > 'how many channels are there'), everything else is fluff. Ok. > 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 use them. Their behavior is perfectly well defined, but to give them a good user interface requires channel names and duplication. It's too bad you invested a lot of work while forgetting about them. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 compilers are allowed to shunt the checks, and they do. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 > > result from the analogous perfectly well-defined unsigned computation. > > > > to be clear: I am not objecting against fixing UB, but clarifying my > > 'theoretical gain' comment above. > > It seems you have missed some of the drama that happened on this list > recently. Michael and others have been intent on fixing the UB caused by > integer overflows, including cases that I personally find futile. > > But I do not consider this case futile: a channel number will typically > be used as an array index, and an invalid value will cause an invalid > memory access and a segmentation fault, or an exploitable memory > corruption. > > What makes signed overflows, which are UB, worse than unsigned > overflows, which are completely specified, is that you cannot guard > against it. For example, if your write: > > if (ch < 0 || ch >= nb_channels) > return AVERROR_BUG; > > you think you are safe, but if the compiler detects that ch cannot be > negative without overflow, it will silently discard the ch<0 test. Then, > if the overflows does happen, there is no protection against invalid > memory access. > > And this is not theoretical: I have seen entire blogs and twitter > accounts dedicated to posting examples of actual cases where an > optimizing compiler produces very unintuitive code because there is a > tiny UB in the middle. 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). -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 I'd > > lean towards keeping that aligned with the namespace. Not a very strong > > opinion though. > > I meant both, but of course the names of the public symbols (and the name > of the header, which is not set in marble) are what we are stuck with > and requires careful planning. I do not insist on it, but it is > something to consider. > > In fact, I just noticed that you used chlayout at some places in the > public API instead of channel_layout. Yes, fields in structs where channel_layout already exists. I don't see what else can be done there. > > > Hmm, this was apparently added by Vittorio so I'm not sure, but would > > assume it refers to AV_CHAN_SILENCE. > > It will need to be clarified before it's done. Right, explanation added. > > > I am aware that it is different, but making the struct dynamic would > > make using it significantly more cumbersome. Given how long we have > > lived with the bitmask, I do not expect there to be a significant need > > to add more fields to it. > > The bitmask was constraining, but it was very simple: we can accept to > be constrained as the cost of simplicity. This new API is not very > simple: if it is constraining, the it is not worth it. 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. > > > Plus, it can still be extended by adding a new AV_CHANNEL_ORDER types > > and a corresponding new union member. > > Not all extensions can be done like that. > > > Given that a copy of this struct is embedded in every single frame, I'd > > rather not add extensive dynamically allocated metadata to it. Those > > should rather appear in some higher level API. > > What higher level API? Maybe we need to reconsider embedding the > structure in every single frame, and possibly using reference counting > instead. Reference counting means dynamic allocation and a whole bunch of extra complixity. I believe it is not worth it. > > > They also can (and are, in the patchset) used as > > (AVChannelLayout)AV_CHANNEL_LAYOUT_FOO > > > > We might want to add a macro for that. > > Ok. Or just mention it in the doc. > > > That still requires error checks and adds considerable complexity. > > This is not true, please have a look at the API I have proposed, since I > have posted it on the mailing-list: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254901.html > > As you can see, all the complexity is inside the implementation. For the > code that uses the API, it actually makes things simpler. > > In particular, with your version, error checking must be done twice: > once in av_channel_layout_describe() and once when calling it. With > AVWriter, the first one is unnecessary. And the caller gets an extra opportunity to receive an invalid truncated result if he doesn't go out of his way to check the result. > > > There is no hiding from the fact that the string size is not bounded, so > > either you make up an arbitrary limit and hope it's enough (and have it > > fail for special cases), or you do dynamic allocation with error checks. > > All that is taken care of by the API and hidden from the user. > > > Yes. The point of the API is to provide a logical mapping between > > audio channels and their indices in a stream. That way, the callers that > > only read the channel layout do not (typically) need to know how exactly > > it is stored. > > > > This function is the canonical way of answering the question 'what > > semantics does n-th channel in this stream have?', so the callers don't > > need to handle ORDER_NATIVE vs ORDER_CUSTOM, or do any messing with > > bitmasks. > > Ok. But my point is: is the question "what semantics does n-th channel > in this stream have?" really relevant? > > (Similar with strings: the question "what is the n-th character" is > hardly ever relevant, but people keep asking it and implementing APIs to > answer it.) What questions about a channel layout would you consider relevant then? A channel layout IS - by definition - a mapping from stream indices to semantics. 'What semantics does the n-th channel have' is one of just two fundamental questions you can ask about a layout (the other one is 'how many channels are there'), everything else is fluff. > > > 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 caller will want to disregard that possibility > > and just take the first channel of each semantics.
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 namespace. Not a very strong > opinion though. I meant both, but of course the names of the public symbols (and the name of the header, which is not set in marble) are what we are stuck with and requires careful planning. I do not insist on it, but it is something to consider. In fact, I just noticed that you used chlayout at some places in the public API instead of channel_layout. > Hmm, this was apparently added by Vittorio so I'm not sure, but would > assume it refers to AV_CHAN_SILENCE. It will need to be clarified before it's done. > I am aware that it is different, but making the struct dynamic would > make using it significantly more cumbersome. Given how long we have > lived with the bitmask, I do not expect there to be a significant need > to add more fields to it. The bitmask was constraining, but it was very simple: we can accept to be constrained as the cost of simplicity. This new API is not very simple: if it is constraining, the it is not worth it. > Plus, it can still be extended by adding a new AV_CHANNEL_ORDER types > and a corresponding new union member. Not all extensions can be done like that. > Given that a copy of this struct is embedded in every single frame, I'd > rather not add extensive dynamically allocated metadata to it. Those > should rather appear in some higher level API. What higher level API? Maybe we need to reconsider embedding the structure in every single frame, and possibly using reference counting instead. > They also can (and are, in the patchset) used as > (AVChannelLayout)AV_CHANNEL_LAYOUT_FOO > > We might want to add a macro for that. Ok. Or just mention it in the doc. > That still requires error checks and adds considerable complexity. This is not true, please have a look at the API I have proposed, since I have posted it on the mailing-list: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254901.html As you can see, all the complexity is inside the implementation. For the code that uses the API, it actually makes things simpler. In particular, with your version, error checking must be done twice: once in av_channel_layout_describe() and once when calling it. With AVWriter, the first one is unnecessary. > There is no hiding from the fact that the string size is not bounded, so > either you make up an arbitrary limit and hope it's enough (and have it > fail for special cases), or you do dynamic allocation with error checks. All that is taken care of by the API and hidden from the user. > Yes. The point of the API is to provide a logical mapping between > audio channels and their indices in a stream. That way, the callers that > only read the channel layout do not (typically) need to know how exactly > it is stored. > > This function is the canonical way of answering the question 'what > semantics does n-th channel in this stream have?', so the callers don't > need to handle ORDER_NATIVE vs ORDER_CUSTOM, or do any messing with > bitmasks. Ok. But my point is: is the question "what semantics does n-th channel in this stream have?" really relevant? (Similar with strings: the question "what is the n-th character" is hardly ever relevant, but people keep asking it and implementing APIs to answer it.) > 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 caller will want to disregard that possibility > and just take the first channel of each semantics. > So I do not believe a dedicated function for this makes sense. We could > always add something later though, if it turns out to be necessary. I think you are making a mistake. I think that as soon as it will be technically possible, we will see cases with duplicated channels. And I know that some filters will do exactly that as soon as they are ported to this new API. Therefore, I insist, we need a clean user interface to handle duplicated channels. > Again, yes. E.g. you are decoding an audio stream with multiple channels > and want to know which is the 'front left' one. This function gives you > the canonical answer to that. Same as above: I do not insist, but I doubt that "which one is the front left" is a very interesting question. > It turns out to be useful in flacenc, matroskaenc and mlpdec > conversions. And of course can be potentially useful to the callers. > Since we are not deprecating the AV_CH_FOO macros, I do not see a > problem with having it public. Ok. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 unsigned computation. > > to be clear: I am not objecting against fixing UB, but clarifying my > 'theoretical gain' comment above. It seems you have missed some of the drama that happened on this list recently. Michael and others have been intent on fixing the UB caused by integer overflows, including cases that I personally find futile. But I do not consider this case futile: a channel number will typically be used as an array index, and an invalid value will cause an invalid memory access and a segmentation fault, or an exploitable memory corruption. What makes signed overflows, which are UB, worse than unsigned overflows, which are completely specified, is that you cannot guard against it. For example, if your write: if (ch < 0 || ch >= nb_channels) return AVERROR_BUG; you think you are safe, but if the compiler detects that ch cannot be negative without overflow, it will silently discard the ch<0 test. Then, if the overflows does happen, there is no protection against invalid memory access. And this is not theoretical: I have seen entire blogs and twitter accounts dedicated to posting examples of actual cases where an optimizing compiler produces very unintuitive code because there is a tiny UB in the middle. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 old API working with just uint64_t bitmasks.
> >
> > Expanded and completed by Vittorio Giovara .
> > Signed-off-by: Vittorio Giovara
> > ---
> > libavutil/channel_layout.c | 393 +--
> > libavutil/channel_layout.h | 415 ++---
> > libavutil/version.h| 3 +
> > 3 files changed, 719 insertions(+), 92 deletions(-)
>
> Thanks for sending this here. I will make a few preliminary remarks
> below.
>
> Before that, I want to mention I think the real trial for this API will
> be integration with libavfilter, especially the format negotiation and
> the user interface of the filters that allow fine control of channels.
> The negotiation, in particular, promises to be an interesting
> algorithmic problem. By "real trial", I mean that it is very possible
> that trying to implement that will make us realize some details need to
> be changed. I have these questions in mind while writing my comments.
>
> Two important comments to consider, because they affect the structure of
> the API itself:
>
> - about av_channel_layout_describe(), a general reflection on functions
> that return strings;
>
> - about getting a channel by name.
>
>
> > +int av_channel_layout_from_mask(AVChannelLayout *channel_layout,
> > +uint64_t mask)
>
> I find that "channel_layout" all over the place makes the code bulky,
> harder to read. And tiring to write. We could decide on a standard
> shortening for it everywhere. For example chlayout.
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 namespace. Not a very strong
opinion though.
> > +enum AVChannel {
> > +AV_CHAN_FRONT_LEFT,
> > +AV_CHAN_FRONT_RIGHT,
> > +AV_CHAN_FRONT_CENTER,
> > +AV_CHAN_LOW_FREQUENCY,
> > +AV_CHAN_BACK_LEFT,
> > +AV_CHAN_BACK_RIGHT,
> > +AV_CHAN_FRONT_LEFT_OF_CENTER,
> > +AV_CHAN_FRONT_RIGHT_OF_CENTER,
> > +AV_CHAN_BACK_CENTER,
> > +AV_CHAN_SIDE_LEFT,
> > +AV_CHAN_SIDE_RIGHT,
> > +AV_CHAN_TOP_CENTER,
> > +AV_CHAN_TOP_FRONT_LEFT,
> > +AV_CHAN_TOP_FRONT_CENTER,
> > +AV_CHAN_TOP_FRONT_RIGHT,
> > +AV_CHAN_TOP_BACK_LEFT,
> > +AV_CHAN_TOP_BACK_CENTER,
> > +AV_CHAN_TOP_BACK_RIGHT,
> > +/** Stereo downmix. */
> > +AV_CHAN_STEREO_LEFT = 29,
> > +/** See above. */
> > +AV_CHAN_STEREO_RIGHT,
> > +AV_CHAN_WIDE_LEFT,
> > +AV_CHAN_WIDE_RIGHT,
> > +AV_CHAN_SURROUND_DIRECT_LEFT,
> > +AV_CHAN_SURROUND_DIRECT_RIGHT,
> > +AV_CHAN_LOW_FREQUENCY_2,
> > +
> > +/** Channel is empty can be safely skipped. */
> > +AV_CHAN_SILENCE = 64,
> > +};
> > +
> > +enum AVChannelOrder {
> > +/**
> > + * The native channel order, i.e. the channels are in the same order in
> > + * which they are defined in the AVChannel enum. This supports up to 63
> > + * different channels.
> > + */
> > +AV_CHANNEL_ORDER_NATIVE,
> > +/**
> > + * The channel order does not correspond to any other predefined order
> > and
> > + * is stored as an explicit map. For example, this could be used to
> > support
>
> > + * layouts with 64 or more channels, or with channels that could be
> > skipped.
>
> [ Already said on 2019-10-30 ]
> "or with channels that could be skipped"? What does that mean. If a
> channel is skipped, it is not present, that can be expressed in the
> mask. Is this a mistake for "duplicated"?
Hmm, this was apparently added by Vittorio so I'm not sure, but would
assume it refers to AV_CHAN_SILENCE.
>
> > + */
> > +AV_CHANNEL_ORDER_CUSTOM,
> > +/**
> > + * Only the channel count is specified, without any further information
> > + * about the channel order.
> > + */
> > +AV_CHANNEL_ORDER_UNSPEC,
> > +};
> > +
> > +
> > /**
> > * @defgroup channel_masks Audio channel masks
> > *
> > @@ -46,36 +103,41 @@
> > *
> > * @{
> > */
> > -#define AV_CH_FRONT_LEFT 0x0001
> > -#define AV_CH_FRONT_RIGHT0x0002
> > -#define AV_CH_FRONT_CENTER 0x0004
> > -#define AV_CH_LOW_FREQUENCY 0x0008
> > -#define AV_CH_BACK_LEFT 0x0010
> > -#define AV_CH_BACK_RIGHT 0x0020
> > -#define AV_CH_FRONT_LEFT_OF_CENTER 0x0040
> > -#define AV_CH_FRONT_RIGHT_OF_CENTER 0x0080
> > -#define AV_CH_BACK_CENTER0x0100
> > -#define AV_CH_SIDE_LEFT 0x0200
> > -#define AV_CH_SIDE_RIGHT 0x0400
> > -#
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 you, except for the last sentence: I do not agree that > the gain is only theoretical. We only need to look at the number of > recent commits fixing possible integer overflows. Signed arithmetic is > tricky, possibly as tricky as the traps of mixing signed and unsigned. > The reason we are seeing this only now is because compilers have only > recently started to optimize these undefined behaviors aggressively. And > we have only recently started to care. But these are real traps that do > not happen with unsigned. 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 unsigned computation. to be clear: I am not objecting against fixing UB, but clarifying my 'theoretical gain' comment above. > > I would advise everybody to adopt the policy of always using unsigned > unless there is a good reason to use signed, instead of the default now > which is the opposite. > > Of course, for your own code and everybody else, I would not block the > patch if my advice is not followed. But this is public API, it should be > clean, so I will insist a little more. I would agree to that only if it was done consistently across the entire API. Since the channel count tends to be used in expressions with other values which are signed (e.g. sample rate). Which means that the users will have to mix signed and unsigned, making things harder for them. > > Using the logical type has practical benefits. One is that it guarantees > to the API users that negative values cannot happen, need not to be > tested. With an unsigned, the value can be injected in size and pointer > arithmetic directly. With a signed, the API user need either to add an > useless test or to blindly trust the library. Blindly trusting a piece > of code should always put people ill at ease. The guarantee that it cannot be negative in valid cases is already present, there is no need for users to test that explicitly. The only conceivable case where it will be negative is a bug in the code populating the channel layout. Making the value unsigned would not make such bugs go away, it would only make the value absurdly large instead of negative. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 gain is only theoretical. We only need to look at the number of recent commits fixing possible integer overflows. Signed arithmetic is tricky, possibly as tricky as the traps of mixing signed and unsigned. The reason we are seeing this only now is because compilers have only recently started to optimize these undefined behaviors aggressively. And we have only recently started to care. But these are real traps that do not happen with unsigned. I would advise everybody to adopt the policy of always using unsigned unless there is a good reason to use signed, instead of the default now which is the opposite. Of course, for your own code and everybody else, I would not block the patch if my advice is not followed. But this is public API, it should be clean, so I will insist a little more. Using the logical type has practical benefits. One is that it guarantees to the API users that negative values cannot happen, need not to be tested. With an unsigned, the value can be injected in size and pointer arithmetic directly. With a signed, the API user need either to add an useless test or to blindly trust the library. Blindly trusting a piece of code should always put people ill at ease. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 reasonable to demand from FFmpeg developers that they know > enough C to be at ease with this. 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. Will reply to the rest of your remarks later. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 enough C to be at ease with this. And for remembering exactly and not missing corner cases, there are compiler warnings. IIRC they are not enabled in FFmpeg, but they do lead to a much better code hygiene. > OTOH if everything is signed, then the developer does not need to worry > about these things, and its easier to remember "all is signed int" vs. > "these specific fields are unsigned" Indeed. Instead, if everything is signed, they have to worry about the many undefined behaviors attached with signed. Plus the risks that are not related to UB, like checking that an array index is small enough but forgetting to check non-negative. Considering the time you spent recently "fixing" signed integer overflows, I suspect you may be receptive to the fact that unsigned arithmetic is entirely specified. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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 unexpected behavior bugs
> >
> > for example
> > if (ch >= s->nb_channels) {
> > ...
> > } else if (ch < 0)
> > ...
> >
> > would not work as expected
>
> I do not see it as a problem, I see it as exactly what we want. If a
> value cannot meaningfully be negative, there is no sense in wasting time
> and code allowing it to be negative and then testing it.
>
> In the above code, ch should be unsigned too. Or, if it has a good
> reason to be signed (negative values meaning something else?), test them
> first.
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
OTOH if everything is signed, then the developer does not need to worry
about these things, and its easier to remember "all is signed int" vs.
"these specific fields are unsigned"
What i meant really is
"Its easier to maintain code that is all int, instead of code mixing
signed and unsigned int"
Sometimes we need unsigned and thats fine, i think though when we dont
"need" it, its better to use plain int.
Just my oppinion, not objecting to anything
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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) {
> ...
> } else if (ch < 0)
> ...
>
> would not work as expected
I do not see it as a problem, I see it as exactly what we want. If a
value cannot meaningfully be negative, there is no sense in wasting time
and code allowing it to be negative and then testing it.
In the above code, ch should be unsigned too. Or, if it has a good
reason to be signed (negative values meaning something else?), test them
first.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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.
> >
> > Deprecate the old API working with just uint64_t bitmasks.
> >
> > Expanded and completed by Vittorio Giovara .
> > Signed-off-by: Vittorio Giovara
> > ---
> > libavutil/channel_layout.c | 393 +--
> > libavutil/channel_layout.h | 415 ++---
> > libavutil/version.h| 3 +
> > 3 files changed, 719 insertions(+), 92 deletions(-)
>
> Thanks for sending this here. I will make a few preliminary remarks
> below.
[...]
> > + * Unlike most structures in Libav, sizeof(AVChannelLayout) is a part of
> > the
> > + * public ABI and may be used by the caller. E.g. it may be allocated on
> > stack.
> > + * In particular, this structure can be initialized as follows:
> > + * - default initialization with {0} or by setting all used fields
> > correctly
> > + * - with predefined layout as initializer (AV_CHANNEL_LAYOUT_STEREO, etc.)
> > + * - with a constructor function such as av_channel_layout_default()
> > + * On that note, this also applies:
> > + * - copy via assigning is forbidden, av_channel_layout_copy() must be used
> > + * instead (and its return value should be checked)
> > + * - if order is AV_CHANNEL_ORDER_CUSTOM, then it must be uninitialized
> > with
> > + * av_channel_layout_uninit().
> > + *
> > + * No new fields may be added to it without a major version bump, except
> > for
> > + * new elements of the union fitting in sizeof(uint64_t).
>
> [ Already said on 2019-10-30 ]
> This is a significant difference from the other APIs, and we need to be
> really sure we can live with it.
>
> I am rather for this version, but I am afraid we will find cases that
> need extending the structure.
>
> I suggest we explicitly declare this API unstable for a few months,
> during which we consider acceptable to add fields.
>
> > + *
> > + * An AVChannelLayout can be constructed using the convenience function
> > + * av_channel_layout_from_mask() / av_channel_layout_from_string(), or it
> > can be
> > + * built manually by the caller.
> > + */
> > +typedef struct AVChannelLayout {
> > +/**
> > + * Channel order used in this layout.
> > + * This is a mandatory field, will default to AV_CHANNEL_ORDER_NATIVE.
> > + */
> > +enum AVChannelOrder order;
> > +
> > +/**
> > + * Number of channels in this layout. Mandatory field.
> > + */
>
> > +int nb_channels;
>
> [ Already said on 2019-10-30 ]
> unsigned
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) {
...
} else if (ch < 0)
...
would not work as expected
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 001/244] Add a new channel layout API
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.
>
> Expanded and completed by Vittorio Giovara .
> Signed-off-by: Vittorio Giovara
> ---
> libavutil/channel_layout.c | 393 +--
> libavutil/channel_layout.h | 415 ++---
> libavutil/version.h| 3 +
> 3 files changed, 719 insertions(+), 92 deletions(-)
Thanks for sending this here. I will make a few preliminary remarks
below.
Before that, I want to mention I think the real trial for this API will
be integration with libavfilter, especially the format negotiation and
the user interface of the filters that allow fine control of channels.
The negotiation, in particular, promises to be an interesting
algorithmic problem. By "real trial", I mean that it is very possible
that trying to implement that will make us realize some details need to
be changed. I have these questions in mind while writing my comments.
Two important comments to consider, because they affect the structure of
the API itself:
- about av_channel_layout_describe(), a general reflection on functions
that return strings;
- about getting a channel by name.
>
> diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
> index 3bd5ee29b7..b7077ed5fd 100644
> --- a/libavutil/channel_layout.c
> +++ b/libavutil/channel_layout.c
> @@ -37,75 +37,89 @@ struct channel_name {
> };
>
> static const struct channel_name channel_names[] = {
> - [0] = { "FL","front left"},
> - [1] = { "FR","front right" },
> - [2] = { "FC","front center" },
> - [3] = { "LFE", "low frequency" },
> - [4] = { "BL","back left" },
> - [5] = { "BR","back right"},
> - [6] = { "FLC", "front left-of-center" },
> - [7] = { "FRC", "front right-of-center" },
> - [8] = { "BC","back center" },
> - [9] = { "SL","side left" },
> -[10] = { "SR","side right"},
> -[11] = { "TC","top center"},
> -[12] = { "TFL", "top front left"},
> -[13] = { "TFC", "top front center" },
> -[14] = { "TFR", "top front right" },
> -[15] = { "TBL", "top back left" },
> -[16] = { "TBC", "top back center" },
> -[17] = { "TBR", "top back right"},
> -[29] = { "DL","downmix left" },
> -[30] = { "DR","downmix right" },
> -[31] = { "WL","wide left" },
> -[32] = { "WR","wide right"},
> -[33] = { "SDL", "surround direct left" },
> -[34] = { "SDR", "surround direct right" },
> -[35] = { "LFE2", "low frequency 2" },
> +[AV_CHAN_FRONT_LEFT ] = { "FL","front left"
> },
> +[AV_CHAN_FRONT_RIGHT ] = { "FR","front right"
> },
> +[AV_CHAN_FRONT_CENTER ] = { "FC","front center"
> },
> +[AV_CHAN_LOW_FREQUENCY] = { "LFE", "low frequency"
> },
> +[AV_CHAN_BACK_LEFT] = { "BL","back left"
> },
> +[AV_CHAN_BACK_RIGHT ] = { "BR","back right"
> },
> +[AV_CHAN_FRONT_LEFT_OF_CENTER ] = { "FLC", "front left-of-center"
> },
> +[AV_CHAN_FRONT_RIGHT_OF_CENTER] = { "FRC", "front right-of-center"
> },
> +[AV_CHAN_BACK_CENTER ] = { "BC","back center"
> },
> +[AV_CHAN_SIDE_LEFT] = { "SL","side left"
> },
> +[AV_CHAN_SIDE_RIGHT ] = { "SR","side right"
> },
> +[AV_CHAN_TOP_CENTER ] = { "TC","top center"
> },
> +[AV_CHAN_TOP_FRONT_LEFT ] = { "TFL", "top front left"
> },
> +[AV_CHAN_TOP_FRONT_CENTER ] = { "TFC", "top front center"
> },
> +[AV_CHAN_TOP_FRONT_RIGHT ] = { "TFR", "top front right"
> },
> +[AV_CHAN_TOP_BACK_LEFT] = { "TBL", "top back left"
> },
> +[AV_CHAN_TOP_BACK_CENTER ] = { "TBC", "top back center"
> },
> +[AV_CHAN_TOP_BACK_RIGHT ] = { "TBR", "top back right"
> },
> +[AV_CHAN_STEREO_LEFT ] = { "DL","downmix left"
> },
> +[AV_CHAN_STEREO_RIGHT ] = { "DR","downmix right"
> },
> +[AV_CHAN_WIDE_LEFT] = { "WL","wide left"
> },
> +[AV_CHAN_WIDE_RIGHT ] = { "WR","wide right"
> },
> +[AV_
