[AVT] Comments on the codecs parameter for bucket media types (file for mats)

[Per Fröjdh (KI/EAB) <[e-mail]>]

Dear all,

We at Ericsson have reviewed the Internet Draft ´The Codecs Parameter for "Bucket" Media Types´
http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-00.txt
and identified some issues.

The ID addresses the need to specify codecs contained in a "bucket" file by adding a parameter to its MIME type (which by itself gives no details on which codecs the file contains). However, the information conveyed in the proposed codec parameter is currently limited and gives the (false) impression that it would provide a client enough details to decide whether it can render the content of the corresponding file.

Our major concerns are the following:

1) Scope of the ID

The ID states generally that it targets bucket media types, but the design is only explicit for file formats that are based on the ISO Base Media File Format (including the MP4, 3GP and 3G2 file formats). The values of the codec parameters only mention such code points (as registered by the MP4 registration authority) and it is not clear how this would apply to any other file formats or bucket media types.

One option to resolve the issue would be to explicitly state that the ID is only intended for file formats in the "ISO family". However, some work would still be needed to serve this purpose (see below). 

A better alternative would be to address bucket media types in general, but then remove ISO specific details and make a general framework that can be used for all files (bucket media types). Such a framework could specify the general syntax of the codecs parameter. Each media type that would use the parameter would then define the semantics (list entries) that are applicable to that particular media type. 


2) Incomplete differentiation of codecs

The codecs parameter takes MP4 code points (sample entry character codes) as its main values to identify codecs. The main problem with this is that it does not provide a sufficent description of the codec:
 
	a) For codecs that use the MP4 file format entries (mp4v and mp4a) the proposal includes an MPEG-4 systems object type indication to further specify the codec. However, it is still not clear how to distinguish AAC-LC from AAC-LTP (both used by 3GPP) as this information is carried by the Audio object type in the decoder specific information (and not by the MPEG-4 systems object type). Similar problems may arise for ACCplus or Enhanced AACplus(?). 

	b) For codecs that are not signalled using MPEG-4 systems object type there are also problems. 3GPP uses both H.263 Profile 0 (Baseline) and H.263 Profile 3, but these codecs cannot be distinguished by the MP4 code point (s263). A quick solution may be to define extended list entries, e.g., s263.P0 and s263.P3, but considerable care must then be taken to cover all cases and codecs that may be interesting. Keeping track of such entries would also be outside the scope of the MP4 registration authority.

Instead of using the MP4 code points (and define extensions that would cover the information not carried by them) it would be straightforward to define the relevant entries for a given bucket media type. The owner of the media type would then naturally serve as the "registration authority" for its entries. 3GPP can keep a list of the relevant entries for 3GP files and 3GPP2 one for 3G2 files. Also profiles and levels can be included in the list of such entries.


3) Codecs information not enough

One "risk" of introducing the codecs parameter is that it may be perceived as the only description of the file. The ID states that it "adds a parameter to allow unambiguous specification of the codecs required to render the content in a media element". However, even if the codec information is made more detailed, it is still possible that some codecs may be required whereas some may be optionally used. This and other aspects of a file in the ISO family is currently carried by the file type box of a file. By only singling out codecs, we don't think you get an adequate descripton of the file. 

The file type box of an ISO file includes a major brand ("best use") and compatible brands. It may tell you that a file is "best" played by a 3GPP release-5 terminal, although it is compatible with release-4 terminals. This may be the case if the content creator included timed text (introduced in release 5), but does not require terminals to display the text. Hence, if a file contains a codec, it's not always required that the receiving terminal supports it.

If the codecs parameter is introduced, in one form or another, it should be made clear that it only gives partial information of the requirements of an end device. One option to make the description more complete for an ISO file would be to "lift" the file type information into a second MIME parameter for brand and compatible brands, although this would imply some level of redundancy.


In summary,

a) the details specified for files in the ISO family (MP4, 3GP, 3G2, etc) are not enough for differentiating codecs;
b) we propose to have a general syntax for the bucket parameter defined in IETF, but keep the details to each organisation defining a file format that would use this parameter.

Best regards,

Per Fröjdh, editor of the 3GPP file format (3GPP TS 26.244)

----------------------------------------------------------------
Per Fröjdh, Ph.D.                              Tel [phone]
Ericsson Research, Multimedia Technologies     Mob [phone]




 




_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt