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

[Randall Gellens <[e-mail]>]

At 4:41 PM +0200 10/1/04, Per Fröjdh (KI/EAB) wrote:

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

Thank you for the detailed review and discussion. 
Please see below for in-line responses.


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

This is the approach taken in the most recent 
revision of this document, a draft of which I am 
attaching.  Please see especially Section 3 ("The 
Codecs Parameter") for the updated text and ABNF.


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

If we go this route, I would think that the 
extended entries would be the responsibility of 
the owner of the MIME type.  An initial list of 
such could be included in the document for types 
in its initial scope.


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

This could also be a workable solution, but we 
would need to be careful to list all needed 
entries.  Do any of the others on the 
distribution list have comments on these 
approaches?


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

Certainly that is not the intent.  The goal is to 
allow Internet-connected hosts which may receive, 
relay, or process files containing "bucket" MIME 
types to determine if all required codecs are 
present in the target resource without needing to 
parse the media itself.  The draft does attempt 
to make this clear, but of course suggestions for 
improved working are always welcome.

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

The intent here is to be able to specify the 
codecs that are required.  In the example you 
cite, I'd be inclined to leave it up to the 
originator of the media to determine if a 
particular codec should be listed or not, that 
is, to determine how essential a given codec is.

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

If this would be helpful to the underlying goal 
I'd be happy to assist in such efforts.

>
>
>  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]
>
>
>
>
>


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Democracy is a form of government that substitutes election by the
incompetent many for appointment by the corrupt few.
                                                      --G. B. Shaw

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