On Sun, Oct 11, 2020 at 08:50:50PM +0200, Nicolas George wrote: > Michael Niedermayer (12020-10-11): > > The situation with a single API+ABI shared by 2 libs with their own soname > > is bad. > > lavd either needs an independant API thats designed for devices (which is > > probably more a medium to long term effort) > > This would be a terrible idea. Being functionally a part of lavf, with > the same API is an essential feature of lavd: it is what allows users to > use devices with applications that are designed for files. Otherwise, > lavd would only be usable with applications meant for it, i.e. none.
I dont think that what i suggested leads to what you describe here. For example Lets consider a hypothetical lavd with a API/ABI thats designed more towards devices than (de)muxers. lavf can depend on lavd and provide each device from lavd as a (de)muxer in lavf too. That can even be in a 1 to 1 match or a single lavf (de)muxer with an option to choose which device to map to. These would maintain the device availability for existing applications. While it would avoid requireing access to devices through the (de)muxer interface. Some people and maybe most people dislike that interface for devices. I think you too want lavd to be something an author of a simple media player considers. While ATM i think people consider variuous things but skip lavd as it doesnt feel as an equal to the other choices. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
