Memory Streaming

as outlined above, the romediastreamer object provides a means of specifying a single flexible pipeline of multimedia processing however, the pipeline is constrained to having a single input and a single output the memory streaming feature adds a means of bifurcating the data stream so that multiple outputs can be created, and more than one thread of processing can be realized note that memory streaming is especially important when serving live encoded media such as hdmi ® input memory streaming ensures that only a single encoder is needed to distribute a live encoded stream to multiple clients http multiple unicasting to unicast a source stream to multiple clients, output the source (in this case, encoded hdmi input) to a memory stream m = createobject("romediastreamer") m setpipeline("hdmi , encoder , mem /livehdmi") m start() now a large number of clients can receive the same stream named "livehdmi" (the name is arbitrary but must not conflict with any other memory stream) when a client accesses the following url, the http media server code creates a separate romediaserver instance reading from the source mem /livehdmi/stream ts and forwards it to the http socket http //ip address\ port/mem /livehdmi/stream ts notice that /stream ts must be appended to the memory stream name to denote that the entire stream should be used in the above instance, the media streamer code will actually create the source component memsimple /livehdmi/stream ts as it uses fewer resources and is more efficient once the memory stream has been created, it can also be simultaneously multicast using another media streamer instance m1 = createobject("romediastreamer") m1 setpipeline("memsimple /livehdmi/stream ts,rtpsimple //239 192 0 0 5004/") m1 start() mem and memsimple as with certain other components, there is a "simple" and a "non simple" version of memory streaming the simple version ( memsimple ) can only be used in a pipeline with other simple components, although simple memory streams can read from non simple mem memory streams (as shown above, where the memsimple /livehdmi component reads from the mem /livehdmi component) however, the converse is not possible the mem source component cannot be used to read from a memory stream that was created with the memsimple destination component because simple memory streams are not indexed, they cannot support hls streaming operations downstream (other components will not receive information about the hls segments) as is the case with other "simple" components, simple memory streams should be used wherever possible because they consume fewer resources hls multiple unicasting hls multiple unicasting functions similarly to the http multicast example given above, but with one exception stream indexing filters only work on streams read into the transport stream processor, not on streams read into the encoder (both of which are handled by the mem component) as a result, encoded streams such as hdmi input must be passed to the mem component twice before they can be multicast this is easily accomplished using two setpipeline() calls m = createobject("romediastreamer") m1 = createobject("romediastreamer") m setpipeline("hdmi ,encoder ,mem /hdmi unindexed?size=5") m1 setpipeline("mem /hdmi unindexed/stream ts ,mem /hdmi indexed?size=30\&duration=5") m start() m1 start() note that a larger memory buffer (30mb in this instance) must be specified for the second mem component because it must hold at least five complete 5 second segments at any time clients generally require 5 complete segments at all times for hls streams, so they will often need to wait at least 25 seconds before the stream can be played successfully clients can then access hls streams using the following url http //ip address\ port/mem /hdmi indexed/index m3u8 like http multicasting, the media streamer will generate additional romediastreamer instances for each client that connects in addition to hls clients, http and rtsp clients can also connect to the indexed stream using the following urls http http //ip address\ port/mem /hdmi indexed/stream ts rtsp rtsp\ //ip address\ port/mem /hdmi indexed/stream ts the indexed stream can also be multicast by another romediastreamer instance access an indexed memory stream as shown in previous examples, appending stream ts to the memory stream identifier denotes the entire buffer, while appending index m3u8 to an indexed (hls) stream denotes the entire index file similarly, appending the name of a segment listed in the index file will access that segment for the duration of its lifetime in the memory stream buffer for example, if the index file lists a segment named 000179 ts as available in the mem /livestream component , then the following source component can be used to fetch that segment mem /livestream/000179 ts the memsimple component can also be used to fetch the segment memory stream pacing the flow of data into the memory stream is always paced in real time to give the reading clients time to keep up an romediastreamer instance that is writing will never wait for any of the reading clients; if any client gets too far behind (which is detected by the writing edge of the fifo overtaking the client's reading edge), the client will abort and issue an event eos error message because of this limitation, it is important to note the following if a memory stream is used to work around the fact that data cannot be passed directly from an encoder to a decoder (as in the below example), then processing cannot happen faster than in real time example m1 = createobject("romediastreamer") m2 = createobject("romediastreamer") m1 setpipeline("hdmi ,encoder ,mem /hdmi") m2 setpipeline("mem /hdmi/stream ts,decoder ,file ///file ts") m1 start() m2 start() memory stream states a memory stream is only created when the media streamer that names it as a destination is in at least the connected state this means it is possible to connect the pipeline (using connect() ) that creates the memory stream but not start it any number of media streamers reading from a memory stream can be created (and even started) before the original media streamer is itself started, beginning the flow of data into the memory stream see media streamer docid\ kxuyhjbrdmol7zmofc525 for more info on romediastreamer states encryption & copy protection generally speaking, an romediastreamer instance reading from a memory stream will adopt the same encryption/copy protection as the associated romediastreamer instance that is writing to it the specific rules are as follows simple writer a memsimple destination cannot be marked as requiring protection (nor can it receive such a stream) simple reader a memsimple source will only read from a memory stream that was marked as unencrypted (requiring no protection) when it was created non simple writer a mem destination will be marked as requiring protection when it is created according to the source of the pipeline if a stream becomes protected later, it will continue to operate if it was marked as requiring protection initially (optionally with the encrypt parameter), otherwise it will stop non simple reader a mem source inherits the protection status of its associated writer, and therefore its output will ultimately require hdcp or dtcp protection if the source was similarly marked