> 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.
I'm not quite sure what you mean by those last two sentences, but I hope you've read <http://www.live555.com/liveMedia/faq.html#threads>. 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. > > 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? 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. > 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. 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...) Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
