Recherche avancée

Sur d’autres sites (11777)

• How to parallelize ffmpeg setPTS filter when using GPU ? [closed]

  28 février, par Souvic Chakraborty

  We have a long python code which chunks the video into multiple parts and changes the speed using setPTS filter.

  


  import ffmpeg
ffmpeg.input(segment_path).filter("setpts", f"{1/speed_factor}*PTS").output(
                                adjusted_segment_path,vcodec="h264_nvenc", acodec="aac",preset="fast", crf=23, g=30, keyint_min=30, sc_threshold=0,r=30,vsync='cfr',threads=1
                            ).global_args("-hwaccel", "cuda").run(quiet=True, overwrite_output=True,capture_stdout=True, capture_stderr=True)


  


  Now, because this happens multiple times before concatenation, we thought, instead of sequential processing using a ThreadPool, it may help reduce the time.
So we did that :

  


  import ffmpeg
import concurrent.futures

def process_video(segment_path, adjusted_segment_path, speed_factor):
    ffmpeg.input(segment_path).filter("setpts", f"{1/speed_factor}*PTS").output(
        adjusted_segment_path,
        vcodec="h264_nvenc",
        acodec="aac",
        preset="fast",
        crf=23,
        g=30,
        keyint_min=30,
        sc_threshold=0,
        r=30,
        vsync='cfr',
        threads=1
    ).global_args("-hwaccel", "cuda").run(
        quiet=True, overwrite_output=True, capture_stdout=True, capture_stderr=True
    )


segment_paths = ["input1.mp4", "input2.mp4", "input3.mp4"]  # List of input video segments
output_paths = ["output1.mp4", "output2.mp4", "output3.mp4"]  # Corresponding output paths
speed_factor = 1.5  

# Using ThreadPoolExecutor for concurrent processing
with concurrent.futures.ThreadPoolExecutor(max_workers=4) as executor:
    futures = [
        executor.submit(process_video, seg, out, speed_factor)
        for seg, out in zip(segment_paths, output_paths)
    ]
    
    # Wait for all tasks to complete
    for future in concurrent.futures.as_completed(futures):
        try:
            future.result()  # This will raise any exceptions encountered in the thread
        except Exception as e:
            print(f"Error processing video: {e}")


  


  But the time required did not reduce. Previously, it was 50 seconds for a long video input, now too, it remains the same.

  


  Is there any other way I can improve the code ?

  


  I also noticed the GPU utilization is low and the code is still executed sequentially (I can see when I run nvtop, which processes are running)

  


  I am using an L4 GPU with CUDA Version : 12.4, nvcc CUDA Toolkit is also at 12.4

  


• piping data into an ffmpeg subprocess. Why does write() get stuck ? [closed]

  12 mai 2024, par Tebyy

  It displays the number of frames at the beginning and shows that there are over 300, but when I count all the frames in the loop, the last one I see is 53, and then it only displays the value of 'ret', which is always true. I'm wondering what could be causing this issue of not reading all the frames, resulting in the file not being closed after reading. From what I've read, 'ret' should return false when there are no more frames to read, but because it's not reading all the frames, this isn't happening. Does anyone have any idea what could be causing this ?

  


  Edit : I solved the problem by adding a Thread. Thanks everyone for the help !

  


  I changed those lines of code :

  


  recogniteAndPushFramesToFfmpeg("video-979257305707693982.mp4", ffmpeg_process)
# In function "recogniteAndPushFramesToFfmpeg"
process.stdin.write(frame)


  


  to these :

  


  ffmpeg_thread = Thread(target=recogniteAndPushFramesToFfmpeg, args=("video-979257305707693982.mp4", ffmpeg_process))
ffmpeg_thread.start()
# In function "recogniteAndPushFramesToFfmpeg"
process.stdin.write(frame.tobytes())


  


  Code :

  


  import subprocess
import cv2

def recogniteAndPushFramesToFfmpeg(video_path, process):
    cap = cv2.VideoCapture(video_path)
    i = 1
    print('Frames:', cap.get(cv2.CAP_PROP_FRAME_COUNT))
    while cap.isOpened():
        ret, frame = cap.read()
        print(ret)
        if not ret:
            break

        process.stdin.write(frame)
        process.stdin.flush()
        print('Frame:', i)
        i += 1

    cap.release()
    process.stdin.close()
    #process.wait()
    return
    

ffmpeg_command = [
    'ffmpeg', '-f', 'rawvideo', '-s:v', '1920x1080', '-r', '60',
    '-i', '-', '-vf', 'setpts=2.5*PTS',
    '-c:v', 'libvpx-vp9', '-g', '60',
    '-f', 'webm', '-'
]
ffmpeg_process = subprocess.Popen(ffmpeg_command, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=-1)
recogniteAndPushFramesToFfmpeg("video-979257305707693982.mp4", ffmpeg_process)


  


  Python Logs :

  


  Frames: 328.0
...
True
Frame 50
True
Frame 51
True
Frame 52
True
Frame 53
True


  


  I placed cap.isOpened() in the loop to check if it always returns true, and when I printed it, it always showed true

  


  Link to video : Tested Video

  


• FFmpeg downloading entire live stream when making a small clip

  6 février 2021, par stevendesu

  Setup

  


  I'm using FFmpeg to generate video clips from M3U8 videos. The command looks like this :

  


  ffmpeg -ss <start> -i &lt;1080p-chunklist-url> -c:v copy -c:a copy -t <duration> -f mp4 -y out.mp4&#xA;</duration></start>

  


  For example, to create a 30-second clip starting at the 5-minute mark for a particular video, the command would be :

  


  ffmpeg -ss 300 -i https://example.com/path/to/1080p/index.m3u8 -c:v copy -c:a copy -t 30 -f mp4 -y out.mp4


  


  Some caveats I'm already aware of :

  


  

  • If -ss comes after -i then FFmpeg will attempt to download the entire M3U8 instead of just the relevant TS files, and will parse the entire video contents looking for the exact timestamp. By putting -ss before -i FFmpeg uses "seek points", which with HLS videos means it looks at the M3U8 and only downloads relevant TS files

  


  • TS file boundaries function as "seek points" in HLS, so if a TS file starts at 4:51 and the next TS file starts at 5:01, this command will start the clip at 4:51 instead of 5:01 (it prefers the first seek point before the requested time)

  


  • The -t parameter sets an exact clip duration instead of an ending position, so in the above example of a clip starting at 4:51 the same clip would end at 5:21 instead of 5:30

  


  


  In theory I can utilize -to instead of -t to specify an ending time of 5:30, however in practice this hasn't worked. Also in theory I can force -accurate_seeking to discard the contents from 4:51 to 5:00 and start the clip where I wanted it, but I learned this only works for transcodes and not transmux

  


  Now to the meat of my problem :

  


  Problem

  


  When the M3U8 URL provided is a live stream (no #EXT-X-ENDLIST tag) then FFmpeg does not behave correctly. On FFmpeg versions 4.2.1 and earlier, it starts by downloading the TS file containing my clip segment, then proceeds to download every TS file in the M3U8 then hangs while waiting for new TS files to become available, downloading them as they appear - even hours after the end of the section I wanted to clip. On FFmpeg version 4.2.2 and later, I can create clips so long as they end before the second-to-last TS file. If the live stream currently has 20 minutes of video data and I create a clip from 19:30 - 19:40 (ending right at the start of the second-to-last TS file, assuming a 10-second TS file duration) then it will behave the same as 4.2.1 : waiting infinitely to download the entire video.

  


  The "2 TS files from the end" rule I believe is related to FFmpeg's initial probe of the video to get stream data. In the aforementioned 20-minute long video, if I make a clip from 3:00 to 3:30 (well before the end of the stream) it will first download TS files 119 and 120 (19:40-19:50 and 19:50-20:00), then it displays a list of the streams in the video (audio, video, metadata), then it downloads TS files 19 - 21 (containing the actual data I want for my clip)

  


  Is there a way to fix it so I can properly make clips of sections near the "end" of live M3U8s ?