[Live-devel] Newbie with a DirectShow headache

[Ralf Globisch]

Hi Iain,


Here's my two cents on the topic: 


Ross, I hope this is not too OT but it is closely related to live555
since it concerns the integration with DirectShow.


The problem of integrating live555 and DirectShow consists of two main aspects:
- DirectShow requires you to "know" the media type in order to setup a 
DirectShow media pipeline (generate output pins as Jeremy stated): You 
need to send an RTSP DESCRIBE to the server before your filter can 
generate an output pin and before GetMediaType is called. To send the DESCRIBE with live555
and process responses you need to start the live555 eventloop. 
Since this eventloop is blocking, you need to start it in a separate thread.


- Integration between live555 single-threaded eventloop and DirectShow's source 
filter eventloop via CSource::DoBufferProcessing): use some kind of shared queue or memory.


Also, it might be helpful search the mailing lists for topics related to a "watch variable". 
This allows you to control the live555 eventloop.


Like John stated, you can download our live555-based OS RTSP filter from sourceforge.
I'll explain the approach used in it: I decided to start a thread that is responsible only for 
the live555 RTSP related code in IFileSourceFilter::Load (This is your entry point when 
using WMP or GraphEdit/Studio). This thread will then issue RTSP requests like DESCRIBE. 
IFileSourceFilter::Load blocks on the result of this operation. Once the DESCRIBE is 
successful in obtaining media session parameters (SPS, PPS, or Channel,bits per second, 
etc for audio) I notify the blocked thread (IFileSourceFilter::Load) of the outcome so that 
it can either continue to setup the output pins or show an error message and cleanup. 
If the pin creation is successful the RTSP thread then goes on to call SETUP and PLAY 
and starts receiving RTP packets similar to Jeremy's description and adds them to a 
shared queue. In the case of failure, the live555 eventloop is ended.


Then in the DirectShow DoBufferProcessingLoop I check for new media packets and pass them
into the DirectShow pipeline. As Jeremy stated, one of the tricky bits is that the first couple
of packets in a stream do not have RTCP synchronised timestamps. Once the sync occurs,
you need to adjust your DirectShow timestamps to take this shift into account.
It's been one of the most frustrating parts for me as well.


> However, getting timestamping working correctly has been (and continues to
> be) an issue.  Live555 timestamps aren't accurate until the RTCP channel has
> been sync-d up, so the first few frame that come through have invalid
> timestamps.  And DirectShow's timestamping for live sources sucks in
> general--I have yet to make heads or tails of it.  If you have any good
> advice for getting timestamping working better in DShow, that'd be awesome.


Agreed, I have tried so many things and am still not sure, what is effective, redundant etc.
We seem to have got it working through lots of trial and error (at least in our test infrastructure). 
When we startup, the video and audio seem to sync correctly and play correctly.
>From my experience so far, live555 does a great job with the RTCP synchronisation.
We left a test system stream for days and the media was still in sync.


@John: I'd be interested in the flaws you found. It still only supports 
audio since my "real" work is keeping me rather busy... 


@Iain: Like John stated you can use it to add video, in fact the "original" RTSP source filter
that it's based on also contained H.263 video but due to company IP issues I had to strip out the video 
related code. I'm still planning to add some video support but have no timeframe as yet.


Hope this helps,
Ralf






-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.