Thank you Ross, That solved my issue with audio packets being properly
transmitted. I am still facing issue with Audio at reception side. When
I try with VLC it gives ausio for half a second and then stops. If i
stop and start VLC again it agian gives audiio for half a second and
stops. Then i tried with ffmpeg. FFmpeg reports that the audio codec is
(null) and shows mono channels whereas VLC shows proper codec which is
AC3 and stereo channels.
I am using AC3 codec to encode audio and then stream it using
AC3AudioStreamFramer and AC3AudioRTPSink. Am i doing anything wrong ? I
also found that somone used MPEG4GenericRTPSink for audio. Is it right?
PS: I apologize for my last repeated email.
Thanks
On 2013-10-24 13:03, Ross Finlayson wrote:
Thank you Ross for clarification, its more clear now. Now I am
facing issue that i have separate thread that pushes audio packets
for my device source to stream. I trigger event each time I push
packet to that queue. I noticed that on VLC my audio comes for about
a second and then stops. When I debugged my code I found that I have
more than 1000 packets in my audio queue waiting to be streamed by
devicesource.
I think what is happening is that whenever I trigger an event and
that event is already happening it ignores it, is it correct? Whats
is the correct way to handle this. I think the audio packets should
be streamed at the same rate as they are being encoded from live
source.
This should all be OK, provided that your "doGetNextFrame()"
implementation knows to check for (queued) data that is immediately
available, rather than always waiting for a triggered event. Note this
code on lines 87-90 of "DeviceSource.cpp":
// If a new frame of data is immediately available to be delivered,
then do this now:
if (0 /* a new frame of data is immediately available to be
delivered*/ /*%%% TO BE WRITTEN %%%*/) {
deliverFrame();
}
Replace the "0" with some test that checks whether queued data is
immediately available. (Remember that because your queue data
structure is also being written to by the encoding thread, it needs to
be 'thread safe'.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ [1]
Links:
------
[1] http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
