Message ID | ZhwnSn-WU4dPWAEU@metallschleimette |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel] libavdevice: Improve example in deprecation message for opengl and sdl | expand |
Context | Check | Description |
---|---|---|
yinshiyou/make_loongarch64 | success | Make finished |
yinshiyou/make_fate_loongarch64 | success | Make fate finished |
andriy/make_x86 | success | Make finished |
andriy/make_fate_x86 | success | Make fate finished |
Alexander Strasser via ffmpeg-devel (12024-04-14): > When piping ffmpeg into ffplay both programs write a status line in > the terminal. That causes flickering and invisibility of one or the > other status line. The suggestion of piping to ffplay to replace opengl is inadequate: the muxing, pipe, demuxing steps introduce a significant latency, and ffplay tries to maintain the timing, so the latency is never reduced. Compare: ffplay -f x11grab -framerate 5 -video_size 284x92 -i :0+1138+0 ffmpeg -f x11grab -framerate 5 -video_size 284x92 -i :0+1138+0 \ -f nut -c:v rawvideo - | ffplay -loglevel warning - ffmpeg -f x11grab -framerate 5 -video_size 284x92 -i :0+1138+0 \ -pix_fmt yuv420p -f xv :0 (since at least xv was not broken) (replace 284x92 and +1138+0 with an area of your screen where something is happening) The first two ones will have a delay of about five seconds, the last one is almost instantaneous. Either we find options to make ffplay display frames as fast as possible, or we must document to the user that no adequate replacement exists. Or we make a point of fixing the devices that were broken. Regards,
Nicolas George (12024-04-14): > Either we find options to make ffplay display frames as fast as > possible, or we must document to the user that no adequate replacement > exists. Please add “-vf setpts=0”. It still has a little more latency than a built-in device, but at least the feature is not *completely* broken. > Or we make a point of fixing the devices that were broken. We still should. Regards,
On 2024-04-14 21:24 +0200, Nicolas George wrote: > Nicolas George (12024-04-14): > > Either we find options to make ffplay display frames as fast as > > possible, or we must document to the user that no adequate replacement > > exists. > > Please add “-vf setpts=0”. It still has a little more latency than a > built-in device, but at least the feature is not *completely* broken. Thank for your feedback. I sent a v2 with `-vf setpts=0`. > > Or we make a point of fixing the devices that were broken. > > We still should. As long as we are not able to get it fixed, an improved suggestion in the deprecation message seems better than what we have now. Alexander
diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index 6f7a30ff9e..c50d02870a 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h) av_log(opengl, AV_LOG_WARNING, "The opengl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" - "Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" + "Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); opengl->warned = 1; } diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c index 779c8e08b0..59e3182df8 100644 --- a/libavdevice/sdl2.c +++ b/libavdevice/sdl2.c @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) av_log(sdl, AV_LOG_WARNING, "The sdl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" - "Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" + "Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); sdl->warned = 1; }