mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-23 10:11:08 +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> 2007-10-03 Stefan Kost <ensonic@users.sf.net>
* tests/check/pipelines/simple-launch-lines.c: * 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 The tagreading (metadata reading) use case for mediacenter applications is not
to well supported by the current GStreamer architecture. It uses demuxers on the 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. that just do the tag-reading.
The idea is to have one plugin 'tagread' simmilar to 'typefind' that provides 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 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. 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. 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 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 * 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 * e.g. album-art via web, video-thumbnails
* what about caching backends * what about caching backends
* it would be good to allow applications to supply tagbin with a tagcache- * 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 object instance. Whenever tagbin gets a 'location' to tagread, it consults
cache first. whenever there is a cache-miss it will tag-read and then store the cache first. whenever there is a cache-miss it will tag-read and then
in the cache store in the cache
GstTagList *gst_tag_cache_load_tag_data (GstTagCache *self, const gchar *uri); 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); gst_tag_cache_store_tag_data (GstTagCache *self, const gchar *uri, GstTagList *tags);