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