[gstreamer-bugs] [Bug 630046] sdpdemux: Add optional support for rtspsrc as session element

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #13 from Marco Ballesio <gibrovacco at gmail.com> 2010-10-05 11:17:52 UTC ---
(In reply to comment #12)
> Created an attachment (id=171749)
 View: https://bugzilla.gnome.org/attachment.cgi?id=171749
 Review: https://bugzilla.gnome.org/review?bug=630046&attachment=171749

> sdpdemux: workaround rtspsrc failing state change
> 
> (continued from bug #628214)
> 
> The only difference (that matters here) between the original patch and the one
> committed is that the original one actually performs _set_state twice.
> That (accidentally) happens to workaround rtspsrc failing to reach PLAYING (in
> one call).  The attached patch (hackishly) arranges for 2 _set_state calls,
> which suffices to eliminate race/deadlock.

So it all goes back to my original comment in
https://bugzilla.gnome.org/show_bug.cgi?id=628214#c0 that "Still the key issue
of state change violations in sdpdemux are remaining" (which is actually based
on your observations ;) ).

> 
> A "cleaner fix" may require (tricky?) core modifications, e.g. not having
> async_done wipe out the pending state if not a toplevel bin (??)

Yep we've already discussed about this and I guess the only way would be to set
back the pipeline to PAUSED at some point, add the rtspsrc and then going again
to PLAYING. I dunno how hackish it would be when compared with the current
implementation.

Btw your patch looks quite good to me, I'll test it as soon as I get to my
hacking laptop @ home.

-- 
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.