WATERMARKING VIDEO FRAGMENTS INTO TWO OR MORE VARIANTS

Abstract

A method of processing a video fragment into two or more variants of the video fragment, each variant having a different watermark, the method comprising: fragmenting a video content into a sequence of fragments; watermarking a plurality of the fragments to create two or more variants of each of the plurality of fragments, wherein the two or more variants of one fragment are watermarked using different watermarks; adjusting the length of the two or more variants for at least one of the fragments to a same adjusted length, wherein the adjusted length is indicative of a temporal position of the two or more variants of the at least one of the fragments compared to variants of other fragments in the sequence of fragments.

Claims

1. A method of processing a video fragment (f.sub.1 . . . f.sub.4) into two or more variants (V.sub.A, V.sub.B) of the video fragment, the method comprising: fragmenting (101) a video content (10) into a sequence of fragments; watermarking (102) a plurality of the fragments to create two or more variants of each of the plurality of fragments, wherein the two or more variants of one fragment are watermarked using different watermarks; adjusting (104) the length of the two or more variants for at least one of the fragments to a same adjusted length, wherein the adjusted length is indicative of a temporal position of the two or more variants of the at least one of the fragments compared to variants of other fragments in the sequence of fragments.

2. The method according to claim 1, wherein the adjusting of the length comprises adding padding data to one or more of the variants of the at least one of the fragments.

3. The method according to claim 1 or 2, further comprising equalizing the length of the two or more variants for each of the fragments before adjusting the length.

4. The method according to claim 3, wherein the equalizing of the length comprises adding padding data to one or more of the variants.

5. The method according to any one of the preceding claims, wherein the adjusting of the length results in the length of the variants of the at least one of the fragments to be larger than the length of the variants of a preceding fragment in the sequence of fragments.

6. The method according to claim 5, wherein the length of the variants of the at least one of the fragments is a predefined number of data units, e.g. one data unit, larger than the length of the variants of the preceding fragment in the sequence of fragments, wherein the data unit is preferably a byte.

7. The method according to any one of the preceding claims, wherein the same or related watermarks as used for watermarking the variants of one fragment are used for watermarking the variants of other fragments.

8. The method according to any one of the preceding claims, wherein the temporal position is defined as a position within a limited number of possible positions that is repeated in time, and wherein the adjusted length reflects the position of a variant having the adjusted length within the limited number of possible positions.

9. The method according to claim 8, wherein the temporal position of the variant is derivable from the length of said variant modulo the limited number of possible positions.

10. The method according to any one of the claims, wherein the watermarking is an A/B watermarking for ABR video content.

11. The method according to any one of the claims, wherein the temporal position of one or more of the two or more variants is derivable from an offset of a variant.

12. A method for selecting variants (V.sub.A, V.sub.B) of video fragments (f.sub.1 . . . f.sub.4) for delivery to a requestor, the method comprising: receiving (201) a request for all or a part of a video content that has been fragmented into a sequence of fragments, wherein a plurality of the fragments has been watermarked to create two or more variants of each of the plurality of the fragments according to any one of the claims 1-11; determining (202) a temporal position of the two or more variants of a fragment compared to variants of other fragments in the sequence of fragments; selecting (203) for each of the plurality of the fragments one variant from the two or more variants based on the determined temporal position and an identifier of the requestor, wherein the identifier defines which of the two or more variants to select for each fragment based on the temporal position.

13. The method according to claim 12, wherein the temporal position is defined as a position within a limited number of possible positions that is repeated in time, and wherein the temporal position is determined from the length of the variants modulo the limited number of possible positions.

14. The method according to claim 12 or 13, wherein the request is received in the form of a byte-range request.

15. The method according to any one of the claims 12-14, further comprising detecting an out of bounds request indicative of the request being made to incorrect or non-existing variants.

16. The method according to any one of the claims 12-15, wherein the determining of the temporal position is further based on an offset of one or more of the two or more variants.

17. The method according to claim 16, wherein the offset is received with the request.

18. The method according to any one of the claims 12-17, wherein the determining of the temporal position is further based on a secret.

19. A variant preprocessor module configured to perform the method according to any one of the claims 1-11.

20. A head-end system comprising a variant preprocessor module according to claim 19.

21. A watermark embedder module configured to perform the method according to any one of the claims 12-18.

22. A CDN server comprising a watermark embedder module according to claim 21.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0049] Embodiments will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbols indicate corresponding parts, and in which:

[0050] FIG. 1 shows a system architecture including inputs and outputs of system components according to an exemplary embodiment of this disclosure;

[0051] FIG. 2 shows a flow diagram of a method according to an exemplary embodiment of this disclosure;

[0052] FIG. 3 shows a flow diagram of a method according to another exemplary embodiment of this disclosure; and

[0053] FIG. 4 shows an exemplary byte-range padding example for generating and selecting variants of fragments of a video content according to an exemplary embodiment of this disclosure.

[0054] The figures are meant for illustrative purposes only, and do not serve as restriction of the scope or the protection as laid down by the claims.

DESCRIPTION OF EMBODIMENTS

[0055] The following examples are based on two-step watermarking in the form of A/B watermarking for ABR video content. It will be understood that this disclosure is not limited to this example and may be applied to any video content that is fragmented and watermarked into variants. Also, the disclosure is not limited to two variants per fragment as in A/B watermarking, but any number of variants may be generated and used.

[0056] With A/B watermarking a variant has the same size as the video segments used by the delivery network and there are two variants per video segment, version A and version B. The client device can use playlist manipulation or segment selection at the (CDN) edge to only receive a collection of video segments encoded with its watermark identifier.

[0057] As shown in FIG. 1, the first step of a two-step watermarking may be a preprocessing step for computing sets of variants for an input video content 10. The first step is typically performed once per input video content 10. In this example, a variant preprocessor 1 takes the input frames 10, and transforms them into two intermediate versions. For one or more of the frames in the intermediate versions the length of the variants may be adjusted by processor 2, as will be explained in more detail below, to obtain two sets of variants 20, 21 with adjusted lengths, which allows for fast embedding at a later stage by selecting which version is used for actual play-out. The variant preprocessor 1 and the processor 2 may be implemented as two separate apparatus, may be integrated into a single apparatus, or may be one and the same processor configured to perform both tasks.

[0058] Both versions 20, 21 are typically visually identical, but they differ in a subtle manner due to watermark insertion. In the first step, the watermark preprocessor 1 may provide variants of the baseband content to a video encoder. The resulting sets of variants 20, 21 are typically encoded and packetized in a relevant container for transport.

[0059] In FIG. 1 a first set of variants 20 includes four variants f.sub.1V.sub.A . . . f.sub.4V.sub.A and a second set of variants 21 includes four variants f.sub.1V.sub.B . . . f.sub.4V.sub.B. Herein, f1 . . . f4 indicate four frames that have been watermarked to obtain a variant of the frames. V.sub.A and V.sub.B indicate a variant A and a variant B of the respective frame. The length of the variants have been adjusted to allow a temporal position of the variant in a stream of fragments to be determined at a later stage.

[0060] Variants may be generated by analyzing the video content, typically frame-by-frame, either in the baseband domain (prior to encoding) or in the encoded domain (post encoding). The variants may be pre-watermarked variations of segments (i.e., chunks or fragments) of the video bitstream that can be used interchangeably without affecting the viewing experience while still providing means to perform forensic watermarking. The length of a variant may differ between watermarking suppliers, ranging from a couple of bytes to a whole video segment in Adaptive Bit Rate (ABR) video networks.

[0061] In the first step of the two-step watermarking, a watermark algorithm may define basic properties of a watermarking system. Depending on the application area, an algorithm may e.g. be tailored to support short fragment lengths or tuned to carry large payloads. As a consequence, different algorithms are typically not directly compatible with each other, requiring all components of the watermarking system to use the same algorithm.

[0062] The second step of the two-step watermarking may be responsible for creating a serialized video bitstream 30, 31 that uniquely identifies the recipient to whom it is delivered. The second step is typically implemented by a watermark embedder 3 that has access to a watermark identifier that is used to generate a unique variant sequence 30, 31, by selecting for each set of variants 20, 21 a single variant. This variant sequence 30, 31 is part of the final forensically watermarked video content that may comprise unaltered segments of video. This operation can be performed in transit (e.g., in a network edge) or in the client device (e.g., during playback or PVR recording).

[0063] With A/B watermarking, the embedder is rewriting the fragment requests from a requestor to provide back the A or B version of the requested fragment. One version of fragment (A or B) may be selected based on fragment start time and the unique ID value that is to be inserted in the watermark. This start time is typically part of the fragment filename, for example in case of DASH timeline, but when using byte-range requests, this byte-range needs to be translated to a fragment start time. The same can also be applied to HLS when respecting the file naming or byte-range translate approach.

[0064] The watermark embedding (second step) process may be performed by a Variant Sequence Generator (VSG) that selects for each fragment f.sub.1 . . . f.sub.4 a single variant V.sub.A or V.sub.B from each set of variants 20, 21 and thus produces a variant sequence that encodes the desired watermark identifier, and a watermark embedder (EMB) that applies the selected variant to the compressed video bitstream in order to obtain a Variant sequence 30, 31, which is a video watermarked with a unique identifier. In the example of FIG. 1 the video sequence 30 may be generated for a first end user and includes the following unique watermarks for fragments f.sub.1 to f.sub.4: ABAB. The video sequence 31 may be generated for a second end user and includes the following unique watermarks for fragments f.sub.1 to f.sub.4: ABBA.

[0065] If the variant data is applied in independent encryption blocks, they may be applied in the encrypted domain without knowledge of the decryption key.

[0066] The VSG receives set of variants in a relevant container. Based on the watermark identifier, it produces a sequence of variants, and the EMB applies them to the bitstream to generate a watermarked video. This sequence can be decoded for rendering, stored for later use (PVR), or forwarded further along the transmission pipeline.

[0067] The second step may be implemented at the head-end, like the origin server in an OTT scenario. All segment requests are escalated to the origin server that is then in charge of producing a serialized segment containing a unique sequence of variants that encodes part of the watermark identifier associated to the entity querying the segment. In A/B watermarking, it amounts to returning either version A or version B of the requested segment. In such an integration, all segment requests reach the origin server so there is no cache. While it precludes large scale deployments, such integration may be appropriate in some low volume cases such as screeners, hospitality window, or mezzanine content distribution.

[0068] The second step may be implemented at the client device. In this case variant metadata may travel along with the video from the head-end down to the device. To keep control over the bandwidth overhead, such integration usually requires having variants of the finest possible granularity. When the serialization process operates on the cleartext encoded bitstream, its integration within a Trusted Execution Environment (TEE) may be recommended for security reasons. Alternately, the different variants may be encrypted with different keys and each device provisioned with a unique set of keys that provide access to a unique Sequence of variants. Such crypto-binding of the access to variants has been standardized for ISO BMFF and for Blu-ray discs.

[0069] The second step is preferably implemented as ABR segment selection on the edge. A/B segment selection is when the selection is performed between prepared segments of A/B variants just in time for each client segment request. Here, the serialization step of a two-step watermarking system is performed in the edge servers. The video delivery system needs to deliver a unique sequence of A and B segments to every individual. This can be achieved by making the edge servers select either A or B version of the segment to be returned when they receive a segment request. When the version of the segment, i.e. the variant, has been selected, the edge server can then query the cache possibly to the origin server which delivers it to the recipient.

[0070] ABR segment selection on the edge may be required in cases where byte-range indexed playlists are used, or the playlist is templated (such as with Smooth Streaming and DASH VoD profiles) and segments cannot be addressed individually. The serialization effort during playlist delivery is eliminated and the same playlist can be used for all streams. However, the edge needs to apply logic to decide for each requested segment. This logic includes identification of the information to be embedded, a decision for segment selection, and the delivery of the corresponding segment. The fact that all recipients receive the same playlist provides an extra layer of security against comparison and manipulation of playlists before the content is downloaded. It is recommended to make use of https-based segment URIs or other strategies to avoid local ISPs from further caching the seemingly “common” content segments after they leave the CDN edge, thus destroying the A/B serialization pattern.

[0071] Some edge servers can perform late repacketization operations on the segment content itself. This allows for segments to not only be selected on the edge allowing choice between A/B, but preceding assembly of these segments even after they have been requested. The idea is to use a single video transport protocol between the origin server and edge servers to optimize caching capabilities and perform repacketization operations (container and scrambling) at the edge to deliver segments in the desired format. Such repacketization implies that the encoded video buffers are available in cleartext at some point. For two-step watermarking systems that use variants at a finer granularity than the whole segment, it provides an opportunity to perform the serialization step at the edge. In this case, the transmission of variants metadata alongside the video can be significantly lower than the ratio inherent to A/B watermarking where storage is doubled, and cache is doubled for A/B segments. This approach is not limited to ABR, it can apply to any progressive download and employs. a common playlist for all subscribers.

[0072] As not all CDN providers support outgoing requests to be processed on their CDN edge server, it is not always possible to access an external mapping table while processing a fragment request. Such mapping table is normally used to map a byte-range request to time to enable the selection of the correct variants to be delivered to the requestor. Without access to the mapping table on the CDN edge server, the watermark decision cannot be computed, as the byte-range cannot be linked to time.

[0073] To enable a byte-range request to be processed without a mapping table, the temporal information indicating the position of a variant in time is encoded in the length of the variants. Hereto the known two-step watermarking is modified and improved as follows.

[0074] In the content preparation step, i.e. the first step, padding is applied to the variants of the fragments to encode “time” information corresponding to each fragment. After the padding, the variants of a fragment have the same adjusted length, wherein the length can be used to derive the temporal position of the variants compared to variants of other fragments. Optionally, padding may be applied to the video content such that all watermark variants of a fragment have the same size before adjusting the length to encode the temporal information.

[0075] In the watermarking step, i.e. second step, for each virtual fragment request the byte-range information may be used to compute the fragment size of the variants in the byte-range. Based on this fragment size of the variants the “time information” may extracted.

[0076] Thus, the necessity of having a lookup table to relate byte positions to time is avoided.

[0077] It will be understood that instead of using the size of a variant in the byte-range request, the fragment start positions or offsets could be used to obtain the temporal information, as the start position or offset depends on the length of the variants.

[0078] The time information encoded in the length of the variants by adding padding typically only needs to account for a limited number of ‘watermark symbols’. In the specific case of watermarking, a message may be constructed of a sequence of watermark symbols of length N that is repeated over time. Therefore, the padding added can be minimized as only a small number of ‘watermark symbols’ need to be encoded.

[0079] FIG. 2 shows an exemplary embodiment of a method of processing video fragments, such as f.sub.1 . . . f.sub.4, into two or more variants, such as V.sub.A and V.sub.B, of the video fragment, each variant having a different watermark. In step 101 a video content 10 is fragmented into a sequence of fragments. In step 102 a plurality of the fragments f.sub.1 . . . f.sub.4 is watermarked to create two or more variants of each of the plurality of fragments, wherein the two or more variants of one fragment are watermarked using different watermarks. Step 103 indicates that the watermarking 102 may be repeated for each fragment f.sub.1 . . . f.sub.4 that is to be watermarked to create the sets of variants of the fragments. In step 104 the length of the two or more variants is adjusted for at least one of the fragments to a same adjusted length. For example, for a first fragment f.sub.1 the length of the two variants V.sub.A and V.sub.B may be adjusted to have the same length. Thus, f.sub.1V.sub.A and f.sub.1V.sub.B will have the same length. Typically, this is also done for the variants of the other fragments f.sub.2 . . . f.sub.4. Step 105 indicates that the adjusting 104 of the length may be repeated for the variants V.sub.A, V.sub.B of each fragment f.sub.1 . . . f.sub.4. The adjusted length may be indicative of a temporal position of the two or more variants of the at least one of the fragments compared to variants of other fragments in the sequence of fragments. Step 110 indicates the end of the process, wherein the sets 20, 21 of variants of the fragments after adjusting the lengths of the variants are obtained.

[0080] The result of the adjusting 104 of the length is for example as follows. The length of f.sub.2V.sub.A and f.sub.2V.sub.B (which are equal in length) may become one larger than f.sub.1V.sub.A and f.sub.1V.sub.B (which are equal in length). The length of f.sub.3V.sub.A and f.sub.3V.sub.B (which are equal in length) may become one larger than f.sub.2V.sub.A and f.sub.2V.sub.B (which are equal in length). And the length of f.sub.4V.sub.A and f.sub.4V.sub.B (which are equal in length) may become one larger than f.sub.3V.sub.A and f.sub.3V.sub.B (which are equal in length). Thus, the adjusted lengths of the variants may be used to derive a temporal position of the variant based on the length of a variant compared to the length of a previous variant. It will be understood that the present disclosure is not limited to this particular example of increasing the length of subsequent variants by 1, only having four fragments f.sub.1 . . . f.sub.4 and having two variants V.sub.A, V.sub.B for each fragment.

[0081] FIG. 3 shows an example of a method for selecting variants of video fragments for delivery to a requestor. In step 201 a request is received for all or a part of a video content that has been fragmented into a sequence of fragments, wherein a plurality of the fragments has been watermarked to create two or more variants of each of the plurality of the fragments according to the method shown in FIG. 2. In step 202 a temporal position is determined of the two or more variants of a fragment compared to variants of other fragments in the sequence of fragments. In step 203, for each of the plurality of the fragments, one variant is selected from the two or more variants based on the determined temporal position and an identifier of the requestor, wherein the identifier defines which of the two or more variants to select for each fragment based on the temporal position. Thus, for a particular end user a unique variant sequence 210, such as 30, 31, may be created.

[0082] FIG. 4 shows an example of A/B watermarking according to an exemplary embodiment of the present disclosure, wherein the watermark message to be generated for the byte-range request has a length of 32 symbols. In this example, the watermark message to be generated—and which may be and typically is repeated—equals “ABBBAABAABBBABABAABBBAAAAABABBBA”. Herein, the location of each of the symbols A and B can be derived as a symbol index 0 to 31, wherein e.g. the first “A” has a symbol index of 0 and the last “A” has a symbol index of 31.

[0083] The encoder output after fragmenting a video content into a sequence of fragments and A/B watermarking the fragments is shown in the leftmost table 41 of FIG. 4, wherein for eleven group of pictures fragments GOP#0 . . . GOP#10 the size of the A and B watermarked variants are shown. These variants are for example formatted as H.264 or HEVC fragments in an elementary stream (ES).

[0084] Initial alignment 301 of the A and B variants may be applied, the result of which is shown in the second table 42 of FIG. 4. Initial alignment 301 may be required to support switching at fragment boundaries between version A/B of a content using byte range requests. Also, the encoder output as shown in the leftmost table 41 of FIG. 4 is mostly different in size for the A and B variants due to differences in the applied watermark, e.g. 16393 bytes and 16235 bytes for GOP#0 with watermark A and watermark B, respectively. Padding may be applied to make A/B equal in size, e.g. 16393 bytes for GOP#0, such that a byte requests to access Fragment(N) uses the same ‘start-end’ byte-range for both A and B versions. The variants after the initial alignment may still be formatted as e.g. H.264 or HEVC fragments in an elementary stream (ES). The initial padding typically needs to remain present in the final container format used during OTT streaming, most commonly (fragmented) MP4 or TS.

[0085] The variants of the GOP fragments may be converted 302 from e.g. H264 or HEVC format into another container and packet format, e.g. a CMAF container format with MP4, fragmented MP4 or TS fragments. The result of this conversion is shown in the third table 43 of FIG. 4, wherein the group of pictures GOP#0 . . . GOP#10 have been converted into fragments Frag#0 . . . Frag#10, respectively, and e.g. the variants of Frag#0 have a length of 17051 bytes. The fragments Frag#0 . . . Frag#10 may be similar to the fragments f.sub.1 . . . f.sub.4 of the example of FIG. 1 and the variants may be similar to the variants V.sub.A and V.sub.B of the example of FIG. 1.

[0086] The fourth table 44 of FIG. 4 shows the result of encoding 303 the symbol index, as indicated in table 45, into the length of the variants. Additional padding may be applied to the fragments to encode positional information. The additional padding may be added equally to both A/B versions of the fragments to encode the temporal information. This enables positional information that could normally be obtained from the file name (index number or timestamp) and is unavailable in byte-range requests, to be encoded.

[0087] For example, to encode a symbol index for 32 positions, at most 31 bytes of padding would be needed when using the following modulo calculations: [0088] mod.sub.0(N)=size.sub.0(N) MODULO 32, wherein size.sub.0 is the size after initial alignment of a fragment N, e.g. as shown in the third table of FIG. 4; [0089] padding(N)=(32+SymbolIndex(N)−mod0(N)) MODULO 32; [0090] size.sub.1(N)=size.sub.0(N)+padding(N), wherein size.sub.1 is the size after additional padding of fragment N, e.g. as shown in the fourth table of FIG. 4.

[0091] Recovery of the positional information, e.g. at the CDN Edge, may be performed when receiving the byte-range request. The size of the request, carefully tuned by the padding earlier, may be used to determine the encoded position, i.e. symbol index, for a requested fragment N using the following modulo calculation: [0092] SymbolIndex(N)=size.sub.1(N) MODULO 32

[0093] For example, a byte range request may be received for Frag#3, which has a length of 19139 in the fourth table of FIG.4. The symbol index for this Frag#3 can be obtained by calculating 19139 MODULO 32, which results in a SymbolIndex=3. For the requestor requesting this byte range the watermark message was determined before to be “ABBBAABAABBBABABAABBBAAAAABABBBA”. At symbol index 3 of this watermark message the symbol B is indicated, thus the variant to be returned in response to the byte range request is the B variant of the MP4 fragment.

[0094] In the above examples fragment length (size in bytes) may indicate the temporal position of a fragment n. This may be formulated as the position of a fragment n being defined by a function of the length of the fragment n: position[n]=function(length[n]), where the function is for example a modulo M, resulting in the following formula in this example: position[n]=length[n] modulo M.

[0095] Some length values may be assigned to be invalid. For instance, the ones that map to positions larger than a maximum. Use of invalid length values, especially when requesting variants, may signal and error and may be logged. An error may be signaled for example if function(length[n])>MAX, where MAX is a predefined value known to be invalid. Such security measure may be used to detect invalid and potentially illegal attempts to obtain variants, e.g. by hackers.

[0096] When subsequent variants have equal lengths, a complete file may be requested when a single valid length value. For instance, if a first fragment is 12000 bytes in length which maps to first position, an attacker may ask the following byte-ranges: 0-12000, 12000-24000, 24000-36000, 36000-48000, and so on. As all lengths are the same and valid, these requests may be served as if it is the first fragment.

[0097] As a counter measure against requesting subsequent fragments using the same length value, the length of one or more variants may be varied by an offset of the variant to the lengths, effectively also changing the temporal positions. The position may then be represented as a function of the start-offset, length and optionally a secret (key): position[n]=function(length[n], offset[n], optional secret).

[0098] Some offset-length pairs (or corresponding position values) may be assigned to be invalid. For example, an error may be signaled and/or logged if “function(length[n], offset[n], optional secret)>MAX”, similar to the example above without using the offset. With such counter measure, the attack stated above is likely to fail.

[0099] When applying offsets, the first call will typically have offset 0, but the subsequent ones may have different offsets. A function(length[n], offset[n], secret) may involve a cryptographic hash function or encryption in addition to the function, such as the modulo M function described above. The position of a fragment n may thus be obtained using position[n]=hash(length[n], offset[n], secret) modulo M in this example.

[0100] The secret may be system wide, per distributor or per content. The CDN should typically know the corresponding secret in order to process the content requests.

[0101] The processing step to determine the adjusted length needs to be run in order. Notice that the start offset of the current fragment depends on the lengths of the previous fragments. In pseudo-code the processing may include the following steps for obtaining the temporal positions including the offsets:

TABLE-US-00001 offset[0] = 0; find padding[0] which makes function(length[0]+padding[0], offset[0], secret) == 0; offset[1] = offset[0] + length[0] + padding[0]; find padding[1] which makes function(length[1]+padding[1], offset[1], secret) == 1; ...; offset[i] = offset[i-1] + length[i-1] + padding[i-1]; find padding[i] which makes function(length[i]+padding[i], offset[i], key) == i.

[0102] When using byte-range requests, the requests may include the start-offset (offset[0] in the example above) and the length (or the start-offset and the end-offset). Thus, the start-offset or the end-offset may be used as an indicator or to obtain for the temporal position or the requested fragment.

[0103] When the start-offset is zero, the temporal position may map to position[0]=0 by default. When the start-offset is non-zero, i.e. there is data before the first fragment (e.g. header), then the preceding section (e.g. header) may be padded as needed. In case of the end-offset, the current fragment may be padded to make the end-offset indicate the correct position.

[0104] In an embodiment, it may be assumed that the start-offset is used to indicate the position as follows: position[n]=function(offset[n], secret). Since the offset for the next fragment may typically be expressed as offset[n+1]=offset[n]+length[n] (and both may be given in the byte-range request), it may be computed that position[n+1]=function(offset[n]+length[n], secret). Herein it may be required that position[n+1]=position[n]+1 or position[n+1]=0 if position[n] is the last position in a limited sequence.

[0105] The codecs used in the above examples are not to be construed to limit the scope of this disclosure. Other codecs may be used, such as one of the following. There have been two main audio/video codecs in the last decade: AVC (H.264) and VP9. These two are being replaced, respectively by HEVC (H.265) and AV1. VP9 can now be used with MP4, as part of the Common Media Application Format (CMAF).

[0106] HTTP Live Streaming (HLS) will support fragmented MP4 (fMP4) files in the form of the Common Media Application Format (CMAF). This MPEG-ratified media format, which relies on the ISO Base Media File Format (ISOBMFF) commonly known as MP4 (MPEG-4 Part 12 or ISO/IEC 14496-12), relies on this fundamental baseline format of the MPEG-4 standard to allow for fragmented or segmented streaming of MP4 files using a byte-range addressing scheme. CMAF is now MPEG-A Part 19, or ISO/IEC 23000-19.

[0107] CMAF is intended to be codec-agnostic, meaning that it can be used with either AVC or HEVC and, potentially AV1.

[0108] One or more embodiments of the disclosure may be implemented as a computer program product for use with a computer system. The program(s) of the program product may define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. The computer-readable storage media may be non-transitory storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information may be permanently stored; and (ii) writable storage media (e.g., hard disk drive or any type of solid-state random-access semiconductor memory, flash memory) on which alterable information may be stored.