Build Media Services transform configs with encoding presets, H.264 video layers, AAC audio, and thumbnail generation.
Build Media Services transform configs with encoding presets, H.264 video layers, AAC audio, thumbnail generation, and streaming policies.
Required Fields
accountNametransformNameoutputsoutputs[0].presetOutput will appear here...The builder validates that accountName, transformName, outputs, and the first output's preset all resolve before accepting the JSON as a valid Transform definition, the fields Media Services needs to know the encoding pipeline's outputs and their error-handling behavior; it can't verify the specific codec/layer parameter combinations are valid together or that referenced streaming policy names exist, those are only confirmed when an actual job using this transform is submitted.
Build an Azure Media Services Transform combining multiple TransformOutputs, each with its own encoding preset and independently-configured onError behavior (StopProcessingJob versus ContinueJob), so a job producing both adaptive-streaming output and separate custom-layered H.264/thumbnail output can fail the whole job on a critical output's error while tolerating a failure in a lower-priority output (relativePriority: Low) without losing the outputs that did succeed. The layers array under H264Video defines multiple bitrate/resolution renditions from one encoding pass (1080p/720p/480p in the example), the actual adaptive-bitrate ladder viewers' players switch between based on network conditions, getting this ladder's bitrate/resolution spacing wrong produces either wasted encoding work (too many similar renditions) or a poor low-bandwidth viewing experience (too few, too-high-bitrate options).
Set onError deliberately per output based on its actual importance to the overall job's success criteria, a low-priority secondary output shouldn't be able to fail the entire job via StopProcessingJob if the primary output's success is what actually matters most.
Design the bitrate ladder with meaningful spacing between rungs (a common rule of thumb is roughly a 2x bitrate difference between adjacent renditions), a ladder with too-similar bitrates wastes encoding compute without giving the adaptive player useful switching granularity.
Combine video, audio, and thumbnail generation in one preset/job where the outputs are related, rather than running separate jobs, reducing both total processing time and the operational complexity of coordinating multiple related jobs.
Yes, StopProcessingJob on any single output's onError setting means a failure in that specific output stops the entire job, including outputs that might otherwise have completed successfully. This is why the example uses ContinueJob for the lower-priority secondary output, so a failure there doesn't retroactively waste the primary AdaptiveStreaming output's successful completion.
Not necessarily, more layers mean more encoding compute cost and more storage for the resulting files, without necessarily improving the actual viewer experience if the added layers are too close in bitrate to provide meaningfully different quality/bandwidth tradeoffs. A well-designed ladder has enough spacing between rungs (like the example's roughly 2x bitrate steps between 1080p/720p/480p) to give the adaptive player genuinely useful switching points.
It can happen in the same job, as the example demonstrates by including a JpgImage codec entry alongside the video and audio codecs within one StandardEncoderPreset output, Media Services generates the thumbnails as part of that same encoding pass rather than requiring a completely separate transform and job dedicated only to thumbnail extraction.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.