<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 9pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>Hi Shishir,<BR>
<BR>
You are right, it contains SPS ,PPS ,but also a part of "Coded slice of an IDR picture",I list the data below:<BR>
<BR>
<BR>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 ...<BR>
<BR>
These datas losted in transmission, So my client--Mplayer can't decoded the H264 video,it appears:<BR>
<BR>
<SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: #333333; FONT-FAMILY: Simsun; mso-fareast-font-family: 宋体; mso-font-kerning: 1.0pt; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Error while decoding frame!<BR>[h264 @ 0x87b<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:chmetcnv w:st="on" TCSC="0" NumberType="1" Negative="False" HasSpace="False" SourceValue="73" UnitName="F">73f</st1:chmetcnv>4]non existing PPS referenced<BR>[h264 @ 0x87b<st1:chmetcnv w:st="on" TCSC="0" NumberType="1" Negative="False" HasSpace="False" SourceValue="73" UnitName="F">73f</st1:chmetcnv>4]decode_slice_header error<BR>Error while decoding frame!<BR style="mso-special-character: line-break"><BR style="mso-special-character: line-break"></SPAN>I solve this problem by filled the 1435 bytes zeros from the head.<BR>
<BR>
I want to know why and where the live555 dropped these datas.<BR>
<BR>
How to solve it in essential. <BR>
<BR>
Thanks for your help.<BR>
<BR>
C.J<BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Thu, 25 Jan 2007 19:54:01 +0530<BR>> From: shishir@birmiwal.net<BR>> To: live-devel@ns.live555.com<BR>> Subject: Re: [Live-devel] 1435Bytes(598H) lost in the first rtp bag<BR>> <BR>> Chenjun,<BR>> <BR>> > I compared the received datas with the original datas, I found the first<BR>> > streaming rtp bag always lost about<BR>> > 1435bytes data from the head, however after that the data transmission are<BR>> > correct.Maybe you can give me a hint.<BR>> ><BR>> <BR>> Maybe this will help (from RFC 3984 - RTP Payload Format for H.264 Video):<BR>> <BR>> Section 1.2:<BR>> <BR>> One very fundamental design concept of H.264 is to generate self-<BR>> contained packets, to make mechanisms such as the header duplication<BR>> of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11]<BR>> unnecessary. This was achieved by decoupling information relevant to<BR>> more than one slice from the media stream. This higher layer meta<BR>> information should be sent reliably, asynchronously, and in advance<BR>> from the RTP packet stream that contains the slice packets.<BR>> (Provisions for sending this information in-band are also available<BR>> for applications that do not have an out-of-band transport channel<BR>> appropriate for the purpose.) The combination of the higher-level<BR>> parameters is called a parameter set. The H.264 specification<BR>> includes two types of parameter sets: sequence parameter set and<BR>> picture parameter set. An active sequence parameter set remains<BR>> unchanged throughout a coded video sequence, and an active picture<BR>> parameter set remains unchanged within a coded picture. The sequence<BR>> and picture parameter set structures contain information such as<BR>> picture size, optional coding modes employed, and macroblock to slice<BR>> group map.<BR>> <BR>> To be able to change picture parameters (such as the picture size)<BR>> without having to transmit param
eter set updates synchronously to the<BR>> slice packet stream, the encoder and decoder can maintain a list of<BR>> more than one sequence and picture parameter set. Each slice header<BR>> contains a codeword that indicates the sequence and picture parameter<BR>> set to be used.<BR>> <BR>> This mechanism allows the decoupling of the transmission of parameter<BR>> sets from the packet stream, and the transmission of them by external<BR>> means (e.g., as a side effect of the capability exchange), or through<BR>> a (reliable or unreliable) control protocol. It may even be possible<BR>> that they are never transmitted but are fixed by an application<BR>> design specification.<BR>> <BR>> Maybe you're missing the first 1435 bytes because they form the SPS<BR>> and PPS. You can easily verify that by looking at the missing bytes<BR>> (headers) for NAL unit type 7 and 8.<BR>> <BR>> HTH<BR>> <BR>> Regards<BR>> Shishir<BR>> _______________________________________________<BR>> live-devel mailing list<BR>> live-devel@lists.live555.com<BR>> http://lists.live555.com/mailman/listinfo/live-devel<BR><BR><br /><hr />通过 MSN Spaces，可以直接用电子邮件发布网络日志，上载笑话、照片等。它是免费的！ <a href='http://spaces.msn.com' target='_new'>它是免费的！</a></body>
</html>