Support explicit binding between drm keys and output media tracks

[KarlGallagher]

Hello,

currently the width of the output is set as automatic (-2) via FFMEG processing command.

I would like to propose that it is instead set as per the required output resolution settings - e.g.
filters.append('scale={0}:{1}'.format(stream.resolution.max_width, stream.resolution.max_height))

The main reason is that when we apply DRM based encryption, Shaka Packager's auto-assignment of keys to specific tracks (based on resolution) can get thrown off when the width fluctuates. For example, sometimes it treats 480p as 'HD' or 1080p as 'UHD'.

Since typically we associated HD and UHD quality settings with more restrictive DRM requirements this can lead to compatibility issues for some clients/users

[joeyparrish]

I believe that using the scale command you proposed would result in some content being encoded at the wrong aspect ratio, with things squished or stretched inappropriately.

[joeyparrish]

I believe Packager can be configured as to how the keys are assigned. Could we perhaps fix it that way instead?

[KarlGallagher]

@joeyparrish yeah this would lock output to 16:9, which for me does not cause much of an issue, but I understand what you are saying.

The key assigment issues could be probably be worked around in raw key mode by setting the stream descriptor drm_label field to match the key label AFAIK (so long as labels are defined...)

[joeyparrish]

From Packager docs, it appears that we can use the drm_label descriptor without needing to resort to raw key mode, so long as we use predefined, expected values. See https://google.github.io/shaka-packager/html/options/stream_descriptors.html#drm-related-stream-descriptor-fields

[mariocynicys]

@KarlGallagher Try adding - scale=your_wanted_max_width:max_height in the filters option in input_config.yaml, this will apply you scale first so the scale='-2:{0}'.format(stream.resolution.max_height) will have no effect at this moment.

[KarlGallagher]

@joeyparrish OK sounds like we could update the bitrate_configuration to also support the concept of drm_label.

ill have a look at what 'fixed' labels are defined by default....