Reorganized a bit for easier replying.
Also, while i think this is an important discussion, i do not see why
it should stop de-deprecation of a good API. Deprecating the device
capabilities API cleaned up avformat a bit, but various other function
pointers are left. A redesign would clean them all
Nicolas, I agree with what you said, and you obviously have given this
more thought than me. Your and Anton's replies provide two by now
pretty clear different views, I hope more will chime in.
I will only highlight some things below.
On Fri, Jun 11, 2021 at 3:17 PM Nicolas George wrote:
> Input
Anton Khirnov (12021-06-11):
> And it would be really really REALLY nice if you finally learned to
> distinguish between your personal opinions, official project policy, and
> objective truth.
Have you missed the part where I ask you to give arguments?
Regards,
--
Nicolas George
signature.a
Quoting Nicolas George (2021-06-11 14:14:57)
> Anton Khirnov (12021-06-09):
> > > > There is no timeline, it depends on someone sitting down and doing the
> > > > work. The options proposed so far were
> > > > 1) merging libavdevice into libavformat
> > > > 2) making libavdevice into an independent
Quoting Diederick C. Niehorster (2021-06-10 15:29:57)
> > The problem is that libavdevice is a separate library from libavformat,
> > but fundamentally depends on accessing libavformat internals.
>
> Ah ok, so this is at first instance about cleanup/separation, not
> necessarily about adding new f
Diederick C. Niehorster (12021-06-10):
> Let me respond on two levels.
>
> Before exploring the design space of a separation of libavdevice and
> libavformat below, I think it is important to first comment on the
> current state (and whether the AVDevice Capabilities part of my patch
> series shou
Anton Khirnov (12021-06-09):
> > > There is no timeline, it depends on someone sitting down and doing the
> > > work. The options proposed so far were
> > > 1) merging libavdevice into libavformat
> > > 2) making libavdevice into an independent library with an independent
> > >API
> > > 3) movi
Let me respond on two levels.
Before exploring the design space of a separation of libavdevice and
libavformat below, I think it is important to first comment on the
current state (and whether the AVDevice Capabilities part of my patch
series should be blocked by this discussion).
Importantly, I
Quoting Diederick C. Niehorster (2021-06-09 21:49:28)
> On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
> >
> > Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > > Sorry to rain on your parade, but I don't think we should go
On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov wrote:
>
> Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > > Sorry to rain on your parade, but I don't think we should go ahead with
> > > this before deciding what is to be done with li
Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> > Sorry to rain on your parade, but I don't think we should go ahead with
> > this before deciding what is to be done with libavdevice. The last
> > discussion about it died without being
Anton Khirnov (12021-06-05):
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
So, now we have somebody who wants to w
On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
I understand. I
Quoting Diederick Niehorster (2021-06-04 00:45:48)
> ** Resending as it seems they didn't all make it..**
>
> Undeprecating the avdevice capabilities API and implementing it for the
> dshow device. Much needed. Together with the other patches i sent, a
> dshow device can now be properly used progr
** Resending as it seems they didn't all make it..**
Undeprecating the avdevice capabilities API and implementing it for the
dshow device. Much needed. Together with the other patches i sent, a
dshow device can now be properly used programmatically by programs using
ffmpeg under the hood.
Diederi
Undeprecating the avdevice capabilities API and implementing it for the
dshow device. Much needed. Together with the other patches i sent, a
dshow device can now be properly used programmatically by programs using
ffmpeg under the hood.
Diederick Niehorster (4):
avdevice/avdevice: Revert "Deprec
16 matches
Mail list logo
