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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
