Creates a new redirect message and adds a new entry to it. Redirect messages
are posted when an element detects that the actual data has to be retrieved
from a different location. This is useful if such a redirection cannot be
handled inside a source element, for example when HTTP 302/303 redirects
return a non-HTTP URL.
The redirect message can hold multiple entries. The first one is added
when the redirect message is created, with the given location, tag_list,
entry_struct arguments. Use gst.message.Message.addRedirectEntry to add more
entries.
Each entry has a location, a tag list, and a structure. All of these are
optional. The tag list and structure are useful for additional metadata,
such as bitrate statistics for the given location.
By default, message recipients should treat entries in the order they are
stored. The recipient should therefore try entry \#0 first, and if this
entry is not acceptable or working, try entry \#1 etc. Senders must make
sure that they add entries in this order. However, recipients are free to
ignore the order and pick an entry that is "best" for them. One example
would be a recipient that scans the entries for the one with the highest
bitrate tag.
The specified location string is copied. However, ownership over the tag
list and structure are transferred to the message.
Creates a new redirect message and adds a new entry to it. Redirect messages are posted when an element detects that the actual data has to be retrieved from a different location. This is useful if such a redirection cannot be handled inside a source element, for example when HTTP 302/303 redirects return a non-HTTP URL.
The redirect message can hold multiple entries. The first one is added when the redirect message is created, with the given location, tag_list, entry_struct arguments. Use gst.message.Message.addRedirectEntry to add more entries.
Each entry has a location, a tag list, and a structure. All of these are optional. The tag list and structure are useful for additional metadata, such as bitrate statistics for the given location.
By default, message recipients should treat entries in the order they are stored. The recipient should therefore try entry \#0 first, and if this entry is not acceptable or working, try entry \#1 etc. Senders must make sure that they add entries in this order. However, recipients are free to ignore the order and pick an entry that is "best" for them. One example would be a recipient that scans the entries for the one with the highest bitrate tag.
The specified location string is copied. However, ownership over the tag list and structure are transferred to the message.