From 6bb3d023059d98e278ea52bd76d7b7b187501bba Mon Sep 17 00:00:00 2001 From: Edward Hervey Date: Fri, 10 Oct 2008 14:31:03 +0000 Subject: [PATCH] docs/design/part-TODO.txt: Add another limitation of pad-blocking with segment seeks not pushing Original commit message from CVS: * docs/design/part-TODO.txt: Add another limitation of pad-blocking with segment seeks not pushing EOS events. --- ChangeLog | 6 ++++++ docs/design/part-TODO.txt | 2 ++ 2 files changed, 8 insertions(+) diff --git a/ChangeLog b/ChangeLog index 12c939a830..8925c4dee0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2008-10-10 Edward Hervey + + * docs/design/part-TODO.txt: + Add another limitation of pad-blocking with segment seeks not pushing + EOS events. + 2008-10-10 Jan Schmidt * win32/common/libgstbase.def: diff --git a/docs/design/part-TODO.txt b/docs/design/part-TODO.txt index 9737ee9741..ed1c356663 100644 --- a/docs/design/part-TODO.txt +++ b/docs/design/part-TODO.txt @@ -71,6 +71,8 @@ API/ABI 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. + * the same goes for segment seeks that don't push in-band EOS events. Maybe + segment seeks should also send an EOS event when they're done. * 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