mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-26 03:31:05 +00:00
Code Issues 1 Projects Releases Wiki Activity

faq updates metadata/mediainfo

Browse source 
Original commit message from CVS:
faq updates
metadata/mediainfo
This commit is contained in:
Thomas Vander Stichele 2002-11-29 13:56:23 +00:00
parent 0bb8c8b7f7
commit f6f841cbb8
4 changed files with 197 additions and 45 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
docs/faq/getting.xml
View file

@ -9,14 +9,35 @@
<answer>
<para>
You have multiple options available. Our primary method of distribution is by providing tarballs of our releases. You find these tarballs on our
<ulink url="http://sourceforge.net/project/showfiles.php?group_id=1936">Sourceforge files page.</ulink>
Generally speaking, you have three options, ranging from easy to hard :
<itemizedlist>
<item><link linkend="getting-gstreamer-packages">
distribution-specific packages</link></item>
<item><link linkend="getting-gstreamer-source">
source tarballs</link></item>
<item><link linkend="getting-gstreamer-packages">
CVS</link></item>
</itemizedlist>
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="getting-gstreamer">
<question id="getting-gstreamer-source">
<para>How can I install GStreamer from source ?</para>
</question>
<answer>
<para>
We provide tarballs of our releases on our
<ulink url="http://sourceforge.net/project/showfiles.php?group_id=1936">
Sourceforge files page.</ulink>
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="getting-gstreamer-packages">
<para>Are there premade binaries available ?</para>
</question>
@ -34,7 +55,7 @@
</qandaentry>
<qandaentry>
<question id="getting-gstreamer">
<question id="getting-gstreamer3">
<para>Why don't you provide premade binaries for distribution XY ?</para>
</question>
@ -46,7 +67,7 @@
</qandaentry>
<qandaentry>
<question id="getting-gstreamer">
<question id="getting-gstreamer4">
<para>I am having trouble compiling GStreamer on my LFS installation, why ?</para>
</question>
@ -58,5 +79,16 @@ neither can or want to know enough, about how your unique system is configured,
</answer>
</qandaentry>
<qandaentry>
<question id="getting-gstreamer-cvs">
<para>How do I get GStreamer through CVS ?</para>
</question>
<answer>
<para>
</para>
</answer>
</qandaentry>
</qandaset>
</sect1>

63
docs/faq/troubleshooting.xml
View file

@ -2,6 +2,69 @@
<title id="title-troubleshooting">Troubleshooting GStreamer</title>
<qandaset>
<qandaentry>
<question id="troubleshooting-missing-plug-in">
<para>
Some application is telling me that I am missing a plug-in. What do I do ?
</para>
</question>
<answer>
<para>
Well, start by checking if you really are missing the plug-in.
<programlisting>
gst-inspect (plug-in)
</programlisting>
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.
</para>
<para>
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.
<itemizedlist>
<listitem>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.
</listitem>
<listitem>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 !
</listitem>
<listitem>
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.
</listitem>
</itemizedlist>
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="troubleshooting-old-plug-ins">
<para>
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 ?
</para>
</question>
<answer>
</answer>
</qandaentry>
<qandaentry>
<question id="troubleshooting-segfault">
<para>

39
docs/faq/using.xml
View file

@ -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.
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="using-sound">
<para>Can my system play sound through GStreamer ?</para>
</question>
<answer>
<para>
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
<itemizedlist>
<listitem>osssink for OSS output</listitem>
<listitem>esdsink for ESound output</listitem>
<listitem>artssink for aRTs output</listitem>
<listitem>alsasink for ALSA output</listitem>
<listitem>jacksink for JACK output</listitem>
</itemizedlist>
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
<programlisting>
$ gst-inspect osssink
</programlisting>
and see if that prints out a bunch of properties for the plug-in.
</para>
<para>
Then try to play the sine tone by running
<programlisting>
$ gst-launch sinesrc ! osssink
</programlisting>
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.
</para>
</answer>
</qandaentry>

98
docs/random/thomasvs/metadata
View file

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