> Can I confirm that this shouldn’t interact with the file sink buffer sizes as > they effectively receive decoded and depacketised frames?
They’re different buffers, with different purposes. A single RTP packet may contain one or more ‘frames’ (for H.264 video: ‘NAL units’). Or a single very large ‘frame’ (again, for H.264 video: ‘NAL unit’) may be fragmented over more than one RTP packet. This is true, regardless of the size of the RTP packets. In each case, should an input frame (whether it was contained within a RTP packet along with other frames, or was fragmented over multiple RTP packets) exceed the size of the buffer used by the downstream ‘sink’ object (e.g., a “FileSink”), then the data will be truncated (as indicated by the “numTruncatedBytes” parameter in the ‘after getting’ function. In other words, the “FileSink” buffer size should be at least as large as the largest expected frame (or H.264 ‘NAL unit’). This has nothing to do with RTP packet size. As an aside, I should note that using a very large RTP/UDP/IP packet size (perhaps signaled by the RTSP “Blocksize:” header) is a good strategy for transporting very large video ‘key frames’ - but ONLY IF these very large IP packet sizes are supported all the way along the path from server to client. If any part of the path between the server and client goes over the public Internet, or over any LAN whose MTU is smaller than the IP packet size, then you’ll get fragmentation at the IP level, which is just as bad as fragmenting the ‘key frame’ over multiple RTP packets: If *any* packet gets lost, then the whole ‘key frame’ will be lost. In general, you can’t count on an MTU larger than 1500 - which is what our code assumes, by default, when sending packets. 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
