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

[Nicolas George]

Josh de Kock (2018-03-22):
> 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.

I am sorry, but I have trouble understanding what you are trying to say.
Maybe rephrase it with shorter sentences?

There is no separate type for devices, they are coded as AVInputFormat
and AVOutputFormat. That is fine, because they are designed to behave
like (de)muxers and can be used anywhere a (de)muxer can be used.

The result is a huge benefit for users. Just look at ffmpeg: it was
designed for (de)muxers, but thanks to that it can do real-time capture
and quick on-the-fly preview. The features are not as complete as with a
real device API, but most of the time the basic features provided by
lavf are largely enough to suit the needs.

You want proof? Just look at the users mailing-list where questions are
asked about dshow, X11 capture, Decklink cards, etc.

If you were to change the lavd API to make it different from (de)muxers,
all applications that right now can use devices automatically would lose
that ability, to the detriment of users.

Also, a general note about user interface design: specific choices
should override general choices.

In more specific words: applications can only assume what their users
want or need, in general way. On the other hand, an user knows what he
or she needs right now, in this specific case. That means that if the
user wants to use a device, then the user should be, as much as
possible, be allowed to use a device, and the application has no
business trying to prevent that. The current API makes it more
convenient to applications to not mess that up.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180322/95581bc1/attachment.sig>