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

[Josh de Kock]

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.

4) Scrap the entire API

This is super easy, just figure out which commits are related to the new 
API using `git log`, then revert. We can then have a whole new 
discussion on how we'd rather do things entirely instead, though this 
sounds like a lot of work that people would agree to and then it'd just 
not get done.

There may be other options I haven't described, I'd love to hear them. 
As for the ones I did, 2 will impede the new ffmpeg release the most 
(something I think no one wants), and 4 just moves backwards. I think 1 
or 3 are preferred, and I lean towards 3 (and obviously this is just my 
opinion, you are entitled to your own).

What are your thoughts on how to proceed with the new iteration APIs, 
and lavf & lavd being separated?

--
Josh