[gstreamer-bugs] [Bug 564749] tagreadbin + GstTagReader interface
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Mon May 18 04:16:26 PDT 2009
If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
http://bugzilla.gnome.org/show_bug.cgi?id=564749
GStreamer | gst-plugins-base | Ver: git
Tim-Philipp Müller changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #124802|0 |1
is obsolete| |
Attachment #124804|0 |1
is obsolete| |
------- Comment #11 from Tim-Philipp Müller 2009-05-18 11:16 UTC -------
Created an attachment (id=134859)
--> (http://bugzilla.gnome.org/attachment.cgi?id=134859&action=view)
GstTagReader interface, tagreadbin, and gst-tagread test application
First stab at fast tag reading implementation based on the
make-it-work-first-optimise-later school of thought. It mostly works great
already (excl. ogg files maybe), but will only really shine once elements are
fixed up a bit more. I think the main priority is to settle on the API and
design now and do the micro-tinkering later.
Rationale and design goals:
- people often only want the tags and metadata of
a file; as fast as possible and with a convenient
API; they don't have to get the information from
different places (tags, caps, queries etc.)
- people don't want to deal with dynamic pads,
"prerolling", queries, caps, taglist merging
etc. just to get some tags.
- people want global info and per-stream info and
stream types (audio/video/subtitle)
- implementation detail: we don't want to plug any
decoders to get to this info, for two reasons:
(a) speed / overhead, (b) to make it possible to
extract tags on embedded/mobile devices without
starting up or interfering with or be blocked by
hardware decoders
- the design should allow for optional thumbnailing
(currently not implemented)
==========================================
Main components of this patch (I don't think single patches make this easier to
review, so I made a big one), in the order they appear in the patch:
- docs
- GstTagReader interface, in libgsttag-0.10: basically a
dummy interface elements can implement so their tag-reading
behaviour can be fine-tuned (e.g. demuxers can skip index
processing). One *could* do without this interface, but the
alternatives are not very nice from an API/discoverability
perspective, or involves unnecessary overhead like double
plugin feature registration or so.
- make decodebin2 and uridecodebin implement the tag reader
interface and propagate the tag reading mode set to any
tag reader elements they auto-plug into the pipeline
- tagreadbin: this is a stand-alone pipeline element similar
to playbin, only that it reads tags given a URI. You set
the "uri" property, set it to PLAYING state and will get
a TAG message on the bus for the global tags, and then
one tag messages for each stream, followed by an EOS
message.
In terms of implementation, tagreadbin will internally
plug a uridecodebin and do special filtering of what
elements get plugged via the "autoplug-continue" and
"autoplug-factories" signals. It will stop autoplugging
when it gets a pad with width/height or rate/channels
caps and a duration query succeeds, or if there are no
other elements to plug.
The exposed uridecodebin pads are linked to an internal
tagsink element with N inputs (request pads), which
will collect the tags via the stream events, and merge
and filter the various tags, and decide when it has
enough information from all streams to stop. It will
also extract things like width/height rate/channels
from the caps and do duration queries on all streams
etc.
- last, the gst-tagread example, which uses tagreadbin
to extract tags and prints them as they come in. It
takes filenames and directories and will recurse
into directories. The output will look something
like this:
URI: file:///home/tpm/samples/m101758-push-mode-mjpeg.avi
CONTAINER TAGS:
duration: 20817981859
container format: AVI
STREAM #1 TAGS:
audio codec: Uncompressed 24-bit PCM audio
channels: 2
rate: 44100
duration: 20817981859
STREAM #2 TAGS:
video codec: Motion JPEG
width: 320
height: 240
framerate: 25/1
duration: 20800000000
URI: file:///home/tpm/samples/dirac-sage-640x360.mov
CONTAINER TAGS:
duration: 14888333333
container format: Quicktime
STREAM #1 TAGS:
video codec: Dirac
description: audiotest wave
width: 640
height: 360
framerate: 24/1
duration: 14888333333
STREAM #2 TAGS:
audio codec: MPEG-4 AAC audio
description: audiotest wave
channels: 2
rate: 48000
duration: 14888333333
URI: file:///home/tpm/samples/577468-id3-synchronisation-working.mp3
CONTAINER TAGS:
duration: 10224000000
container format: ID3 tag
STREAM #1 TAGS:
audio codec: MPEG 3 Audio, Layer 3 (MP3)
has crc: FALSE
channel mode: mono
image: buffer of 9928 bytes, type: image/gif,
image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_UNDEFINED
album: Album
genre: Pop
title: ARTIST
artist: 藝人
channels: 1
rate: 8000
duration: 10224000000
(Yes, the info from the ID3 tag should be in the global tags section, which it
will be after a fix to id3demux.)
--
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.
You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=564749.
More information about the Gstreamer-bugs
mailing list