RTP payloading of program streams...

[Sebastian Rasmussen]

I have a few questions relating to rtp payloading.

Based on GstRTPMP2TPay (Transport Stream payloader) we have
developed a GstRTPMP2PPay (Program Stream payloader). There 
are a few niggles that probably need to be ironed out before we
can attach it as a patch in bugzilla though.

Would it be reasonable for a GstRTPMP2PPay to have these sinkpad
caps: mpegversion=(int)2, systemstream=(boolean)true

GstRTPMP2TPay sinkpad caps has media-type video/mpegts.
Which I assume means transport stream. Lots of other elements
just have video/mpeg. Would a GstRTPMP2PPay to payload
Program Streams have video/mpegps as the media-type? In that
case what does video/mpeg refer to? Or should we use video/mpeg?

The srcpad of the same element has a caps-field: encoding-name = (string) "MP2T-ES"
I can guess the meaning of MP2T, and I believe that it comes from here: http://tools.ietf.org/html/rfc3555#section-4.2.9
The "-ES" part on the other hand, I don't get. Nor can I find anything referencing it..?

My assumption then is that a GstRTPMP2PPay according to 
http://tools.ietf.org/html/rfc3555#section-4.2.11 would have "MP2P"

Also, to my understanding of the code of GstRTPMP2TPay it accumulates
a number of incoming buffers until the data reaches a limit (either expessed
in bytes or in time). One the limit is reached an RTP header is setup together
with the accumulated data passed as a payload in a single buffer on the srcpad.
With program streams though, the data is already assumed to be packetized
so therefore no accumulation is necessary. Is this correct?

Finally, if we provide the source of a MP2P payloader, would we also
be requested to provide the corresponding MP2P _depayloader_ if we
want the payloader to be present in gst-plugins-good with the other 
payloaders?

 / Sebastian