Recherche avancée

Sur d’autres sites (10346)

• MoviePy write_videofile is very slow. Why ?

  5 novembre 2024, par RukshanJS

  I've seen multiple questions on SO relating with this, but couldn't find a solid answer. The following is my code.

  


  async def write_final_video(clip, output_path, results_dir):
    cpu_count = psutil.cpu_count(logical=False)
    threads = max(1, min(cpu_count - 1, 16))

    os.makedirs(results_dir, exist_ok=True)

    output_params = {
        "codec": await detect_hardware_encoder(),
        "audio_codec": "aac",
        "fps": 24,
        "threads": threads,
        "preset": "medium",
        "bitrate": "5000k",
        "audio_bitrate": "192k",
    }

    logger.info(f"Starting video writing process with codec: {output_params['codec']}")
    try:
        await asyncio.to_thread(
            clip.write_videofile,
            output_path,
            **output_params,
        )
    except Exception as e:
        logger.error(f"Error during video writing with {output_params['codec']}: {str(e)}")
        logger.info("Falling back to libx264 software encoding")
        output_params["codec"] = "libx264"
        output_params["preset"] = "medium"
        try:
            await asyncio.to_thread(
                clip.write_videofile,
                output_path,
                **output_params,
            )
        except Exception as e:
            logger.error(f"Error during fallback video writing: {str(e)}")
            raise
    finally:
        logger.info("Video writing process completed")

    # Calculate and return the relative path
    relative_path = os.path.relpath(output_path, start=os.path.dirname(ARTIFACTS_DIR))
    return relative_path


  


  and the helper function to get encoder is below

  


  async def detect_hardware_encoder():
    try:
        result = await asyncio.to_thread(
            subprocess.run,
            ["ffmpeg", "-encoders"],
            capture_output=True,
            text=True
        )

        # Check for hardware encoders in order of preference
        if "h264_videotoolbox" in result.stdout:
            return "h264_videotoolbox"
        elif "h264_nvenc" in result.stdout:
            return "h264_nvenc"
        elif "h264_qsv" in result.stdout:
            return "h264_qsv"

        return "libx264"  # Default software encoder
    except Exception:
        logger.warning("Failed to check for hardware acceleration. Using default encoder.")
        return "libx264"


  


  This code makes the rendering of a 15s video around 6min+ which is not acceptable.

  


  t:  62%|██████▏   | 223/361 [04:40<03:57,  1.72s/it, now=None]

  


  My config is MPS (Apple Silicon Metal Performance Shader), but also should work with NVIDIA CUDA.

  


  How can I reduce the time to write the video ? How to actually reduce this long time to write the file ?

  


  The question is about optimizing MoviePy's video processing pipeline, not just FFmpeg :

  


  

  1. clip is a MoviePy VideoFileClip object handling video processing before FFmpeg encoding

  


  2. write_videofile() is MoviePy's method that manages the entire rendering pipeline including :

     

     • Frame extraction and processing

     


     • Memory management

     


     • Multiprocessing coordination

     


     • Audio synchronization

     


     


  


  


  Source - https://zulko.github.io/moviepy/getting_started/videoclips.html#video-files-mp4-webm-ogv

  


  Other places where this is asked,

  


  

  • https://github.com/Zulko/moviepy/issues/2039

  


  


• Setting dpi flag in image files generated using ffmpeg

  17 mars 2023, par jim_e_jib

  We're using ffmpeg to batch out some TIFF images that are being resized and having white borders created to fit specific paper sizes.

  


  The resulting images default to 72dpi, even when the source is 300dpi. Is there a way to set the dpi flag in the output file ?

  


  Many thanks :-)

  


  The command we're using :

  


  for %%a in ("*.tif") do ffmpeg -i "%%a" -vf "scale=6974:4919:force_original_aspect_ratio=decrease,pad=7016:4961:(ow-iw)/2:(oh-ih)/2:color=white, format=rgb24" "%%~na A2 poster 594x420mm-Border.tif"


  


  We have tried using -dpi 300 in the code but get the error that this is not a recognised.

  


  Edit :

  


  I have just managed to answer my own question :

  


  for %%a in ("*.tif") do ffmpeg -i "%%a" -vf "scale=6974:4919:force_original_aspect_ratio=decrease,pad=7016:4961:(ow-iw)/2:(oh-ih)/2:color=white,format=rgb24" -dpi 300 "%%~na A2 poster 594x420mm-Border.tif"


  


  I had been placing the -dpi 300 in the wrong place when I'd tried it...

  


• HTML5 Video Compatibility (MP4, WEBM, OGG) in 2021

  19 juillet 2021, par William

  The support of HTML5 video has evolved a lot over the years. I am trying to understand whether the <video></video> element still needs to have three sources : MP4, WEBM, and OGG.

  


  There are a lot of answers throughout StackOverflow with deeply conflicting information - some of which say that you just need MP4 now, others say, MP4 and WEBM are enough, and then finally many say that you need all three (although many of those article are 10 years old).

  


  W3 suggests that either MP4 or WEBM alone would have universal support (Even though I found a 2011 article from Google saying that they would be removing support for MP4/H.264). Wikipedia paints a more complicated picture (as well as listing that Google Chrome does indeed support MP4/H.264). Azure Media services ONLY seems to allow output in MP4, which would suggest to me that MP4 must have widespread compatibility.

  


  Also see Example 1, Example 2, Example 3.

  


  Is there any definitive information on what video types to include in an HTML5 video player to achieve widespread compatibility ?

  


  Background : I am building a Content Management Platform that allows uploading videos. When a new video is uploaded, a conversion process kicks off to convert the video into the required formats. This takes time and CPU/Memory, so if it is possible I would like to convert uploaded videos into as few formats as possible.

  


  p.s. This question HAS been asked before, however, the fundamentals of playing video on the web continually evolve and most of the answers out there have become irrelevant.