Method and system of push-template and URL list for dash on full-duplex protocols

Abstract

A method and system of message exchange for controlling flow associated with multimedia streaming services from a server to a client using DASH are disclosed. In one method, one or more Push Directives are sent from a client to a server to indicate information related to media data requested. At least one selected Push Directive uses one URLTemplate that comprises a list of media parameter values, and where each media parameter value corresponds to one media parameter associated with one media segment requested. The server then pushes one or more groups of data for the media data requested to the client according to the list of media parameter values. In another method, at least one selected Push Directive uses one URLTemplate that includes a first number to represent a number of repeating difference of media parameter values associated with requested media segments.

Claims

1. A method of message exchange for controlling flow associated with multimedia streaming services performed by a client using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the method comprising: sending one or more Push Directives to a server to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that comprises a URL associated with a plurality of segments and a list of a plurality of media parameter values wherein: each media parameter value of the list of the plurality of the media parameter values is configured to be substituted into the URL to resolve the URL to a segment specified by the media parameter value; and each media parameter value comprises a number; receiving one or more groups of data pushed from the server for the media data requested according to the list of the plurality of media parameter values, comprising receiving data for a set of segments specified by the URL and the list of the plurality of media parameter values; and playing back said one or more groups of data for the media data received.

2. The method of claim 1, wherein the list of the plurality of media parameter values represent one or more media parameters selected from a group including parameters {Number}, {Time }, {ID } and {Timestamp }.

3. The method of claim 2, wherein each media parameter value corresponds to parameter {Number} to indicate a segment number associated with one media segment.

4. The method of claim 2, wherein each media parameter value corresponds to parameter {Times} and a symbol is used to indicate one or more values specified for parameter {Time} are for a time range or for a list of timestamps.

5. The method of claim 4, wherein the symbol corresponds to character.

6. The method of claim 1, wherein the list of the plurality of media parameter values belongs to different media parameters and the different media parameters are separated by a delimiter.

7. The method of claim 6, wherein the delimiter corresponds to vertical bar character, |.

8. The method of claim 6, wherein for each specified representation ID, URLs are generated for all media parameter values for one or more indicated media parameters if said one or more indicated media parameters exist, wherein said one or more indicated media parameters belong to a group including parameters {Number}, {Timestamp} and {Time}.

9. The method of claim 6, wherein the list of the plurality of media parameter values include first values for a value range, a list of values or both for parameter {ID}, and second values for another media parameter.

10. The method of claim 9, wherein for each specified representation ID, a corresponding value or range is specified for parameter {Number}, {Timestamp} or {Time} if the parameter {Number}, {Timestamp } or {Time } exists.

11. The method of claim 6, wherein the list of the plurality of media parameter values includes list values for parameter {ID } to indicate representation switching among representations associated with two or more list values for the parameter {ID}.

12. The method of claim 1, wherein the list of the plurality of media parameter values comprises segment numbers and segment timelines for the server to expand one or more URL templates to generate one or more URL addresses using the list of the plurality of media parameter values, and wherein underlying values for the segment numbers and the segment timelines are treated in a same manner by replacing each parameter with each value in the list of the plurality of media parameter values.

13. A method of message exchange for controlling flow associated with multimedia streaming services performed by a server using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the method comprising: receiving one or more Push Directives from a client to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that comprises a URL associated with a plurality of segments and a list of a plurality of media parameter values wherein: each media parameter value of the list of the plurality of the media parameter values is configured to be substituted into the URL to resolve the URL to a segment specified by the media parameter value; and each media parameter value comprises a number; and pushing one or more groups of data to the client for the media data requested according to the list of the plurality of media parameter values for the client to play back said one or more groups of data for the media data received.

14. The method of claim 13, wherein each media parameter value corresponds to parameter {Number} to indicate a segment number associated with one media segment, wherein: the server generates a URL for each segment number corresponding to one value in the list of the plurality of media parameter values; or the server generates a URL for each segment by replacing each parameter {Number} with each value in the list of the plurality of media parameter values.

15. A client device for receiving media services using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the client device comprising one or more electronic circuits or processors arranged to: send one or more Push Directives to a server to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that comprises a URL associated with a plurality of segments and comprises a list of a plurality of media parameter values, wherein: each media parameter value of the list of the plurality of the media parameter values is configured to be substituted into the URL to resolve the URL to a segment specified by the media parameter value; and each media parameter value comprises a number; receive one or more groups of data from the server for the media data requested according to the list of the plurality of media parameter values, comprising receiving data for a set of segments specified by the URL and the list of the plurality of media parameter values; and play back said one or more groups of data for the media data received.

16. A method of message exchange for controlling flow associated with multimedia streaming services performed by a client using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the method comprising: sending one or more Push Directives to a server to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that includes a first number to represent a number of repeating difference of media parameter values associated with requested media segments; receiving one or more groups of data pushed from the server for the media data requested according to the media parameter values associated with the requested media segments; and playing back said one or more groups of data for the media data received.

17. The method of claim 16, said one URLTemplate further comprises a second number to indicate a starting media parameter value and a third number to indicate the number of repeating difference of media parameter values.

18. A method of message exchange for controlling flow associated with multimedia streaming services performed by a server using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the method comprising: receiving one or more Push Directives from a client to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that includes a first number to represent a number of repeating difference of media parameter values associated with requested media segments; and pushing one or more groups of data to the client for the media data requested according to the media parameter values associated with the requested media segments for the client to play back said one or more groups of data for the media data received by the client.

19. A client device for receiving media services using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)), the client device comprising one or more electronic circuits or processors arranged to: send one or more Push Directives to a server to indicate information related to media data requested, wherein at least one selected Push Directive uses one URLTemplate that includes a first number to represent a number of repeating difference of media parameter values associated with requested media segments; receive one or more groups of data from the server for the media data requested according to the media parameter values associated with the requested media segments; and play back said one or more groups of data for the media data received.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 illustrates an example of the overall flow of video streaming using server push, where a set of communication procedures are used between the server and the client to facilitate media streaming..

(2) FIG. 2 illustrates an example of the URLTemplate that includes changes made to the conventional URLTemplate according to an embodiment of the present invention.

(3) FIG. 3 illustrates an example of the URLTemplate that includes changes made to the conventional URLTemplate according to another embodiment of the present invention.

(4) FIG. 4 illustrates an example of the URLTemplate that includes changes made to the conventional URLTemplate according to yet another embodiment of the present invention.

(5) FIG. 5 illustrates an exemplary flowchart for a system incorporating message exchange for controlling flow associated with multimedia streaming services from a server to a client using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)) according to an embodiment of the present invention.

(6) FIG. 6 illustrates an exemplary flowchart for a system incorporating message exchange for controlling flow associated with multimedia streaming services from a server to a client using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)) according to another embodiment of the present invention.

DETAILED DESCRIPTION

(7) The following description is of the best-contemplated mode of carrying out the invention. This description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is best determined by reference to the appended claims.

(8) As mentioned previously, the existing streaming protocols have some drawbacks that affect the efficiency of messaging for streaming. Accordingly, techniques to overcome these drawbacks are disclosed in the present invention.

(9) In one aspect of the present invention, modifications to the Working Draft aiming at enabling the following are disclosed: A. Compact representation for an explicit list of values for URL address such as {Number}, {Time} or {Timestamp}. B. Compact representation for an explicit list of URLs based on SegmentTimeline. C. Representation switchingincluding the capability of items A and B.

(10) The modifications may be achieved in lieu of modifying certain parameters or introducing new parameters for URLTemplate. The details of various embodiments according to the present invention are discussed as follows. These parameters are also referred as media parameters in this disclosure.

(11) URLTemplate with List of Values (Number or Time/Timestamps)

(12) According to this method, compact representation for a list of values for parameter{Number} is allowed. For example, the push directives specified previously can be modified as: a. ../rep1/segment{Number}: {25, 50, 75, 100}, and b. http://cdn1.example.com/SomeMovie/{Number}.mp4v: {180180, 360360, 540540, 720720}.

(13) As shown in example a, the modified push directive allows multiple non-consecutive segments (i.e., 25, 50, 75 and 100) signalled for a representation (i.e., rep1). In example b, the modified push directive can use a single URLTemplate. Therefore, the URLTemplate according to this method allows efficient signalling of push directives. Note that, additional consideration is needed for push-template containing both parameters {ID} and {Number}. Currently, if both are present, symbol , is used to separate values for the two parameters types, such as {ID, Number}: {2, 5-7}. More on this will be discussed in a later section.

(14) URLTemplate with Segment URLs Based on SegmentTimeline

(15) To support segment URLs based on SegmentTimeline, where the URL address are the earliest presentation times obtained from the SegmentTimeline, a method to extend or use similar syntax structure of list of values as discussed above is disclosed for handling a list of timestamps. It can be the same parameter type as {Number} or introducing another parameter {Timestamp}, such as: http://mvsite.com/MovieC/rep1/{Number}.mp4v: {15000, 25000, 30000}, or http://mvsite.com/MovieC/rep1/{Timestamp}.mp4v: {15000, 25000, 30000}

(16) The above modification providesan explicit list of URLs with time-based addressing obtained from SegmentTimeline. Accordingly, the server does not need to parse the MPD.Again additional consideration is needed when the timestamp URL list is used together with parameter {ID} in push-template. More on this will be discussed later.

(17) In one of the examples above, parameter {Number} is used to represent presentation time in the URL list. In other words, for the list of values, the expansion to obtain the URL addresses is the same regardless of whether the underlying values are for Number or for timestamps. Therefore, the parameters of Number and timestamp can be exchangeable with each other in the list. There is no need to distinguish whether the value is for segment number or for time.

(18) In another example,URLTemplate can be constructed by specifying a list of timestamps under parameter {Time} instead of under parameter {Number} or under new parameter {Timestamp}.

(19) List of Values with Repeated Value Difference

(20) Two methods for compact representation of values with repeated difference are disclosed.

(21) The first method introduces a delimiter to indicate the subsequence value that specifies a difference in value rather than value itself ../rep1/segment{Number}: {25; 5; 10}//Starting value, difference, repeat

(22) In this example, the symbol ; is used as a delimiter,value 25 is the first URL address value,value 5 after ; is the value difference to be added to produce the next values, value 10 indicates the number of times to be repeated, i.e., {25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75}.

(23) In another example, the URLTemplate can be constructed by signalling the end value, instead of specifying the number of repeat times, to indicate {25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75}. ../rep1/segment{Number}: {25; 5; 75}//Starting value, difference, end value

(24) The second method introduces a format to encompass the values with repeated difference without introducing an additional delimiter. ../rep1/segment{Number}: {(25, 5, 10)}//Start value, difference, repeat

(25) In this example, the triplet values with the pair of parenthesis,( and ) specify the starting value, difference and the number to repeat. The expansion process knows the format once it encounters the symbol ( so that there is no need to use a different delimiter to separate values and difference.

(26) In another example, the URLTemplate can be constructed by signalling the end value instead of specifying the number of repeat times. ../rep1/segment{Number}: {(25, 5, 75)}//Start value, difference, end value

(27) Other symbolsmay be used as the delimiter for the first method as long as the symbols do not cause ambiguity. Also, other symbol pair,except for the parenthesis pair( and ), can be used to encompass the value and difference as long as the symbols do not lead to ambiguity. For example,the bracket pair [ and ] can be used as a delimiter pair.

(28) Handling Representation Switching

(29) To facilitate push-template with both parameter {ID} and the segment list, a method to use a delimiter to clearly separate values specified for different parameters is disclosed according to the present invention. For example, if | is selected as the delimiter, the following can be used to specify representation change (i.e., representation switching), where multiple non-consecutive segments from each representation can be requested: a. ../rep{ID}/segment{Number}: {2|4}: {4|5}: {7|6} This may represent the following: ../rep2/segment4, ../rep4/segment5, ../rep7/segment6 b. ../rep{ID}/segment{Number}: {2|8, 16, 24}: {4|32, 40}: {7|48} This may represent thefollowing: ../rep2/segment8, ../rep2/segment16, ../rep2/segment24, ../rep4/segment32, ../rep4/segment40, ../rep7/segment48,

(30) Representation switch with URLs based on SegmentTimeline can also be explicitly specified using push-template: ../rep{ID}/{Number}: {2|15000, 25000, 30000}: {4|35000, 40000, 50000}: {7|60000, 65000} or ../rep{ID}/{Timestamp}: {2|15000, 25000, 30000}: {4|35000, 40000, 50000}: {7|60000, 65000} Both examples may represent the following: ../rep2/15000, ../rep2/25000, ../rep2/30000, ../rep4/35000, ../rep4/40000, ../rep4/50000, ../rep7/60000, ../rep7/65000

(31) The values in the URL address are the earliest presentation times, which the client obtained from the SegmentTimeline.

(32) For list of values with a repeated difference: ../rep{ID}/segment{Number}: {2|18; 8; 5}: {4|48; 8; 5} or ../rep{ID}/segment{Number}: {2|(8, 8, 5)}: {4|(48, 8, 5)} Both examples may represent the following: ../rep2/segment8, ../rep2/segment16, ../rep2/segment24, ../rep2/segment32, ../rep2/segment32, . . ./rep2/segment40, ../rep4/segment48, ../rep4/segment56, ../rep4/segment64, ../rep4/segment72, ../rep4/segment80,

(33) In the above examples, segment numbers 8, 16, 24, 32 and 40 are from rep2, and segments 48, 56, 64, 72 and 80 are from rep4.

(34) In another example for specifying time value, the client obtains the time values from the SegmentTimeline. ../rep{ID}/{Number/Timestamp}: {2|10000; 5000; 5}: {4|35000; 5000; 5} or ../rep{ID}/{Number/Timestamp}: {2|(10000, 5000, 5)}: {4|(35000, 5000, 5)} Both example may represent the following: ../rep2/10000, ../rep2/15000, ../rep2/20000, ../rep2/25000, ../rep2/30000, ../rep4/35000, ../rep4/40000, ../rep4/45000, ../rep4/50000, ../rep4/55000,

(35) In the above examples, segment addresses 10000, 15000, 20000, 25000 and 30000 are from rep2, and segment addresses 35000, 40000, 45000, 50000 and 55000 are from rep4.

(36) Embodiment Category A

(37) To achieve the disclosed capabilities mentioned above, this category of embodiments introducesa list of values variable, a {Timestamp} parameter variable and a delimiter into the FDH Working Draft. For example, the URLTemplate can be modified as shown in FIG. 2, where the changes from the conventional URLTemplate are highlighted as texts in bold. For example, in FIG. 2, a new Clause variable {Timestamp} (i.e., CLAUSE_VAR_TIMESTAMP) is introduced as indicated by reference number 210. The format of {Timestamp} is indicated by reference number 220. The vertical bar character | is used as a delimiter as indicated by reference number 230. The format for VAL_LIST is indicated by reference number 240.

(38) Each template item is formed as a URL containing macros for parameterization relative to the segment being requested.

(39) The {Number} parameter is used to specify a range of URLs that differ by the segment number. The {Number} parameter is expanded using a provided range variable or a provided VAL_LIST variable. Parameter {Timestamp} is used to specify a range of URLs that differ by segment time. Parameter {Timestamp} is expanded using a provided VAL_LIST variable. Parameter {Time} is used to specify a range or URLs that differ by the segment time. Parameter {Time} is expanded using a provided time variable. Parameter {ID} is used to specific a range of URLs that differ by the representation ID. Parameter {ID} parameter is expanded using a provided range variable.

(40) A template may include no more than one of the following: a parameter {Number}, a parameter {Timestamp}, or a parameter {Time} parameter.

(41) The URL list will be generated from each template item by evaluating the provided parameter at the server. For number ranges, the server will generate a URL for each segment number in the range provided (inclusive). For number value lists, the server will generate a URL for each segment number explicitly provided in the value list. For timestamp value lists, the server will generate a URL for each segment by replacing {Timestamp} with each of the value explicitly provided in the value list. For time ranges, URLs will be generated for each subsequent segment until the segment time (i.e., presentation time of the first frame) exceeds the indicated time.

(42) Parameters are expanded in a well-defined order to prevent any ambiguity in the template expansion. For each representation ID in the specified range, URLs are generated for all values for the indicated parameter {Number}, {Timestamp} or {Time}, if they exist as specified after the delimiter|. In other words, the {ID} expansion represents the outer loop of the expansion process.

(43) In another embodiment, the URLTemplate can be constructed by extending the usage of parameter {Number} to specify Timestamps in the URLs using VAL_LIST. This embodiment does not need to introduce new parameter {Timestamp}.

(44) In yet another embodiment, the values for a parameter can be a mixture of single values, a list of values and a range of values.

(45) In the above example, the delimiter , for separating values in the VAL_LIST and the delimiter | for separating values for different parameters are just examples according to an embodiment of the present invention. Other symbol may also be used to construct unambiguous parameter values.

(46) More examples incorporating embodiments of the present invention are shown as follows.

(47) a. Example of Push Template with Segment Number Address List

(48) This example shows a push template for use with URLs utilizing segment number addressing. The example shows a push sequence of segment number 25, followed by number 50 and number 75. Note that relative addressing in the URL is used. ../rep1/segment{Number}.mp4: {25, 50, 75} This may represent the following: ../rep1/ segment25.mp4, ../rep1/segment50.mp4, ../rep1/segment75.mp4

(49) b. Example of Push Template with Segment Addressing Based on SegmentTimeline

(50) This example shows a push template for use with URLs described using SegmentTimeline in MPD. The example shows a push sequence of segment URL address15000, followed by URL address 25000, URL address 30000 and URL address 35000. Note that relative addressing in the URL is used. ../rep1/{Timestamp}.mp4: {15000, 25000, 30000, 35000} This may represent the following: ../rep1/15000.mp4, ../rep1/25000.mp4, ../rep1/30000.mp4, ../rep1/35000.mp4

(51) In the above example, the values 15000, 25000 and 30000 in the URL address are the earliest presentation times, which the client obtained from the SegmentTimeline.

(52) c. Example of Push Template with Both Representation ID and Number Addressing

(53) This example shows a push template that pushes segments from different representations. The example shows that a push sequence pushes segments 2-4 from representation 1 followed by a push of segments 5-7 from representation 2. ../rep{ID}/segment{Number}: {1|2-4}: {2|5-7} This may represent the following: ../rep1/segment2, ../rep1/segment3, ../rep1/segment4 ../rep2/segment5, ../rep2/segment6, ../rep2/segment7

(54) d. Example of Push Template with Multiple Representations

(55) This example shows a push template for pushing segments from different representations. The example shows a push sequence that would result in the push of segments 2-4 different representations (i.e., representation ID 2, 4 and 7 respectively). Note that relative addressing in the URL is used. ../rep{ID}/segment{Number}: {2|2}: {4|3}: {7|4} This may represent the following: ../rep2/segment2, ../rep4/segment3, ../rep7/segment4

(56) e. Example of Push Template with Multiple Representations and Number Address List

(57) This example shows a push template for pushing segments from different representations. The example shows a push sequence that would result in the push of segment numbers 8, 16 and 24 from representation 2, segments 32 and 40 from representation 4, and segment 48 from representation 7. Note that relative addressing in the URL is used. ../rep{ID}/segment{Number}: {2|8, 16, 24}: {4|32, 40}: {7|81} This may represent the following: ../rep2/segment8, ../rep2/segment16, ../rep2/segment24, ../rep4/segment32, ../rep4/segment40, ../rep7/segment48,

(58) f. Example of Push Template with Multiple Representations and Address Based on SegmentTimeline

(59) This example shows a push template for pushing segments from different representations. The example shows a push sequence that would result in the push of URL addresses15000, 25000 and 30000 from representation 2, URL address 35000, 40000 and 50000 from representation 4, and URL address 60000 and 65000 from representation 7. Note that relative addressing in the URL is used. ../rep{ID}/{Timestamp}: {2|15000, 25000, 30000}: {4|35000, 40000, 50000}: {7|60000, 65000} This may represent the following: ../rep2/15000, ../rep2/25000, ../rep2/30000, ../rep4/35000, ../rep4/40000, ../rep4/50000, ../rep7/60000, ../rep7/65000

(60) In the above example, the values in the URL address are the earliest presentation times, which the client obtained from the SegmentTimeline.

(61) Embodiment Category B

(62) According to this category of embodiments, URLTemplate is constructed by extending the usage of {time} parameter to cover both time range as current FDH specification and list of timestamps (i.e., VAL_LIST in this invention). This is achieved by using the symbol as identification to distinguish between time-range and the list of time stamps. For example, the URLTemplate can be modified as shown in FIG. 3, where the changes made from the conventional URLTemplate are highlighted as texts in bold.For example, in FIG. 3, the vertical bar character | is used as a delimiter as indicated by reference number 310. The format for VAL_LIST is indicated by reference number 320. Parameter {Time} can be represented by an ending value (i.e., INTEGER) or a list of times (i.e., VAL_LIST).

(63) Each template item is formed as a URL containing macros for parameterization relative to the segment being requested. Parameter {Number} is used to specify a range of URLs that differ by the segment number. Parameter {Number} is expanded using a provided range variable or a provided VAL_LIST variable. Parameter {Time} is used to specify a range or URLs that differ by the segment time. Parameter {Time} is expanded using a provided time variable. The {ID} parameter is used to specific a range of URLs that differ by representation ID. Parameter {ID} is expanded using a provided range variable.

(64) A template may include parameter {Number}, or parameter {Time}, but not both. The URL list will be generated from each template item by evaluating the provided parameter. For number ranges, the server will generate a URL for each segment number in the range provided (inclusive). For number value lists, the server will generate a URL for each segment number explicitly provided in the value list. For time ranges, specified using symbol,INTEGER, URLs will be generated for each subsequent segment until the segment time (i.e., presentation time of the first frame) exceeds the indicated time.For time value lists specified using VAL_LIST, the server will generate a URL for each segment by replacing {Time} with each of the value explicitly provided in the value list.

(65) Parameters are expanded in a well-defined order to prevent any ambiguity in the template expansion. For each representation ID in the specified range, URLs are generated for all values for the indicated parameter {Number} or {Time} if they exist as specified after the delimiter|. In other words, the {ID} expansion represents the outer loop of the expansion process.

(66) In other embodiment examples, the values for a parameter can be a mixture of single values, a list of values ora range of values. The delimiter , for separating values in the VAL_LIST and the delimiter| for separating values for different parameters are just examples to illustrate an embodiment of the present invention. Other symbols can be usedto construct unambiguous parameter values as well.

(67) More examples incorporating embodiments of the present invention are shown as follows.Some examples presented for embodiment Category A are also applicable to embodiment Category B. Accordingly, only these examples that are different from embodiment Category A are presented as follows.

(68) a. Example of Push Template with Time-Based Addressing

(69) This example shows a push template for use with URLs utilizing time-based addressing. The example shows a push sequence that terminates at presentation time 10000. Note that relative addressing in the URL is used. ../rep1/segment{Time}.mp4: {10000}

(70) b. Example of Push Template with Segment Addressing Based on SegmentTimeline

(71) This example shows a push template for use with URLs described using SegmentTimeline in the MPD. The example shows a push sequence of segment URL address15000, followed by URL address 25000, URL address 30000 and URL address 35000. Note that relative addressing in the URL is used. ../rep1/{Time}.mp4: {15000, 25000, 30000, 35000} This may represent the following: ../rep1/15000.mp4, ../rep1/25000.mp4, ../rep1/30000.mp4, ../rep1/35000.mp4

(72) In the above example, the values 15000, 25000 and 30000 in the URL address are the earliest presentation times, which the client obtained from the SegmentTimeline.

(73) The usage of delimiter (e.g.|) in both embodiment Categories A and B can be further generalized such that the parameter values for {ID} can also be a range, a value or empty. For example, the following alternative representations can be used:

(74) a. Empty ID Values Indicating ID is Fixed ../rep1/segment{Number}.mp4: {|25, 50, 75} This may represent the following: ../rep1/segment25.mp4, ../rep1/segment50.mp4, ../rep1/segment75.mp4 ../rep1/segment{Timestamp}.mp4: {|15000, 25000, 30000, 35000} This may represent the following: ../rep1/segment15000.mp4, ../rep1/segment25000.mp4, ../rep1/segment30000.mp4, ../rep1/segment35000.mp4

(75) b. Range or List of Values for ID ../rep{ID}/segment{Number}: {1-2|2-4, 5-7} This may represent the following: ../rep1/segment2, ../rep1/ segment3, ../rep1/segment4 ../rep2/segment5, ../rep2/segment6, ../rep2/segment7 ../rep{ID}/segment{Number}: {2,4,7|2, 3, 4} This may represent the following: ../rep2/segment2, ../rep4/segment3, ../rep7/segment4 ../rep{ID}/segment{Number}: {2|8, 16, 24}: {4|32, 40}: {7|48} This may represent the following: ../rep2/segment8, ../rep2/segment16, ../rep2/segment24, ../rep4/segment32, ../rep4/segment40, ../rep7/segment48, ../rep{ID}/{Timestamp}: {2|15000, 25000, 30000}: {4|35000, 40000, 50000}: {7|60000, 65000} This may represent the following: ../rep2/15000, ../rep2/25000, ../rep2/30000, ../rep4/35000, ../rep4/40000, ../rep4/50000, ../rep7/60000, ../rep7/65000 ../rep{ID}/segment{Timestamp}.mp4: {1-3|500-1000,2000-3000,15000-35000} This may represent the following: Segments in rep1 with timestamp values between 500 to 1000, Segments in rep2 with timestamp values between 2000 to 3000, Segments in rep3 with timestamp values between 15000 to 35000, ../rep{ID}/segment{Time}.mp4: {1-3|1000, 3000, 35000} This may represent the following: Segments in rep1 with timestamp values less than 1000, Segments in rep2 with timestamp values between 1000 to 3000, Segments in rep3 with timestamp values between 3000 to 35000,

(76) Embodiment Category C

(77) According to this category of embodiments, URLTemplate is constructed by introducing a list of values variable and list of values with same difference variable to the FDH Working Draft. For example, the URLTemplate can be modified as shown in FIG. 4, where the changes from the conventional URLTemplate are highlighted as texts in bold. For example, in FIG. 4, the parameter includes VAL_LIST and LIST_DIFF (i.e., list of values with same difference) separated by a vertical bar character | as a delimiter as indicated by reference number 410. The format for VAL_LIST is indicated by reference number 420 and the format for LIST_DIFF is indicated by reference number 430, where character , is used as a delimiter to separate list values in LIST_DIFF. Alternatively, character ; can be used as a delimiter to separate list values in LIST_DIFF as indicated by reference number 440. Parameter {Time} can be represented by a starting value (i.e., INTEGER) as indicated by reference number 450.

(78) The URL list will be generated from each template item by evaluating the provided parameter. For number ranges, this means generating a URL for each segment number in the range provided (inclusive). For value lists (i.e., VAL_LIST), this means generating a URL for each segment by replacing {Parameter(Time,Number,Timestamp)} with each of the value explicitly provided in the value list. For list of values with same difference (i.e., LIST_DIFF), this means first generating a list of values starting from the Starting Value, adding the Difference to produce the next values, until number of Repeat being reached (or until exceeding the End Value). A URL for each segment is then generated by replacing {Parameter(Time,Number,Timestamp)} with each of the value obtained in the first step. For time ranges, URLs will be generated for each subsequent segment until the segment time (i.e., presentation time of the first frame) exceeds the indicated time.

(79) Parameters are expanded in a well-defined order to prevent any ambiguity in the template expansion. For each representation ID in the specified range, URLs are generated for all values for the indicated {Number}, {Timestamp}, or {Time} parameter, if they exist as specified after the delimiter|. In other words, the {ID} expansion represents the outer loop of the expansion process.

(80) URLList Values, Representation Switching

(81) The mostgeneric method to request multiple segments with specific URL addressesis to use URL list as a special example of URLTemplate.For example, URL list can be specified with number values. ../rep1/segment25.mp4, ../rep1/segment50.mp4, ../rep1/segment75.mp4

(82) For example, the URL list can be specified with segment time: ../SomeMovie/rep1/15000.mp4v, ../SomeMovie/rep1/25000.mp4v, ../SomeMovie/rep1/30000.mp4v.

(83) In another example, the URL list can be specified with representation switching: ../rep1/segment2.mp4, ../rep1/segment3.mp4, ../rep2/segment4.mp4

(84) For compact representation, the aforementioned examples can also be implemented using URLTemplate with macro expansion, such as: ../rep1/segment{}.mp4: {25, 50, 75} ../SomeMovie/rep1/{}.mp4v: {15000, 25000, 30000} ../rep{}/segment{}.mp4: {1|2, 3}: {2|4}

(85) It is observed that the crux of URLTemplate is to only specify the values of the parameters (i.e., representation, segment number, time, etc.) while the common part of URL is only signalled once. The same spirit can also be found in the string compression methods, which eliminate duplicated strings. Thus, in addition to the usage of URLTemplate, the present invention also discloses a URL list with compression. Table 1 illustrates an example of URL list with compression according to an embodiment of the present invention.

(86) TABLE-US-00001 TABLE 1 PushType PushParams Description urn:mpeg:dash:fdh:2016:push-urllist C: Binary value C: 1-bit binary value to indicate whether N: (if C is 1) k bits compression is used for the subsequent list URLlist of URL addresses. N: If C is 1 (compression is utilized), this k-bit field specifies the compression methods used to compress the subsequent list of URL addresses. URLlist explicitly specifies the URL addresses of some segments are considered for push. A server receiving such push directive may use it to identify some segments to push. A client receiving such push directive can be informed on the segments the server intends to push.

(87) In the above example, for the push type push-urllist, a 1-bit binary value C is first signalled to indicate whether compression is used for the subsequent URL list. If the value of C is 0, the next parameter will be the URL list, which explicitly specifies each of the URL of the requested segments. If the value of C is 1, the next parameter will be a k-bit value N, which specifies the compression methods used to compress the subsequent URL list. For example, if k is equal to 2, values 00, 01, 10 and 11 can be used to indicate different compression methods. Common string compression methods, such as DEFLATE (IETF RFC 1951), HPACK (IETF RFC 7541 Header compression), LZ, etc. can be selected as shown in Table 2. The next parameter will be the compressed URL list which explicitly specifies each of the URL of the requested segments. Upon receiving this push type and the corresponding parameters, the server can decompress the URL list using the specified compression method (e.g. value N).

(88) TABLE-US-00002 TABLE 2 N (2-bit example) Compression 00 DEFLATE 01 HPACK 10 LZMA 11 LZ77

(89) Table 3 illustrates another example of URL list with a compression method according to an embodiment of the present invention.

(90) TABLE-US-00003 TABLE 3 PushType PushParams Description urn:mpeg:dash:fdh:2016:push-urllist N: (if C is 1) k bits N: This k-bit field specifies whether URLlist compression is used, and the compression method, for the subsequent list of URL addresses. URLlist explicitly specifies the URL addresses of some segments are considered for push. A server receiving such push directive may use it to identify some segments to push. A client receiving such push directive can be informed on the segments the server intends to push.

(91) In the above example, for the push type push-urllist, a k-bit value N is first signalled. It specifies whether compression is used and the compression method for the subsequent list of URL address. For example, if k is equal to 2, values 00, 01, 10 and 11 can be used to indicate four different compression modes as shown in Table 4.

(92) TABLE-US-00004 TABLE 4 N (2-bit example) Compression 00 No compression 01 DEFLATE 10 HPACK 11 LZMA

(93) The next parameter will be the compressed URL list, which explicitly specifies each of the URL of the requested segments. Upon receiving this push type and the corresponding parameters, the server can decompress the URL list using the specified compression method (value N).

(94) Besides fixed length coding for the value N, variable length coding can also be utilized. Various examples are shown in Table 5 to Table 8.

(95) TABLE-US-00005 TABLE 5 N Compression 1 DEFLATE 01 HPACK 001 LZMA 0001 LZ77

(96) TABLE-US-00006 TABLE 6 N Compression 0 DEFLATE 10 HPACK 110 LZMA 1110 LZ77

(97) TABLE-US-00007 TABLE 7 N (2-bit example) Compression 0 No compression 10 DEFLATE 110 HPACK 1110 LZMA

(98) TABLE-US-00008 TABLE 8 N (2-bit example) Compression 1 No compression 01 DEFLATE 001 HPACK 0001 LZMA

(99) FIG. 5 illustrates an exemplary flowchart for a system incorporating message exchange for controlling flow associated with multimedia streaming services from a server to a client using DASH (Dynamic Adaptive Streaming over HTTP (Hypertext Transfer Protocol)) according to an embodiment of the present invention. The steps shown in the flowchart may be implemented as program codes executable on one or more processors (e.g., one or more CPUs) at the server side and/or the client side. The steps shown in the flowchart may also be implemented based hardware such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to this method, the client sends one or more Push Directives from a server to indicate information related to media data requested in step 510, where at least one selected Push Directive uses one URLTemplate that comprises a list of media parameter values, and wherein each media parameter value corresponds to one media parameter associated with one media segment requested. As described in this disclosure, the use of a list of media parameter values allows the URLTemplate signalled in a compact form. In step 520, the server pushes one or more groups of data for the media data requested to the client according to the list of media parameter values. As mentioned in the disclosure, the server will evaluate and expand the URLTemplate that are signalled in a compact form to full URL addresses to locate the segments to be sent. The client can then play back said one or more groups of data for the media data received in step 530.

(100) In FIG. 5, the steps of the message exchange for controlling flow associated with multimedia streaming services according to an embodiment of the present invention are disclosed for both the server side and the client side. However, the steps at each of the server side and the client side can be identified accordingly.

(101) FIG. 6 illustrates an exemplary flowchart for a system incorporating message exchange for controlling flow associated with multimedia streaming services from a server to a client using DASH according to another embodiment of the present invention. The steps shown in the flowchart may be implemented as program codes executable on one or more processors (e.g., one or more CPUs) at the server side and the client side. The steps shown in the flowchart may also be implemented based hardware such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to this method, the client sends one or more Push Directives from a client to a server to indicate information related to media data requested in step 610, where at least one selected Push Directive uses one URLTemplate that includes a first number to represent a number of repeating difference of media parameter values associated with requested media segments. As described in this disclosure, the use of a list of media parameter values and the number of repeating difference of media parameter values allows the URLTemplate signalled in a compact form. In step 620, the server pushes one or more groups of data for the media data requested according to the media parameter values associated with the requested media segments. As mentioned in the disclosure, the server will evaluate and expand the URLTemplate that are signalled in a compact form to full URL addresses to locate the segments to be sent. The client can then play back said one or more groups of data for the media data received in step 630.

(102) In FIG. 6, the steps of the message exchange for controlling flow associated with multimedia streaming services according to an embodiment of the present invention are disclosed for both the server side and the client side. However, the steps at each of the server side and the client side can be identified accordingly.

(103) The flowchart shown above is intended to illustrate examples of messaging between a server and a client for media streaming incorporating embodiments of the present invention. A person skilled in the art may modify each step, re-arranges the steps, split a step, or combine the steps to practice the present invention without departing from the spirit of the present invention.

(104) The above description is presented to enable a person of ordinary skill in the art to practice the present invention as provided in the context of a particular application and its requirement. Various modifications to the described embodiments will be apparent to those with skill in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed. In the above detailed description, various specific details are illustrated in order to provide a thorough understanding of the present invention. Nevertheless, it will be understood by those skilled in the art that the present invention may be practiced.

(105) Embodiment of the present invention as described above may be implemented in various hardware, software codes, or a combination of both. For example, an embodiment of the present invention can be a circuit integrated into a video compression chip or program code integrated into video compression software to perform the processing described herein. An embodiment of the present invention may also be program code to be executed on a Digital Signal Processor (DSP) to perform the processing described herein. The invention may also involve a number of functions to be performed by a computer processor, a digital signal processor, a microprocessor, or field programmable gate array (FPGA). These processors can be configured to perform particular tasks according to the invention, by executing machine-readable software code or firmware code that defines the particular methods embodied by the invention. The software code or firmware code may be developed in different programming languages and different formats or styles. The software code may also be compiled for different target platforms. However, different code formats, styles and languages of software codes and other means of configuring code to perform the tasks in accordance with the invention will not depart from the spirit and scope of the invention.

(106) The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described examples are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.