[Live-devel] MultiFramedRTPSink::specialHeaderSize()

[David Arnold]

When implementing RFC 3984 using LiveMedia, I couldn't get
specialHeaderSize() to do what I wanted, so I had to implement fragmentation
(FU-A NAL Types) in a different way.

Dave Arnold
Future Concepts, La Verne CA

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com]On Behalf Of Ross Finlayson
Sent: Friday, April 07, 2006 3:04 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MultiFramedRTPSink::specialHeaderSize()



>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/>

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system.