From 2c86c99241fde47f96f52c4f8c832c3f9e0578ce Mon Sep 17 00:00:00 2001 From: Wim Taymans Date: Tue, 6 Nov 2007 10:21:01 +0000 Subject: [PATCH] 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. --- ChangeLog | 11 +++++++++++ MAINTAINERS | 2 +- docs/design/part-TODO.txt | 22 ++++++++++++++++++++-- docs/design/part-buffering.txt | 21 +++++++++++++++++++++ 4 files changed, 53 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 14930d38c3..e0116c36ed 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2007-11-06 Wim Taymans + + * 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 * tests/check/gst/gstobject.c: diff --git a/MAINTAINERS b/MAINTAINERS index 13a45eb089..5f671888c2 100644 --- 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 - Wim Taymans + Wim Taymans David Schleef Thomas Vander Stichele diff --git a/docs/design/part-TODO.txt b/docs/design/part-TODO.txt index 626562add6..a3813bdc06 100644 --- 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 67a4fe4aff..10f093ef96 100644 --- 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 --------------------