MAINTAINERS: Update with new email address.

Original commit message from CVS:
* MAINTAINERS:
Update with new email address.
* docs/design/part-TODO.txt:
Add some more info about future pad-block and negotiation changes.
* docs/design/part-buffering.txt:
Add some ideas about buffering reporting.

diff --git a/ChangeLog b/ChangeLog
index 14930d3..e0116c3 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2007-11-06  Wim Taymans  <wim.taymans@gmail.com>
+
+       * MAINTAINERS:
+       Update with new email address.
+
+       * docs/design/part-TODO.txt:
+       Add some more info about future pad-block and negotiation changes.
+
+       * docs/design/part-buffering.txt:
+       Add some ideas about buffering reporting.
+
 2007-11-06  Jan Schmidt  <jan.schmidt@sun.com>
 
        * tests/check/gst/gstobject.c:

diff --git a/MAINTAINERS b/MAINTAINERS
index 13a45eb..5f67188 100644 (file)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2,7 +2,7 @@ GStreamer is currently maintained by the consensus of a number
 of people, including, but not limited to:
 
  Jan Schmidt <thaytan@noraisin.net>
- Wim Taymans <wim@fluendo.com>
+ Wim Taymans <wim.taymans@gmail.com>
  David Schleef <ds@schleef.org>
  Thomas Vander Stichele <thomas@fluendo.com>
 

diff --git a/docs/design/part-TODO.txt b/docs/design/part-TODO.txt
index 626562a..a3813bd 100644 (file)
--- a/docs/design/part-TODO.txt
+++ b/docs/design/part-TODO.txt
@@ -26,7 +26,8 @@ API/ABI
   (gstvalue/gststructure)
 
 - rethink how we handle dynamic replugging wrt segments and other events that
-  already got pushed and need to be pushed again.
+  already got pushed and need to be pushed again. Might need GstFlowReturn from
+  gst_pad_push_event().
 
 - keep track of seeks with a counter so that we can match seek events received
   in the demuxer srcpads. This is needed because a normal seek on a pipeline
@@ -37,6 +38,12 @@ API/ABI
   that resulted from the seek so that everything seek related can be tracked
   properly.
 
+- Optimize negotiation. We currently do a get_caps() call when we link pads,
+  which could potentially generate a huge list of caps and all their
+  combinations, we need to avoid generating these huge lists by generating them
+  incrementaly when needed. We can do this with a gst_pad_iterate_caps() call.
+  We also need to incrementally return intersections etc, for this.
+
 - When an element goes to PAUSED there is no way to figure out the running time
   when this happened. One could think that we can store this time in the
   base_time field of the element but that causes problems when the element is
@@ -58,6 +65,17 @@ API/ABI
   There needs to be a mechanism for a live source to request a new base_time or
   pipeline restart.
 
+- pad block has several issues: 
+  * can't block on selected things, like push, pull, pad_alloc, events, ...
+  * can't check why the block happened. We should also be able to get the item/
+    reason that blocked the pad. 
+  * it only blocks on datapassing. When EOS, the block never happens but ideally
+    should because pad block should inform the app when there is no dataflow.
+  * blocking should only happen from one thread. If one thread does pad_alloc
+    and another a push, the push might be busy while the block callback is done.
+  * maybe this name is overloaded. We need to look at some more use cases before
+    trying to fix this.
+
 
 IMPLEMENTATION
 --------------
@@ -66,7 +84,7 @@ IMPLEMENTATION
 
 - implement BUFFERSIZE.
 
-- implement pad_block with probes.
+- implement pad_block with probes? see above.
 
 
 DESIGN

diff --git a/docs/design/part-buffering.txt b/docs/design/part-buffering.txt
index 67a4fe4..10f093e 100644 (file)
--- a/docs/design/part-buffering.txt
+++ b/docs/design/part-buffering.txt
@@ -52,6 +52,27 @@ with 100 percent value is received, which might only happen after the pipeline
 prerolled.
 
 
+Buffering Query
+---------------
+
+It is possible to query the amount of buffering performed in the pipeline, which
+is defined as the amount of data made available at the source. This amount is
+expressed in some GstFormat and is usually compared to the duration or position 
+of the media stream in the same GstFormat.
+
+The buffering query should return the following information:
+
+ - format
+ - position
+ - duration
+
+The format is of lesser importance, the ratio of position versus duration can be
+used to calculate the percentage of available media. It should also be possible
+for the application to calculate the expected time when the complete file will
+be buffered. 
+
+
+
 Incremental download
 --------------------