Opened 10 years ago

Last modified 10 years ago

#3989 open enhancement

"Overwrite?" dialog causes frozen video when capturing desktop video

Reported by: Jack O'Connor Owned by:
Priority: wish Component: ffmpeg
Version: git-master Keywords: x11grab
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

1) Record some video of the desktop with a command like ffmpeg -f x11grab -i $DISPLAY test.mkv.

2) Without deleting the video from (1), run that command again. This time it pauses with the question "File 'test.mkv' already exists. Overwrite ? [y/N]". Wait a few seconds before saying yes.

3) Play the resulting video in VLC.

BUG: The video begins with several seconds of stillness, corresponding to the amount of time you waited at the prompt in (2).

Repros on the release version (1:2.4.1-1, Arch Linux) and also when I build locally from master.

Attachments (1)

delayed_desktop_recording.mkv (145.1 KB ) - added by Jack O'Connor 10 years ago.

Download all attachments as: .zip

Change History (5)

by Jack O'Connor, 10 years ago

comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: x11grab added
Version: unspecifiedgit-master

Is there really an issue or is this the expected behaviour?

Please provide command line and complete, uncut console output for current git head to make this a valid ticket.

comment:2 by Jack O'Connor, 10 years ago

I can't speak to the expectations of an expert, but as an ordinary user, the experience feels broken. Let's say I fire up glxgears, start an ffmpeg recording of my desktop, wait at the prompt for 2 seconds, and then record for 2 seconds. (Like in my example video attached.) I would expect one of two behaviors:

1) I get 4 seconds of video of glxgears moving, because ffmpeg started recording immediately.
2) I get 2 seconds of video of glxgears moving, because ffmpeg only started recording after I agreed to overwrite the existing file.

But what actually happens is:

3) I get 4 seconds of video, but for the first 2 seconds the picture is frozen.

I can't use that video. I must've done something wrong. I spend a lot of time fiddling with all the flags I'm using. The problem seems to come and go when I change container types (but actually, it goes away whenever I used a new filename).

The workaround of course is to delete the preexisting video file before re-recording it, so that I don't get prompted. What sucks is that it's not at all obvious *why* it's happening, at least to a beginner like me.

Console output from my git master build:

# The first run, no prompt:
$ /var/tmp/ffmpeg/ffmpeg -f x11grab -i $DISPLAY test.mkv
ffmpeg version N-66543-g1441641 Copyright (c) 2000-2014 the FFmpeg developers
  built on Sep 29 2014 13:46:22 with gcc 4.9.1 (GCC) 20140903 (prerelease)
  configuration: --enable-x11grab --enable-gpl
  libavutil      54.  7.101 / 54.  7.101
  libavcodec     56.  1.101 / 56.  1.101
  libavformat    56.  7.101 / 56.  7.101
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  1.102 /  5.  1.102
  libswscale      3.  1.100 /  3.  1.100
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  1.100 / 53.  1.100
[x11grab @ 0x2f90c20] device: :0 -> display: :0 x: 0 y: 0 width: 640 height: 480
[x11grab @ 0x2f90c20] shared memory extension found
Input #0, x11grab, from ':0':
  Duration: N/A, start: 1412025598.375747, bitrate: 294617 kb/s
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 640x480, 294617 kb/s, 29.97 tbr, 1000k tbn, 29.97 tbc
Output #0, matroska, to 'test.mkv':
  Metadata:
    encoder         : Lavf56.7.101
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 640x480, q=2-31, 200 kb/s, 29.97 fps, 1k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc56.1.101 mpeg4
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame=   70 fps= 30 q=2.0 Lsize=     263kB time=00:00:02.33 bitrate= 923.6kbits/s
video:262kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.498994%
Received signal 2: terminating.

# The second run, with the overwrite prompt:
$ /var/tmp/ffmpeg/ffmpeg -f x11grab -i $DISPLAY test.mkv
ffmpeg version N-66543-g1441641 Copyright (c) 2000-2014 the FFmpeg developers
  built on Sep 29 2014 13:46:22 with gcc 4.9.1 (GCC) 20140903 (prerelease)
  configuration: --enable-x11grab --enable-gpl
  libavutil      54.  7.101 / 54.  7.101
  libavcodec     56.  1.101 / 56.  1.101
  libavformat    56.  7.101 / 56.  7.101
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  1.102 /  5.  1.102
  libswscale      3.  1.100 /  3.  1.100
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  1.100 / 53.  1.100
[x11grab @ 0x36c9c20] device: :0 -> display: :0 x: 0 y: 0 width: 640 height: 480
[x11grab @ 0x36c9c20] shared memory extension found
Input #0, x11grab, from ':0':
  Duration: N/A, start: 1412025603.853949, bitrate: 294617 kb/s
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 640x480, 294617 kb/s, 29.97 tbr, 1000k tbn, 29.97 tbc
File 'test.mkv' already exists. Overwrite ? [y/N] y
Output #0, matroska, to 'test.mkv':
  Metadata:
    encoder         : Lavf56.7.101
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 640x480, q=2-31, 200 kb/s, 29.97 fps, 1k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc56.1.101 mpeg4
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame=   19 fps=0.0 q=2.0 size=     103kB time=00:00:02.66 bitrate= 315.4kbits/s dupframe=   34 fps= 34 q=2.0 size=     167kB time=00:00:03.16 bitrate= 432.3kbits/s dupframe=   49 fps= 32 q=1.6 size=     265kB time=00:00:03.67 bitrate= 592.5kbits/s dupframe=   65 fps= 32 q=2.0 size=     320kB time=00:00:04.20 bitrate= 623.1kbits/s dupframe=   67 fps= 31 q=2.4 Lsize=     326kB time=00:00:04.27 bitrate= 625.2kbits/s dup=0 drop=28
video:325kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.396367%
Received signal 2: terminating.

in reply to:  1 comment:3 by Michael Niedermayer, 10 years ago

Replying to cehoyos:

Is there really an issue or is this the expected behaviour?

Id say its a issue but its maybe some work to fix it ...
one possible fix would be to check the output file first before opening the input(s)
iam not sure this should be marked as defect or enhancement though

comment:4 by Carl Eugen Hoyos, 10 years ago

Component: undeterminedffmpeg
Priority: normalwish
Status: newopen
Type: defectenhancement
Note: See TracTickets for help on using tickets.