On 2018/03/22 11:37, wm4 wrote:
On Thu, 22 Mar 2018 12:32:29 +0100
Nicolas George <geo...@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.
--
Josh
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
