From f6f841cbb83dea9728e1106b1e48ea9afbf3dd1c Mon Sep 17 00:00:00 2001 From: Thomas Vander Stichele Date: Fri, 29 Nov 2002 13:56:23 +0000 Subject: [PATCH] faq updates metadata/mediainfo Original commit message from CVS: faq updates metadata/mediainfo --- docs/faq/getting.xml | 42 ++++++++++++++++--- docs/faq/troubleshooting.xml | 63 ++++++++++++++++++++++++++++ docs/faq/using.xml | 39 ++++++++++++++--- docs/random/thomasvs/metadata | 98 ++++++++++++++++++++++++++++--------------- 4 files changed, 197 insertions(+), 45 deletions(-) diff --git a/docs/faq/getting.xml b/docs/faq/getting.xml index f564ca8..1ece463 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 a02a08e..b2fbcdd 100644 --- a/docs/faq/troubleshooting.xml +++ b/docs/faq/troubleshooting.xml @@ -3,6 +3,69 @@ + + +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 ? + + + + + + + + The GStreamer application I used stops with a segmentation fault. What can diff --git a/docs/faq/using.xml b/docs/faq/using.xml index ded44ee..b04971e 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 a23b9a6..0aae098 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 -- 2.7.4