What you would like to accomplish: In short, I would like the Transcoder API to have new job config options that allow it to dynamically exclude my provided elementary streams depending on the input video.
I have videos of various dimensions and frame rates that I want to transcode. I would like to use the same job template for all of these videos. The template includes multiple output variants for an HLS/DASH ABR ladder.
I would like the Transcoder API to automatically skip any elementary streams (and consequently any mux streams that contain them, also removing those mux streams from any manifests that included them) that have larger dimensions than the input video. For example, if my input video is 1280x720 and I have 2 elementary streams, with dimensions 1280x720 and 1920x1080, then I want the Transcoder API to skip the 1920x1080 stream instead of upscaling the video. Again, the skipped stream should then be excluded from any dependent mux streams and manifests (skipping entirely those mux streams and manifests that would be empty as a result of excluding elementary streams).
How this might work: The Transcoder API can add, without any breaking changes for existing users, a new job config option that allows users to optionally enable this behavior, defaulting to the current behavior if omitted. The option could either be added to each VideoStream object (e.g. excludeIfLarger: true), or the top-level JobConfig object (e.g., excludeStreamsWithLargerDims: true).
If applicable, reasons why alternative solutions are not sufficient: Currently, developers need to fuss with finicky tools like ffmpeg in order to first extract the video dimensions and send a customized ad-hoc job config with each job request. While possible, this is an inferior, error-prone workaround. In my case, I am sending the Transcoder API job request from a Cloud Function, so I would first have to download the entire video file from Cloud Storage into the Cloud Function's memory, then inspect it with ffmpeg, before I can request the job. Not ideal.
Description
What you would like to accomplish: In short, I would like the Transcoder API to have new job config options that allow it to dynamically exclude my provided elementary streams depending on the input video.
I have videos of various dimensions and frame rates that I want to transcode. I would like to use the same job template for all of these videos. The template includes multiple output variants for an HLS/DASH ABR ladder.
I would like the Transcoder API to automatically skip any elementary streams (and consequently any mux streams that contain them, also removing those mux streams from any manifests that included them) that have larger dimensions than the input video. For example, if my input video is 1280x720 and I have 2 elementary streams, with dimensions 1280x720 and 1920x1080, then I want the Transcoder API to skip the 1920x1080 stream instead of upscaling the video. Again, the skipped stream should then be excluded from any dependent mux streams and manifests (skipping entirely those mux streams and manifests that would be empty as a result of excluding elementary streams).
How this might work: The Transcoder API can add, without any breaking changes for existing users, a new job config option that allows users to optionally enable this behavior, defaulting to the current behavior if omitted. The option could either be added to each
VideoStreamobject (e.g.excludeIfLarger: true), or the top-levelJobConfigobject (e.g.,excludeStreamsWithLargerDims: true).If applicable, reasons why alternative solutions are not sufficient: Currently, developers need to fuss with finicky tools like ffmpeg in order to first extract the video dimensions and send a customized ad-hoc job config with each job request. While possible, this is an inferior, error-prone workaround. In my case, I am sending the Transcoder API job request from a Cloud Function, so I would first have to download the entire video file from Cloud Storage into the Cloud Function's memory, then inspect it with ffmpeg, before I can request the job. Not ideal.
Thanks!