[gstreamer-bugs] [Bug 608036] [qtdemux] deadlock during typefinding of 3gpp

[GStreamer (bugzilla.gnome.org)]

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

Thiago Sousa Santos <thiago.sousa.santos> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2010-01-28 14:31:56 UTC ---
Here's the problem:

It happens in typefind's sink pad activation (the code has enumerated steps,
I'll use them here)

In step 2, typefind helpers pull buffers from upstream, dataurisrc sets caps on
those buffers and causes the typefind's setcaps function to be called and the
'typefound' signal is emitted.

Decodebin2 catches the signal, plugs qtdemux and sets it to PAUSED/PLAYING,
qtdemux's pads are activated in pull mode (and consequently typefind's pads are
as well). At this point, everything is ready to flow correctly.

Now the root of the problem: the rest of the steps in typefind's pad activation
are still to run, and they deactivate and reactivate its pads, making their
state inconsistent with downstream qtdemux.


Me and Tim agree that applying patches to typefind so close to a release is
dangerous, I'd rather keep them for after the release. Meanwhile we can try
working out a solution for dataurisrc, making it possible to be used in
playbin2.

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