Assigned
Status Update
Comments
va...@google.com <va...@google.com>
su...@google.com <su...@google.com> #2
Hello,
Thank you for reaching out to us with your request.
We have duly noted your feedback and will thoroughly validate it. While we cannot provide an estimated time of implementation or guarantee the fulfillment of the issue, please be assured that your input is highly valued. Your feedback enables us to enhance our products and services.
We appreciate your continued trust and support in improving our Google Cloud Platform products. In case you want to report a new issue, Please do not hesitate to create a new issue on the
Once again, we sincerely appreciate your valuable feedback; Thank you for your understanding and collaboration.
Description
The ffmpeg system package, which is auto deployed for cloud functions seems to not take advantage of Cloud Function's multiple CPUs (if configured) resulting in longer processing latency.
For example, deploying a function that performs a simple conversion of a PCM format wav audio files to aac/mp4 will always only utilize a single CPU. This can be easily seen by examining the function's Container CPU utilization: If configuring the function with the default single CPU, the CPU util will be 100% for the duration of the Ffmpeg execution. If configuring the function with the 2 CPUs, the CPU util will be 50% for the duration of the Ffmpeg execution. If configuring the function with the 4 CPUs, the CPU util will be 25% for the duration of the Ffmpeg execution. The duration of processing a set audio file will remain the same no matter how many CPUs are configured.
The root cause might be that the ffmpeg build used by Cloud Functions is not built with the --enable-pthreads build option but this also may be an issue with the build specific codec libraries used by ffmpeg.
This is the ffmpeg build info for the system package (no --enable-pthreads):