On Thu, Jul 19, 2012 at 10:31 AM, Timothy B. Terriberry < [email protected]> wrote:
> Both of these things propagate the blocking status through the graph. I > don't know how this interferes with our plan to add cycles to the graph, > since apparently we have to do that to support the Web Audio API. > It's fine, these features are compatible. I've always viewed MediaStreams made up of tracks from other MediaStreams > as just a special case of ProcessedMediaStream. That is exactly how I've implemented them internally. > If it were an actual ProcessedMediaStream, you could do everything you > want to do here with these blocking flags. I.e., you unset blockInput on > the stream feeding to PeerConnection/local preview. I will provide the blockInput and blockOutput functionality at the MediaStreamGraph level. We won't expose them to the DOM API (yet) but you'll be able to use them from C++. Those flags are properties of the MediaInputPorts of a ProcessedMediaStream, so you'll need to configure some kind of ProcessedMediaStream in order to use them. There is one other piece that needs to be added to the infrastructure: we should also have a mode flag for SourceMediaStream so that while it's blocked, we throw away buffered data. I think that's what Randell wanted originally. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47] _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
