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

[Michael Niedermayer]

On Thu, Mar 22, 2018 at 01:07:18PM +0100, Nicolas George wrote:
> 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.

not taking a position on any of the suggestions in this thread (as i dont 
have the time ATM to properly think about them ...) but
if lavd had a incompatible API then it would likely be possible to add a
demuxer and muxer to lavf that gives access to all these devices.
So they would then still be accessable through the (de)muxer interface.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180322/5cb30af9/attachment.sig>