[FFmpeg-devel] Deprecation of visual output devices

James Almer jamrial at gmail.com
Wed Sep 27 18:12:33 EEST 2017

On 9/27/2017 12:01 PM, wm4 wrote:
> On Wed, 27 Sep 2017 16:34:49 +0200
> Michael Niedermayer <michael at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list