RTP payloading of program streams...

[Wim Taymans]

On 09/24/2013 12:05 PM, Sebastian Rasmussen wrote:
>> The RFC says
> Just to verify that we are talking about the same thing:
> Are you refering to the very last paragraph of section 2?
> http://tools.ietf.org/html/rfc2250#section-2
>
>> 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.
> Ok, so then each payloaded buffer would not necessarily start with an RTP header
> immediately followed by a Packetized Elementary Stream packet header..? Apparently
> my colleagues, through experimentation (by attempting to play the payloaded stream
> in video players), discovered that it might be necessary for each buffer to have a PES
> packet header as well. Thus if there is a restriction on the packet size then the
> payloader would need to divide a single large PES packet into several small ones each
> no bigger than the configured packet size restriction. This is more complex than what
> you outline above though.
According to how I read the RFC, there are no rules to follow, you just 
place the bytes
of the stream in the packets, nothing is mentioned about headers and so on.

That said, there are ways to improve the packetization and minimize the 
effects of
packet loss by choosing better PES sizes but this should be done 
somewhere else, like
in the encoder or a separate element. The payloader should simply place 
the bytes in
packets.

>
>> 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.
> That is only true if the payloading is simple, and as I'm trying to write above, this
> might not be the case, in practice...

This is unrelated to how you payload the data, depayloading is taking 
the data from the
packets and appending it into a new stream of bytes.

Wim
>
>   / Sebastian