I am having an issue on the streaming-out side. The audio and video
encoders read raw data from shared buffers using two derived
FramedSource classes modeled after DeviceSource.cpp. The
deliverFrame() function in these derived classes read raw audio and
video from respective shared buffers, encodes them using ffmpeg
libraries, fills up the buffers and sets other parameters
appropriately, before returning. Occasionally, when a shared buffer
is accessed for read, there is'nt enough data avaialable to read,
possibly due to jitter in processing time on the write side of the
shared buffers. What is the right action in that case?
If your "doGetNextFrame()" implementation can't deliver data (to its
downstream object) immediately, it should instead just return
(*without* calling "FramedSource::afterGetting()", because you
haven't delivered any data in this case). In this case, the future
availability of sufficient data must be handled via an event in the
event loop (delayed 'polling' using
"TaskScheduler::scheduleDelayedTask()" is one way to do this, if you
can't make the arrival of new data an 'event' in any other way).
If my buffer reader waited a few milli-secs until there is enough
data available to read (by using Events or otherwise), the receiver
side VLC player freezes. If I return with fFramesize = 0
No, don't do this.
, the application crashes. The only thing that seems to work is if I
re-encoded the previous frame (for video) and encoded all-zero (for
audio), and filled up the buffers and other parameters the normal
way. Even in this case, the receiving VLC player freezes every few
min or so.
This 'freezing' suggests one of two possibilities:
1/ You might not be setting presentation times correctly on the data,
before it gets fed to a "MultiFramedRTPSink" (subclass). Your
"doGetNextFrame()" implementation should set "fPresentationTime",
before calling "FramedSource::afterGetting()".
2/ Your "doGetNextFrame()" implementation might not be setting
"fDurationInMicroseconds" correctly, thereby causing the downstream
"MultiFramedRTPSink" to delay excessively (after sending a RTP
packet) before requesting new data. Because you are streaming from a
live source - rather than from a prerecorded file - you might be able
to get away with not setting "fDurationInMicroseconds" at all (which
will cause it to keep its default value of zero).
I hope this helps.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
