Hi Guys, >> I doubt that *each* frame is 160 kBytes - presumably only the ‘key frames’.
Yes, but in this case the GOP length is 1, so every frame is a key frame. Yes it’s nuts I know ☺ >> I recommend that you reconfigure your encoder so that… I totally agree with your recommendations as regards to encoding, however I am actually working on a decoding product. I am using the RTSP server as a way to simulate various cameras out in the wild, so I would capture streams from cameras to raw h264 and then replay them using live555 media server so that we can do regression tests. If I transcode the stream it defeats the purpose, so I need the server to be able to play back any encoded stream. >> have been successfully streamed at full framerate on a single thread in >> debug mode or on low end dedicated PC Actually I found that a slow CPU drops less packets for the case I was describing, because the CPU is not capable of queueing as many packets to the OS in a short period of time as a fast CPU is. Therefore the buffers don’t get filled up quick enough to overflow them. I’ve solved my problem for now, just thought it would be nice to contribute something back. Regards, Martin. From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Jeff Shanab Sent: 01 December 2015 01:46 To: LIVE555 Streaming Media - development & use <live-de...@ns.live555.com> Subject: Re: [Live-devel] RTSP Server Packet Loss I concour. Here are some data points. I have been streaming 4K cameras recently one of them is actually 4000x3000 resolution. A Sony is the normal 3840 x 2150 streaming at 30 fps, It puts out 5 slices for each frame type. I,P,B Slices also enable us to parallelize the decoding so it can be reasonably decoded. The keyframes are indeed 250K+ A 12MB (4000x3000) Samsung also streams at 30 fps but no slices. keyframes are large, I am not near my measurements so I cannot say but I would not be surprised if they hit 160K. A Panasonic does not have slices either but it has a powerful processor on board. The Sony has larger frames than the Samsung but is by far smoother and easier to stream, less resources and better at maintaining the framerate. Rock solid timestamps not varying more than a ms, not dropping either. All 3 of these as well as some panoramic cameras that use slices and stitch the images into a ridiculously wide view, have been successfully streamed at full framerate on a single thread in debug mode or on low end dedicated PC.s TCP has overhead and if combined with any network latency, I think it taxes the camera's internal buffer and it will drop framerate. I was surprised by this, really sensitive to latency. I am guessing that it must hold onto packets until they are acked and if there is delay the queue is forced to hold more. Measure your network latency and try UDP transport if you think you are hitting a wall. On Mon, Nov 30, 2015 at 7:06 PM, Ross Finlayson <finlay...@live555.com<mailto:finlay...@live555.com>> wrote: > I have a 40 Mb/s 1920x1080 H264 source video file running at 30 frames per > second. So each frame is roughly 160 kB being bursted out every 33ms. I doubt that *each* frame is 160 kBytes - presumably only the ‘key frames’. But in any case, with key frames this large, I recommend that you reconfigure your encoder so that each key frame is encoded as a sequence of ’slice’ NAL units, rather than as a single NAL unit. People often have trouble streaming H.264 video with extremely large I-frames, if each I-frame gets encoded as a single NAL-unit. The problem with this is that these NAL units get sent as a (very long) sequence of RTP packets - and if even one of these RTP packets gets lost, then the whole NAL (I-frame in this case) will get discarded by the receiver; see http://lists.live555.com/pipermail/live-devel/2011-December/014190.html http://lists.live555.com/pipermail/live-devel/2012-August/015615.html http://lists.live555.com/pipermail/live-devel/2013-May/016994.html http://lists.live555.com/pipermail/live-devel/2014-June/018426.html http://lists.live555.com/pipermail/live-devel/2014-June/018432.html http://lists.live555.com/pipermail/live-devel/2014-June/018433.html http://lists.live555.com/pipermail/live-devel/2014-June/018434.html http://lists.live555.com/pipermail/live-devel/2015-March/019135.html http://lists.live555.com/pipermail/live-devel/2015-April/019228.html For streaming, it’s better to encode large I-frames as a sequence of ‘slice’ NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com<mailto:live-devel@lists.live555.com> http://lists.live555.com/mailman/listinfo/live-devel ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
