<html><head><base href="x-msg://2590/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; margin-top: 0in; margin-bottom: 0.0001pt; ">I’m in the process of evaluating Live555, and I’m trying to send out a live H264 stream using the Intel’s Media SDK H264 encoder. To ensure I was encoding properly, I made a raw h264 file and made sure I could stream out the file with mediaserver.exe, which with VLC it acted like the frame time was off(played quickly), but using SMPlayer everything worked fine(so I think that particular issue is VLC and not with the encoding).</div></div></div></span></blockquote><div><br></div>That's odd, because VLC is usually more reliable than (S)MPlayer. But anyway...</div><div><br></div><div><br><blockquote type="cite"><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 15px; ">My second test is to see if I can get Live555 to now stream the output, meaning, instead of writing to a file, send out through RTSP.</span></blockquote><div><br></div>I found this confusing, because that ("sending it out through RTSP") is what you were doing before, when you ran the "LIVE555MediaServer".</div><div><br></div><div>However, from the rest of your message, I inferred that what you were really talking about was having the server take your H.264 input directly from your encoder, rather than from a file.</div><div><br></div><div>So, because you've read the FAQ, I assume that you have written your own subclass of "OnDemandServerMediaSubsession" (that sets the "reuseFirstSource" parameter to True), and have redefined the "createNewStreamSource()" and "createNewRTPSink()" virtual functions.</div><div><br></div><div>Your "createNewRTPSink()" implementation can be exactly the same as the one that's in "H264VideoFileServerMediaSubsession.cpp".</div><div><br></div><div>Your "createNewStreamSource()" implementation, however, would create a new instance of your "EncoderSource" class, and feed it to a "H264VideoStreamDiscreteFramer" (note, *not* a "H264VideoStreamFramer"). The function would then return a pointer to the 'framer' object.</div><div><br></div><div>There are two important things to note:</div><div>1/ Each NAL unit delivered by your "EncoderSource" class must be a single, complete NAL unit, *without* a preceding 'start code' (i.e., with *no* preceding 0x00000001)</div><div>2/ You need to provide SPS and PPS NAL units. If they occur frequently in the encoder's output, then there is nothing more that you need to do.</div><div><br></div><div>If, however, the SPS and PPS NAL units do not occur frequently (or at all) in the encoder's output, then you need to supply them directly. (In this case we assume that the SPS and PPS NAL units are static - i.e., do not change within the stream.) There are two ways you can do this:</div><div>1/ In your "createNewStreamSource()" function, call "H264VideoStreamFramer::setSPSandPPS()" on the "H264VideoStreamDiscreteFramer" object (which is a subclass of "H264VideoStreamFramer"), before you return it.</div><div>2/ Alternatively, in your "createNewRTPSink()" function, use one of the variants of "H264VideoRTPSink::createNew()" that take SPS/PPS NAL units as parameters.</div><div><br></div><div>Finally, when you are streaming directly from your encoder, rather than from a file, you should consider using VLC - rather than MPlayer - as a client. The timing problems that you saw when you streamed from a file will probably not occur when you're streaming from your encoder.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>