Subject: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter

From: "Ali C. Begen" <[email-masked]>
Date: Thu, 14 Sep 2017 12:25:05 +0300

Hi there,

Alexey M. suggested that I wrote my question to this list. I hope to get
some advice on something we are dealing with in MPEG.

The core discussion is here:
https://github.com/w3c/encrypted-media/issues/400

(At the bottom, there is the text we presented in the last mpeg meeting)

I personally think overloading the codecs parameter to indicate every media
future (the encryption scheme in this specific discussion but the main
problem is broader) is not a good idea just for the sake of using it as
implicit signaling.

Admittedly, defining a new parameter is not perfect, either but maybe we
can find a way to make it work nicely.

What are your thoughts on this? Comments are welcome.

Thanks.
-acbegen

m41135 (Joint contribution to July 2017 meeting by Comcast, Google and
AAU/Bitmovin)

Title: MIME Type Parameters for Signaling Encryption and Other Media
Features

1) Introduction

RFC 6381 specifies parameters that are used with various MIME types or
type/subtype combinations to allow for unambiguous specification of the
codecs employed by the media formats contained within, or the profile(s) of
the overall container format. However, the MIME type parameters do not
indicate the type of encryption. This could create a problem for the
receivers when the encapsulating environment is not capable of declaring
separately that the content is protected (such as in the MPD for DASH)
since in that case the receivers cannot infer whether they can decode the
media without first fetching and parsing the media tracks.

ISO/IEC 14496-12 defect report (N16618) reported this issue, and the
revised defect report (N16785) proposed an annex that defined certain rules
on how to use MIME type parameters for ISOBMFF and derived specifications.

The proposed annex in N16785 specifies the following:
If the 4CC of a sample entry indicates protected content (e.g., ‘encv’,
‘enca’, ‘enct’ etc.), the ‘codecs’ parameter value for that track is any
the following values, separated by “.”:
* the 4CC indicating protected content (e.g., ‘encv’);
* the scheme-type (e.g., ‘cenc’);
* the original_format (e.g., ‘avc1’), followed by any sub-parameters as
defined for that original format

As a result, the following values would be possible for the ‘codecs’
parameter:
encv.cbcs.avc1.402567
or
encv.cenc.avc1.402567

The motivation here is that when a receiver reads such a value, it can
determine whether it can decode the media (i.e., whether it supports the
encryption mode). If it does not understand the value, by definition it
will ignore the value and will not fetch the media to avoid waste of
(server, network or time) resources.

While the motivation for this approach seems just, overloading the ‘codecs’
parameter value has several drawbacks and may lead us to more problems in
the future.

2) Proposal

A cleaner and more future-proof approach is to put the additional values
out of the ‘codecs’ parameter. For example, to indicate the encryption mode
for the following existing media
video/mp4; codecs=”avc1.640028”
we could rather say
video/mp4; codecs=”avc1.640028”; encscheme=”cbcs”
or
video/mp4; codecs=”avc1.640028”; encscheme=”cenc”

Indeed, the older receivers who do not understand the ‘encsheme’ parameter
will ignore it and may unnecessarily fetch the media (this is a behavior by
design). However, we need to worry more about the newer clients who will
understand this and other newly-defined parameters since very likely the
usage will be dominated by such newer clients.
Note that on the respective Github discussion page [1], other issues have
also been listed for using the ‘codecs’ parameter to indicate the
encryption mode. They are:
* The protection scheme is more related to the container than the codec.
So, it should not be signaled as a part of the ‘codecs’ parameter.
* Codec strings are currently container-independent, and the same string
can be used with multiple containers. However, the protection scheme is not
container-independent and this complicates the decoder APIs.
* Codec strings are more likely to be passed around into deeper layers of a
system than container. Implementations would need to strip this prefix
before doing so.
* Strings for some codecs are already quite long.
While the above uses the encryption mode as the example, the same approach
equally applies to other media features. For example, a media could be HDR
or non-HDR, supports (or not) WCG, could be omnidirectional video, etc. One
should not signal these types of features in the ‘codecs’ parameter.

It is recommended that the MPEG community reaches an agreement on these
principles at this meeting and the work is coordinated between the IETF,
W3C and MPEG to implement the necessary changes as an update to RFC 6381.

3) References
[1] https://github.com/w3c/encrypted-media/issues/400#issue