Recherche avancée

Sur d’autres sites (10776)

• OpenCV - motion detection in large video files

  18 décembre 2023, par M9A

  I have large video files (over a few GB each) that I am trying detect motion on. I am using fairly basic OpenCV code in python with ROI to detect motion in a certain area of the video only. This works absolutely fine but takes absolutely ages to process large files. Is there any way to speed things up ? I am simply just checking to see which file has motion detected in it and will not be outputting a video. The moment the first motion is detected the rest of the file is not checked.

  


  import sys
import cv2

video_path = “video.mp4”

capture = cv2.VideoCapture(video_path)

# Set the first frame as the reference background
_, background = capture.read()

# Define the region of interest (ROI)
x, y, w, h = 1468, 1142, 412, 385
roi = (x, y, x + w, y + h)

while capture.isOpened():
    ret, frame = capture.read()

    if not ret:
        break

    # Extract the region of interest from the current frame
    frame_roi = frame[y:y + h, x:x + w]

    # Calculate the absolute difference between the ROI and the background
    diff = cv2.absdiff(background[y:y + h, x:x + w], frame_roi)
    gray = cv2.cvtColor(diff, cv2.COLOR_BGR2GRAY)
    _, thresh = cv2.threshold(gray, 30, 255, cv2.THRESH_BINARY)

    # Check if motion is detected in the ROI (adjust threshold as needed)
    if cv2.countNonZero(thresh) > 75:
        print("YES")
        break

# Release the video capture object
capture.release()


  


• Camera Rendering Buffers and Stutters When Processing Large Video Files with FFmpeg

  20 avril 2023, par TIANYU HU

  When rendering a real-time camera, I use ffmpeg to process a large video file(like 4G or even larger) at the same time. However, I noticed that the video frames are buffering and stuttering, indicated they are probably competing for limited system resources, like cpu, memory or I/O bandwidth etc.

  


  I‘ve tried a lot of experiments to figure out the root cause. Firstly I limit the cpu usage of ffmpeg to 25%, but sadly it’s not getting better.

  


  Then I suspect that ffmpeg would read the large video file from disk to page cache in memory as much as it can before processing, and the generated files are going to be written back from page cache to disk. The RAM of our computer is 8G, apparently it needs to swap in and swap out pages between memory and disk. This process is costly for the CPU, and other processes are likely to trigger an interrupt named “Page Fault” when they access pages that are not actually loaded into memory. If the time taken for “page fault” is too long, the program may lag.

  


  Lastly I configure the system parameters related to “write back dirty pages to disk”, such as vm.dirty_writeback_centisecs and vm.dirty_background_ratio, to try to write back the dirty (Disk I/O) more frequently or infrequently. But I’m not quite sure what would happen if I modify these parameters.

  


  Expection :
The requirement can be summarized as “real-time video rendering has higher priority, and the low rate of large file processing is accepted”, are there any possible solutions of this issue from your perspective ? Thanks in advance.

  


• FFMPEG Failure - Extracting frames on large file

  25 avril 2018, par Marian Montagnino

  Calling the ffmpeg command :

  ffmpeg -y -ss "00:00:02" -i 5ccaea226acfc1b4b75ccd1a9f09512c.mxf -frames 30 -f image2 -vf "fps=1/1.25,scale='min(420,iw)':-1" video%04d.jpg

  Causes a failure :

  ffmpeg failed: ffmpeg version N-85692-g78a5fc4 Copyright (c) 2000-2017 the FFmpeg developers
  
  built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)
  
  configuration: --prefix=/tmp/gm-ffmpeg-1.0.4/BUILD/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/tmp/gm-ffmpeg-1.0.4/BUILD/ffmpeg_build/include --extra-ldflags=-L/tmp/gm-ffmpeg-1.0.4/BUILD/ffmpeg_build/lib --bindir=/tmp/gm-ffmpeg-1.0.4/BUILDROOT/gm-ffmpeg-1.0.4-1.el7.centos.x86_64/opt/graymeta/bin --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree
  
  libavutil 55. 61.100 / 55. 61.100
  
  libavcodec 57. 93.100 / 57. 93.100
  
  libavformat 57. 72.101 / 57. 72.101
  
  libavdevice 57. 7.100 / 57. 7.100
  
  libavfilter 6. 87.100 / 6. 87.100
  
  libswscale 4. 7.101 / 4. 7.101
  
  libswresample 2. 8.100 / 2. 8.100
  
  libpostproc 54. 6.100 / 54. 6.100
  
  [mxf @ 0x2c6da60] broken or empty index
  
  Input #0, mxf, from '/alloc/5ccaea226acfc1b4b75ccd1a9f09512c.mxf':
  
  Metadata:
  
  uid : 27b07007-2dc8-4305-a78a-81a612d78b94
  
  generation_uid : ef5ae870-4075-4513-ea1f-39c0ed197267
  
  company_name : Colorfront
  
  product_name : Transkoder
  
  product_uid : 3a4fe380-0d01-11e4-869f-3cd92b5c1dfc
  
  product_version : 2.7.3.20150121
  
  application_platform: Microsoft Windows 7 Professional Service Pack 1 (Build 7601)
  
  modification_date: 2016-09-09T11:29:39.000000Z
  
  material_package_umid: 0x060A2B340101010501010F20130000008991E1DCEA584837149E72E7F9F0E09D
  
  timecode : 00:00:17;12
  
  Duration: 00:11:58.92, start: 0.000000, bitrate: 150802 kb/s
  
  Stream #0:0: Video: jpeg2000, yuv422p10le(progressive), 3840x2160, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 59.94 tbn, 59.94 tbc
  
  Metadata:
  
  file_package_umid: 0x060A2B340101010501010F2013000000F8B3B48BE8044408DDD6303A6D43F566
  
  track_name : Picture
  
  Stream mapping:
  
  Stream #0:0 -> #0:0 (jpeg2000 (native) -> mjpeg (native))
  
  Press [q] to stop, [?] for help
  
  : signal: killed

  I’m not sure how to interpret this error message and why it actually failed. This file is about 90GB large and shot in 4K resolution but 11 seconds long.