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, what is the point of this new API if anything of value needs to be
done with side data and yet another API?
It seems to me you are indulging in a sunken-costs fallacy: you wrote
this API and all the code but you neglected to poll your fellow
developers for needs that it should cover, and as a result got something
much too limited. But now, you are trying to force it anyway.
What I propose is:
(1) define the needs properly;
(2) redesign the API;
(3) see how much code can still be used.
The needs as far as I can see, please add to the list:
A. Allow the same channel to appear several time in the layout. Hendrik
agreed that it was useful for some kind of USER_SPECIFIED or UNKNOWN
channel specification, but allowing for any channel specification is
actually simpler.
It is not limited to just having the same channel in the list, it
requires API and user interface support: the API must be able to tell
the user "this USER_SPECIFIED channel is the oboe, this USER_SPECIFIED
is the piano", and the user must be able to tell the API "the second
USER_SPECIFIED channel" or "the USER_SPECIFIED channel relating to the
piano".
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 times in a layout.
Oboe can be 65, piano can be 66.
Also, each channel is meant to map to a speaker in a different physical
location. If your idea is to have oboe and piano play through the same
speaker, then you're thinking filtering, and that sounds beyond the
scope of a channel layout API.
The user interface part to query and tell non standard AVChannel values
apart in a human readable way is a different thing. That would probably
require giving each channel a user defined name in some form.
B. Possibly, I do not personally insist on it like A: groups of
channels.
_______________________________________________
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".
_______________________________________________
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".
