Recherche avancée

Sur d’autres sites (793)

• 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 ?

• Play a video with ffmpeg and SDL2 on a Raspberry Pi 5

  18 février 2024, par aforino

  I want to create a python script that decodes a h264 1080p video and outputs it via SDL2 on a Raspberry Pi 5. The Raspberry Pi 5 is able to play a h264 1080p video without problem using VLC. Total CPU load with VLC is about 10%. However decoding with ffmpeg and outputting via SDL2 uses around 70% CPU load. Since I want to be able to switch seamlessly between two output videos I will need to decode two videos at the same time. Therefore 70% CPU load for one transcoded 1080p video is not acceptable. How can I make the code more efficient and why is VLC so much more efficient ?

  


  This is my current python script :

  


  import numpy as np
import ffmpeg  # ffmpeg-python
import sdl2.ext

in_file = ffmpeg.input('bbb1080_x264.mp4', re=None)

width = 1920
height = 1080

process1 = (
    in_file
    .output('pipe:', format='rawvideo', pix_fmt='bgra')
    .run_async(pipe_stdout=True)
)

sdl2.ext.init()
window = sdl2.ext.Window("Hello World!", size=(width, height))
window.show()
windowsurface = sdl2.SDL_GetWindowSurface(window.window)
windowArray = sdl2.ext.pixels3d(windowsurface.contents)

sdl2.ext.mouse.hide_cursor()

while True:
    in_bytes = process1.stdout.read(width * height * 4)

    if not in_bytes:
        break

    in_frame = (
        np
        .frombuffer(in_bytes, np.uint8)
        .reshape([height, width, 4])
        .transpose(1, 0, 2)
    )

    for event in sdl2.ext.get_events():
        if event.type == sdl2.SDL_QUIT:
            exit()

    windowArray[:] = in_frame
    window.refresh()

process1.wait()


  


  Also it is interesting to note that when I start VLC on a Raspberry Pi 5 this is the output on the terminal

  


  [00007fff78c1a550] avcodec decoder error: cannot start codec (h264_v4l2m2m)
Fontconfig warning: ignoring UTF-8: not a valid region tag
[00007fff68002d70] gles2 generic error: parent window not available
[00007fff68002d70] xcb generic error: window not available
[00007fff680013f0] mmal_xsplitter vout display: Try drm
[00007fff68002d70] drm_vout generic: <<< OpenDrmVout: Fmt=I420
[00007fff68002d70] drm_vout generic error: Failed to get xlease`


  


  It indicates that VLC is not using the h264_v4l2m2m hardware acceleration.