[Bug 743703] http connectivity robustness of hlsdemux (and now adaptivedemux)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743703
  GStreamer | gst-plugins-bad | unspecified

--- Comment #10 from Mathieu Duponchelle <mduponchelle1 at gmail.com> 2015-02-05 13:36:07 UTC ---
(In reply to comment #8)
> Review of attachment 296140 [details]:
> 
> This is aligned with what I had in mind, but I'd prefer if we had new functions
> on core to set/get those details.
> 

Indeed, the "problem" with the GST_ELEMENT_ERROR macro is that it creates the
message and sends it immediately, that's why I duplicated it and slightly
modified it in that patch, not very nice.

> Ideally I'd like to have a new GstStructure under the event's structure just to
> set these element fields, perhaps under the "element-details" name. This way we
> could have gst_message_set_error_element_details() and
> gst_message_parse_error_element_details(). OTOH, GstStructure in GstStructure
> is not so nice in 1.x because of serialization/deserialization limitations (use
> of the same symbol for opening and closing -> "") so we need to think carefully
> if we can do this.

I remember that issue, didn't we "sort of fix it" by allowing one nested
structure. I imagine there can be use cases for serialization of error
messages.

> 
> Even if we don't use this approach I'd still prefer to have the set/get done
> through some custom function in core, this way we can prevent that it
> overwrites standard fields used and it is easier to identify code that is using
> this new feature for future changes.
> 

> Mathieu and Tim, what's your take on this?

I agree that having this in core would be nice, we will need to define a
correct API, I can propose something if we decide to do so.

I'll comment on the bug itself separately now.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.