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".

B. Possibly, I do not personally insist on it like A: groups of
channels.

-- 
  Nicolas George

Attachment: 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".

Reply via email to