MAINTAINERS: Update with new email address.
authorWim Taymans <wim.taymans@gmail.com>
Tue, 6 Nov 2007 10:21:01 +0000 (10:21 +0000)
committerWim Taymans <wim.taymans@gmail.com>
Tue, 6 Nov 2007 10:21:01 +0000 (10:21 +0000)
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.

ChangeLog
MAINTAINERS
docs/design/part-TODO.txt
docs/design/part-buffering.txt

index 14930d38c37691d1740aaa7249c763284d1936a6..e0116c36edf6cdbad126c63d1de6dce991adca2f 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:
index 13a45eb089dfbe2edd9c4c73d97ab48f02ec6a6b..5f671888c2ab8b6f34e92d4ac29d97d0eb1695e7 100644 (file)
@@ -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>
 
index 626562add6cb47db5cbb0d4531f565efc07b899b..a3813bdc06067fdde80be6d9ea8c7f7704079974 100644 (file)
@@ -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
index 67a4fe4aff2435d7188b124e31ff8a13bd822c46..10f093ef96e7cd5d5affec0f63d3e1bbc55c39b4 100644 (file)
@@ -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
 --------------------