You may want to wait for at least some review and then of course, Andreas,
for example, sometimes sends 200 patch series.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201203003628.778278-6-andreas.rheinha...@gmail.com/
___
ffmpeg-devel mailing list
Hi All,
If instead of the various separate patch series i have sent the last
few days, you would like to see one integrated series where all are
applied on top of each other and conflicts resolves, please see all
the commits ahead of master (currently 22) on the develop branch here:
https://github
Hi Nicolas,
On Fri, Jun 4, 2021 at 11:06 AM Nicolas George wrote:
> I do not understand: you did send them as a large patch series. Twice,
> by the way, which is confusing.
Yes, the first series got messed up, send it a second time correctly.
I've cleaned up patchwork, it only shows the right on
Diederick C. Niehorster (12021-06-04):
> Just sent the patch, it completes my push together with my other
> patches of the last few days to make the dshow device fully
> programmatically controllable and discoverable.
>
> By the way, each of these patch series applies to master, but not on
> top o
Hi Nicolas,
On Wed, Jun 2, 2021 at 2:37 PM Nicolas George wrote:
> Excellent. Applications that use the advanced features of libavdevice
> and serve as test beds for these features are sorely needed.
>
> The project has no real system to make engagements about something like
> this, but I can say
On Wed, Jun 2, 2021 at 2:37 PM Nicolas George wrote:
>
> dcni...@gmail.com (12021-06-02):
> > I (new contributor) have been making a push to get avdevice/dshow to where
> > it is great to use programmatically (see recent patches, more coming). One
> > thing on my list is to be able to through the
dcni...@gmail.com (12021-06-02):
> I (new contributor) have been making a push to get avdevice/dshow to where
> it is great to use programmatically (see recent patches, more coming). One
> thing on my list is to be able to through the API query the capabilities of
> my device, as right now I'd have
rdt)
Sent: 24 January 2021 21:16
Subject: [FFmpeg-devel] [PATCH] avdevice/avdevice: Deprecate AVDevice
Capabilities API
It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API com
Andreas Rheinhardt:
> Anton Khirnov:
>> Quoting Andreas Rheinhardt (2021-02-09 09:04:23)
>>> Can I get an update on how to proceed with this patch?
>>
>> It doesn't seem that anyone actually objected to this patch, so go ahead
>> and push IMO.
>>
>>>
>>> - Andreas
>>>
>>> PS: I could already remove
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-02-09 09:04:23)
>> Can I get an update on how to proceed with this patch?
>
> It doesn't seem that anyone actually objected to this patch, so go ahead
> and push IMO.
>
>>
>> - Andreas
>>
>> PS: I could already remove all the av_device_capabilitie
Quoting Andreas Rheinhardt (2021-02-09 09:04:23)
> Can I get an update on how to proceed with this patch?
It doesn't seem that anyone actually objected to this patch, so go ahead
and push IMO.
>
> - Andreas
>
> PS: I could already remove all the av_device_capabilities options
> (except the sent
Andreas Rheinhardt:
> It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
> yet since then none of the necessary create/free_device_capabilities
> functions has been implemented, making this API completely useless.
>
> Because of this one can already simplify
> avdevice_capabilities_fre
Mark Thompson (12021-01-27):
> See for example the list of suggestions I made for improving the API a few
> days ago.
I intended to reply to them, but the conversation never came back to it
before now.
> * Handle frames as well as packets.
Already possible.
> * Including hardware frames - DR
On 27/01/2021 14:36, Nicolas George wrote:
Mark Thompson (12021-01-26):
Even after such a merge, the libavdevice API is still a problem.
I will re-center the discussion on this alone.
And I ask, simply: what problem exactly?
See for example the list of suggestions I made for improving the A
Jean-Baptiste Kempf (12021-01-26):
> Unfortunately, that's not how it works.
> We need to accept the will of majority of developers, even if you (or
> someone else) is not convinced.
We will accept the will of the majority of developers when the time for
making a decision comes if no consensus has
Mark Thompson (12021-01-26):
> Even after such a merge, the libavdevice API is still a problem.
I will re-center the discussion on this alone.
And I ask, simply: what problem exactly?
You, who AFAIK, do not maintain anything in libavdevice and have never
used it in a project, say there is a prob
On 25/01/2021 23:20, Nicolas George wrote:
Mark Thompson (12021-01-25):
Merging the libraries (in source form, orthogonal to merging the
binaries) only makes sense if we are going to continue using the
libavformat internals, and that is exactly the thing we are trying to
get rid of.
"We"?
It
On Tue, 26 Jan 2021, at 11:28, Nicolas George wrote:
> I will accept other people's opinion when it is founded on knowledge.
Unfortunately, that's not how it works.
We need to accept the will of majority of developers, even if you (or someone
else) is not convinced.
--
Jean-Baptiste Kempf - Pr
James Almer (12021-01-25):
> If by agenda you mean trying to solve the hacky state of the library, then
> sure. Otherwise, please get rid of any potential slanderous thoughts you may
> be have about it, because it sounds like you may be having trouble
> distinguishing expressed personal opinions wi
On 1/25/2021 8:20 PM, Nicolas George wrote:
Mark Thompson (12021-01-25):
Merging the libraries (in source form, orthogonal to merging the
binaries) only makes sense if we are going to continue using the
libavformat internals, and that is exactly the thing we are trying to
get rid of.
"We"?
It
Mark Thompson (12021-01-25):
> Merging the libraries (in source form, orthogonal to merging the
> binaries) only makes sense if we are going to continue using the
> libavformat internals, and that is exactly the thing we are trying to
> get rid of.
"We"?
It seems to me that many people here have
On 25/01/2021 17:11, James Almer wrote:
Mark then suggested to directly replace/extend the API with one that's more
useful in the long run, instead of removing them as Anton suggested since you
and some other devs stated they in fact do have users, and you agreed to that.
So how about we try t
James Almer (12021-01-25):
> And that's why we're trying to merge them. So again, a subdirectory is not
> obligatory for this purpose, and alternative suggestions are welcome.
> Even just saying to keep them in the root folder would be more useful than
That is what leaving it alone implies.
> say
On 1/25/2021 1:46 PM, Nicolas George wrote:
James Almer (12021-01-25):
Solving the hacky state of lavd <-> lavf *is* useful.
The only "hacky state" comes from the useless split of the libraries.
And that's why we're trying to merge them. So again, a subdirectory is
not obligatory for this p
James Almer (12021-01-25):
> Solving the hacky state of lavd <-> lavf *is* useful.
The only "hacky state" comes from the useless split of the libraries.
> And it would help the
> project a lot if you could be a tiny bit less aggressive and dis
On 1/25/2021 1:38 PM, Nicolas George wrote:
James Almer (12021-01-25):
Suggestions for alternatives are obviously welcome, if you dislike Anton's
current approach
Simple: if you do not have plans to make it better, leave it alone and
work on something useful.
Solving the hacky state of lavd
James Almer (12021-01-25):
> Suggestions for alternatives are obviously welcome, if you dislike Anton's
> current approach
Simple: if you do not have plans to make it better, leave it alone and
work on something useful.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
On 1/25/2021 1:18 PM, Nicolas George wrote:
Anton Khirnov (12021-01-25):
My plan is currently to move the sources into a subdirectory of
libavformat/.
If that is all, then no. Please spend your time in more useful manners.
As somebody who maintains parts of libavdevice, I do not want tracking
Anton Khirnov (12021-01-25):
> My plan is currently to move the sources into a subdirectory of
> libavformat/.
If that is all, then no. Please spend your time in more useful manners.
As somebody who maintains parts of libavdevice, I do not want tracking
history made more difficult and brittle, I d
Quoting Andreas Rheinhardt (2021-01-24 21:42:10)
> James Almer:
> > On 1/24/2021 5:16 PM, Andreas Rheinhardt wrote:
> >> It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
> >> yet since then none of the necessary create/free_device_capabilities
> >> functions has been implemented, maki
Andreas Rheinhardt (12021-01-24):
> I know that Anton is currently working on merging them, but I thought
> that this would only involve compiling lavd into libavformat.so; not
> that the API would be changed or the libavdevice/ source folder merged
> into libavformat.
Considering Anton's open dis
James Almer:
> On 1/24/2021 5:16 PM, Andreas Rheinhardt wrote:
>> It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
>> yet since then none of the necessary create/free_device_capabilities
>> functions has been implemented, making this API completely useless.
>>
>> Because of this one c
On 1/24/2021 5:16 PM, Andreas Rheinhardt wrote:
It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevic
It has been added in 6db42a2b6b22e6f1928fafcf3faa67ed78201004,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove
34 matches
Mail list logo
