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.
This commit is contained in:
Wim Taymans 2007-11-06 10:21:01 +00:00
parent 942b97b2cb
commit 2c86c99241
4 changed files with 53 additions and 3 deletions

View file

@ -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> 2007-11-06 Jan Schmidt <jan.schmidt@sun.com>
* tests/check/gst/gstobject.c: * tests/check/gst/gstobject.c:

View file

@ -2,7 +2,7 @@ GStreamer is currently maintained by the consensus of a number
of people, including, but not limited to: of people, including, but not limited to:
Jan Schmidt <thaytan@noraisin.net> Jan Schmidt <thaytan@noraisin.net>
Wim Taymans <wim@fluendo.com> Wim Taymans <wim.taymans@gmail.com>
David Schleef <ds@schleef.org> David Schleef <ds@schleef.org>
Thomas Vander Stichele <thomas@fluendo.com> Thomas Vander Stichele <thomas@fluendo.com>

View file

@ -26,7 +26,8 @@ API/ABI
(gstvalue/gststructure) (gstvalue/gststructure)
- rethink how we handle dynamic replugging wrt segments and other events that - 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 - 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 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 that resulted from the seek so that everything seek related can be tracked
properly. 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 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 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 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 There needs to be a mechanism for a live source to request a new base_time or
pipeline restart. 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 IMPLEMENTATION
-------------- --------------
@ -66,7 +84,7 @@ IMPLEMENTATION
- implement BUFFERSIZE. - implement BUFFERSIZE.
- implement pad_block with probes. - implement pad_block with probes? see above.
DESIGN DESIGN

View file

@ -52,6 +52,27 @@ with 100 percent value is received, which might only happen after the pipeline
prerolled. 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 Incremental download
-------------------- --------------------