[gst-devel] move & rename rfc2250enc plugin

[Ralph Meijer]

On Thu, Jul 17, 2003 at 06:25:37PM +0200, Angel Carpintero wrote:
> > Hey,
> 
>  Hey Ronald ! 
> 
>  First at all thanks for the answer :-)
>  
> > On Thu, 2003-07-17 at 17:30, Angel Carpintero wrote:
> > > In example could be named gstrtpmpeg12enc and it will need
> > > the parser as well , gstrtpmpeg12parse ( almost all features
> > > needed are implemented already in mpegparse ).
> > 
> > mpegparse is much more generally applicable, I wouldn't recommend moving
> > it away to the RTP dir or giving it a RTP-specific name.
> 
>  Sure , the only i guess is totally RTP-specific is rfc2550enc . About mpegparse
>  it could be used to create the parser for mpeg12 rtp packets but i'm agree with 
>  you that it shouldn't be moved.

Hey!

As I tried to explain in another thread, a useful rfc2250enc element (which
it isn't yet in its current incarnation), would generate data packets
that would be almost completely be fullblown RTP elements.

At the moment, what comes out of rfc2250enc is just the input stream chopped
up differently. I should add that it at the moment actually doesn't because
a few bugs in it. One of them I have filed a bugreport for, the others I
can point out, but not provide code because of the company I work for.

If you wanted to keep the mpeg-parsing-packetizing-and-information-extraction
thingy separate from the RTP wrapper, you need to come up with an intermediate
data format that stores all the data you need to make RTP packet.

One approach could be to already add the MPEG-specific RTP headers as specified
in the RFC to the buffers coming out of rfc2250enc. Technically these buffers
would contain the payload of what later becomes an RTP packet. Lets call
this application/x-rtp-payload

The one piece
of information you then need to communicate without having to parse the MPEG
again, is the display timestamp that goes in the RTP headers.

I tried to explain why it is a bad idea to use the buffer timestamp for this.
In short: the timestamps are non-monotonically increasing and cause bursts.

I see one solution here and that is to extend the above described new data
format (application/x-rtp-payload) with 4 bytes to fill in the timestamp.

As you can see, the new format is almost like RTP packets.

Another way would be to make the stuff used by both mpegstream and the
new MPEG RTP wrapper into a shared lib and let it be used by both plugins,
thereby moving the code from rfc2250 into the wrapper.

Ralphm