Recherche avancée

Sur d’autres sites (7787)

• Getting Error message Unknown encoder 'libx264' , any help appreciated

  16 janvier 2022, par Alex.Foster

  I am trying to compress videos files to a target size within python using ffmpeg-python for an A level project as part of my coursework, I keep getting this error saying it doesn't know the encoder. Not sure what I'm meant to do as this is literally an entirely new space to me. Am I meant to have installed the codec or something, or is there an alternative I can use ?

  


  import os, ffmpeg
##import section:this part is where I import all of the modules I will use
import  tkinter
import shutil
from tkinter import filedialog
import os


def fileSelect():                                                                           #start of fileSelect function
    global startingLocation                                                                 #declares startingLocation as global variable
    global originalName                                                                     #declares originalName as global variable
    global fileType                                                                         #declares fileType as global variable
    startingLocation = filedialog.askopenfilename(initialdir="/", title="Select file",      #tkinter function that opens file explorer, lets user select file saves the file path as a variable
                    filetypes=(("video files", "*.mp4"),("images", "*.jpg*")))
    originalName = os.path.basename(startingLocation)                                       #os function that gets the actaul file name from the path string
    print (originalName)                                                                    #print statement to check if originalName has been found
    fileType = startingLocation.split('.')                                                  #splits original name where any full stop in found and saves array as variable
    fileType = fileType[-1]                                                                 #changes variable to have the str value of the final item in the array; the file type
    fileType = '.' + fileType                                                               #adds fullstop to the start of the file type so i dont have to repeatedly do it
    print (fileType)                                                                        #print statement to check file type is found correctly

def outputSelect():                                                                         #start of outputSelect function
     global outputLocation                                                                  #declares outputLocation as global variable
     outputLocation = filedialog.askdirectory(initialdir="/", title="Select folder")        #tkinter function that opens file explorer, lets the user select of folder as saves the folder path as a variable

def fileNewName():                                                                          #start of fileNewName function
    global customName                                                                       #declares customName as global variable
    customName = input("Enter the end name of your file")                                   #simple code assigning user input to the custom name vairable
    customName = customName + fileType                                                      #add the fileType onto the end of the custom name

def compress():                                                                             #start of compress function
    fileSelect()                                                                            #calls the fileSelect function
    outputSelect()                                                                          #calls the outputSelect function
    fileNewName()
    global src
    global dst                                                                           #calls the fileNewName function
    src = startingLocation                                                                  #assigns startingLocation str as src, so the shutil module is able to use it in a cleaner way
    dst = outputLocation                                                                    #assigns outputLocation dst as src, so the shutil module is able to use it in a cleaner way
    shutil.copy(src, dst)                                                                   #shutil command that copies the file from src to dst
    src = outputLocation + '/' + originalName                                               #reassigns src as the location of the file copy
    dst = outputLocation + '/' + customName                                                 #reassigns dst as the location of the file copy but with a new name
    shutil.move(src,dst)


def compress_video(video_full_path, output_file_name, target_size):
    # Reference: https://en.wikipedia.org/wiki/Bit_rate#Encoding_bit_rate
    min_audio_bitrate = 32000
    max_audio_bitrate = 256000

    probe = ffmpeg.probe(video_full_path)
    # Video duration, in s.
    duration = float(probe['format']['duration'])
    # Audio bitrate, in bps.
    audio_bitrate = float(next((s for s in probe['streams'] if s['codec_type'] == 'audio'), None)['bit_rate'])
    # Target total bitrate, in bps.
    target_total_bitrate = (target_size * 1024 * 8) / (1.073741824 * duration)

    # Target audio bitrate, in bps
    if 10 * audio_bitrate > target_total_bitrate:
        audio_bitrate = target_total_bitrate / 10
        if audio_bitrate < min_audio_bitrate < target_total_bitrate:
            audio_bitrate = min_audio_bitrate
        elif audio_bitrate > max_audio_bitrate:
            audio_bitrate = max_audio_bitrate
    # Target video bitrate, in bps.
    video_bitrate = target_total_bitrate - audio_bitrate

    i = ffmpeg.input(video_full_path)
    ffmpeg.output(i, os.devnull,
                  **{'c:v': 'libx264', 'b:v': video_bitrate, 'pass': 1, 'f': 'mp4'}
                  ).overwrite_output().run()
    ffmpeg.output(i, output_file_name,
                  **{'c:v': 'libx264', 'b:v': video_bitrate, 'pass': 2, 'c:a': 'aac', 'b:a': audio_bitrate}
                  ).overwrite_output().run()

compress()
compress_video(dst, outputLocation, 3 * 1000)


  


• How to retrieve, process and display frames from a capture device with minimal latency

  14 mars 2024, par valle

  I'm currently working on a project where I need to retrieve frames from a capture device, process them, and display them with minimal latency and compression. Initially, my goal is to maintain the video stream as close to the source signal as possible, ensuring no noticeable compression or latency. However, as the project progresses, I also want to adjust framerate and apply image compression.

  


  I have experimented using FFmpeg, since that was the first thing that came to my mind when thinking about capturing video(frames) and processing them.

  


  However I am not satisfied yet, since I am experiencing delay in the stream. (No huge delay but definately noticable)
The command that worked best so far for me :

  


  ffmpeg -rtbufsize 512M -f dshow -i video="Blackmagic WDM Capture (4)" -vf format=yuv420p -c:v libx264 -preset ultrafast -qp 0 -an -tune zerolatency -f h264 - | ffplay -fflags nobuffer -flags low_delay -probesize 32 -sync ext -

  


  I also used OBS to capture the video stream from the capture device and when looking into the preview there was no noticable delay. I then tried to simulate the exact same settings using ffmpeg :

  


  ffmpeg -rtbufsize 512M -f dshow -i video="Blackmagic WDM Capture (4)" -vf format=yuv420p -r 60 -c:v libx264 -preset veryfast -b:v 2500K -an -tune zerolatency -f h264 - | ffplay -fflags nobuffer -flags low_delay -probesize 32 -sync ext -

  


  But the delay was kind of similar to the one of the command above.
I know that OBS probably has a lot complexer stuff going on (Hardware optimization etc.) but atleast I know this way that it´s somehow possible to display the stream from the capture device without any noticable latency (On my setup).

  


  The approach that so far worked best for me (In terms of delay) was to use Python and OpenCV to read frames of the capture device and display them. I also implemented my own framerate (Not perfect I know) but when it comes to compression I am rather limited compared to FFmpeg and the frame processing is also too slow when reaching framerates about 20 fps and more.

  


  import cv2
import time

# Set desired parameters
FRAME_RATE = 15  # Framerate in frames per second
COMPRESSION_QUALITY = 25  # Compression quality for JPEG format (0-100)
COMPRESSION_FLAG = True   # Enable / Disable compression

# Set capture device index (replace 0 with the index of your capture card)
cap = cv2.VideoCapture(4, cv2.CAP_DSHOW)

# Check if the capture device is opened successfully
if not cap.isOpened():
    print("Error: Could not open capture device")
    exit()

# Create an OpenCV window
# TODO: The window is scaled to fullscreen here (The source video is 1920x1080, the display is 1920x1200)
#       I don´t know the scaling algorithm behind this, but it seems to be a simple stretch / nearest neighbor
cv2.namedWindow('Frame', cv2.WINDOW_NORMAL)
cv2.setWindowProperty('Frame', cv2.WND_PROP_FULLSCREEN, cv2.WINDOW_FULLSCREEN)

# Loop to capture and display frames
while True:
    # Start timer for each frame processing cycle
    start_time = time.time()

    # Capture frame-by-frame
    ret, frame = cap.read()

    # If frame is read correctly, proceed
    if ret:
        if COMPRESSION_FLAG:
            # Perform compression
            _, compressed_frame = cv2.imencode('.jpg', frame, [int(cv2.IMWRITE_JPEG_QUALITY), COMPRESSION_QUALITY])
            # Decode the compressed frame
            frame = cv2.imdecode(compressed_frame, cv2.IMREAD_COLOR)

        # Display the frame
        cv2.imshow('Frame', frame)

        # Calculate elapsed time since the start of this frame processing cycle
        elapsed_time = time.time() - start_time

        # Calculate available time for next frame
        available_time = 1.0 / FRAME_RATE

        # Check if processing time exceeds available time
        if elapsed_time > available_time:
            print("Warning: Frame processing time exceeds available time.")

        # Calculate time to sleep to achieve desired frame rate -> maintain a consistent frame rate
        sleep_time = 1.0 / FRAME_RATE - elapsed_time

        # If sleep time is positive, sleep to control frame rate
        if sleep_time > 0:
            time.sleep(sleep_time)

    # Break the loop if 'q' is pressed
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

# Release the capture object and close the display window
cap.release()
cv2.destroyAllWindows()


  


  I also thought about getting the SDK of the capture device in order to upgrade the my performance.
But Since I am not used to low level programming but rather to scripting languages, I thought I would reach out to the StackOverflow community at first, and see if anybody has some hints to better approaches or any tips how I could increase my performance.

  


  Any Help is appreciated !

  


• Minimal Understanding of VP8′s Forward Transform

  16 novembre 2010, par Multimedia Mike — VP8

  Regarding my toy VP8 encoder, Pengvado mentioned in the comments of my last post, “x264 looks perfect using only i16x16 DC mode. You must be doing something wrong in computing residual or fdct or quantization.” This makes a lot of sense. The encoder generates a series of elements which describe how to reconstruct the original image. Intra block reconstruction takes into consideration the following elements :

  
  
  

  I have already verified that both my encoder and FFmpeg’s VP8 decoder agree precisely on how to reconstruct blocks based on the predictors, coefficients, and quantizers. Thus, if the decoded image still looks crazy, the elements the encoder is generating to describe the image must be wrong.

  So I started studying the forward DCT, which I had cribbed wholesale from the original libvpx 0.9.0 source code. It should be noted that the formal VP8 spec only defines the inverse transform process, not the forward process. I was using a version designated as the “short” version, vs. the “fast” version. Then I looked at the 0.9.5 FDCT. Then I got the idea of comparing the results of each.

  input:   92 91 89 86 91 90 88 86 89 89 89 88 89 87 88 93

  • libvpx 0.9.0 “short” :

    forward : -314 5 1 5 4 5 -2 0 0 1 -1 -1 1 11 -3 -4
    inverse : 92 91 89 86 89 86 91 90 91 90 88 86 88 86 89 89
    

  • libvpx 0.9.0 “fast” :

    forward : -314 4 0 5 4 4 -2 0 0 1 0 -1 1 11 -2 -5
    inverse : 91 91 89 86 88 86 91 90 91 90 88 86 88 86 89 89
    

  • libvpx 0.9.5 “short” :

    forward : -312 7 1 0 1 12 -5 2 2 -3 3 -1 1 0 -2 1
    inverse : 92 91 89 86 91 90 88 86 89 89 89 88 89 87 88 93
    

  I was surprised when I noticed that input[] != idct(fdct(input[])) in some of the above cases. Then I remembered that the aforementioned property isn’t what is meant by a “bit-exact” transform– only that all implementations of the inverse transform are supposed to produce bit-exact output for a given vector of input coefficients.

  Anyway, I tried applying each of these forward transforms. I got slightly differing results, with the latest one I tried (the fdct from libvpx 0.9.5) producing the best results (to my eye). At least the trees look better in the Big Buck Bunny logo image :

  
  
  The dense trees of the Big Buck Bunny logo using one of the libvpx 0.9.0 forward transforms
  
  
  The same segment of the image using the libvpx 0.9.5 forward transform
  

  Then again, it could be that the different numbers generated by the newer forward transform triggered different prediction modes to be chosen. Overall, adapting the newer FDCT did not dramatically improve the encoding quality.

  Working on the intra 4×4 mode encoding is generating some rather more accurate blocks than my intra 16×16 encoder. Pengvado indicated that x264 generates perfectly legible results when forcing the encoder to only use intra 16×16 mode. To be honest, I’m having trouble understanding how that can possibly occur thanks to the Walsh-Hadamard transform (WHT). I think that’s where a lot of the error is creeping in with my intra 16×16 encoder. Then again, FFmpeg implements an inverse WHT function that bears ‘vp8′ in its name. This implies that it’s custom to the algorithm and not exactly shared with H.264.