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

[chenjun]

Hi Shishir,
 
You are right, it contains SPS ,PPS ,but also a part of "Coded slice of an IDR picture",I list the data below:
 
00 00 00 01 27 42 00 1E 8D 8D 40 80 4A 20 00 00 00 01 28 CE 04 08 C8 00 00 00 01 25 B8 00 04 ...
 
These datas losted in transmission, So my client--Mplayer can't decoded the H264 video,it appears:
 
Error while decoding frame![h264 @ 0x87b73f4]non existing PPS referenced[h264 @ 0x87b73f4]decode_slice_header errorError while decoding frame!I solve this problem by filled the 1435 bytes zeros from the head.
 
I want to know why and where the live555 dropped these datas.
 
How to solve it in essential. 
 
Thanks for your help.
 
C.J



> Date: Thu, 25 Jan 2007 19:54:01 +0530> From: shishir at birmiwal.net> To: live-devel at ns.live555.com> Subject: Re: [Live-devel] 1435Bytes(598H) lost in the first rtp bag> > 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 mecha
nism 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> _______________________________________________> live-devel mailing list> live-devel at lists.live555.com> http://lists.live555.com/mailman/listinfo/live-devel
_________________________________________________________________
通过 Windows Live Messenger 表达您自己！
http://get.live.com/messenger/overview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070125/e30ae627/attachment-0001.html