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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
