Recherche avancée

Sur d’autres sites (796)

• FFMPEG is not recording the whole window

  25 mai 2021, par John

  I'm using FFMPEG to record a window as illustrated in the figure below. In all cases, the right hand side of the recorded window is cropped. The command I'm giving is

  



  ffmpeg -f gdigrab -i title="example.txt - Notepad++" output.mkv


  



  Any suggestion on how to fix this problem is much appreciated.

  



  

  



  Here are some additional info :

  



  

  • Running Windows 10

  


  • Using ffmpeg-20181215-011c911-win64-static, but I have the same issue using other versions of FFMPEG

  


  • Desktop resolution is 3200x1800 (dpi scaling issue ?)

  


  



  This is what the recorded area looks like in the example above

  



  

  



  Update 1 :

  



  Recording the whole desktop works fine, however, when recording a region using x and y offsets, the region captured is correct, but the region indicated is wrong. I illustrate this in the image below that shows a screen capture of the desktop during recording. The background image is a grid and the taskbar has been hidden.

  



  

  



  The size of the area to capture is specified to 1280x720, but the region indicated is 1600x900. Also, the x offset is specified to 400px, but the region indicted starts at 500px.

  



  The area recorded is correct ! The image below shows a screenshot of the recording during playback in vlc, note that the "misplaced" region indicator can be seen

  



  

  



  Update 2 :

  



  I noticed that the cursor, the mouse, is not correctly placed when capturing from the desktop, see recording below. Everything looks fine during recording, but at playback the cursor is misplaced.

  



  

  



  The command issued for the recording above was :

  



  ffmpeg -f gdigrab -framerate 30 -offset_x 1820 -offset_y 100 -video_size 1280x720 -i desktop output5.mkv


  



  Windows 10 / ffmpeg-20181215-011c911-win64-static

  


• Pointers returned by xlib don't match any existing window IDs

  1er septembre 2022, par Kroltan

  I'm using some X11 bindings to query some window information and later pass it to FFmpeg. FFmpeg expects a "window ID" given in hexadecimal notation.

  


  This notation seems somewhat standard, as it is returned by programs like xwininfo or wmctrl. I haven't found much information about it, but it seems to just be the hexadecimal representation of the window pointer ? If I take the ID string given by these programs and give it to FFmpeg, it is able to capture the window correctly :

  


  $ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x2800014 "Desktop — Plasma"

$ ffmpeg -f x11grab -window_id 0x2800014 -i :0+0,0 -f apng -vframes 1 out.png
# works fine


  


  However, if I try listing all the windows in code :

  


  var root = Window.None;
var parent = Window.None;
Xlib.XQueryTree(_display, Xlib.XDefaultRootWindow(_display), ref root, ref parent, out var children);

var ids = children
    .Select(ptr => $"0x{(ulong) ptr:x}")
    .ToArray();


  


  I don't see 0x2800014 in the results (even disregardingleading zeroes), and if I try running FFmpeg on one of those results, it fails terribly :

  


  $ ffmpeg -f x11grab -window_id 0x4400003 -i :0+0,0 -f apng -vframes 1

# snipped for brevity

Trailing option(s) found in the command: may be ignored.
[x11grab @ 0x55b811a8da40] Cannot get the image data event_error: response_type:0 error_code:8 sequence:10 resource_id:167772160 minor_code:4 major_code:130.
[x11grab @ 0x55b811a8da40] Continuing without shared memory.
[x11grab @ 0x55b811a8da40] Cannot get the image data event_error: response_type:0 error_code:8 sequence:11 resource_id:71303171 minor_code:0 major_code:73.
Input #0, x11grab, from ':0+0,0':
  Duration: N/A, bitrate: 38361 kb/s
  Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 200x200, 38361 kb/s, 29.97 fps, 1000k tbr, 1000k tbn
At least one output file must be specified


  


  So I must conclude my guess that they are hex pointers is incorrect, or that the Window type is not the pointer itself, but then the question stands, how can I get the actual window IDs so I can pass them to FFmpeg ?

  


• Seek function of HTML5 video and Maximum Keyframe Interval in video encoding compression

  20 décembre 2019, par Sanxofon

  This is a very specific question about how the seek function (of an HTML5 video element) interprets a video, in this case one in WEBM format and what specific relationship it has with the Maximum Keyframe Interval in the process of coding of said video.

  I’ve made this fiddle to show what I mean :

  https://jsfiddle.net/sanxofon/hctuxo3e/

  What it does : The idea is to control the position of a paused video with the scroll wheel of the mouse ... in addition, each frame of the video is copied to a canvas element, but I think that has no relation. I mention it just in case.

  What to watch : In Chrome (v66) and slightly less in Firefox (v59) the scrolling looks pretty good when the video is encoded with a Maximum Keyframe Interval of 6 or less, but jumps are appreciated when the interval is every 24 frames or more. This is noticeable in the video and even more on the canvas.

  FFMPEG : When encoding a video with FFMPEG this is achieved with the option -g6 or -g24 of Maximum Keyframe Interval. However, the file becomes heavier as we decrease the interval. It can be seen that there is no difference between both formats when the video is in play.

  You can switch the video in the snippet with the buttons.

  • Case 1 : When we use the video encoded with -g 6 the video scrolling is acceptable but the size increases : 6.229 Mb.

  FFMPEG string used :

   ffmpeg -i INPUT.MOV -c: v libvpx -qmin 0 -deadline best -qmax 50 -crf 1 -b: v 100K -g 6 test / video_g6.webm

  • Case 2 : When we use the video encoded with -g 24 the displacement is not smooth and suffers from jumps but the size decreases : 4,477 Mb.

  FFMPEG string used :

   ffmpeg -i INPUT.MOV -c: v libvpx -qmin 0 -deadline best -qmax 50 -crf 1 -b: v 100K -g 24 test / video_g24.webm

  Why does this happen ?

  What about -keyint_min or -force_key_frames ? Do they have any positive effect ? Is it better to use something like cgop (closed gop) ?

  I would appreciate some reference of consultation on this subject or a more or less detailed explanation of this relationship for both the WEBM container and for MP4 and OGG video.

  I am not looking so much for a magical ffmpeg chain (although I would appreciate it) but rather an explanation of how this relationship between the keyframes and the seek of a javascript video works.

  Thank you very much for reading here.

  P.S. One more thing, if the seek function only stops in a keyframe, is it possible that this frame has more quality than the others so that the quality increases when the video stops ?