Recherche avancée

Sur d’autres sites (4095)

• Revision 37427 : mmmh c’est l’inverse manuel écrit brutalement ... non manuel d’une manière ...

  19 avril 2010, par kent1@… — Log

  mmmh c’est l’inverse manuel écrit brutalement ... non manuel d’une manière plus smooth

• 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

  


• Multiple nVidia GPU transcoding (NOT computing) bottleneck

  11 décembre 2018, par Daniel Cantarin

  I’m doing some nVidia multi-GPU testing. However, this tests are not on the computing field but transcoding, using nvenc/nvdec.

  I have a setup with 3 Quadro GPUs (max 4 on this motherboard), and running some transcoding jobs using ffmpeg.

  Thing is, up to 8 jobs everything is fine, with tolerable GPU and CPU stats.
  But when reaching the 9th job, the nVidia cards metrics start to fall down. Whats troublesome is this : it doesn’t matter the job distribution. That is, if I send 8 jobs to GPU0, and 1 job to GPU1, is the same as 4-5, or 4-4-1, or 0-4-5, etc.

  What I see beggining on the 9th job is :

  1. CPU gets to about 60% usage (30% up to 8th jobs) and doesn’t go up much after adding more jobs.
  2. DECODING metrics falls from about 75% (when single card has 8 jobs) to about 20%.
  3. Every card behaves the same when this problem starts, no matter how many jobs they have.

  And the last strange thing I see : when that problem happens, and I kill all the jobs, the cards keep working for a while (sometimes even minutes).

  All this points to some bottleneck somewhere on the motherboard. Maybe the PCIe bus, maybe some CPU subsystem, I’m not sure. It also points to some buffering happening somewhere. I’m using the usual popular tools to see high-level metrics and curves (top/htop, nvidia-smi, nvtop, etc).

  My question : does anybody knows some common bottlenecks regarding multi-GPU setups that could lead to a problem like this ?

  Any tip would be nice.

  Thanks in advance.