|
From: Andy W. <wi...@po...> - 2005-04-18 14:39:37
|
Been thinking a bit more. On Mon, 2005-04-18 at 13:15 +0200, Andy Wingo wrote: > that > getrange(pad, offset, size, &buf) > keep its current semantics; > > and that > getrange(pad, -1, size, &buf) > mean to get the next SIZE bytes from the pad. Being able to pass the offset as a parameter to gst_pad_pull makes it seem like all sources are random access, which in fact is the exception. Maybe it's a good idea to explicitly begin random access by sending an event upstream, and make sure that all upstream elements support random access. The only point about this that's bothering me is the part of the code that figures out whether a connection should go into push or pull mode. Now gst_element_pads_activate does a check_get_range, which will figure out if upstream elements can handle a get_range and if so schedules the connection pull-based. Otherwise it's push-based. Buuuuut it might be misleading if you can't actually do random access, but the downstream element is assuming it's possible because it was activated in pull mode. The goal of this all is to (1) seek cheaply when necessary and (2) avoid reframing of buffers. Offset getrange allows (1) and (2), and offsetless getrange allows only (2) via the size parameter. Chain-based scheduling avoids neither. So maybe there is a hierarchy of activation methods: First GST_ACTIVATE_PULL_RANGE (getrange with offset) Otherwise GST_ACTIVATE_PULL (getrange, offset doesn't mean anything) Otherwise GST_ACTIVATE_PUSH (chaining, src element has control) PULL_RANGE would be a new activation method. That's what I'm looking at as a plan. Ciao, -- Andy Wingo http://wingolog.org/ |