[Live-devel] True push DeviceSource

[ssingh at neurosoft.in]

Any input on this?

On 2013-10-23 11:49, ssingh at neurosoft.in 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.
> 
> Thanks
> 
> 
> On 2013-10-22 06:13, Ross Finlayson wrote:
>>> I am confused as how the event mechanism works in live555. I have a
>>> source that is fed with video and audio frames and I want to trigger
>>> doGetNextFrame() of my custom DeviceSource so that those frames are
>>> streamed using live555. For this I am using
>>> 
>>> m_eventID =
>>> envir().taskScheduler().createEventTrigger(deliverFrame0);
>>> envir().taskScheduler().triggerEvent(m_eventID, this);
>> 
>> The "this" in the "triggerEvent()" call is wrong, because you should
>> not be calling "triggerEvent()" from within one of your 'DeviceSource'
>> class's member functions. "triggerEvent()" should be called from a
>> *separate thread* - the thread that is doing your encoding. Because
>> this separate thread is not the LIVE555 thread, then "triggerEvent()"
>> is the *only* LIVE555 code that it is allowed to be calling.
>> 
>>> void MyStreamingDeviceSource::deliverFrame0(void* clientData)
>>> {
>>> ((MyStreamingDeviceSource*)clientData)->doGetNextFrame();
>>> }
>> 
>> No, don't do this. "deliverFrame0()" should call "deliverFrame()", as
>> illustrated in the "DeviceSource" code.
>> 
>>> But doGe[Next]tFrame is called when I called
>>> videoSink->startPlaying() too which is not valid for me as I dont
>>> have any data yet to stream.
>> 
>> That's OK. When data later *does* become available, then your separate
>> 'encoder' thread will call "triggerEvent()", and then "deliverFrame()"
>> will be called.
>> 
>>  Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/ [1]
>> 
>> 
>> Links:
>> ------
>> [1] http://www.live555.com/
>> 
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel