On 19 March 2018 at 02:59, Josh de Kock <j...@itanimul.li> wrote:
> Hi, > > The new iteration API to replace the old _next() is nearing the end of > it's completion with the lavfi patch on the mailing list and only one > outstanding issue: > > AVOptions would not be found for devices as there is no AVClass for lavd. > At the moment it would work if you were to still call > avdevice_register_all() because then devices get registered as formats in > the old API (which the child_class_next function still uses). When the > format_child_class_next() function switches to the iterate() API > it would no longer have access to devices and thus there would be no way > for av_opt_find() to find an option for devices. The fix for this is > simple, add an AVClass for lavd--fairly clean and unobjectionable. > > > This leaves the new iteration API in an odd limbo of both being now > consistent with the newer BSF API, and using static lav* components, but > also lying to the user that lavf and lavd are separate libraries. We have a > few options in regards to this: > > 1) Agree that both lavf and lavd are fine in their current state > > This requires no further discussion, and is the easiest to implement but > leaves ffmpeg with a questionable ecosystem of dependent libraries. It also > would require another iteration API change if lavf and lavd were to be > separated in the future (luckily only return types due to the usage of an > opaque state i.e. `const AVInputFormat *av_indev_iterate(void **opaque)` -> > `const AVInputDevice *av_indev_iterate(void **opaque)`) > > 2) Disagree that both lavf and lavd are fine in their current state and > move towards defining lavd as its own separate library immediately at the > same time as the new iteration APIs. > > This is possibly the hardest and most annoying option, as it would require > designing a new API for essentially a new library, and converting the > current library's components (also doing it immediately). This could range > from being simple-ish to being quite tough depending on how much the new > library API just copies the lavf API directly (though a disadvantage of > this is that it wouldn't be able to take good use of designing the API > around how devices should be, it has to design around how they currently > are). > > 3) Disagree that both lavf and lavd are fine in their current state and > merge lavd into lavd to allow redesigning of lavd to happen slowly at its > own pace. > > This may require a fair amount of work, but not too much upfront. It takes > the fact that lavf and lavd aren't really separate libraries to 'delete' > lavd to give space for a new library to be designed from scratch. > > I think this is the best option, though for now option 1 is fine as well. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
