https://bugzilla.gnome.org/show_bug.cgi?id=632222
GStreamer | gst-plugins-bad | unspecified
--- Comment #9 from Tim-Philipp Müller <t.i.m@...> 2011-01-07 22:35:27 UTC ---
No, the patch got reverted for the release because it breaks something that
used to work before and that works everywhere else, whereas the thing it fixes
didn't work before (correct me if I'm wrong).
I don't know for sure if the file is faulty or not, and it doesn't really
matter that much given that other players handle it fine. I'm working mainly on
the principle that it is more desirable to avoid a playback regression than to
add a new fix or feature.
Surely with some tweaking this can be made to work properly for both cases?
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=638941
GStreamer | gstreamer (core) | git
Edward Hervey <bilboed> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|HEAD |0.10.32
--- Comment #1 from Edward Hervey <bilboed@...> 2011-01-07 21:39:58 UTC ---
Actually, my proposed fix needs to be fine-tuned, because you could very well
end up in the situation where a plugin (with the same exact location) was
modified and isn't working anymore.
So we shouldn't just check the basename, but actually the full path.
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=632222
GStreamer | gst-plugins-bad | unspecified
--- Comment #8 from Marc Leeman <marc.leeman@...> 2011-01-07 21:38:37 UTC ---
So, if I get it correctly; the code gets broken again because faulty files are
used as a reference?
This doesn't seem quite right IMO.
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=638941
GStreamer | gstreamer (core) | git
Summary: registry scan/loading race and inconsistency
Classification: Desktop
Product: GStreamer
Version: git
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: Normal
Component: gstreamer (core)
AssignedTo: gstreamer-bugs@...
ReportedBy: bilboed@...
QAContact: gstreamer-bugs@...
GNOME target: ---
GNOME version: ---
Created an attachment (id=177785)
--> (https://bugzilla.gnome.org/attachment.cgi?id=177785)
rm test-registry.reg && rm pipelines/gio &&
GST_DEBUG=2,check:5,*LOAD*:5,*REG*:5 make check -j5 > log-plugin2 2>&1
When running the unit tests in -base, the gio test sometimes fails with the
following error :
Running suite(s): gio
0%: Checks: 1, Failures: 1, Errors: 0
pipelines/gio.c:96:F:general:test_memory_stream:0: Assertion 'src != NULL'
failed
FAIL: pipelines/gio
What's actually happening is that it actually attempted to load the libgstgio
from /usr/lib, which was blacklisted and therefore had zero features. And
obviously... it couldn't create a giostreamsrc element since that plugin
doesn't have one.
The local source libgstgio.so does exist, is valid, has all the features.
This only happens with the subprocess scanning.
This is one is tricky... so bare with me for the explanations (debug logs
attached).
The registry scan (to create/update test-registry.reg) does the following:
* The parent process scans the various paths for potential .so
* It checks if a potential .so isn't already register
* If there isn't already a registered plugin with the same basename
(libgstFOO.so) it sends it to the child process to be scanned
* CHILD : processes the incoming .so, checks it against a potential
whitelist, and eventually returns the information back to the parent process
* The parent process receives plugin info from the child process and calls
gst_registry_add_plugin()
* If a plugin with the same basename isn't already present it adds it
* If a plugin with the same basename is already present it replaces it with
the new one
Where the race happens:
* parent scans potential .so in local source (including the local libgstgio.so)
and sends it to child
* CHILD : eventually sends it back (stress-word : eventually)
* parent scans system-wide paths for potential .so (including libgstgio.so).
=> The problem is that the child might have not sent back the result from
scanning the local libgstgio.so at that time. And therefore the parent process
thinks libgstgio.so is a new plugin and sends it to the child process to scan
* CHILD : sends back the results from scanning the local libgstgio.so
* PARENT : adds it to registry
* CHILD : scans system-wide libgstgio.so, but since we have a whitelist and
it's not in it it is marked as blacklisted and no features are added to it and
sends it back to the parent
* PARENT : adds system-wide libgstgio.so to registry. There already is an
existing libgstgio.so .... and it therefore replaces it by the new
(system-wide, blacklisted, 0 features) libgstgio.so
=> FAILURE ENSUES
How to solve this:
in gst_registry_add_plugin, if there's already an existing same-basename
plugin... check if either the new or existing plugin is blacklisted and make a
*smart* choice on whether to replace the existing plugin by the new one or
ignore the new one.
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=638914
GStreamer | gst-rtsp-server | git
Summary: Stopping and starting multiple time leaks resources
Classification: Desktop
Product: GStreamer
Version: git
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-rtsp-server
AssignedTo: gstreamer-bugs@...
ReportedBy: jonas@...
QAContact: gstreamer-bugs@...
GNOME target: ---
GNOME version: ---
In my setting I must be able to totally deinitialize the server when not in use
to conserve resources (embedded in Android app). Simply unreffing the server
doesn't help. It doesn't close it's listening socket, so when started the next
time the listening port is already in use. The server also has refs to
GIOChannel and GSource which are never unreffed from what I can see.
For now, I've added code close the listening socket and unref GIOChannel and
GSource in gst_rtsp_server_finalize. It seems to work, but I'm a glib noob, so
I could be horribly wrong.
The caller of gst_rtsp_server_attach is responsible for detaching the server
from its context. If not done, GIOChannel and GSource will be left with
ref_count 1.
My updated gst_rtsp_server_finalize:
static void
gst_rtsp_server_finalize (GObject * object)
{
GstRTSPServer *server = GST_RTSP_SERVER (object);
g_free (server->address);
g_free (server->service);
g_object_unref (server->session_pool);
g_object_unref (server->media_mapping);
if (server->io_watch)
g_source_unref (server->io_watch);
if (server->io_channel)
g_io_channel_unref (server->io_channel);
if (server->server_sock.fd >= 0)
close (server->server_sock.fd);
}
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=617045
GStreamer | gstreamer (core) | git
--- Comment #20 from Wim Taymans <wim.taymans@...> 2011-01-07 15:13:39 UTC ---
After some more thinking about it:
1) The zigzag simulates a simple cost model where each caps list entry has an
equal weight. It then orders the resulting intersection based on the lowest
sum of weights. This model would find an 'overall' fair intersection as seen
in Comment #11.
2) The sorted one tries to maintain the order of the downstream caps as much as
possible. This by definition tries to maintain the same caps order as far
upstream as possible. It is not fair because the order of the upstream caps
is ignored.
1) Is easy to throw off balance. When something is not the first element of the
list, we don't really know how much worse it is compared to the top of the
list because it uses a fixed cost model (comment #11). Trying to add more fine
grained sorting weights (comment #16) might make things better but it sounds
too
complicated. This model favours 'small' conversions to get an overall best
format.
2) Tries to minimize conversions as much as possible but can cause 'very
expensive' conversions because there is no fair cost model. This is the case in
comment #15. The source has no other option than taking the cost of providing
the first downstream format (and doing the conversion) because it can't know if
any other format is going to be even more expensive downstream.
The current 1) seems to fail because it uses a too broken cost model, so, 2)
seems like it might indeed work better. Let's try this after the release then.
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=617045
GStreamer | gstreamer (core) | git
--- Comment #19 from Edward Hervey <bilboed@...> 2011-01-07 14:03:38 UTC ---
(In reply to comment #15)
> (You said that downstream order should be preffered but there are cases where
> this isn't optimal, i.e. if you have a source that can output all video formats
> but internally only uses a single one and then converts... but much slower than
> ffmpegcolorspace)
In that case the *source* can decide it prefers a certain format and do its
own intersection.
--
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.

https://bugzilla.gnome.org/show_bug.cgi?id=636851
GStreamer | common | unspecified
Tim-Philipp Müller <t.i.m> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
--- Comment #7 from Tim-Philipp Müller <t.i.m@...> 2011-01-07 12:48:58 UTC ---
I think it's the -jN, but only seems to affect distcheck, so will fix it after
the first pre-release.
--
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.