Michael Niedermayer via ffmpeg-devel (HE12025-10-29): > 1. merge libavdevice and libavformat
Of course we should do that. The split into multiple libraries serves no purpose, it only makes our work more complicated; the benefits people think they get from it either are nonexistent or could be obtained more efficiently with less intrusive solutions. IIRC, in the case of libavdevice, it was done under the pressure of people who hated it and wanted to get rid of it, just like they managed to put pressure on you to get rid of libpostproc. > 2. make libavdevice actually great again, aka a seperate API designed for > devices That would not make libavdevice great, that would kill it. The fact that devices can pass as muxers / demuxers is the key to the usefulness of libavdevice: people write code for plain files, and thanks to the magic of having the same API, this code can be used as is with ALSA playback or desktop capture. If libavdevice gets its own API, then the only code that works with it is code that was specifically written for it, and who would write code specifically for a mishmash of devices whose sole common point is that they used to have the same API. > (3. maybe a bunch of flags checks version whatever can be used to make it > work as is) We could also consider making libavdevice API evolve towards the one of libavfilter. That would require the driving code to work with non-buffersink sinks, though, and we are not there yet. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
