{" . "}

…Currently, we are constantly switching content from HLS to DASH and vice versa. The CMAF Hypothetical Application Model (HAM) provides a means to do this but there has been little player implementation of this aspect of the ISO standard which provides a hypothetical model but does not provide any reference code;

…Media player clients can convey information to Content Delivery Networks (CDNs) with each object request. This information can be useful in log analysis, QoS monitoring and delivery optimization. Session identification allows thousands of individual server log lines to be interpreted as a single user session, leading to a clearer picture of end-user quality of service. Bitrate, buffer and segment signaling allow CDNs to fine-tune and optimize their midgress traffic by intelligently reacting to the time constraints implicit in each request. Prefetch hints allow CDNs to have content ready at the edge ahead of the client request, improving delivery performance. Buffer starvation flags allow performance problems across a multi-CDN delivery surface to be identified in real-time. In combination, this transferred data should improve the quality of service offered by CDNs, which in turn will improve the quality of experience enjoyed by consumers;

…Adaptive streaming of segmented media is enabled by media players requesting media objects from servers. These servers are arranged in a hierarchy starting with the origin server, which holds the authoritative copy of the content requested by user agents and other servers. Outbound [RFC9110] responses traverse a series of mid-tier and edge intermediaries, known collectively as Content Distribution Networks (CDNs). These CDNs may themselves be stacked. The edge servers are the outermost servers. Edge servers are the first intermediaries to receive user-agent requests, in a given request/response flow, and the last intermediary to forward a response when communicating with media players. The origin servers know information about the media object which the CDN servers do not. For example, they may know the format, the duration and the encoded bitrate of a media object. In the case of live streams, they may know for how long the object has been available and the likely next object in the sequence. The edge servers in turn know information unavailable to the origin or players. For example, they may know the throughput available in the next network hop, or the cache status of the various objects or the accumulated history of the media object as it was moved from origin to edge server. The purpose of the Common Media Server Data (CMSD) specification is to define a standard means by which every media server (intermediate and origin) can communicate data with each media object response and have it received and processed consistently by every intermediary and player, for the purpose of improving the efficiency and performance of distribution and ultimately the quality of experience enjoyed by the users;

…CEA-608-D is a technical standard and guide for using or providing Closed Captioning services or other data services embedded in line 21 of the vertical blanking interval of the NTSC video signal. This includes provision for encoding equipment and/or decoding equipment to produce such material as well as manufacturers of television receivers which are required to include such decoders in their equipment as a matter of regulation. It is also a usage guide for producing material using such equipment, and for distributing such material. This standard describes the specifications for creation, transmission, reception, and display of caption data, plus the relationship of Caption Mode data to other line 21 data;

…ID3v2 is a general tagging format for audio, which makes it possible to store meta data about the audio inside the audio file itself. The ID3 tag described in this document is mainly targeted at files encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may work with other types of encoded audio or as a stand alone format for audio meta data. ID3v2 is designed to be as flexible and expandable as possible to meet new meta information needs that might arise. To achieve that ID3v2 is constructed as a container for several information blocks, called frames, whose format need not be known to the software that encounters them. At the start of every frame is an unique and predefined identifier, a size descriptor that allows software to skip unknown frames and a flags field. The flags describes encoding details and if the frame should remain in the tag, should it be unknown to the software, if the file is altered;