FFmpeg job working with limited resources??

Tagged: , ,

Viewing 3 posts - 1 through 3 (of 3 total)
  • Back to forum
    Posted in: Muster 9
  • Sergey Berengard
    15th May 2020 at 9:53 pm #33419

    Hi!

    I’m trying out Muster for my project and I stumbled upon a curious issue…

    I’m running an FFmpeg job that transcodes a .mp4 file to .mov.
    Simply running FFmpeg with all it’s parameters in the command prompt, does the work nice and fast, but when I create a Muster job to do the same thing with the same parameters, it works x3-4 times slower.

    In the Task Manager, I’m seeing that it’s utilizing all the available cores and the GPU CUDA as well, which tells me that it’s taking the parameters I give it just fine, but it’s just doing it slower like it was executing in a limited environment.

    What could be the cause of this?
    Please help.

    Thanks,
    -Sergey.

    Leonardo Bernardini
    16th May 2020 at 10:02 pm #33469

    Hi Sergey,

    No this is a no sense, muster spawns any process assuming we are talking about windows, using the CreateProcess() API, or using a fork() call on Unix systems. That means this is the same exact way of creating a process through a console.
    Now, what can in the end change between a console and Muster, is the context where Muster is running. If you’re running Muster as a system service, you may have environmental variables, and environments in general inherited from the user account you actually assigned to the service (or if you run it as a local system account, that’s strongly discouraged, a more weird environment).
    So this is your first test: stop the Muster renderclient service from the system service control panel, and launch the renderclient.exe manually, this will spawn Muster inside a shell. Launch your job and check what happens.

    Also if you get back with your actual installation configuration, we may understand better this weird issue.

    Cheers !

    Sergey Berengard
    16th May 2020 at 11:06 pm #33472

    Hi Leonardo,

    Thanks for your informative reply!
    I figured it out by looking into it exactly like you said, stopping the service and running the client in console mode instead.
    What I found was that the FFmpeg job was running with logging level set to 100 causing it to spit out every tiny bit of tracing and debugging information during the transcoding process. All that overhead was what was causing it to run x3 times slower.

    So I modified the FFmpeg python template to have it run with logging level 16, which would only print out errors if they occur, otherwise FFmpeg runs silently without any unnecessary overhead. And that totally worked!
    Just a thought, but maybe it had also to do with the fact that I was using QSV for FFmpeg’s hardware acceleration, which works on the CPU, causing it to jam…? Will see how it compares when I switch to CUDA.

    But it works now. Thanks for your all your help!
    Cheers!

    -Sergey.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.