[Live-devel] DeviceSource "not so clean" fix

[Ross Finlayson]

>Wouldn't there be much less confusion, if these input and output 
>parameters were just arguments to
>getNextFrame?

The 'in' parameters - "to" and "maxSize" - *are* parameters to 
"FramedSource::getNextFrame()".  The other parameters (the 'out' 
parameters) are passed to the 'after getting' function (which itself is a 
parameter to "FramedSource::getNextFrame()").  Note that due to the 
event-driven nature of the code, it's not possible to do everything with 
just a single function (with both in and out parameters).  With any 
event-driven code, you need one function to register interest in an event, 
and another function to actually handle the event, when it occurs.

>besides I am not so fond of this strategy of passing buffers from one 
>Medium to another, especially because
>it is a "pull", not a "push" strategy. typically the source should know 
>better when data is available for processing

It depends.  For some applications - e.g., streaming data that's being read 
from a file - the 'pull' approach - as used by the "liveMedia" library - 
seems most appropriate (to ensure that you end up reading from the input 
file at the correct rate).  It's not clear to me that one approach ('push' 
or 'pull') is inherently better than the other.

>I also realized, from reading the source, that most Media classes in 
>libLive do a lot of fiddling with buffer pointers.
>one of the worst of all is the MPEG1or2VideoStreamFramer. about 75% of the 
>code is only about buffer management.

No, that's not correct.  Most of that code does parsing of the various MPEG 
video headers - stuff that needs to be done for any implementation.

It's possible that in the future I'll also support an (optional) 
alternative memory management scheme, in which the data source can return - 
in the 'after getting' function - a *pointer* to a data buffer, rather than 
(as in the current scheme) requiring the data source to copy data into a 
buffer that was supplied by the sink.  That approach would - in some cases 
- be more efficient for things like raw UDP streaming, because it would 
eliminate some data copying.  (Note, though, that it wouldn't help for 
*RTP* streaming (because of the 12-byte RTP header), unless you also had a 
scatter-gather network interface.)

In most cases, though, the current memory management approach (where sinks 
pass a memory buffer to the source) actually seems cleaner and more 
efficient than the alternative, because it allows the final data sink to 
have complete control over the memory buffer.  For example, for RTP 
streaming the "RTPSink" does just one dynamic memory allocation - when it's 
created - and then uses this same memory buffer throughout its lifetime 
(with no more allocations or deallocations).


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>