Josh de Kock (2018-03-22): > There is always the option to just merge lavf and lavd. The state of them > being sort-of merged, but not really, isn't very good and adds a lot of > complexity especially in inter-library dependencies (which are unneeded if > lavf and lavd are either merged or actually separate).
You are driving your reasoning the wrong way: you start from the limitations of your new API, and based on what it can do you intent huge changes to the project that affect user interface. It should be the opposite: first decide on the user interface and general design, and then make sure the API allow it. For user interface, I state: 1. FFmpeg should allow users to select devices the same way as (de)muxers, because it allows them to use devices in a basic way even when applications are not explicitly prepared for them, that makes extra features for free. Hence, I deduce: 2. All lavf APIs should treat devices the same way as (de)muxers. And I still think that the better option is to revert the new API and design a new new one, learning from the small mistakes of this one. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
