diff mbox

[FFmpeg-devel,v3,3/3] lavd: deprecate opengl outdev

Message ID 1473620098-75606-3-git-send-email-josh@itanimul.li
State Superseded
Headers show

Commit Message

Josh Dekker Sept. 11, 2016, 6:54 p.m. UTC
This device depends on SDL which is deprecated.

Signed-off-by: Josh de Kock <josh@itanimul.li>
---
 Changelog                | 2 +-
 doc/outdevs.texi         | 2 ++
 libavdevice/opengl_enc.c | 2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

Comments

Nicolas George Sept. 14, 2016, 5:53 p.m. UTC | #1
Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit :
> This device depends on SDL which is deprecated.
> 
> Signed-off-by: Josh de Kock <josh@itanimul.li>

Although your port of the code to SDL2 address my concern about deprecating
without a replacement, I would be pained if this code were to be removed.

I still hope that lavd can become powerful and usable enough to serve as a
base for applications, at least simple ones. (Actually, I have a simple
music player running right now that does just that.) If that were to happen,
OpenGL would be the figurehead of the video output part.

If I understand correctly, SDL is only used in this device to set up a
window and a context in a cross-platform way. I even notice that the code
can be used without SDL altogether if the applications handles the context
and window itself.

The warning could be printed only when no_window is false, with the intent
that the code not under "#if HAVE_SDL" is there to stay?

Regards,
Josh Dekker Sept. 14, 2016, 6:53 p.m. UTC | #2
On 14/09/2016 18:53, Nicolas George wrote:
> Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit :
>> This device depends on SDL which is deprecated.
>>
>> Signed-off-by: Josh de Kock <josh@itanimul.li>
>
> Although your port of the code to SDL2 address my concern about deprecating
> without a replacement, I would be pained if this code were to be removed.
What is your attachment to the SDL1 library?

> I still hope that lavd can become powerful and usable enough to serve as a
> base for applications, at least simple ones. (Actually, I have a simple
> music player running right now that does just that.) If that were to happen,
> OpenGL would be the figurehead of the video output part.
Firstly, the OpenGL device doesn't have the best implementation, and 
lavd really doesn't seem like the right place for this. You'd be better 
off writing your own from scratch or using something like libmpv (which 
has a proper renderer).

> If I understand correctly, SDL is only used in this device to set up a
> window and a context in a cross-platform way. I even notice that the code
> can be used without SDL altogether if the applications handles the context
> and window itself.
Sorry, I'm not sure how you think the SDL device can be used without SDL.

--
Josh
Nicolas George Sept. 14, 2016, 7:07 p.m. UTC | #3
Le nonidi 29 fructidor, an CCXXIV, Josh de Kock a écrit :
> What is your attachment to the SDL1 library?

None at all. You did not read me carefully at all. My attachment is to the
OpenGL device.

> Firstly, the OpenGL device doesn't have the best implementation, and lavd

I am rather surprised. IIRC, Reimar was active on the list at the time it
was implemented, I think he would have spotted problems like that. Can you
elaborate?

> really doesn't seem like the right place for this. You'd be better off
> writing your own from scratch or using something like libmpv (which has a
> proper renderer).

That defeats the purpose of libavdevice.

> Sorry, I'm not sure how you think the SDL device can be used without SDL.

I think the OpenGL device can be used without SDL, please read carefully.
OpenGL uses a global state, not a context parameter passed to each function.
That means that part of an application can create and init the OpenGL
context and other parts of the application can draw on it without any
explicit communication between them. That is exactly what is meant for the
device in lavd: the application creates and inits the context, then lavd
generates OpenGL commands which are executed on the context. SDL is only
used in this device as a convenience for simpler applications.

Regards,
Lukasz Marek Sept. 15, 2016, 8:56 p.m. UTC | #4
On 14.09.2016 19:53, Nicolas George wrote:
> Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit :
>> This device depends on SDL which is deprecated.
>>
>> Signed-off-by: Josh de Kock <josh@itanimul.li>
>
> If I understand correctly, SDL is only used in this device to set up a
> window and a context in a cross-platform way. I even notice that the code
> can be used without SDL altogether if the applications handles the context
> and window itself.

You are correct. SDL is used just to created default window with opengl 
context. Probably the only use case of this is to test this device with 
following command: ffmpeg -i video -f opengl aaa. The relevant 
implementation is depending on opengl API only and has nothing to do 
with SDL. Removing it just because of switching to SDL 2.0 is 
misunderstanding. I can port SDL part to use 2.0 API, just figure out 
how this will be handled. I mean if you want to support both or just 2.0.
Josh Dekker Sept. 15, 2016, 9:22 p.m. UTC | #5
On 15/09/2016 21:56, Lukasz Marek wrote:
> On 14.09.2016 19:53, Nicolas George wrote:
>> Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit :
>>> This device depends on SDL which is deprecated.
>>>
>>> Signed-off-by: Josh de Kock <josh@itanimul.li>
>>
>> If I understand correctly, SDL is only used in this device to set up a
>> window and a context in a cross-platform way. I even notice that the code
>> can be used without SDL altogether if the applications handles the
>> context
>> and window itself.
>
> You are correct. SDL is used just to created default window with opengl
> context. Probably the only use case of this is to test this device with
> following command: ffmpeg -i video -f opengl aaa. The relevant
> implementation is depending on opengl API only and has nothing to do
> with SDL. Removing it just because of switching to SDL 2.0 is
> misunderstanding. I can port SDL part to use 2.0 API, just figure out
> how this will be handled. I mean if you want to support both or just 2.0.

Yes, I did misunderstand, sorry. As for supporting SDL2 or both, wait a 
week to see the outcome of the SDL vote.

--
Josh
diff mbox

Patch

diff --git a/Changelog b/Changelog
index f609a86..6c9f766 100644
--- a/Changelog
+++ b/Changelog
@@ -27,7 +27,7 @@  version <next>:
 - weave filter
 - gblur filter
 - avgblur filter
-- deprecated sdl outdev
+- deprecated sdl and opengl outdev
 
 
 version 3.1:
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index cfcc176..34afa6f 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -214,6 +214,8 @@  See also @url{http://linux-fbdev.sourceforge.net/}, and fbset(1).
 @section opengl
 OpenGL output device.
 
+This device is deprecated and will be removed in a future release.
+
 To enable this output device you need to configure FFmpeg with @code{--enable-opengl}.
 
 This output device allows one to render to OpenGL context.
diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index 1dbbb80..d611830 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -1064,6 +1064,8 @@  static av_cold int opengl_write_header(AVFormatContext *h)
     AVStream *st;
     int ret;
 
+    av_log(h, AV_LOG_WARNING, "The opengl output device is deprecated.\n");
+
     if (h->nb_streams != 1 ||
         h->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
         h->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {