[Live-devel] 1435Bytes(598H) lost in the first rtp bag

Shishir Birmiwal shishir at birmiwal.net
Thu Jan 25 06:24:01 PST 2007


Chenjun,

> I compared the received datas with the original datas, I found the first
> streaming rtp bag always lost about
> 1435bytes data from the head, however after that the data transmission are
> correct.Maybe you can give me a hint.
>

Maybe this will help (from RFC 3984 - RTP Payload Format for H.264 Video):

Section 1.2:

   One very fundamental design concept of H.264 is to generate self-
   contained packets, to make mechanisms such as the header duplication
   of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11]
   unnecessary.  This was achieved by decoupling information relevant to
   more than one slice from the media stream.  This higher layer meta
   information should be sent reliably, asynchronously, and in advance
   from the RTP packet stream that contains the slice packets.
   (Provisions for sending this information in-band are also available
   for applications that do not have an out-of-band transport channel
   appropriate for the purpose.)  The combination of the higher-level
   parameters is called a parameter set.  The H.264 specification
   includes two types of parameter sets: sequence parameter set and
   picture parameter set.  An active sequence parameter set remains
   unchanged throughout a coded video sequence, and an active picture
   parameter set remains unchanged within a coded picture.  The sequence
   and picture parameter set structures contain information such as
   picture size, optional coding modes employed, and macroblock to slice
   group map.

   To be able to change picture parameters (such as the picture size)
   without having to transmit parameter set updates synchronously to the
   slice packet stream, the encoder and decoder can maintain a list of
   more than one sequence and picture parameter set.  Each slice header
   contains a codeword that indicates the sequence and picture parameter
   set to be used.

   This mechanism allows the decoupling of the transmission of parameter
   sets from the packet stream, and the transmission of them by external
   means (e.g., as a side effect of the capability exchange), or through
   a (reliable or unreliable) control protocol.  It may even be possible
   that they are never transmitted but are fixed by an application
   design specification.

Maybe you're missing the first 1435 bytes because they form the SPS
and PPS. You can easily verify that by looking at the missing bytes
(headers) for NAL unit type 7 and 8.

HTH

Regards
Shishir


More information about the live-devel mailing list