On Thu, Oct 16, 2008 at 12:29 AM, Ross Finlayson <[EMAIL PROTECTED]> wrote: > >> I am writing a streaming application with live555, both on the server >> and client ends. I will be using live555 to mulitcast MPEG2 transport >> streams over RTP to the clients. Periodically, the server will stop >> multicasting the current file and switch to a new one, sending it to >> the same multicast address and port to which the previous TS was being >> sent. >> >> Now, obviously, the second TS may defer in parameters from the 1st TS. >> For example, the picture size could be different, or it could contain >> a different video codec. I am thinking that the decoder on the client >> end will need, somehow, to know of this change. Are there any >> facilities in live555, the TS protocol or the RTP protocol that would >> help with this. > > No, because the RTP payload format for Transport Stream data is extremely > simple: RTP packets contain just the Transport Stream data (in groups of > 188-byte transport 'packets'), with no extra RTP-specific parameters. In > other words, you don't do anything extra to our RTSP/RTP/RTCP code to stream > your 'joined' Transport Stream data; instead, all of the information that a > client's decoder requires needs to be in the Transport Stream data itself. > > Fortunately, though, the Transport Stream header (inside the Transport > Stream data itself - independent of RTP) includes a 1-bit > "discontinuity_indicator" that you can use to indicate - to a receiver - > that a Transport Stream 'join' has taken place. (See the ISO-IEC > specification for Transport Streams: ISO-IEC 13818-1, section 2.4.3.5.)
Thanks. -- B. Gitonga Marete Tel: +254-722-151-590 _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
