RTP payloading of program streams...

[Wim Taymans]

On 09/24/2013 03:57 AM, Sebastian Rasmussen wrote:
> 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
Yes, those are the caps for an mpeg2 program stream.
>
> 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 naming of the caps is historical. video/mpeg refers to both the
program/system stream and the elementary streams (using the systemstream
property).
>
> 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..?
It is MP2T in git on the payloader, the depayloader also has MP2T-ES for 
backward
compatibility.
>
> My assumption then is that a GstRTPMP2PPay according to
> http://tools.ietf.org/html/rfc3555#section-4.2.11 would have "MP2P"
Yes
>
> 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?
The RFC says that you should treat the data as bytes so you should pack 
as many
bytes in a packet as can fit.  I would think the algorithm is thus the 
same as
the mp2t payloader.
>
> 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?
It would be nice, but the depayloader would be extremely simple, copy the
mp1s depayloader, change method names and encoding-name and that's it.

Wim
>
>   / Sebastian
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel