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

2018-03-23 Thread Nicolas George
Nicolas F. (2018-03-23):
> Thankfully, you are always involved in every long and drawn-out
> discussion, which is a very handy coincidence, so if someone has
> questions about the summary of the API changes, I believe it could be
> incredibly helpful if you already just went ahead and filled in
> everyone on those.

> I guess FFmpeg can never ever change the API again then. Pack it up
> folks.

> It has been months. This wasn't rushed. You either disagree with the
> design or with having the patch author contribute to FFmpeg, but
> either way, postponing this further isn't going to solve whatever
> issue you have with it.

The purely sarcastic contents of this message is not conductive of a
productive discussion. Was your intent to make progress or to poison
things further?

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2018-03-23 Thread Nicolas F.
Nicolas George
>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.

Thankfully, you are always involved in every long and drawn-out discussion, 
which is a very handy coincidence, so if someone has questions about the 
summary of the API changes, I believe it could be incredibly helpful if you 
already just went ahead and filled in everyone on those.

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

I guess FFmpeg can never ever change the API again then. Pack it up folks.

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

It has been months. This wasn't rushed. You either disagree with the design or 
with having the patch author contribute to FFmpeg, but either way, postponing 
this further isn't going to solve whatever issue you have with it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2018-03-19 Thread Rostislav Pehlivanov
On 19 March 2018 at 02:59, Josh de Kock  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


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

2018-03-19 Thread 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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

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

2018-03-19 Thread Paul B Mahol
On 3/19/18, wm4  wrote:
> On Mon, 19 Mar 2018 02:59:54 +
> Josh de Kock  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.
>
> I really don't understand the problem, or why this AVClass crap is
> needed. It sounds absurd.

Yes, avdevice (non)API is absurd.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2018-03-19 Thread wm4
On Mon, 19 Mar 2018 02:59:54 +
Josh de Kock  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.

I really don't understand the problem, or why this AVClass crap is
needed. It sounds absurd.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel