Our software uses liveMedia as an RTSP client to connect to network cameras to receive H.264 frames. Our sink is being passed data from (presumably) the FramedSource class in response to data arriving from the camera/RTSP/H.264 video source and being depacketised.
We are also getting similar issues from the same camera where the H.264 I frame is discarded/dropped before it gets to our sink. I can see it in the network stream, but it is never sent to our sink. I expect this may be related, but can’t find any obvious cause for either just yet. The data file in my previous email was one single “frame” that was passed from liveMedia to our sink. My apologies about the assumption, I keep forgetting that it can be used as a server amongst many other things. Many thanks -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher<http://www.icode.co.uk/icatcher> | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: 01 May 2015 17:21 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Multiple NALUs concatenated together in one afterGettingFrame Simply put, a single call to afterGettingFrame in my file sink is receiving a single large “frame” that actually consists of an SPS, PPS, and the I frame in one single byte stream with no prefix or separator between them. But where is this data coming from? I.e., what in your code is feeding into your “FileSink”? And what is producing this H.264 data? I.e., please explain what your system is, and how it uses our code. Although you know precisely what your system does, and how it uses our code, please don’t assume that I or the other 1,000+ people on this mailing list do. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
