Menu
▾
▴
[gst-cvs] uraeus www: www/src/htdocs/tasks/
|
From: <ur...@fr...> - 2005-10-25 16:20:29
|
CVS Root: /cvs/gstreamer
Module: www
Changes by: uraeus
Date: Tue Oct 25 2005 09:20:18 PDT
Log message:
remove some old tasks
Modified files:
src/htdocs/tasks: gstreamer.xml
Links:
http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/www/src/htdocs/tasks/gstreamer.xml.diff?r1=1.9&r2=1.10
====Begin Diffs====
Index: gstreamer.xml
===================================================================
RCS file: /cvs/gstreamer/www/src/htdocs/tasks/gstreamer.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- gstreamer.xml 28 Jan 2005 23:07:46 -0000 1.9
+++ gstreamer.xml 25 Oct 2005 16:20:06 -0000 1.10
@@ -52,130 +52,6 @@
<person>Thomas</person>
</see>
</task>
-
- <task name="elementlist">
- <title>Revive the element status tables</title>
- <description>
- In the early days (around 0.2.0), <application>GStreamer</application>
- used to have extended status tables. In Google, search for
- <quote>GStreamer Status Tables</quote> to get an idea of what they
- were. They have never been updated since, and were removed some time
- ago because they were hopelessly outdated. We would like to see those
- status tables revived, but slightly differently.
- </description>
- <why>
- The idea of plugin/element status tables is very useful, though. It
- allows users to see what formats are supported (by element name, by
- mimetype, etc.), particular notes on that format and how well it is
- supported, plus maybe even download locations. It allows end users,
- who see Totem telling that <application>GStreamer</application> does
- not support some mimetype found in their media file, to actually
- find a solution by knowing which additional plugin to install.
- </why>
- <how>
- The reason that the status tables were abandoned was because they were
- hopelessly outdated and nobody maintained them. What we would like is
- a system that is not too hard to maintain. Ideally, the submitter would
- help us maintaining it, although that is not a requirement.
- <br/>
- The initial setup is most difficult. You'll need to gather a list of
- information that you want to display for each plugin/element, e.g.
- a small description of the plugin, its name, contained elements,
- handled mimetypes, dependency and where to get it and possibly a short
- status summary. Some of this information (like descriptions, handled
- mimetypes, plugin-/elementnames) can be extracted from the source.
- You probably want to do that, since it saves you a lot of work. All
- other information, like the small status description, dependency and
- where to get that, need to be added either alternatively, or needs
- to be added in some way to the sources as well so that it can be
- extracted from the sources.
- After the initial setup is done, we'd like someone to maintain the
- list to be somewhat up-to-date from time to time. You may want to
- improve the element/plugin descriptions once you've found that they
- are really quite lousy (they are), but that's a later concern.
- Note that the <application>GStreamer</application> website is written
- in XML, not HTML. Thus, make sure that whatever method you use to
- generate the tables outputs XML files compatible with the rest of
- the website so that it's an integral part of the website.
- </how>
- <where>
- <code id="website">
- <name>GStreamer website</name>
- <description>The GStreamer website module in GStreamer
- CVS.</description>
- </code>
- </where>
- <difficulty>
- MEDIUM: extracting the required information from all elements will
- require some scripting capabilities (especially since we'll want to
- maintain it after the initial work is done). However, apart from that,
- it requires no actual coding, and is mostly just a whole bunch of work
- that is not particularly difficult.
- </difficulty>
- <notes>
- You'll probably need to ask other people about details on how well
- each element/plugin works for the status descriptions. Feel free to
- ask people on IRC (irc.freenode.net, #gstreamer) for details here.
- </notes>
- <see>
- <person>Ronald</person>
- <person>Thomas</person>
- <person>Christian</person>
- </see>
- </task>
-<task name="686basicomega">
- <title>Make basicomega scheduler work with i686 glibc</title>
- <description>
-One of the fastest schedulers we have is the one called basicomega.
-Unfortunatly we have been bared from using it as the default for quite a
-while because it segfaults when you use a version of glibc that has been
-compiled with -march=686. This means that the standard glibc used with
-major distributions like Mandrake and Red Hat cause this scheduler to crash.
- </description>
- <why>
-Context switching is one of the tasks the scheduler does most. And the
-faster the better. For many heavy applications being able to use this
-scheduler would be a great boon.
- </why>
- <how>
-If we knew we would have fixed it long ago ourselves.
-Andy Wingo says the following:
-<BR/>
-"As you know, omega cothreads uses up the stack in pieces, one piece per
-element. It assumes that it has 2M of stack space to work with, divided
-into 16 pieces (see the top of cothreads.c). Now this 2M size is
-arbitrary, and based on the old pre-i686 glibc's default stack size.
-For new threads in gstthread.c, we explicitly ask for a 2M stack. But
-for the main thread, we never try to query or even change the size with
-getrlimit/setrlimit(2). I would suggest looking here for a solution (try
-calling setrlimit(RLIMIT_STACK,rlim_struct_for_2M).
-<br/>
-So what might be happening is too many (more than 8) elements are being
-put into the main thread and it's trying to use memory that doesn't
-belong to it.Note also that the STACK_SIZE macro in cothreads.c and the
-STACK_SIZE macro in gstthread.c depend on each other.<br/>
-Just keep in mind the saying about the worth of free advice :-)"
- </how>
- <where>
- <code id="basicomega">
- <name>Implementation of basicomega scheduler</name>
- <description>C file with the code for the scheduler</description>
- </code>
-
- </where>
- <difficulty>
-HARD - Demands detailed knowledge of how glibc internals work and compiler optimizations.
- </difficulty>
- <see>
- <person>Andy</person>
- <person>David</person>
- </see>
- </task>
-</tasks>
+ </tasks>
</page>
|