[openbeosmediakit] Re: new decoder/encoder/extractor/writer API


Yes, the lack of this node quite astonished me. =20
Especially since I wanted it exactly for the purpose=20
set out in the one example I started.  (Audio out and
record to disk.)  As David so aptly pointed out, there
is an issue of copy vs. passing buffers.  Perhaps a
good splitter node would have two different types of
outputs: "copy" and "pass" buffers.  There might be
only 1 pass buffer, or perhaps more... (if you had
some sort of concept like "const" passing, where the
buffer would not be edited downstream, then downstream
nodes could possibly share a buffer)  1 is probably
a reasonable start though. :-)

This analysis will focus primarily on the 4 missing
parts of the API though, and not on my wish list for
new functionality. (to the extent I can restrain
myself :-) )  Since I believe it is related to the
decoder/extractor selection problem, I will also be
looking at streaming media to some extent.  Right now
I have to get back to work though. :-)

Andrew

-----Original Message-----
From: "David Shipman" <unlyrn@xxxxxxxxxxxxxxx>
Date: Tue, 13 Aug 2002 23:18:19 NZST (+1200)

> >http://wiki.bebits.com/page/OpenBeOS.MediaKit
> 
> Interesting.  A question though.
> 
> Is there really a need for a splitter node=3D3F
> 
> Cannot an input be connected to multiple outputs without the need for 
> a 
> special node=3D3F

With the current mediakit design - no, it can't. (I presume you mean 
one 
output to many inputs..)
A consumer node receives buffers - which it must either pass to another 
node, or "recycle". Most filtering/processing nodes will simply pass on 
the buffer directly, rather than copying its contents - but in order to 
send to an additional destination, the node needs to create an 
additional buffer.

I have a working audio splitter node which does just that - I imagine 
it
should be easy enough to adapt for other formats.

David Shipman

Other related posts: