Message.this
- this(GstMessage* gstMessage, bool ownedRef)
- this(ObjectGst src, Structure structure)
- this(ObjectGst src, GstClockTime runningTime)
- this(ObjectGst src, int percent)
- this(ObjectGst src, Clock clock)
- this(ObjectGst src, Clock clock, bool ready)
- this(GstMessageType type, ObjectGst src, Structure structure)
- this(ObjectGst src, Device device, Device changedDevice)
- this(ObjectGst src, Context context)
- this(ObjectGst src, string contextType)
- this(ObjectGst src, GstProgressType type, string code, string text)
- this(ObjectGst src, string propertyName, Value val)
- this(ObjectGst src, bool live, ulong runningTime, ulong streamTime, ulong timestamp, ulong duration)
- this(ObjectGst src, string location, TagList tagList, Structure entryStruct)
- this(ObjectGst src, GstState state)
- this(ObjectGst src, GstState oldstate, GstState newstate, GstState pending)
- this(ObjectGst src, GstFormat format, ulong amount, double rate, bool flush, bool intermediate, ulong duration, bool eos)
- this(ObjectGst src, bool active, GstFormat format, ulong amount, double rate, bool flush, bool intermediate)
- this(ObjectGst src)
- this(ObjectGst src, GstStreamStatusType type, Element owner)
- this(ObjectGst src, GstStructureChangeType type, Element owner, bool busy)
- this(ObjectGst src, TagList tagList)
- this(ObjectGst src, Toc toc, bool updated)
gstreamer Message Message
constructorsfunctionsstatic functionsvariables
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 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|0] first, and if this entry is not acceptable or working, try entry [1|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.