<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); position: static; z-index: auto; ">BACKGROUND: I adapted testH264VideoStreamer.cpp and DeviceSouce.cpp/hpp so that I could send a live video feed out over the network. I currently test using VLC. I generate h.264 encoded frames using a Microsoft Media Foundation (MF) back end to my existing MF streaming software. There is a call to env->taskScheduler().doEventLoop() in my adapted testH264VideoStreamer.cpp, which is in a separate thread. Thus, my primary thread handles the MF streaming, and this secondary thread makes sure doEventLoop() happens.</div></blockquote><div><br></div>I'm not quite sure what you mean by those last two sentences, but I hope you've read <<a href="http://www.live555.com/liveMedia/faq.html#threads">http://www.live555.com/liveMedia/faq.html#threads</a>>. Only one thread can call LIVE555 library code, including "doEventLoop()". The one exception to this is that a separate thread can call "triggerEvent()", as it appears you are doing. That's OK.</div><div><br></div><div><br><blockquote type="cite">
<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); position: static; z-index: auto; ">
QUESTION ONE: My h.264 encoding repeatedly creates new [output] buffers that I pass to the live555 side, using an adapted signalNewFrameData() function that goes through the scheduler trigger event. This is fine. But how can I figure out when the buffer is no longer in use?</div></blockquote><div><br></div>Once the buffer's data has been copied to the downstream object's buffer - e.g., after the call to "memmove()" on line 137 in the "DeviceSource.cpp" example code - then the buffer is no longer needed.</div><div><br></div><div><br></div><div><blockquote type="cite"><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); position: static; z-index: auto; ">QUESTION TWO: Right now, the video I see using VLC is truly horrible. I'm no h.264 or mpeg-4 expert, but it appears as if half my detail frames are missing. It's like watching satellite TV during a rain storm. This could be related to the above, but I don't think so due to a prior single-thread solution that looked the same but guaranteed appropriate buffer allocation/de-allocation. So why might my video look so bad, or how can I go about figuring out why it's so? Being sufficiently ignorant, I can only guess at how you may answer to assist me. One thing I guess about is a method to trace the h.264 encoded output to see if it's all getting though, I frames P frames we call frame for Ice cream, or whatever.</div></blockquote><div><br></div></div>Unfortunately we can't help you specifically with VLC, as it's not our software. Instead, I suggest that you start by running our own RTSP client applications - "testRTSPClient", and then "openRTSP". In particular, "testRTSPClient" will tell you the sizes of each of the H.264 NAL units that it receives. You can then compare these to those that your encoder is generating. I suspect that your problem may be that some of your NAL units (for I-frames) may be too large for the streamer's output buffer (for RTP streaming). (However, if that were the case, you'd be seeing console warning messages about the need to increase "OutPacketBuffer::maxSize". You didn't mention seeing any warning messages like that...)<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><div><br class="webkit-block-placeholder"></div>
<br></body></html>