[Live-devel] General tips would be appreciated

[Ross Finlayson]

> P.S. I've read the FAQ last time, the part I think you were referring to wasn't really referring to me :) esp the one about not reading the FAQ.

No, the part of the FAQ that relates specifically to what you're trying to do (I think) is:
	http://www.live555.com/liveMedia/faq.html#liveInput-unicast
You should also note:
	http://www.live555.com/liveMedia/faq.html#modifying-and-extending


> Alternatively (sorry for bad spelling btw) should I perhaps adapt MPEG2TSFileSubsession to use the MemoryBufferSource since my byte[] holds raw TS data? Thank you in advance for quick and precise answers.

The RTP payload format for Transport Stream data is independent of the particular codec(s) that the Transport Stream contains.  Therefore, because you are streaming Transport Stream data, you should not be using (or looking at) any of the *H264* classes.

Instead, you should be writing and using your own new subclass of "OnDemandServerMediaSubsession" that (as noted in the first FAQ entry referred to above):
	1/ In its constructor, sets the "reuseFirstSource" variable in the base class constructor to True, and
	2/ Implements the two pure virtual functions "createNewStreamSource()" and "createNewRTPSink()".

Your "createNewRTPSink()" implementation can be exactly the same as the one that's in "MPEG2TransportFileServerMediaSubsession" - i.e.

	RTPSink* yourServerMediaSubsession::createNewRTPSink(Groupsock* rtpGroupsock,
				unsigned char /*rtpPayloadTypeIfDynamic*/,
				FramedSource* /*inputSource*/) {
		return SimpleRTPSink::createNew(envir(), rtpGroupsock,
			33, 90000, "video", "MP2T",
			1, True, False /*no 'M' bit*/);
	}


Your "createNewStreamSource()" implementation would probably create a "ByteStreamMemoryBufferSource", and feed it into a "MPEG2TransportStreamFramer".


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120123/8ef30fbf/attachment.html>