[Live-devel] RFC4175 uncompressed video streaming: variable payload header length

[Ross Finlayson]

After reviewing RFC 4175 (and your code), I've decided not to implement this RTP payload format in the released "LIVE555 Streaming Media" source code (at least, not right now).  There are a number of issues:


1/ For the "RTPSource" subclass (for receiving RTP packets using this payload format):

The basic problem here is that the RTP payload format defined in RFC 4175 is very general.  It allows a sender to (in principle) transmit just some lines of a frame, and even just parts of some lines of a frame.  These lines (and/or parts of lines) could even be in some arbitrary order.  It would be very difficult to implement a "RTPSource" subclass that handled all of this generality.

In practice, however, most streams that use this payload format will probably do so in a 'simple and sane' way: By including all lines of each frame, in order.  It would be possible to implement a "RTPSource" subclass that properly handled the reception of only 'simple and sane' streams - and that's basically what you've done with your "UncompressedVideoRTPSource" code.  Even with this, however, there's a problem: The first (valid) line number of each frame is *not* zero (see section 3 of RFC 4175), so you can't - in general - use a line number of zero to determine when a packet begins a frame.  (You can do this for *your* streams, though, because your "UncompressedVideoRTPSink" implementation starts line numbers at zero.  However, you could not assume this in general, for other people's streams.)


2/ For the "RTPSink" subclass (for transmitting RTP packets using this payload format):

As before, the RTP payload format is very flexible in what it lets you do, although you can "be conservative in what you send" when implementing your RTP sink, so that you transmit just a 'simple and sane' stream - and that's basically what you've done with your "UncompressedVideoRTPSink" code.

As you noted, the fact that this RTP payload format has a variable-length 'payload-specific header' (i.e., depending on how many lines are packed into the packet) is problematic.  (I was probably sitting in the room in the IETF meeting(s) several years ago when this payload format document was being discussed.  I wish I'd realized at the time that this was going to be a problem, otherwise I would have objected at the time.)  Your solution, however, seems reasonable: Use the output packet size to figure out - in advance -  how many lines are going to be packed into the packet.  Note, though, that you shouldn't hardwire a packet size of '1448 bytes' into your code.  Instead, you can just call "ourMaxPacketSize()", which should give you the same value.

One other thing that I noticed from your code, BTW, is that your "m_lineLength" member variable seems to be assigned to be a length in bits (i.e., "imgWidth * imgChannels"), but when you use it (e.g., by passing it as a parameter to your "getHeaderSize()" function), you seem to be assuming that it's a length in bytes.  That looks like a bug to me...


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140727/8fbed7e3/attachment.html>