| Message ID | 1378deab-71dd-0f0a-a398-a74e509bcd54@itanimul.li |
|---|---|
| State | New |
| Headers | show |
On 9/27/17, Josh de Kock <josh@itanimul.li> wrote: > Hi, > > There is no point of having these output devices as all the > functionality is contained in the 'ffplay' tool. If people wanted to > integrate these devices in their own programs instead of using the > ffmpeg tool then they are far too constrained for proper control, not to > mention output devices have been quick hacky in libavdevice for a long > time. There are three patches attached to deprecate the SDL2, OpenGL, > and libcaca devices. > > -- > Josh > NAK
On Wed, 27 Sep 2017 14:18:13 +0100 Josh de Kock <josh@itanimul.li> wrote: > Hi, > > There is no point of having these output devices as all the > functionality is contained in the 'ffplay' tool. If people wanted to > integrate these devices in their own programs instead of using the > ffmpeg tool then they are far too constrained for proper control, not to > mention output devices have been quick hacky in libavdevice for a long > time. There are three patches attached to deprecate the SDL2, OpenGL, > and libcaca devices. > +1
Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit : > There is no point of having these output devices as all the > functionality is contained in the 'ffplay' tool. ffplay is not a library. > If people wanted to > integrate these devices in their own programs instead of using the > ffmpeg tool then they are far too constrained for proper control Maybe for your needs. Do not generalize. Regards,
On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote: > Hi, > > There is no point of having these output devices as all the > functionality is contained in the 'ffplay' tool. If people wanted to > integrate these devices in their own programs instead of using the > ffmpeg tool then they are far too constrained for proper control, not to > mention output devices have been quick hacky in libavdevice for a long then please write a better API / lib / system > time. There are three patches attached to deprecate the SDL2, OpenGL, > and libcaca devices. Once a better system exists with these features this can be deprecated. requiring each user application to directly support each API of each of these systems is very inconvenient for all but the large applications Indeed the large applications benefit from the absence of a single API as they eliminate competition from smaller apps which are unable to maintain support for a wide range of output devices. I think a good API that supports a wide range of in/out devices would be very usefull for smaller/simpler applications using the libs [...]
On Wed, 27 Sep 2017 16:34:49 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote: > > Hi, > > > > There is no point of having these output devices as all the > > functionality is contained in the 'ffplay' tool. If people wanted to > > integrate these devices in their own programs instead of using the > > ffmpeg tool then they are far too constrained for proper control, not to > > > mention output devices have been quick hacky in libavdevice for a long > > then please write a better API / lib / system It should never have been added this way. Why did it happen? On that note, I tried to prevent it, and to argue that the contributor should have created a better API instead of badly hacking it into libavdevice. Why do you suddenly think there is a strong argument for keeping it? > > time. There are three patches attached to deprecate the SDL2, OpenGL, > > and libcaca devices. > > Once a better system exists with these features this can be deprecated. > requiring each user application to directly support each API of each > of these systems is very inconvenient for all but the large applications There are entire frameworks for abstracting these things. libavdevice is one of them, but only as a joke. > Indeed the large applications benefit from the absence of a single API > as they eliminate competition from smaller apps which are unable to > maintain support for a wide range of output devices. > > I think a good API that supports a wide range of in/out devices would > be very usefull for smaller/simpler applications using the libs Name a user of these APIs. Your argumentation is full of fallacies. We don't actually do any of those things for applications. As far as I'm aware, only the person who added this API is even using it. Are you even aware that ffplay doesn't use this API? I'm sick of this attitude to keep bad/broken stuff just so that we "have it". Supporting a feature is meaningless if it's low quality. Maybe one day you will learn this. I can't way for the day libavdevice or libavfilter will grow a UI toolkit.
2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: > There is no point of having these output devices as all the > functionality is contained in the 'ffplay' tool. I use at least sdl and opengl regularly for tests that cannot be done with ffplay. Carl Eugen
On 9/27/2017 12:01 PM, wm4 wrote: > On Wed, 27 Sep 2017 16:34:49 +0200 > Michael Niedermayer <michael@niedermayer.cc> wrote: > >> On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote: >>> Hi, >>> >>> There is no point of having these output devices as all the >>> functionality is contained in the 'ffplay' tool. If people wanted to >>> integrate these devices in their own programs instead of using the >>> ffmpeg tool then they are far too constrained for proper control, not to >> >>> mention output devices have been quick hacky in libavdevice for a long >> >> then please write a better API / lib / system > > It should never have been added this way. Why did it happen? On that > note, I tried to prevent it, and to argue that the contributor should > have created a better API instead of badly hacking it into libavdevice. > > Why do you suddenly think there is a strong argument for keeping it? > >>> time. There are three patches attached to deprecate the SDL2, OpenGL, >>> and libcaca devices. >> >> Once a better system exists with these features this can be deprecated. > >> requiring each user application to directly support each API of each >> of these systems is very inconvenient for all but the large applications > > There are entire frameworks for abstracting these things. libavdevice > is one of them, but only as a joke. > >> Indeed the large applications benefit from the absence of a single API >> as they eliminate competition from smaller apps which are unable to >> maintain support for a wide range of output devices. >> >> I think a good API that supports a wide range of in/out devices would >> be very usefull for smaller/simpler applications using the libs > > Name a user of these APIs. > > Your argumentation is full of fallacies. We don't actually do any of > those things for applications. As far as I'm aware, only the person who > added this API is even using it. Are you even aware that ffplay doesn't > use this API? > > I'm sick of this attitude to keep bad/broken stuff just so that we > "have it". Supporting a feature is meaningless if it's low quality. > Maybe one day you will learn this. We can't just remove something that works and has a defined use, as much as it's disliked, without at least come up with a replacement or a good reason why it's being dropped without a replacement. And by good reason i mean something like "This is in the way of this other useful thing that we're trying to add/achieve". If that happens, i assume not a lot of people will speak in favor of lavd. > > I can't way for the day libavdevice or libavfilter will grow a UI > toolkit. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Wed, 27 Sep 2017 17:08:06 +0200 Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: > > > There is no point of having these output devices as all the > > functionality is contained in the 'ffplay' tool. > > I use at least sdl and opengl regularly for tests that cannot > be done with ffplay. How does it make sense to use those for testing, when the rendering isn't particularly correct in the first place? Seems like a rather bad idea.
2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > On Wed, 27 Sep 2017 17:08:06 +0200 > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: >> >> > There is no point of having these output devices as all the >> > functionality is contained in the 'ffplay' tool. >> >> I use at least sdl and opengl regularly for tests that cannot >> be done with ffplay. > > How does it make sense to use those for testing FFplay only supports a limited set of pix_fmts, contrary to those devices. > when the rendering isn't particularly correct in the first place? I had not known this / this has not hit me so far. How can I reproduce? Carl Eugen
On 27/09/2017 16:17, Carl Eugen Hoyos wrote: > 2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >> On Wed, 27 Sep 2017 17:08:06 +0200 >> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >>> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: >>> >>>> There is no point of having these output devices as all the >>>> functionality is contained in the 'ffplay' tool. >>> >>> I use at least sdl and opengl regularly for tests that cannot >>> be done with ffplay. >> >> How does it make sense to use those for testing > > FFplay only supports a limited set of pix_fmts, > contrary to those devices. > So if there is pix_fmt parity then I can remove OpenGL, and SDL2? This should be simple enough. >> when the rendering isn't particularly correct in the first place? > > I had not known this / this has not hit me so far. > How can I reproduce? > > Carl Eugen
On Wed, Sep 27, 2017 at 05:01:59PM +0200, wm4 wrote: > On Wed, 27 Sep 2017 16:34:49 +0200 > Michael Niedermayer <michael@niedermayer.cc> wrote: > > > On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote: > > > Hi, > > > > > > There is no point of having these output devices as all the > > > functionality is contained in the 'ffplay' tool. If people wanted to > > > integrate these devices in their own programs instead of using the > > > ffmpeg tool then they are far too constrained for proper control, not to > > > > > mention output devices have been quick hacky in libavdevice for a long > > > > then please write a better API / lib / system > > It should never have been added this way. Why did it happen? On that > note, I tried to prevent it, > and to argue that the contributor should > have created a better API instead of badly hacking it into libavdevice. I did not say anything like that. What i stated should be the obvious if people feel what we have doesnt serve its intended goals then it makes sense to write something that does. [...]
2017-09-27 17:21 GMT+02:00 Josh de Kock <josh@itanimul.li>: > On 27/09/2017 16:17, Carl Eugen Hoyos wrote: >> 2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >>> On Wed, 27 Sep 2017 17:08:06 +0200 >>> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>> >>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: >>>> >>>>> There is no point of having these output devices as all the >>>>> functionality is contained in the 'ffplay' tool. >>>> >>>> I use at least sdl and opengl regularly for tests that cannot >>>> be done with ffplay. >>> >>> How does it make sense to use those for testing >> >> FFplay only supports a limited set of pix_fmts, >> contrary to those devices. > > So if there is pix_fmt parity then I can remove OpenGL, and SDL2? No, but you can mark my argument as obsolete. > This should be simple enough. Sure? I was more under the assumption that this is simply impossible. (Until SDL3) Carl Eugen
On Wed, 27 Sep 2017 17:17:37 +0200 Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > > On Wed, 27 Sep 2017 17:08:06 +0200 > > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > >> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: > >> > >> > There is no point of having these output devices as all the > >> > functionality is contained in the 'ffplay' tool. > >> > >> I use at least sdl and opengl regularly for tests that cannot > >> be done with ffplay. > > > > How does it make sense to use those for testing > > FFplay only supports a limited set of pix_fmts, > contrary to those devices. > > > when the rendering isn't particularly correct in the first place? > > I had not known this / this has not hit me so far. > How can I reproduce? Apparently it doesn't respect colorspace, any other colorimetry settings, chroma location, and I wouldn't trust it to get odd cropping right. It's really basic and naive.
On 27/09/2017 16:28, Carl Eugen Hoyos wrote: > 2017-09-27 17:21 GMT+02:00 Josh de Kock <josh@itanimul.li>: >> On 27/09/2017 16:17, Carl Eugen Hoyos wrote: >>> 2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >>>> On Wed, 27 Sep 2017 17:08:06 +0200 >>>> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >>>> >>>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: >>>>> >>>>>> There is no point of having these output devices as all the >>>>>> functionality is contained in the 'ffplay' tool. >>>>> >>>>> I use at least sdl and opengl regularly for tests that cannot >>>>> be done with ffplay. >>>> >>>> How does it make sense to use those for testing >>> >>> FFplay only supports a limited set of pix_fmts, >>> contrary to those devices. >> >> So if there is pix_fmt parity then I can remove OpenGL, and SDL2? > > No, but you can mark my argument as obsolete. I see no reason to bring parity to ffplay then. >> This should be simple enough. > > Sure? > I was more under the assumption that this is simply impossible. > (Until SDL3) Why would it be impossible? I don't see how the OpenGL, SDL2 device could support more pixel formats than FFplay when they *all* use SDL2.
On Wed, 27 Sep 2017 16:31:37 +0100 Josh de Kock <josh@itanimul.li> wrote: > On 27/09/2017 16:28, Carl Eugen Hoyos wrote: > > 2017-09-27 17:21 GMT+02:00 Josh de Kock <josh@itanimul.li>: > >> On 27/09/2017 16:17, Carl Eugen Hoyos wrote: > >>> 2017-09-27 17:15 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > >>>> On Wed, 27 Sep 2017 17:08:06 +0200 > >>>> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >>>> > >>>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock <josh@itanimul.li>: > >>>>> > >>>>>> There is no point of having these output devices as all the > >>>>>> functionality is contained in the 'ffplay' tool. > >>>>> > >>>>> I use at least sdl and opengl regularly for tests that cannot > >>>>> be done with ffplay. > >>>> > >>>> How does it make sense to use those for testing > >>> > >>> FFplay only supports a limited set of pix_fmts, > >>> contrary to those devices. > >> > >> So if there is pix_fmt parity then I can remove OpenGL, and SDL2? > > > > No, but you can mark my argument as obsolete. > > I see no reason to bring parity to ffplay then. > > >> This should be simple enough. > > > > Sure? > > I was more under the assumption that this is simply impossible. > > (Until SDL3) > > Why would it be impossible? I don't see how the OpenGL, SDL2 device > could support more pixel formats than FFplay when they *all* use SDL2. The OpenGL one uses shaders, but for the others his argument is bogus, yes.
Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit :
> I see no reason to bring parity to ffplay then.
Nobody asked you to do that.
Why do you want to remove these devices in the first place?
Regards,
diff --git a/libavdevice/caca.c b/libavdevice/caca.c index 93cc0ffd25..31cb94eda9 100644 --- a/libavdevice/caca.c +++ b/libavdevice/caca.c @@ -95,6 +95,8 @@ static int caca_write_header(AVFormatContext *s) AVCodecParameters *encctx = st->codecpar; int ret, bpp; + av_log(s, AV_LOG_WARNING, "The libcaca output device is DEPRECATED and will be removed in a future version.\n"); + c->ctx = s; if (c->list_drivers) { list_drivers(c);