jiebi/CodeConvo huggingface dataset:
Code change:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Related discussion:
text: the dependencies is assumed to match that of the track declaring the dependencies. <del> 3.2.18. </del> <ins> 3.2.19. </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.19. </del> <ins> 3.2.20. </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.20. </del> <ins> 3.2.21. </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.21. </del> <ins> 3.2.22. </ins> A string defining the mime type MIME of the track.  This parameter is typically supplied with CMAF packaged content. <del> 3.2.22. </del> <ins> 3.2.23. </ins> A number defining the framerate of the track, expressed as frames per second. <del> 3.2.23. </del> <ins> 3.2.24. </ins> A number defining the bitrate of track, expressed in bits second. <del> 3.2.24. </del> <ins> 3.2.25. </ins> A number expressing the encoded width of the track content in pixels. <del> 3.2.25. </del> <ins> 3.2.26. </ins> A number expressing the encoded height of the video frames in pixels. <del> 3.2.26. </del> <ins> 3.2.27. </ins> The number of audio frame samples per second.  This property SHOULD only accompany audio codecs. <del> 3.2.27. </del> <ins> 3.2.28. </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.28. </del> <ins> 3.2.29. </ins> A number expressing the intended display width of the track content in pixels. <del> 3.2.29. </del> <ins> 3.2.30. </ins> A number expressing the intended display height of the track content in pixels. <del> 3.2.30. </del> <ins> 3.2.31. </ins> A string defining the dominant language of the track.  The string MUST be one of the standard Tags for Identifying Languages as defined
Code change:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Related discussion:
text: This example shows catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track.  In <del> this example the namesapce is absent, which infers that each track must inherit the namespace of the catalog. </del> <ins> this example the namespace is absent, which infers that each track must inherit the namespace of the catalog.  Additionally this example shows the presence of the supportsDeltaUpdates flag. </ins> 3.4.3.
Code change:
by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.

Related discussion:
text: This example shows the catalog for a media producer that is outputting two streaming formats simultaneously under different namespaces.  Note that each track name referenced points at another <del> catalog object. </del> <ins> catalog object and that only the first catalog supports incremental delta updates. </ins> 4.
Code change:
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:

Related discussion:
text: 'RC' - the field may be located in either the Root or a Catalog object. <del> 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object. </del> <ins> 'TFC' - the field may be located in either a Track object, the Common Track Fields object or a Catalog object. </ins> <del> 'TC' - the field may be located in either a Track object or a Catalog object. </del> <ins> 'TF' - the field may be located in either a Track object or a Common Track Fields object </ins> <del> 'RT' - the field may be located in either the Root or a Track object. 'T' - the field is located in a Track object. </del> <ins> 'T' - the field is located in a Track object </ins> 'S' - the field is located in the Selection Parameters object.
Code change:
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:

Related discussion:
text: 3.2.4. <ins> An object holding a collection of Track Fields (objects with a location of TF or TFC in table 1) which are to be inherited by all tracks.  A field defined at the Track object level always supercedes any value inherited from the Common Track Fields object. 3.2.5. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.5. </del> <ins> 3.2.6. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.6. </del> <ins> 3.2.7. </ins> A catalog object is a collection of fields whose location is <del> specified as 'RC', 'TC' or 'RTC' in Table 1. </del> <ins> specified as 'RC' or 'TFC' in Table 1. </ins> <del> 3.2.7. </del> <ins> 3.2.8. </ins> A track object is a collection of fields whose location is specified <del> as 'RT', 'TC' or 'RTC' in Table 1. </del> <ins> as 'TFC', 'TF' or 'T' in Table 1. </ins> <del> 3.2.8. </del> <ins> 3.2.9. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root
Code change:
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:

Related discussion:
text: optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. <del> 3.2.9. </del> <ins> 3.2.10. </ins> A string defining the name of the track.  See section 2.3 of MoQTransport.  Within the catalog, track names MUST be unique per namespace. <del> 3.2.10. </del> <ins> 3.2.11. </ins> A string defining the type of payload encapsulation.  Allowed values are strings as defined in Table 2. Table 2: Allowed packaging values <del> 3.2.11. </del> <ins> 3.2.12. </ins> Each track description can specify an optional operation value that identifies the catalog producer's intent.  Track operation is an
Code change:
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:

Related discussion:
text: The default track operation is 'add'.  This value does not need to be declared in the track object. <del> 3.2.12. </del> <ins> 3.2.13. </ins> A string defining a human-readable label for the track.  Examples might be "Overhead camera view" or "Deutscher Kommentar".  Note that the JSON spec requires UTF-8 support by decoders. <del> 3.2.13. </del> <ins> 3.2.14. </ins> An integer specifying a group of tracks which are designed to be rendered together.  Tracks with the same group number SHOULD be
Code change:
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:

Related discussion:
text: accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.14. </del> <ins> 3.2.15. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,
Code change:
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:

Related discussion:
text: be a set video tracks of the same content offered in alternate bitrates. <del> 3.2.15. </del> <ins> 3.2.16. </ins> A string holding Base64 BASE64 encoded initialization data for the track. <del> 3.2.16. </del> <ins> 3.2.17. </ins> A string specifying the track name of another track which holds initialization data for the current track.  Initialization tracks
Code change:
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:

Related discussion:
text: only via the initialization track field of the track which they initialize. <del> 3.2.17. </del> <ins> 3.2.18. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection
Code change:
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:

Related discussion:
text: declaration of a selection parameter at the track level overrides the inherited root value. <del> 3.2.18. </del> <ins> 3.2.19. </ins> Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is
Code change:
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:

Related discussion:
text: This example shows catalog for a sports broadcast sending time- aligned audio and video tracks using CMAF packaging.  Init segments <del> are delivered as inband data. </del> <ins> are delivered as inband data.  The data has been truncated for clarity. </ins> 3.4.10.