[Live-devel] MultiFramedRTPSink::specialHeaderSize()

[Ross Finlayson]

>I am working with an RTP payload that requires the following:
>
>Non fragmented frames: specialHeaderSize = 0;
>First frag of a frag frame: specialHeaderSize = 1;
>2
n frags of a frag frame: specialHeaderSize = 2;
>
>I am trying to stick to the architecture you have and not do any custom
>modifications. It seems that I don’t have the 
>required information when specialHeaderSize()
>is called to return the proper information.
>
>Do you have any suggestions about how to accomplish this?

You can easily distinguish between the two cases:
         a) non-fragmented frame or first fragment of a fragmented frame, and
         b) fragment 2..n of a fragmented frame
by calling "curFragmentationOffset()" and testing 
whether or not it is >0.  (See "JPEGVideoRTPSink.cpp" for an example of this.)

Unfortunately, though, you can't distinguish - in 
"specialHeaderSize()" - between a non-fragmented 
frame and the first fragment of a fragmented 
frame, because - at the time that 
"specialHeaderSize()" is called - the input frame hasn't even been read yet.

Is your RTP payload format one that's described 
by an existing RFC (or Internet Draft)?  The 
reason I ask this is that - with the payload 
format that you currently describe - I think it's 
going to be difficult for a RTP *receiver* to 
distinguish between these two cases.  How can a 
RTP receiver know - by looking at the incoming 
packet - whether or not there's a special 
header?  What if there's no special header, but 
the first byte of the payload data happens to 
look like a special header?  It seems to me that 
this is going to require some codec-specific knowledge...

Would it be possible, then, to change your payload format so that there's:
         - a 1-byte special header for the first 
fragment, *or* an unfragmented frame, and
         - a 2-byte special header for the 
2nd...nth fragments of a fragmented frame, with 
an easy way for a receiver to tell - by looking 
at the first special header byte - whether or not 
there's also a second special header byte.
?

Although this may appear to 'waste' one byte in 
the (common?) case where there's no 
fragmentation, it will be a lot easier to implement.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>