On Wed, Feb 7, 2024 at 6:40 PM Vittorio Giovara
wrote:
> On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
>
> > Anton Khirnov (12024-02-07):
> > > ...so they are precisely broken by design.
> >
> > Words words words.
> >
> > Words to try and hide that something used to work for people and no
On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
> Anton Khirnov (12024-02-07):
> > ...so they are precisely broken by design.
>
> Words words words.
>
> Words to try and hide that something used to work for people and now you
> are done with it it no longer works.
>
> Exactly the kind of att
Anton Khirnov (12024-02-07):
> ...so they are precisely broken by design.
Words words words.
Words to try and hide that something used to work for people and now you
are done with it it no longer works.
Exactly the kind of attitude that killed libav, killing FFmpeg now.
--
Nicolas George
___
Quoting Stefano Sabatini (2024-02-05 01:02:20)
> This implies a misunderstanding of what these components are. If
> they are broken with ffmpeg.c this is not a good reason to remove
> them (ffmpeg.c is not the only user).
They are broken with _any_ caller that happens to call libavformat from
a th
Anton Khirnov (12024-02-07):
> For instance? What do these devices support that e.g. NUT does not?
Returning the latency of the device.
> neither should we try.
This is the libav mindset we do not want in FFmpeg.
--
Nicolas George
___
ffmpeg-devel
It works until move or resize the window.
yes, that's right. I didn't notice because I didn't try to move or resize the
window.
My point is: Removing SDL would break many examples that can be found in the
internet.
Michael
___
ffmpeg-devel mailin
Quoting Marton Balint (2024-02-04 11:11:12)
> > The 'pipe:' output can be used with a real video player such as mpv, vlc, or
> > even ffplay. For cases where the user was an application using the API they
> > should supply their own renderer.
>
> Yeah, but I never liked when people piped uncompres
> On Feb 7, 2024, at 04:51, Michael Koch wrote:
>
> I didn't notice any problems with -f sdl2. I just tested again with Windows
> 11 and the latest FFmpeg build from Gyan, just 2 days old.
>
> ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 -
>
> Works without any problems.
It works
I didn't notice any problems with -f sdl2. I just tested again with
Windows 11 and the latest FFmpeg build from Gyan, just 2 days old.
ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 -
Works without any problems.
Michael
___
ffmpeg-devel mai
On Tue, Feb 6, 2024 at 9:08 AM Michael Koch
wrote:
> Removing SDL2 sounds like a very bad idea. There are many examples which
> are using these output devices, and all these examples would be broken.
> A quick search in my book
> http://www.astro-electronic.de/FFmpeg_Book.pdf
> finds about 40 occ
Zhao Zhili (12024-02-06):
> Those examples are broken already before the patch.
Funny that the people who actually use the feature had not noticed.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/lis
> On Feb 6, 2024, at 16:08, Michael Koch wrote:
>
> Removing SDL2 sounds like a very bad idea. There are many examples which are
> using these output devices, and all these examples would be broken. A quick
> search in my book
> http://www.astro-electronic.de/FFmpeg_Book.pdf
> finds about 40
Removing SDL2 sounds like a very bad idea. There are many examples which
are using these output devices, and all these examples would be broken.
A quick search in my book
http://www.astro-electronic.de/FFmpeg_Book.pdf
finds about 40 occurences for "-f sdl" or "-f sdl2".
Michael
__
On date Sunday 2024-02-04 10:02:31 +0100, J. Dekker wrote:
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed
On Sun, 4 Feb 2024, Rémi Denis-Courmont wrote:
Le 4 février 2024 11:11:12 GMT+01:00, Marton Balint a écrit :
Actually they work here on a linux box with OpenSuse 15.5. So even if they
are broken on some setups, they are not broken everywhere, or not more broken
than they used to be.
No.
On Sun, Feb 04, 2024 at 10:02:31AM +0100, J. Dekker wrote:
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed
Le 4 février 2024 10:02:31 GMT+01:00, "J. Dekker" a écrit :
>With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
>'main' thread. This means that both the SDL2 and OpenGL output device are
>broken
>in master. Rather than attempting to fix it, they should be removed in
Le 4 février 2024 11:11:12 GMT+01:00, Marton Balint a écrit :
>Actually they work here on a linux box with OpenSuse 15.5. So even if they
>are broken on some setups, they are not broken everywhere, or not more broken
>than they used to be.
No. They were always broken in terms of the design, an
On Sun, 4 Feb 2024, J. Dekker wrote:
With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
'main' thread. This means that both the SDL2 and OpenGL output device are broken
in master. Rather than attempting to fix it, they should be removed instead as
there are better
FFmpeg project leader never left, it is still Michael.
But now there are his minions like Anton and others.
FFmpeg is already dead project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
Quoting Zhao Zhili (2024-02-04 10:19:11)
> > On Feb 4, 2024, at 17:02, J. Dekker wrote:
> >
> > With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> > the
> > 'main' thread. This means that both the SDL2 and OpenGL output device are
> > broken
> > in master. Rather than
Quoting J. Dekker (2024-02-04 10:02:31)
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed instead as
> there
> On Feb 4, 2024, at 17:02, J. Dekker wrote:
>
> With the addition of threading in ffmpeg.c, the SDL2 devices no longer have
> the
> 'main' thread. This means that both the SDL2 and OpenGL output device are
> broken
> in master. Rather than attempting to fix it, they should be removed instea
With the addition of threading in ffmpeg.c, the SDL2 devices no longer have the
'main' thread. This means that both the SDL2 and OpenGL output device are broken
in master. Rather than attempting to fix it, they should be removed instead as
there are better alternatives for debugging or viewing stre
24 matches
Mail list logo