jiebi/CodeConvo huggingface dataset:
Each catalog update MUST be mapped to a discreet moq-transport object. <del> 4.1. Object Delivery Order MUST match the Object sequence number. The media object payload: MUST consist of a Segment Type Box (styp) followed by any number of media fragments.  Each media fragment consists of a Movie Fragment Box (moof) followed by a Media Data Box (mdat).  The Media Fragment Box (moof) MUST contain a Movie Fragment Header Box (mfhd) and Track Box (trak) with a Track ID ("track_ID") matching a Track Box in the initialization fragment. MUST contain a single ISOBMFF track. MUST contain media content encoded in decode order.  This implies an increasing decoding time stamp (DTS). MAY contain any number of frames/samples. MAY have gaps between frames/samples. MAY overlap with other objects.  This means timestamps may be interleaved between objects. Two options are RECOMMENDED for packaging CMAF content into WARP media objects: the first is to package a complete CMAF Fragment (see CMAF sect 6.6.1) into a single object within each group.  This results in there being a single GOP (Group of Pictures) in the media object and a single media object per group. The second is to package a CMAF chunk (see CMAF sect 6.6.5), in which the mdat holds a single frame of video, or sample of audio, into each object and to assign a unique group ID to each fragment. This approach is RECOMMENDED to minimize latency. </del> 5. <del> A WARP publisher MUST publish a catalog track object before publishing any media track objects. At the completion of a session, a publisher should publish a catalog object with track count of 0.  This SHOULD be interpreted by receivers that the publish session is complete. </del> <ins> The MOQT Groups and MOQT Objects need to be mapped to moq-transport Streams.  Irrespective of the packagingmode in place, each MOQT Object MUST be mapped to a new moq-transport Stream. </ins> 6. <del> The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is the RECOMMENDED encryption method. </del> <ins> A WARP publisher MUST publish a catalog track object before publishing any media track objects. </ins> <del> ToDo - details of how keys are exchanged and license servers signalled. </del> <ins> At the completion of a session, a publisher MUST publish a catalog update that removes all currently active tracks.  This action SHOULD be interpreted by receivers to mean that the publish session is complete. </ins> 7.
6. <ins> The timeline track provides data about the previously published groups and their relationship to wallclock time, media time and associated timed-metadata.  Timeline tracks allow players to seek to precise points behind the live head in a live broadcast, or for random access in a VOD asset.  A timeline track may also be used to insert events at media times which do not correlate with Object boundaries.  Timeline tracks are optional.  Multiple timeline tracks MAY exist inside a catalog. 6.1. The payload of a timeline track is a UTF-8 encoded CSV text file. This payload is formatted according to RFC4180 "Common Format and MIME Type for Comma-Separated Values (CSV)" Files RFC4180.  The separator is a comma and each line is separated by a carriage return. The mime-type of a timeline track MUST be specified as "text/csv" in the catalog. Each timeline track begins with a header row of MEDIA_PTS,GROUP_ID,OBJECT_ID,WALLCLOCK,METADATA.  This row defines the 5 columns of data within each record. MEDIA_PTS: a media timestamp rounded to the nearest millisecond. This entry MUST not be empty.  If the Object ID entry is present, then this value MUST match the media presentation timestamp of the first media sample in the referenced Object. GROUP_ID: the MOQT Group ID.  This entry MAY be empty. OBJECT_ID: the MOQT Object ID.  This entry MAY be empty. WALLCLOCK: the wallclock time at which the media was encoded, expressed as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT).  For VOD assets, or if the wallclock time is not known, the value SHOULD be 0. METADATA: a flexible field holding arbitrary string metadata. This field may be empty.  If not empty, it MUST be enclosed in double quotes.  A double-quote appearing inside this field MUST be escaped by preceding it with another double quote. 6.2. A timeline track MUST carry a 'type' identifier in the Catalog with a value of "timeline".  A timeline track MUST carry a 'dependencies' attribute which contains an array of all track names to which the timeline track applies. 6.3. The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group.  The publisher MAY publish incremental updates in the second and subsequent Objects within each GROUP. Incremental updates only contain timeline events since the last timeline Object.  Group duration SHOULD not exceed 30 seconds. 7. </ins> A WARP publisher MUST publish a catalog track object before publishing any media track objects.
1. WARP Streaming Format (WARP) is a media format designed to deliver <del> CMAF CMAF compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages a simple prioritization strategy of assigning newer content a higher delivery order, allowing intermediaries to drop older data, and video over audio, in the face of congestion.  Either complete Groups of Pictures (GOPS) ISOBMFF or individual frames are mapped to MoQTransport Objects.  WARP is targeted at interactive levels of live latency. </del> <ins> CMAF CMAF and LOC LOC compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages the Common Catalog Format COMMON-CATALOG-FORMAT to describe the output of the original publisher.  WARP specifies how content should be packaged and signaled, defines how the catalog communicates the content, specifies prioritization strategies for real-time and workflows for beginning and terminating broadcasts.  WARP also details how end-subscribers may perform adaptive bitrate switching. WARP is targeted at real-time and interactive levels of live latency. </ins> This document describes version 1 of the streaming format.
3. <del> WARP delivers CMAF-packaged media bitstreams.  This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to consumers which object mapping mode is being used for a given Track, a new track field is defined as per table 1. </del> <ins> WARP delivers CMAF CMAF and LOC LOC packaged media bitstreams. Either format may be used in a broadcast, or they may be intermixed between tracks.  The packaging format of a track, once declared, MUST remain constant. </ins> 3.1. <del> The packaging mode value is defined by Table 2. </del> <ins> This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to clients which object mapping mode is being used for a given Track, the catalog "packaging" field MUST use one of the values defined in Table 1.  The values are case-sensitive. Table 1 provides values for the catalog "packaging" field with CMAF packaging. </ins> 3.2. <ins> This specification references Low Overhead Container (LOC) LOC to define how audio and video content is packaged.  With this packaging mode, each EncodedAudioChunk or EncodedVideoChunk sample is placed in a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. Table 2 provides values for the catalog "packaging" field with LOC packaging. 3.3. </ins> WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements:
able to cleanly switch between time-aligned media tracks at group boundaries. <del> 3.3. </del> <ins> 3.4. </ins> The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is <del> the RECOMMENDED encryption method. </del> <ins> the RECOMMENDED encryption method for CMAF packaged content. </ins> ToDo - details of how keys are exchanged and license servers signaled.  May be best to extend catalog spec to allow the specification of content protection schema, along with any pssh or protection initialization data. <ins> ToDo - content protection for LOC-packaged content. </ins> 4. WARP uses the Common Catalog Format {[COMMON-CATALOG-FORMAT}} to
catalog object SHOULD only be published only when the availability of tracks changes. <del> Each catalog update MUST be mapped to a discreet moq-transport object. </del> <ins> Each catalog update MUST be mapped to a discreet MOQT Object. </ins> 5. <del> The MOQT Groups and MOQT Objects need to be mapped to moq-transport Streams.  Irrespective of the packagingmode in place, each MOQT Object MUST be mapped to a new moq-transport Stream. </del> <ins> The MOQT Groups and MOQT Objects need to be mapped to MOQT Streams. Irrespective of the mediapackaging in place, each MOQT Object MUST be mapped to a new MOQT Stream. </ins> 6.
a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. <del> Table 2 provides values for the catalog "packaging" field with LOC packaging. </del> <ins> When LOC packaging is used for a track, the catalog packaging attribute (packaging) MUST be present and it MUST be populated with a value of "loc". </ins> 3.2.
publishers for advertising their output and for subscribers in consuming that output.  The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted.  The Catalog provides the <del> names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </del> <ins> names and namespaces of the tracks being produced, along with therelationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </ins> The catalog track MUST have a case-sensitive Track Name of "catalog".
Location: R Required: Optional JSON Type: Boolean <del> A boolean that if true indicates that the publisher MAY issue </del> <ins> A Boolean that if true indicates that the publisher MAY issue </ins> incremental (delta) updates - see patch.  If false or absent, then <del> the publisher gaurantees that they will NOT issue any incremental </del> <ins> the publisher guarantees that they will NOT issue any incremental </ins> updates and that any future updates to the catalog will be independent.  The default value is false.  This field MUST be present if its value is true, but may be omitted if the value is false.
the catalog. Each timeline track begins with a header row of <del> MEDIA_PTS,GROUP_ID,OBJECT_ID,WALLCLOCK,METADATA.  This row defines </del> <ins> MEDIA_PTS,GROUP_ID,OBJECT_ID, WALLCLOCK,METADATA.  This row defines </ins> the 5 columns of data within each record. MEDIA_PTS: a media timestamp rounded to the nearest millisecond.