On Mon, 08 Jul 2024 09:25:08 -0400 "Ronald S. Bultje"
wrote:
> Hi,
>
> On Mon, Jul 8, 2024 at 8:34 AM Andrew Sayers
> wrote:
>
> > We often say e.g. "this struct currently has such-and-such members, but the
> > size is not part of the public API". So it's not much of a stretch to say
> > "this
Hi,
On Mon, Jul 8, 2024 at 8:34 AM Andrew Sayers
wrote:
> We often say e.g. "this struct currently has such-and-such members, but the
> size is not part of the public API". So it's not much of a stretch to say
> "this preset enables such-and-such features, but the value is not part of
> the
> p
On Mon, Jul 08, 2024 at 07:58:44AM -0400, Ronald S. Bultje wrote:
> On Sat, Jul 6, 2024 at 1:29 PM Hendrik Leppkes wrote:
> > On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
[...]
> > > > The entire point of presets is to have them provide a predefined set
> > > > of parameters, easy for users
Hi,
On Sat, Jul 6, 2024 at 1:29 PM Hendrik Leppkes wrote:
> On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
> wrote:
> >
> > On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > > wrote:
> > > > > /**
> > > > > * The
On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
wrote:
>
> On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > wrote:
> > > > /**
> > > > * The exact interpretation of these quality presets depends on the
> > > > backen
On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> wrote:
> > > /**
> > > * The exact interpretation of these quality presets depends on the
> > > backend
> > > * used, but the backend-invariant common settings are derived as
On Sat, 06 Jul 2024 02:11:30 +0200 Hendrik Leppkes wrote:
> On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> wrote:
> > > /**
> > > * The exact interpretation of these quality presets depends on the
> > > backend
> > > * used, but the backend-invariant common settings are derived as follo
On Fri, 05 Jul 2024 23:34:06 +0200 Michael Niedermayer
wrote:
> On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote:
> > On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote:
> > > On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
> > >
> > > > 1. Is this a good idea, or too confu
On Fri, Jul 05, 2024 at 11:34:06PM +0200, Michael Niedermayer wrote:
> On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote:
[...]
>
> > Attached is my revised working draft of .
>
> I dont agree to the renaming of swscale, that is heading toward
Would you mind talking a bit more about th
On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
wrote:
> > /**
> > * The exact interpretation of these quality presets depends on the backend
> > * used, but the backend-invariant common settings are derived as follows:
> > */
> > enum AVScaleQuality {
> > AV_SCALE_ULTRAFAST = 1, /* no
On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote:
> On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote:
> > On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
> >
> > > 1. Is this a good idea, or too confusing / complex to be worth the gain?
> > >Specifically, I am worried a
On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote:
> On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
>
> > 1. Is this a good idea, or too confusing / complex to be worth the gain?
> >Specifically, I am worried about confusion arising due to differences
> >in behavior, and imple
On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
> 1. Is this a good idea, or too confusing / complex to be worth the gain?
>Specifically, I am worried about confusion arising due to differences
>in behavior, and implemented options, between all of the above.
>
>That said, I th
On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> Finally, avscale_* should ultimately also support hardware frames
> directly, in which case it will dispatch to some equivalent of
> scale_vulkan/vaapi/cuda or possibly even libplacebo. (But I will defer
> this to a future milestone)
How do
On date Monday 2024-06-24 16:44:33 +0200, Vittorio Giovara wrote:
> On Sun, Jun 23, 2024 at 7:57 PM James Almer wrote:
>
> > On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > > Needless to say I support the plan of renaming the library so that it can
> > > be inline with the other libraries names
On Sat, Jun 29, 2024 at 1:47 PM Niklas Haas wrote:
>
> Open questions:
>
> 1. Is this a good idea, or do the downsides outweigh the benefits?
> 2. Is an "advanced configuration" API still needed, in addition to the
>quality presets?
>
Having a sort of preset is a good idea, esp to simplify t
On Sat, 29 Jun 2024 14:35:32 +0200 Michael Niedermayer
wrote:
> On Sat, Jun 29, 2024 at 01:47:43PM +0200, Niklas Haas wrote:
> > On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> > > Hey,
> > >
> > > As some of you know, I got contracted (by STF 2024) to work on improving
> > > swscale, o
On Sat, Jun 29, 2024 at 01:47:43PM +0200, Niklas Haas wrote:
> On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months. I want to share my
> > current
On Sat, 22 Jun 2024 15:13:34 +0200 Niklas Haas wrote:
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
> ## Problem statement
On Sat, 29 Jun 2024 15:41:58 +0800 Zhao Zhili wrote:
>
>
> > On Jun 22, 2024, at 21:13, Niklas Haas wrote:
> >
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months. I want to share my
> > current pl
> On Jun 22, 2024, at 21:13, Niklas Haas wrote:
>
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
> ## Problem statement
>
On Mon, 24 Jun 2024 16:44:33 +0200 Vittorio Giovara
wrote:
> On Sun, Jun 23, 2024 at 7:57 PM James Almer wrote:
>
> > On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > > Needless to say I support the plan of renaming the library so that it can
> > > be inline with the other libraries names, and
On Sun, Jun 23, 2024 at 7:57 PM James Almer wrote:
> On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > Needless to say I support the plan of renaming the library so that it can
> > be inline with the other libraries names, and the use of a separate
> header
> > since downstream applications will
On Sun, 23 Jun 2024 14:57:31 -0300 James Almer wrote:
> On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > Needless to say I support the plan of renaming the library so that it can
> > be inline with the other libraries names, and the use of a separate header
> > since downstream applications will
On Sun, Jun 23, 2024 at 7:46 PM Michael Niedermayer
wrote:
> On Sun, Jun 23, 2024 at 12:19:13AM +0200, Vittorio Giovara wrote:
> > On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
> >
> > > Hey,
> > >
> > > As some of you know, I got contracted (by STF 2024) to work on
> improving
> > > swscal
On Sun, Jun 23, 2024 at 02:57:31PM -0300, James Almer wrote:
> On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > Needless to say I support the plan of renaming the library so that it can
> > be inline with the other libraries names, and the use of a separate header
> > since downstream applications
On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
Needless to say I support the plan of renaming the library so that it can
be inline with the other libraries names, and the use of a separate header
since downstream applications will need to update a lot to use the new
library (or the new apis in the
On Sun, Jun 23, 2024 at 12:19:13AM +0200, Vittorio Giovara wrote:
> On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
>
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months. I want to share my
> > curr
On Sun, Jun 23, 2024 at 12:24:57AM +0200, Niklas Haas wrote:
> On Sat, 22 Jun 2024 21:52:42 +0200 Michael Niedermayer
> wrote:
> > On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote:
> > > On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
> > > wrote:
> > > > On Sat, Jun 22, 2024 at 03:
On Sun, 23 Jun 2024 00:19:13 +0200 Vittorio Giovara
wrote:
> On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
>
> > Hey,
> >
> > As some of you know, I got contracted (by STF 2024) to work on improving
> > swscale, over the course of the next couple of months. I want to share my
> > current p
On Sat, 22 Jun 2024 21:52:42 +0200 Michael Niedermayer
wrote:
> On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote:
> > On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
> > wrote:
> > > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote:
> > > [...]
> > > >
> > > > ## Comment
On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas wrote:
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
> ## Problem statement
>
>
On Sat, Jun 22, 2024 at 05:10:28PM +0200, Niklas Haas wrote:
> On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
> wrote:
> > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote:
> > [...]
> > >
> > > ## Comments / feedback?
> > >
> > > Does the above approach seem reasonable? How do peo
On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers
wrote:
> On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote:
> [...]
> >
> > ## Comments / feedback?
> >
> > Does the above approach seem reasonable? How do people feel about
> > introducing
> > a new API vs. trying to hammer the existi
On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote:
[...]
>
> ## Comments / feedback?
>
> Does the above approach seem reasonable? How do people feel about introducing
> a new API vs. trying to hammer the existing API into the shape I want it to
> be?
>
> I've attached an example of wh
Hey,
As some of you know, I got contracted (by STF 2024) to work on improving
swscale, over the course of the next couple of months. I want to share my
current plans and gather feedback + measure sentiment.
## Problem statement
The two issues I'd like to focus on for now are:
1. Lack of support
36 matches
Mail list logo
