From cb2f2fc7b8b590e4ab415ec1e0b0d6ce6f43e4bc Mon Sep 17 00:00:00 2001 From: Pavan Rangudu Date: Thu, 29 Aug 2024 15:11:49 -0700 Subject: [PATCH] Customer Usage and Interaction for JobTemplate & Preset --- .gitignore | 3 +- text/0635-mediaconvert-l2-construct.md | 258 +++++++++++++++++++++++++ 2 files changed, 260 insertions(+), 1 deletion(-) create mode 100644 text/0635-mediaconvert-l2-construct.md diff --git a/.gitignore b/.gitignore index 0d9399db1..8f463515e 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ # VSCode Local history extension .history/ -*.swp \ No newline at end of file +*.swp +.idea/ \ No newline at end of file diff --git a/text/0635-mediaconvert-l2-construct.md b/text/0635-mediaconvert-l2-construct.md new file mode 100644 index 000000000..951e87021 --- /dev/null +++ b/text/0635-mediaconvert-l2-construct.md @@ -0,0 +1,258 @@ +# AWS MediaConvert L2 Constructs + +* **Original Author(s):**: @PavanRangudu +* **Tracking Issue**: [#635](https://github.com/aws/aws-cdk-rfcs/issues/635) +* **API Bar Raiser**: @{BAR_RAISER_USER} + + +[AWS MediaConvert](https://aws.amazon.com/mediaconvert/) is a file-based video processing service that provides +scalable video processing for content owners and distributors with media libraries of any size. Today, customers can create +MediaConvert JobTemplates, Presets, and Queues using autogenerated L1 (CloudFormation) Constructs. However, this involves +specifying detailed JSON structures as input that is cumbersome and error-prone. Developers need to understand the exact +format and structure required by MediaConvert, as well as how to translate that into CDK code. + +This process could be greatly simplified with the support of L2 constructs. We will build convenience methods working backwards +from common use cases and default to recommended best practices. + +This RFC proposes L2 constructs for MediaConvert which will provide convenience features and abstractions for the existing +L1 (CloudFormation) Constructs building on the functionality already supported in the @aws-cdk/aws-mediaconvert module. + + +## README + +AWS MediaConvert has three CloudFormation resources: + +- Job Templates: + + Job Templates in AWS MediaConvert allow you to predefine the settings for your media processing jobs. By using Job Templates, you can tailor jobs to specific workflows, ensuring consistency and efficiency across your media processing tasks. These templates include settings for video and audio encoding, output formats, and more, simplifying the job creation process by reducing the need for manual configuration. + +- Presets: + + Presets are reusable collections of settings that define how MediaConvert processes video, audio, and captions. Presets can be applied to different jobs, making it easy to standardize encoding settings across multiple tasks. They help streamline workflows by encapsulating complex encoding settings into a single, reusable entity. + +- Queues: + + Queues in AWS MediaConvert are used to manage the order and priority of media jobs. By organizing jobs into different Queues, you can control the processing flow, optimize resource usage, and ensure that critical jobs are handled with the appropriate priority. Queues allow you to separate jobs by priority or workflow, helping manage costs and processing time effectively. + + +### Customer Usage and Interaction + +#### Job Templates + +To create a Custom Job Template using an L2 Construct, you define the ``jobTemplateProps`` object, which includes all the +necessary settings for your media processing tasks. This object is then passed to the ``JobTemplate`` construct to create the custom template. + + const jobTemplateProps: JobTemplateProps = { + name: 'CustomJobTemplate', + settings: { + OutputGroups: [ + { + Name: 'CustomOutputGroup', + OutputGroupSettings: { + Type: 'FILE_GROUP_SETTINGS', + FileGroupSettings: { + Destination: 's3://amzn-s3-demo-destination-bucket/' + } + }, + Outputs: [ + { + ContainerSettings: { + Container: 'MP4' + }, + VideoDescription: { + CodecSettings: { + Codec: 'H_264', + H264Settings: { + MaxBitrate: 1000, + RateControlMode: 'QVBR', + SceneChangeDetect: 'TRANSITION_DETECTION' + } + } + }, + AudioDescriptions: [ + { + CodecSettings: { + Codec: 'AAC', + AacSettings: { + Bitrate: 96000, + CodingMode: 'CODING_MODE_2_0', + SampleRate: 48000 + } + } + } + ] + } + ] + } + ] + } + }; + + // Define the custom MediaConvert Job Template + const customJobTemplate = new JobTemplate(this, 'CustomJobTemplate', jobTemplateProps); + +In this example, the ``customJobTemplate`` is configured with specific output groups and encoding settings. By defining +these properties, you can create a Job Template that aligns precisely with your media processing requirements, ensuring +consistent and optimized workflows across your jobs. + +The System Job Templates are a collection of pre-configured and managed JobTemplates provided by AWS Elemental MediaConvert. +These templates are designed to cater to common media processing use cases and are set up with best practices in mind. +By utilizing these System Job Templates, you can easily configure your MediaConvert jobs by simply referencing the template's +name. The necessary settings and configurations will be automatically applied, ensuring that your media processing workflows +are optimized and aligned with recommended standards. + + const genericMp4Hev1AvcAacSdrQvbJobTemplate = new JobTemplate(this, 'GenericMp4Hev1AvcAacSdrQvbJobTemplate', { + name: "GenericMp4Hev1AvcAacSdrQvbJobTemplate" + }); + +In this example, the ``genericMp4Hev1AvcAacSdrQvbJobTemplate`` is a predefined System Job Template. By specifying its name, +you automatically leverage a set of optimized settings tailored for a specific media conversion scenario. This approach +simplifies the setup process, allowing you to focus on other aspects of your media processing pipeline. + +#### Presets + +To create a Custom Preset using an L2 Construct, you define the ``presetProps`` object, which includes all the necessary +settings for your media processing tasks. This object is then passed to the ``Preset`` construct to create the custom preset. + + const presetProps: PresetProps = { + name: 'CustomPreset', + settings: { + VideoDescription: { + CodecSettings: { + Codec: 'H_264', + H264Settings: { + MaxBitrate: 5000, + RateControlMode: 'CBR', + FramerateControl: 'SPECIFIED', + FramerateNumerator: 30, + FramerateDenominator: 1 + } + } + }, + AudioDescriptions: [ + { + CodecSettings: { + Codec: 'AAC', + AacSettings: { + Bitrate: 128000, + CodingMode: 'CODING_MODE_2_0', + SampleRate: 44100 + } + } + } + ] + } + }; + + // Define the custom MediaConvert Preset + const customPreset = new Preset(this, 'CustomPreset', presetProps); + +In this example, the ``customPreset`` is configured with specific video and audio encoding settings. By defining these properties, you can create a Preset that matches your exact media processing requirements, allowing for consistent and optimized encoding across your jobs. + +System Presets are a collection of pre-configured and managed Presets provided by AWS Elemental MediaConvert. These presets are designed to handle common media processing scenarios and come with recommended best practices for video and audio encoding. By using System Presets, you can quickly set up your MediaConvert jobs by simply referencing the preset's name, ensuring that your encoding tasks are performed with optimized settings. + +In this example, the GenericMp4Hev1AvcAacPreset is a predefined System Preset. By specifying its name, you automatically use a set of optimal encoding settings tailored for a specific media conversion scenario. This simplifies the configuration process, allowing you to focus on other critical aspects of your media processing pipeline. + + const genericMp4Hev1AvcAacPreset = new Preset(this, 'GenericMp4Hev1AvcAacPreset', { + name: "GenericMp4Hev1AvcAacPreset" + }); + +Using System Presets like this allows you to leverage AWS MediaConvert’s best practices without needing to manually configure every encoding parameter, making your media processing workflows more efficient and reliable. + + + + + +Ticking the box below indicates that the public API of this RFC has been +signed-off by the API bar raiser (the `status/api-approved` label was applied to the +RFC pull request): + +``` +[ ] Signed-off by API Bar Raiser @xxxxx +``` + +## Public FAQ TODO + +> This section should include answers to questions readers will likely ask about +> this release. Similar to the "working backwards", this section should be +> written in a language as if the feature is now released. +> +> The template includes a some common questions, feel free to add any questions +> that might be relevant to this feature or omit questions that you feel are not +> applicable. + +### What are we launching today? + +> What exactly are we launching? Is this a new feature in an existing module? A +> new module? A whole framework? A change in the CLI? + +### Why should I use this feature? + +> Describe use cases that are addressed by this feature. + +## Internal FAQ + +> The goal of this section is to help decide if this RFC should be implemented. +> It should include answers to questions that the team is likely ask. Contrary +> to the rest of the RFC, answers should be written "from the present" and +> likely discuss design approach, implementation plans, alternative considered +> and other considerations that will help decide if this RFC should be +> implemented. + +### Why are we doing this? + +> What is the motivation for this change? + +### Why should we _not_ do this? + +> Is there a way to address this use case with the current product? What are the +> downsides of implementing this feature? + +### What is the technical solution (design) of this feature? + +> Briefly describe the high-level design approach for implementing this feature. +> +> As appropriate, you can add an appendix with a more detailed design document. +> +> This is a good place to reference a prototype or proof of concept, which is +> highly recommended for most RFCs. + +### Is this a breaking change? + +> If the answer is no. Otherwise: +> +> Describe what ways did you consider to deliver this without breaking users? +> +> Make sure to include a `BREAKING CHANGE` clause under the CHANGELOG section with a description of the breaking +> changes and the migration path. + +### What alternative solutions did you consider? + +> Briefly describe alternative approaches that you considered. If there are +> hairy details, include them in an appendix. + +### What are the drawbacks of this solution? + +> Describe any problems/risks that can be introduced if we implement this RFC. + +### What is the high-level project plan? + +> Describe your plan on how to deliver this feature from prototyping to GA. +> Especially think about how to "bake" it in the open and get constant feedback +> from users before you stabilize the APIs. +> +> If you have a project board with your implementation plan, this is a good +> place to link to it. + +### Are there any open issues that need to be addressed later? + +> Describe any major open issues that this RFC did not take into account. Once +> the RFC is approved, create GitHub issues for these issues and update this RFC +> of the project board with these issue IDs. + +## Appendix + +Feel free to add any number of appendices as you see fit. Appendices are +expected to allow readers to dive deeper to certain sections if they like. For +example, you can include an appendix which describes the detailed design of an +algorithm and reference it from the FAQ.