[Live-devel] Media stream duplication on a streaming relay

[Bernhard Feiten]

Dear Ross, all,

as nobody answered I started to write a  StreamDup class following your 
hints from the e-mail below.

Related to that I have two questions?
Would it be required that the sequnce number and timestamp of the duplicates 
are newly initialized?
Would RTCP also need to be considered then?

Thank you in advance,
Bernhard


----- Original Message ----- 
From: "Bernhard Feiten" <Bernhard at feiten.de>
To: "LIVE555 Streaming Media - development & use" 
<live-devel at ns.live555.com>
Sent: Thursday, June 26, 2008 7:28 AM
Subject: Re: [Live-devel] Media stream duplication on a streaming relay


> Dear Ross, all,
>
> did somebody wrote the StreamDuplication class you proposed below already?
>
> Do you have a hint how the getNextFrame functions could be synchronized?
>
> Thank  you very much,
> Bernhard
>
>
>
>
> ----- Original Message ----- 
> From: "Ross Finlayson" <finlayson at live555.com>
> To: "LIVE555 Streaming Media - development & use" 
> <live-devel at ns.live555.com>
> Sent: Thursday, December 08, 2005 8:57 PM
> Subject: Re: [Live-devel] Media stream duplication on a streaming relay
>
>
>> As you noticed, you can't duplicate a stream by having each recipient 
>> read from a single object, because "getNextFrame()" can't be called more 
>> than once on the same object concurrently.
>>
>> The solution, instead, is to create a separate object (of some 
>> "FramedSource" subclass) for each recipient.  This new class would 
>> implement the "doGetNextFrame()" virtual function by somehow 
>> 'registering' with the data source object - to request a copy of the next 
>> incoming frame.
>>
>> The data source object (which would *not* be a subclass of 
>> "FramedSource", and so would not implement "doGetNextFrame()") would 
>> handle these requests by delivering copies of each incoming frame to each 
>> recipient, and not ask for a new incoming frame (from its upstream data 
>> source) until it has finished delivering data to each downstream 
>> recipient.
>>
>> For an example of code that is similar to this, note the relationship 
>> between the "MPEG1or2Demux" and "MPEG1or2DemuxedElementaryStream" 
>> classes. (In this case, however, we are demultiplexing data to downstream 
>> recipients, rather than duplicating it.)  Note in particular that (i) 
>> "MPEG1or2Demux" is subclassed from "Medium", not "FramedSource", and (ii) 
>> "MPEG1or2Demux" implements a "getNextFrame()" function that is similar 
>> to, but different from "FramedSource::getNextFrame()".
>>
>> (This functionality (data duplication) is something that should probably 
>> be added to the library someday.  Until then, however, you will need to 
>> implement it yourself.)
>>
>>
>> Ross Finlayson
>> Live Networks, Inc. (LIVE555.COM)
>> <http://www.live555.com/>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel