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

[Nicolas George]

Josh de Kock (2018-03-19):
> 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)`)

I do not understand what "in their current state" means? Before the
patches? After the patches? After half the patches but before the other
half?

I do not understand what "separate libraries" means either. lavf and
lavd are, right now, separate libraries, but what does it have to do
with anything.

Your summary of the API changes is not detailed enough for somebody who
was not involved in the previous discussions. Please be more detailed
and start from scratch.

> 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).

Looks like an enormous waste of time for a terrible outcome. Scrap that
idea.

Having devices presented as demuxsrs or muxers has the benefit that
applications do not need to be designed to use them, they just can
transparently. That means if you have an application that can mux
things, you can have it output a quick preview by just giving an
adequate device name. It only uses basic functionality, but it serves a
lot. Furthermore, applications that want to use devices do not need to
implement a different code path, just a few exceptions specific to the
devices.

If your proposal breaks that, if your proposal requires changes to
applications in order to allow them to uses devices in place of
(de)muxers, then it is not acceptable.

> 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.

lavd was separated from lavf exactly to avoid that. On the other hand,
the people who wanted it have mostly gone and forked themselves, so we
can safely ignore them.

> 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).

Option 5: revert the new API as is for now, design it better, not
rushing things and learning from the mistakes made on this one.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180319/894f43d8/attachment.sig>