Code change:
the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.19. </del> <ins> 3.2.20. </ins> A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing with higher temporal fidelity. <del> 3.2.20. </del> <ins> 3.2.21. </ins> A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing with higher fidelity. <del> 3.2.21. </del> <ins> 3.2.22. </ins> A string defining the codec used to encode the track.  For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of WEBCODECS-CODEC-REGISTRY.  For CMAF packaged content, the string codec registrations are defined in XXX. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.27. </del> <ins> 3.2.28. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.28. </del> <ins> 3.2.29. </ins> A string specifying the audio channel configuration.  This property SHOULD only accompany audio codecs.  A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.31. </del> <ins> 3.2.32. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example: