[Live-devel] Frame granularity

[Ross Finlayson]

>I'm trying to write a custom MultiFramedRTPSource and Sink (and Framer?)
>for a video payload format

Out of curiosity - which codec is this for?  Is this payload format 
already described by a RFC (or IETF Internet Draft)?

>  - but i'm slightly confused about what
>granularity of frames I should be aiming for.  Should the Source yield
>frames which refer to a discrete picture of video, or instead whatever
>sub-picture fragment the individual received packets represent (e.g.
>picture, GOB, slice or macroblocks)?

The latter.  The reason for this is that these 'sub-pictures' 
("slices" for MPEG video; "NAL units" for H.264) are useful to a 
decoder by themselves.  E.g., a MPEG video decoder can display the 
'slices' that it has received, even if some of the other slices in 
the frame were note received.

>If Source frames represent discrete pictures combined from several packets
>(as H263plusVideoSource appears to), each with a set of per-packet
>specialHeaders, should those specialHeaders be used in the Sink (when
>doing a simple relay) to construct the output packets?

The 'special headers' are RTP-specific.  Therefore, they should be 
added by the "RTPSink" (before the packet is sent), and should be 
stripped by the "RTPSource" (before the incoming packet data is 
delivered to the reader).  The various virtual functions in 
"MultiFramedRTPSink/Source" can do this for you.

>  How would one tell
>the extended MultiFramedRTPSink to only fragment the frame on the
>boundaries implied by that frame's specialHeaders, rather than MTU-based
>fragmentation?

Without knowing more about the payload format (and the special 
headers) that you are using, it's hard for me to answer this.

>Alternatively, is the intention for a Framer to perform this operation

'Framers' are usually used only when reading byte-stream data from a 
file (or stdin).


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