[Live-devel] MultiFramedRTPSink::specialHeaderSize()

[Ross Finlayson]

>I am working on implementing RFC 3984 for H.264 streaming.

OK, cool.  FYI, the "LIVE555 Streaming Media" libraries already 
include a "H264VideoRTPSource" (for receiving H.264/RTP packets), but 
not yet a "H264VideoRTPSink" (for sending H.264/RTP packets.

>  I am using the single NAL unit per packet method described in the spec.
>For non fragmented packets the 1 byte header is in my frame data already.

Yes.  In that case the special header size will be 0.

>For fragmented packets
>             The first packet has the FU indicator added to the 
> front with the already existing NAL header byte.

Almost.  You will also need to move the first 3 bits (F and NRI) of 
the existing NAL header to the front of the FU indicator, and replace 
them with the S, E and R bits.  (See section 5.8 of the RFC, and 
"H264VideoRTPSource.cpp".)

>             The rest of the fragmented packets have no header in 
> the data, only raw data. So I need to
>                         add two bytes, one for FU indicator and one 
> for FU header.

Yes.

But anyway, the original problem remains: How to distinguish between 
the 'no fragmentation' case (for which you'll want a special header 
size of 0), and the 'first fragment' case (for which you'll want a 
special header size of 1).  I need to think about this some more, but 
I suspect that I'll need to make some modifications to 
"MultiFramedRTPSink" and/or its virtual functions, to make this possible.

I'll think about this some more, and try to get back to you with an 
answer within a few days.

>I know you don't get into protocol specifics

Au contraire.  I'm actively involved in the IETF's "Audio-Video 
Transport" Working Group, which standardizes RTP and its various 
payload formats.



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