[FFmpeg-devel] [DISCUSSION] New iteration APIs, lavf and lavd

[Rostislav Pehlivanov]

On 19 March 2018 at 02:59, Josh de Kock <josh at 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.