[FFmpeg-devel] [PATCH v4 3/7] cmdutils: use new iteration APIs

Josh de Kock josh at itanimul.li
Thu Mar 22 13:48:14 EET 2018

On 2018/03/22 11:37, wm4 wrote:
> On Thu, 22 Mar 2018 12:32:29 +0100
> Nicolas George <george at nsup.org> wrote:
>> 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.
> Devices are not muxers/demuxers and can behave significantly
> differently. Thus they should be accessible via a different API, and in
> particular avoid accidental use of device (de)muxers if only normal
> (de)muxers are wanted by the application.
Merging lavd into lavf may be the best option here, as it allows us to 
change the return type of av_iterate_indev() etc to an AVDevice or 
another type which may represent an actual device as opposed to a purely 
input/output device (which is just implemented as an actual lavf 
format). I don't know; say this is merged and then we add an AVDevice, 
then we already have device iteration functions which return AVFormat so 
we would need different function names to accommodate the lavd change 
requiring yet another API change--so I am not entirely sure that the 
current patches (implementing option 1) are the best way to go about it.


More information about the ffmpeg-devel mailing list