On Tue, Dec 19, 2023 at 08:48:39PM +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 19. joulukuuta 2023, 18.58.40 EET Michael Niedermayer a écrit :
> > so the idea is that we cannot access any GUI in any code from anything in
> > libavformat and probably all other libs, ever
>
> No. The idea is
Rémi Denis-Courmont (12023-12-19):
> No. The idea is that a command line program cannot use the GUI, and a library
> can only use the GUI if the main program is a GUI program.
This is braindead design at a level way beyond anything we might have in
FFmpeg.
> Lastly, it has been made clear by
Le tiistaina 19. joulukuuta 2023, 18.58.40 EET Michael Niedermayer a écrit :
> so the idea is that we cannot access any GUI in any code from anything in
> libavformat and probably all other libs, ever
No. The idea is that a command line program cannot use the GUI, and a library
can only use the
On Tue, Dec 19, 2023 at 09:23:29AM +0200, Rémi Denis-Courmont wrote:
>
>
> Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer
> a écrit :
> >On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
> >> Quoting Stefano Sabatini (2023-12-16 16:18:07)
> >> > On date Thursday
Le 19 décembre 2023 14:51:21 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-19):
>> Anton's objections are against the horrible hacks necessary to support
>> Mac and Windows, as far as I understand him.
>
>I have not read that. If that is true, maybe he could start with
Rémi Denis-Courmont (12023-12-19):
> Anton's objections are against the horrible hacks necessary to support
> Mac and Windows, as far as I understand him.
I have not read that. If that is true, maybe he could start with
refraining from using expressions like “horrible hacks”.
> Of course it's
Le 19 décembre 2023 11:29:04 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-19):
>> As others noted earlier, that won't work for Mac and Windows.
>
>If it works on Linux and other real Unixes, it is a lot better than if
>it does not work on any platform. And we should still
Rémi Denis-Courmont (12023-12-19):
> As others noted earlier, that won't work for Mac and Windows.
If it works on Linux and other real Unixes, it is a lot better than if
it does not work on any platform. And we should still blame whoever
broke it rather than whoever is trying to fix it.
>
Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer
a écrit :
>On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
>> Quoting Stefano Sabatini (2023-12-16 16:18:07)
>> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
>> > > Anton Khirnov (12023-12-14):
>>
Michael Niedermayer (12023-12-18):
> I think the first question is, does this actually need
> "massive hacks in ffmpeg CLI" ?
Thank you for bringing some sanity.
> If you ignore the recommandition that SDL should be run from the main
> thread then iam not sure what change would be needed in
On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
> Quoting Stefano Sabatini (2023-12-16 16:18:07)
> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > > Anton Khirnov (12023-12-14):
> > [...]
> > > > I have to strongly disagree. This is neither practically
Quoting Stefano Sabatini (2023-12-16 16:18:07)
> On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > Anton Khirnov (12023-12-14):
> [...]
> > > I have to strongly disagree. This is neither practically workable,
> > > nor a good goal to aim at.
> >
> > And I strongly agree with
On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> Anton Khirnov (12023-12-14):
[...]
> > I have to strongly disagree. This is neither practically workable,
> > nor a good goal to aim at.
>
> And I strongly agree with Stefano. Having the tools just thin wrappers
> around the
On 2023-12-14 01:47 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> [...]
> > Honestly I don't see how this could be done in ffmpeg CLI without
> > disgusting hacks, but before that the question is:
>
Anton Khirnov (12023-12-14):
> As mentioned elsewhere in the thread, you can just as well pipe raw
> video in yuv4mpeg or nut to the video player of your choice and thus
As was already mentioned elsewhere in the thread, this solution has a
lot more drawbacks.
> avoid all these hacks.
Please
Quoting Stefano Sabatini (2023-12-14 01:47:44)
> On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> [...]
> > Honestly I don't see how this could be done in ffmpeg CLI without
> > disgusting hacks, but before that the question is:
>
>
On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote:
> Quoting Zhao Zhili (2023-12-12 18:27:39)
[...]
> Honestly I don't see how this could be done in ffmpeg CLI without
> disgusting hacks, but before that the question is:
> why is there an SDL
> "muxer" and why would anyone want to
Quoting Zhao Zhili (2023-12-13 11:37:52)
>
>
> > On Dec 13, 2023, at 18:06, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2023-12-13 10:31:38)
> >>
> >>> On Dec 13, 2023, at 17:08, Anton Khirnov wrote:
> >>>
> >>> Quoting Zhao Zhili (2023-12-12 18:27:39)
> Now it's time to talk
Zhao Zhili (12023-12-13):
> The latency issue may be real or not
The latency is obviously real and obviously unavoidable, since there is
a muxer, a protocol, an OS buffer, a protocol and a demuxer in the chain
that are not necessary with a device. We can try to make it as small as
possible, but
> On Dec 13, 2023, at 18:06, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2023-12-13 10:31:38)
>>
>>> On Dec 13, 2023, at 17:08, Anton Khirnov wrote:
>>>
>>> Quoting Zhao Zhili (2023-12-12 18:27:39)
Now it's time to talk about the libavdevice/sdl issue.
SDL output is broken
Quoting Zhao Zhili (2023-12-13 10:31:38)
>
> > On Dec 13, 2023, at 17:08, Anton Khirnov wrote:
> >
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> >> Now it's time to talk about the libavdevice/sdl issue.
> >>
> >> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer'
> >>
Anton Khirnov (12023-12-13):
> Honestly I don't see how this could be done in ffmpeg CLI without
> disgusting hacks,
As I said: do not expect it to be fixed.
Or we could revert the whole half-baked series.
> but before that the question is: why is there an SDL
> "muxer" and
> On Dec 13, 2023, at 17:08, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2023-12-12 18:27:39)
>> Now it's time to talk about the libavdevice/sdl issue.
>>
>> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer'
>> write_header
>> and write_packet must be run in the same
Quoting Zhao Zhili (2023-12-12 18:27:39)
> Now it's time to talk about the libavdevice/sdl issue.
>
> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer'
> write_header
> and write_packet must be run in the same thread. And to make it work portable
> and reliable, SDL 'muxer' must
> 在 2023年12月13日，上午2:04，Nicolas George 写道：
>
> Zhao Zhili (12023-12-13):
>> Now it's time to talk about the libavdevice/sdl issue.
>>
>> SDL output is broken with ffmpeg multithread refactor.
>
> And OpenGL, since it depends on SDL for its stand-alone setup.
>
> But do not expect it to be
Zhao Zhili (12023-12-13):
> Now it's time to talk about the libavdevice/sdl issue.
>
> SDL output is broken with ffmpeg multithread refactor.
And OpenGL, since it depends on SDL for its stand-alone setup.
But do not expect it to be fixed, they have hated lavd for ever and now
they have all the
Now it's time to talk about the libavdevice/sdl issue.
SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' write_header
and write_packet must be run in the same thread. And to make it work portable
and reliable, SDL 'muxer' must be run in main thread. It's a common requirement
for
27 matches
Mail list logo
