Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC635: L2 Constructs for MediaConvert #639

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
# VSCode Local history extension
.history/
*.swp
*.swp
.idea/
258 changes: 258 additions & 0 deletions text/0635-mediaconvert-l2-construct.md
Original file line number Diff line number Diff line change
@@ -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.
PavanRangudu marked this conversation as resolved.
Show resolved Hide resolved


## 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 = {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how can customers define a template, will they write it in JSON format ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they can write it in a JSON format. We also discussed about having some helper methods to produce this props object. I plan to add some more details on it in my next commit.

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"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are these templated maintained?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial idea is to maintain (a copy of these system templates) inside CDK repo. Discussed offline with @moelasmar and pending implementation details.

});

In this example, the ``genericMp4Hev1AvcAacSdrQvbJobTemplate`` is a predefined System Job Template. By specifying its name,
PavanRangudu marked this conversation as resolved.
Show resolved Hide resolved
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: {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the objects in this settings have types defined?

Same question to the settings in JobTemplateProps.

And in these 2 settings objects, are all fields required?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, my idea is to have strongly-typed fields for all of these interfaces by importing our SDK. Discussed offline with @moelasmar and @samson-keung and pending decision on whether we can use SDK inside CDK.

To your second que: no, not all fields are required. I plan to add respective interfaces (with fields marked as required/optional) in my next commit.

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.



Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add RFC for L2 Queues

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I will add them in my next commit.



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.
Loading