diff mbox

[FFmpeg-devel] Deprecation of visual output devices

Message ID 1378deab-71dd-0f0a-a398-a74e509bcd54@itanimul.li
State New
Headers show

Commit Message

Josh Dekker Sept. 27, 2017, 1:18 p.m. UTC
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.

Comments

Paul B Mahol Sept. 27, 2017, 1:25 p.m. UTC | #1
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
wm4 Sept. 27, 2017, 1:30 p.m. UTC | #2
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
Nicolas George Sept. 27, 2017, 1:38 p.m. UTC | #3
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,
Michael Niedermayer Sept. 27, 2017, 2:34 p.m. UTC | #4
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

[...]
wm4 Sept. 27, 2017, 3:01 p.m. UTC | #5
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.
Carl Eugen Hoyos Sept. 27, 2017, 3:08 p.m. UTC | #6
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
James Almer Sept. 27, 2017, 3:12 p.m. UTC | #7
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
>
wm4 Sept. 27, 2017, 3:15 p.m. UTC | #8
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.
Carl Eugen Hoyos Sept. 27, 2017, 3:17 p.m. UTC | #9
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
Josh Dekker Sept. 27, 2017, 3:21 p.m. UTC | #10
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
Michael Niedermayer Sept. 27, 2017, 3:26 p.m. UTC | #11
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.

[...]
Carl Eugen Hoyos Sept. 27, 2017, 3:28 p.m. UTC | #12
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
wm4 Sept. 27, 2017, 3:28 p.m. UTC | #13
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.
Josh Dekker Sept. 27, 2017, 3:31 p.m. UTC | #14
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.
wm4 Sept. 27, 2017, 3:51 p.m. UTC | #15
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.
Nicolas George Sept. 27, 2017, 5:22 p.m. UTC | #16
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 mbox

Patch

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);