GStreamer RTP e(X)tension bit and video specific fixed headers

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

GStreamer RTP e(X)tension bit and video specific fixed headers

Marc Leeman
I got a remark that our GStreamer based system does use 4 extra bytes
after the RTP header while the X bit in the RTP header is not set. I did
some digging and next to some remarks that the X bit is profile
specific; I do not see in the relevant RFCs that the relevant bit needs
to be set when adding the profile specific header.

Mostly, the RFC (e.g. 2250 for MPEG2) says some fields need to be so and
so; but not that the X bit needs to be set.

I think that the remark originates (indirectly) from the other side
using FFMPEG based RTP handling (skip 12 bytes, do something with the
rest).

Below is my assessment as I thought it to be after reading a number
RFCs; I would apreciate any review of my comments into this and if I am
wrong, we'll have to raise a gst-plugins-good bug on RTP.


On Fri, Jan 28, 2011 at 07:52:26PM +0100, Marc Leeman wrote:

> On Fri, Jan 28, 2011 at 06:39:51PM +0100, Marc Leeman wrote:
> > > controlRtp does not process it correctly. hope you or Marc Leeman can
> > > correct this on the MGS side. Please refer to RFC2250 for details.
> >
> > So for MPEG2; there is not even an option NOT to include the header;
> > which explains why the X bit is profile dependent.
>
> I have been reading a bit more and as far as I read 2250; there are two
> MPEG2 headers.
>
> 1/ must always be there, the MPEG fixed video header
> 2/ MPEG header extension that is optional
>
> IMO the RFC 3550 extension is as such relevant to point 2; not to point 1.
> MPEG2 is used; the 4 byte fixed header MUST always follow the 12
> byte fixed RTP header. If the RTP extension bit is set; then there is
> another variable length extension header (that is MPEG2 specific).
>
> As such; we are sending 12 bytes RTP AND the mandatory 4 bytes MPEG2
> extension. Since we do not set the X bit; there are no MPEG2 header
> extensions (on top of the 4 mandatory MPEG2 bytes).
>
> If the X were to be the fixed header for MPEG2; you would see that
> the definition of the header as defined in 5.3.1 RTP Header Extension
> (3550) would conflict with the MPEG2 fixed header as defined in 3.4 MPEG
> Video-specific header (2250),
>
> Only when the MPEG2 fixed header is considered not covered by the X bit,
> that there is no conflict.
>
> This reasoning seems to be confirmed by other RFCs too for other video
> payloads (mentioned before).
>
> I'll check this next week on IRC.
--
  greetz, marc
We must believe that it is the darkest before the dawn of a beautiful
new world.  We will see it when we believe it.
                -- Saul Alinsky
crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer RTP e(X)tension bit and video specific fixed headers

Olivier Crête-2
On Sat, 2011-01-29 at 09:01 +0100, Marc Leeman wrote:
> I got a remark that our GStreamer based system does use 4 extra bytes
> after the RTP header while the X bit in the RTP header is not set. I did
> some digging and next to some remarks that the X bit is profile
> specific; I do not see in the relevant RFCs that the relevant bit needs
> to be set when adding the profile specific header.

There is RFC 5285 which you probably missed (it took me a while to
discover its existence too).

> Mostly, the RFC (e.g. 2250 for MPEG2) says some fields need to be so and
> so; but not that the X bit needs to be set.

The X bit is in many ways orthogonal to the format. So Payload-type
specific RFCs like 2250 don't tell you anything about it.

Unless you use an application specific extension of RFC 5285 based on,
the X bit should be 0.

--
Olivier Crête
[hidden email]
Collabora Ltd

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment