diff --git a/docs/faq/getting.xml b/docs/faq/getting.xml
index f564ca8530..1ece463c3d 100644
--- a/docs/faq/getting.xml
+++ b/docs/faq/getting.xml
@@ -9,14 +9,35 @@
- You have multiple options available. Our primary method of distribution is by providing tarballs of our releases. You find these tarballs on our
-Sourceforge files page.
+Generally speaking, you have three options, ranging from easy to hard :
+
+
+distribution-specific packages
+
+source tarballs
+
+CVS
+
-
+
+ How can I install GStreamer from source ?
+
+
+
+
+We provide tarballs of our releases on our
+
+Sourceforge files page.
+
+
+
+
+
+ Are there premade binaries available ?
@@ -34,7 +55,7 @@
-
+ Why don't you provide premade binaries for distribution XY ?
@@ -46,7 +67,7 @@
-
+ I am having trouble compiling GStreamer on my LFS installation, why ?
@@ -58,5 +79,16 @@ neither can or want to know enough, about how your unique system is configured,
+
+
+ How do I get GStreamer through CVS ?
+
+
+
+
+
+
+
+
diff --git a/docs/faq/troubleshooting.xml b/docs/faq/troubleshooting.xml
index a02a08e7c2..b2fbcdd5b4 100644
--- a/docs/faq/troubleshooting.xml
+++ b/docs/faq/troubleshooting.xml
@@ -2,6 +2,69 @@
Troubleshooting GStreamer
+
+
+
+Some application is telling me that I am missing a plug-in. What do I do ?
+
+
+
+
+
+Well, start by checking if you really are missing the plug-in.
+
+gst-inspect (plug-in)
+
+and replace (plug-in) with the plug-in you think is missing.
+If this doesn't return any result, then you either don't have it or your
+registry cannot find it.
+
+
+If you're not sure either way, then chances are good that you don't have
+it. You should get the plug-in and run gst-register to register it.
+How to get the plug-in depends on your distribution.
+
+if you run GStreamer using packages for your distribution, you
+should check what packages are available for your distribution and see
+if any of the available packages contains the plug-in.
+
+if you run GStreamer from a source install, there's a good chance
+the plug-in didn't get built because you are missing an external library.
+When you ran configure, you should have gotten output of what plug-ins are
+going to be built. You can re-run configure to see if it's there.
+If it isn't, there is a good reason why it is not getting built.
+The most likely is that you're missing the library you need for it.
+Check the README file in gst-plugins to see what library you need.
+Make sure to remember to re-run configure after installing the supporting
+library !
+
+
+if you run GStreamer from CVS, the same logic applies as for a source install.
+Go over the reasons why the plug-in didn't get configured for build.
+Check output of config.log for a clue as to why it doesn't get built if
+you're sure you have the library needed installed in a sane place.
+
+
+
+
+
+
+
+
+
+
+I get an error that says something like
+
+(process:26626): GLib-GObject-WARNING **: specified instance size for type
+`DVDReadSrc' is smaller than the parent type's `GstElement' instance size
+What's wrong ?
+
+
+
+
+
+
+
diff --git a/docs/faq/using.xml b/docs/faq/using.xml
index ded44ee32e..b04971e1e2 100644
--- a/docs/faq/using.xml
+++ b/docs/faq/using.xml
@@ -42,14 +42,41 @@ execution ended after 5 iterations (sum 301479000 ns, average 60295800 ns, min 3
(Some parts of output have been removed for clarity) If it looks similar, then
GStreamer itself is running correctly.
+
+
+
+
+
+ Can my system play sound through GStreamer ?
+
+
+
-After this, you might want to try and see if GStreamer can play audio on your
-system. You need to combine two plug-ins for this test : sinesrc (which
-produces a pure tone) and an audio output plug-in. You should choose one
-that matches your current sound output and you should make sure you have
-it installed.
+You can test this by trying to play a sine tone. For this, you need to
+connect the sinesrc plug-in to an output plug-in that matches your hardware.
+A (non-complete) list of output plug-ins for audio is
+
+osssink for OSS output
+esdsink for ESound output
+artssink for aRTs output
+alsasink for ALSA output
+jacksink for JACK output
+
+First of all, run gst-inspect on the output plug-in you want to use to
+make sure you have it installed. For example, if you use OSS, run
+
+$ gst-inspect osssink
+
+and see if that prints out a bunch of properties for the plug-in.
+
+
+Then try to play the sine tone by running
+
+$ gst-launch sinesrc ! osssink
+
+and see if you hear something. Make sure your volume is turned up,
+but also make sure it is not too loud and you are not wearing your headphones.
-
diff --git a/docs/random/thomasvs/metadata b/docs/random/thomasvs/metadata
index a23b9a6afd..0aae098382 100644
--- a/docs/random/thomasvs/metadata
+++ b/docs/random/thomasvs/metadata
@@ -1,4 +1,4 @@
-I'll use this doc to describe how I think metadata should work from the
+I'll use this doc to describe how I think media info should work from the
perspective of the application developer and end user, and from that
extrapolate what we need to provide that.
@@ -9,16 +9,16 @@ away. A user is free to choose whatever plug-ins he has, and a developer
can code to the general API that GStreamer provides without having to deal
with the underlying codecs.
-It is important that GStreamer also handles metadata well and efficiently,
+It is important that GStreamer also handles media info well and efficiently,
since more often than not the same libraries are needed to do this. So
-to avoid applications depending on these libs just to do the metadata,
+to avoid applications depending on these libs just to do the media info,
we should make sure GStreamer provides a reasonable and fast abstraction
for this as well.
GOALS
-----
-- quickly read and write content metadata
-- quickly read stream metadata
+- quickly read and write "tags"
+- quickly read stream metadata (technical properties, length, audio props, ...)
- cache both kinds of data transparently
- (possibly) provide bins that do this
- provide a simple API to do this
@@ -29,7 +29,7 @@ The user or developer using GStreamer is interested in all information that
describes the stream. The library handles these two types differently
however, so I will use the following terms to describe this :
-- content metadata
+- metadata :
every kind of information that is tied to the "concept" of the stream,
and not tied to the actual encoding or representation of the stream.
- it can be altered without transcoding the stream
@@ -40,42 +40,69 @@ however, so I will use the following terms to describe this :
- year, track order, album
- comments
-- stream metadata
- every kind of information that is tied to the "codec" or "representation"
- used.
+- mediainfo
+ every kind of information that is tied to the "codec" used.
- cannot be altered without transcoding
- is the set of parameters the stream has been encoded with
- - describes properties of the stream itself
+ - describes properties of the encoded stream itself
+ - examples:
+ - bitrate targets (e.g. nominal), encoding mode (e.g. joint stereo)
+ - to this we also add "bitrate", but we query this through the pad_query
+ interface
+
+- format
+ every kind of information that is tied to the "raw" bitstream
+ - cannot be altered without decoding and changing the raw bitstream
- examples:
- samplerate, bit depth/width, channels
- - bitrate, encoding mode (e.g. joint stereo)
- - video size, frames per second, colorspace used
- length in time
-
+ - video size, frames per second, colorspace used
+ - the format is queried by getting the GstCaps of the pad that sources
+ the buffers
+
+- length in time and tracks for the whole stream
+ - gotten through pad queries
+ - stored in variables in the struct
+
+- immediate info
+ - examples:
+ - position in time
+ - current bitrate
+
+- tracks :
+ a media file or stream can contain multiple consecutive streams, which
+ we will call "tracks". GStreamer has a format for track used in querying
+ and seeking as well.
+ A track should be thought of as the whole of one single piece of media
+ inside a physical stream.
+ A track can have at most one set of tags, and has fixed "raw" properties.
EXAMPLE PIPELINES
-----------------
-reading content metadata : filesrc ! id3v1
+reading metadata : filesrc ! id3v1
- would read metadata from file
- id3v1 immediately causes filesrc to seek until it has found
- the (first) metadata
- that there is no metadata present
+ - id3v1 sends out a property notification with name "metadata" and
+ a GstCaps structure
resetting and writing content metadata :
- filesrc ! id3v1 reset=true artist="Arid" ! filesink
+ id3v1 reset=true artist="Arid" ! filesink
- effect: clear the current tag and reset it to only have Arid as artist
- id3v1 seeks to the right location, clears the tag, and writes the new one
- - filesrc might not be necessary here
- - this probably only works when doing an in-place edit
COST
----
-Querying metadata can be expensive.
-Any application querying for metadata should take this into account and
+Querying media info can be expensive.
+Any application querying for media info should take this into account and
make sure that it doesn't block the app unnecessarily while the querying
happens.
+The app should create an object, hand it a bunch of locations to query,
+and connect to the signal the app is going to send out.
+
In most cases, querying content data should be fast since it doesn't involve
decoding
@@ -83,25 +110,28 @@ Technical data could be harder and thus might be better done only when needed.
CACHE
-----
-Getting metadata can be an expensive operation. It makes sense to cache
-the metadata queried on-disk to provide rapid access to this data.
+Getting media info can be an expensive operation. It makes sense to cache
+the dia info queried on-disk to provide rapid access to this data.
It is important however that this is done transparently - the system should
be able to keep working without it, or keep working when you delete this cache.
The API would provide a function like
- gst_metadata_content_read_cached (location)
-or even
- gst_metadata_read_cached (location, GST_METADATA_CONTENT, GST_METADATA_READ_CACHED)
-to try and get the cached metadata.
+ gst_media_info_read_cached (media_info, location,
+ GST_MEDIA_INFO_METADATA,
+ GST_MEDIA_INFO_READ_CACHED);
-- check if the file is cached in the metadata cache
- - if no, then read the metadata and store it in the cache
+to try and get the cached metadata using the media info object.
+
+- check if the file is cached in the media info cache
+ - if no, then read the media info and store it in the cache
- if yes, then check the file against it's timestamp (or (part of) md5sum ?)
- if it was changed, force a new read and store it in the cache
- - if it wasn't changed, just return the cached metadata
+ - if it wasn't changed, just return the cached media info
+
For optimizations, it might also make sense to do
- GList * gst_metadata_read_many (GList *locations, ...)
+ GList * gst_metadata_read_many (media_info, GList *locations, ...)
+
which would allow the back-end to implement this more efficiently.
Suppose an application loads a playlist, for example, then this playlist
could be handed to this function, and a GList of metadata types could
@@ -131,13 +161,13 @@ so that we can drop the old ones.
The cache should use standard glibc.
FIXME: is it worth it to use gnome-vfs for this ?
-STANDARDIZATION OF METADATA
----------------------------
+STANDARDIZATION OF MEDIAINFO
+----------------------------
Different file formats have different "tags". It is not always possible
to map metadata to tags. Some level of agreement on metadata names is also
required.
-For technical metadata, the names or properties should be fairly standard.
+For media info, the names or properties should be fairly standard.
We also use the same names as used for properties and capabilities in
GStreamer.
@@ -168,13 +198,13 @@ audio and video (-> bitrate) or multiple audio or video streams. One way
to do this might be to make a metadata set for a stream a GList of metadata
for elementary streams.
-For content metadata, the standards are less clear.
+For metadata and tags, the standards are less clear.
Some nice ones to standardize on might be
- artist
- title
- author
- year
- - genre (touchy though)
+ - genre (messy though)
- RMS, inpoint, outpoint (calculated through some formula, used for mixing)
TESTING