[Live-devel] delay in playback/transfer?

[Ross Finlayson]

>>Does your "DeviceSource" implementation deliver complete, discrete MPEG-4 
>>video frames (rather than an arbitrarily framed byte stream)?
>>If so, then you should use a "MPEG4VideoStreamDiscreteFramer" rather than 
>>a "MPEG4VideoStreamFramer".  ("MPEG4VideoStreamFramer" includes some 
>>buffering/parsing overhead that might be contributing to the delay that 
>>you see.)
>
>Yes, we are using discrete framer.
>Any other ideas?

Because your "DeviceSource" implementation delivers frames 'live' (rather 
than from a pre-recorded file, for example), then you can try setting 
"fDurationInMicroseconds" to zero (or else not set it at all, which will 
have the same effect).  That probably won't make a difference, though.

As long as you are arranging for "FramedSource::afterGetting()" to be 
called immediately after you've grabbed a frame from your encoding device, 
then the LIVE.COM code shouldn't introduce introduce any significant 
delay.  (At this point, the video frame data will be passed almost 
immediately through "MPEG4VideoStreamDiscreteFramer" and 
"MultiFramedRTPSink", and get sent out in a RTP packet.)

If you're still seeing a significant delay (and you're sure that it's not 
occurring at the client end), then perhaps the delay is occurring in your 
hardware encoder?

>We are currently trying to find some way to transform "main" frames to 
>"simple" frames. Is there som way to do this with the liveMedia suit?

No.  The "liveMedia" code doesn't include any codec-specific functionality 
like this.

>  I guess not, any hints on how we could do this? Our hardware encoder api 
> does not have any setOutputFramesFormat(simple); functions :)

If you wanted to do this in software, then I suggest doing so in (a 
modified version of) "MPEG4VideoStreamDiscreteFramer", because that's a 
point in the code where it's already does some rudimentary parsing of 
MPEG-4 video headers, etc.


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