From f8b2b6c70d5bf294add99ffc205200e099b09b53 Mon Sep 17 00:00:00 2001 From: Stefan Kost Date: Wed, 3 Oct 2007 15:02:43 +0000 Subject: [PATCH] docs/design/draft-tagreading.txt: Add some more thoughts. Original commit message from CVS: * docs/design/draft-tagreading.txt: Add some more thoughts. --- ChangeLog | 5 +++++ docs/design/draft-tagreading.txt | 16 ++++++++++------ 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 704f3096e1..5555588a6c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2007-10-03 Stefan Kost + + * docs/design/draft-tagreading.txt: + Add some more thoughts. + 2007-10-03 Stefan Kost * tests/check/pipelines/simple-launch-lines.c: diff --git a/docs/design/draft-tagreading.txt b/docs/design/draft-tagreading.txt index 5e717b2fd4..b1272da12f 100644 --- a/docs/design/draft-tagreading.txt +++ b/docs/design/draft-tagreading.txt @@ -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);