Thanks Jeff,<div><br></div><div>I tried out your suggestion of caching and passing the 7,8 frames before every keyframe, so my sequence looked like 7,8,5,7,8,5,7,8,5,1,1,1,1,1,1,7,8,5,7,8,5,... however, I got exactly the same visual artifacts. I think I'm also safe on the prefix endian-ness, as I pack my buffer with:</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>uint8_t nalStartSequence[] = { <span class="s1">0x00</span>, <span class="s1">0x00</span>, <span class="s1">0x00</span>, <span class="s1">0x01</span> };</div>
</blockquote><div><br></div><div>I'm pretty stymied, especially in light of the fact avcodec_decode_video2() is not reporting any errors, other than the disturbingly-consistent DC, AC and MV concealment on every frame (the error count is a constant function of the picture dimensions). </div>
<div><br></div><div>-Jesse</div>
<div><br></div><div><br><div class="gmail_quote">On Sun, Feb 10, 2013 at 5:29 PM, Jeff Shanab <span dir="ltr"><<a href="mailto:jshanab@smartwire.com" target="_blank">jshanab@smartwire.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div style="direction:ltr;font-size:13px;font-family:Tahoma">
<div>I had the same problem a while back. I also use live555 feeding libavcodec.<br>
While the standard only says you need to have a 7 and an 8 before the first 5 and that after that the 5 or 1 is valid, I have had decoding trouble because of it.<br>
So while all the following are technically legal<br>
7,8,5,1,1,1,1,5,1,1,1...<br>
7,8,5,1,1,1,1,1,1......<br>
7,8,5,5,5,1,1,1,5,1,1,1,5,1,1,1 (some axis cameras by default)<br>
<br>
It is the decoder not live555 that needs the 7,8,5 at the beginning of every key frame.
<br>
I have gotten arguments about this, It seems to vary by version. The 7 and 8 packets are so small compared to
<br>
the key frame slices [5] and the diff frames [1] that I just cache them and inject them if missing. Not only do I get<br>
Rock solid playback, I do not need to worry about a second user starting late on a multicast or trouble when I seek.<br>
<br>
BTW each and every frame needs the 0x00 0x00 0x00 0x01 (4 bytes, aka network byte order. not a 32 bit byte that could end up with endian issues)<br>
</div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b> From:</b> <a href="mailto:live-devel-bounces@ns.live555.com" target="_blank">live-devel-bounces@ns.live555.com</a> [<a href="mailto:live-devel-bounces@ns.live555.com" target="_blank">live-devel-bounces@ns.live555.com</a>] on behalf of Jesse Hemingway [<a href="mailto:jhemingw@nerdery.com" target="_blank">jhemingw@nerdery.com</a>]<br>
<b>Sent:</b> Friday, February 08, 2013 8:36 PM<div class="im"><br>
<b>To:</b> LIVE555 Streaming Media - development & use<br>
</div><b>Cc:</b> LIVE555 Streaming Media - development & use<br>
<b>Subject:</b> Re: [Live-devel] H.264 via RTP - ugly artifacts<br>
</font><br>
</div>
<div></div>
<div>
<div><div class="im">Interesting, thank you for the response. I actually discard all but 7, 8 and 5 frames that occur before the initial 'priming' is complete, they are just logged for completeness. So my first buffer passed is of the form [7 8 5], after which I pass all
frames willy-nilly, even the timing NAL [ 6 ]. I'm wondering if my bytestream framing is wrong? 0x000001.NAL.0x00. I read the Appendix B bytestream syntax and also the ffmpeg NAL detection code and it seems sufficient, but I've also read posts that indicated
this simple approach was incorrect.<br></div>
<snip></div>
</div>
</div>
</div>
<p>This message and any attachments contain confidential and proprietary
information, and may contain privileged information, belonging to one or more
affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege
is waived by this transmission. Unauthorized use, copying or disclosure of such
information is prohibited and may be unlawful. If you receive this message in
error, please delete it from your system, destroy any printouts or copies of it,
and notify the sender immediately by e-mail or phone.</p><br></div>
<br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jesse Hemingway<br>Interactive Developer | <a href="http://www.nerdery.com/copresident" target="_blank">Co-President</a><br>The Nerdery<br>(952) 582.6507 // office<br>
(612) 205.4682 // mobile<br><a href="mailto:jesse.hemingway@nerdery.com" target="_blank">jesse.hemingway@nerdery.com</a><br><a href="http://nerdery.com/Hm" target="_blank">http://nerdery.com/people#hw</a>
</div>