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

docs/design/draft-tagreading.txt: Add some more thoughts.

Browse source 
Original commit message from CVS:
* docs/design/draft-tagreading.txt:
Add some more thoughts.
This commit is contained in:
Stefan Kost 2007-10-03 15:02:43 +00:00
parent de65ce3486
commit f8b2b6c70d
2 changed files with 15 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ChangeLog
View file

@ -1,3 +1,8 @@
2007-10-03 Stefan Kost <ensonic@users.sf.net>
* docs/design/draft-tagreading.txt:
Add some more thoughts.
2007-10-03 Stefan Kost <ensonic@users.sf.net>
* tests/check/pipelines/simple-launch-lines.c:

16
docs/design/draft-tagreading.txt
View file

@ -3,7 +3,7 @@ Tagreading
The tagreading (metadata reading) use case for mediacenter applications is not
to well supported by the current GStreamer architecture. It uses demuxers on the
files, which generelly said takes too long. what we want is secialized elements
files, which generelly said takes too long. what we want is specialized elements
that just do the tag-reading.
The idea is to have one plugin 'tagread' simmilar to 'typefind' that provides
@ -13,6 +13,9 @@ would be that when building a metadatabase one only loads this plugin.
Then there would be a tagbin, that similar to decodebin does a typefind and then
plugs the right tagread element. It might plug a demuxer as a fallback solution.
For optimal performance typefind and tagread could share the list of already
peeked buffers.
Still it would be nice to reuse code from demuxers/tag-filters.
@ -38,15 +41,16 @@ The plan is that applications can do the following:
Open Issues
-----------
* would it make sense to have 2-phase tag-reading
* would it make sense to have 2-phase tag-reading (property on tagbin and/or
tagread elements)
* 1st phase: get tag-data that are directly embedded in the data
* 2nd phase: get tag-data that has to be generated fetched
* 2nd phase: get tag-data that has to be generated
* e.g. album-art via web, video-thumbnails
* what about caching backends
* it would be good to allow applications to supply tagbin with a tagcache-
object instance. whenever tagbin gets a uri to tagread, it consults the
cache first. whenever there is a cache-miss it will tag-read and then store
in the cache
object instance. Whenever tagbin gets a 'location' to tagread, it consults
the cache first. whenever there is a cache-miss it will tag-read and then
store in the cache
GstTagList *gst_tag_cache_load_tag_data (GstTagCache *self, const gchar *uri);
gst_tag_cache_store_tag_data (GstTagCache *self, const gchar *uri, GstTagList *tags);