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

[Florian Winter]

Ross Finlayson wrote:

>
>>         fMaxSize = fPreferredFrameSize;
>
>
> Once again, this is wrong.  "fMaxSize" (just like "fTo") is an input 
> parameter (which was set in the original call to "getNextFrame()").  
> It's not something that you set yourself (in "doGetNextFrame()").
>
> Once again, to summarize: In your "doGetNextFrame()" member function 
> implementation, you
> - *read* (but don't set) "fTo" and "fMaxSize"
> - *set* "fFrameSize" and "fPresentationTime"
> - *optionally set* (if you know the values) "fNumTruncatedBytes" and 
> "fDurationInMicroseconds".
>
Wouldn't there be much less confusion, if these input and output 
parameters were just arguments to
getNextFrame? If the signature of that function was

    getNextFrame(size_t max_size, void* to, size_t& frame_size, ...)

it would be clear to everyone how to use these values. of course this 
means changing the interface and would
break existing code...

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
than the sink. for example a network source (such as RTPSource) might 
want to read data from the socket as fast
as possible (to prevent data from being overwritten in the socket 
receive buffer) and let the sinks process the data
only if the buffer overflows. likewise, a live source can't deliver data 
"on demand" when the sinks registers its read
interest.
I may of course be wrong. our multimedia framework uses a push strategy, 
and this causes problems with integrating
live, but this is our problem...

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.
in NMM we have one seperate framework which does ALL of the buffer 
management, and all components (nodes,
transport strategies, etc) just use it and don't have to worry about 
buffer management at all. that's why it is so easy to develop
new plugins for NMM. it also allows passing buffers from one node to 
another by simple pointer forwarding, provided
that the data (size) doesn't change. also the buffer manager reuses 
previously discarded buffers, so no memory allocation/deallocation
is actually done once a flowgraph is running. this makes the buffer 
management completely adaptive.

I can understand that implementing a powerful buffer management 
framework is hard work, and probably not something
you want to focus on. On the other hand, application or framework 
developers *using* live might not even want to have this
functionality implemented in live, because their frameworks come with 
buffer managers of their own. for us it would be just fine,
if we could just "plug in" our own buffer management into live (for 
example by overriding some methods in UsageEnvironment),
so that live can use it.

these are just some thoughts, please don't read them as flames. libLive 
still seems to be the most mature open source streaming libary
which is available, that's why we use it for adding RTP support to NMM. 
keep up the good work.