If I go ahead and pass the successive IDR frames, and look at the decoded picture after each, I see that each one contains a slice of the whole image.  E.g. at 640x480, I get about 5 IDR frames in a row, and each one contains a certain range of the horizontal dimension, e.g. top 5th, second 5th etc, with the entire rest of the image turned into a blur.  If I collect them all together before passing, I get one clear image.  But as you say, then the P-frames seem to be referring to the wrong image data.  I'm wondering if P-frames are also being sent as slices so I need to figure out which ones constitute a full output frame.  It seems like others have had more luck than I have with this stuff!<div>
<br></div><div>-Jesse<br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 2:16 PM, Chris Richardson (WTI) <span dir="ltr"><<a href="mailto:chris@gotowti.com" target="_blank">chris@gotowti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I also collect SPS, PPS and IDR NALS prior to sending them to FFMPEG and had forgotten about that until you mentioned it.   So I send FFMPEG buffers with either [7,8,5] or [1] each time.  The P frames are probably distorted because they refer to IDR reference pictures that are not correct.  I would guess that the P frames are referring to the first [5] in your [7, 8, 5, 5] sequence, and the last [5] in that sequence is incorrect.  Also, there is no purpose to having more than one IDR in a row, unless the whole sequence is IDRs (for enabling seeking to every single frame perhaps).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What is the data source for these sequences?  It does seem odd to me that an encoder would generate these by default.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Chris Richardson<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">WTI<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:live-devel-bounces@ns.live555.com" target="_blank">live-devel-bounces@ns.live555.com</a> [mailto:<a href="mailto:live-devel-bounces@ns.live555.com" target="_blank">live-devel-bounces@ns.live555.com</a>] <b>On Behalf Of </b>Jesse Hemingway<br>
<b>Sent:</b> Monday, February 11, 2013 11:33 AM</span></p><div class="im"><br><b>To:</b> LIVE555 Streaming Media - development & use<br></div><div><div class="h5"><b>Subject:</b> Re: [Live-devel] H.264 via RTP - ugly artifacts<u></u><u></u></div>
</div><p></p></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Ross, I'm sorry to continue this thread on your forum, but I've gotten more traction here than anywhere -- feel free to reject if you feel it's noise.<u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Jeff, to your notes: I spent a little more time experimenting.  I find that for low-res video (e.g. 240x160) I'll just get a single IDR slice at any time, and then decoding works as well as VLC (I think).  At higher res (e.g. 320x240) I start getting multiple IDR slices in a row, and then it's artifact-city.  If I buffer all IDR slices before passing to avcodec_decode_video2(), then I finally get clear-looking frames.  The sequence looks something like: [7,8,5,5], [1], [1], [1], [1], [7,8,5,5], [1], [1]...<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So even if I solve the keyframe issue as above, the intervening P-frames seem to be pushing pixels more than they should.  Basically at each keyframe, I now get a clear image, and in-between, the whole scene kind of bulges and gets more and more distorted until the next keyframe.  BTW my test example is this one: rtsp://<a href="http://media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov" target="_blank">media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov</a> (UDP blocked, as Ross pointed out).<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So two question:<u></u><u></u></p></div><div><p class="MsoNormal">A) Is it really necessary to collect all, successive I-frames to send all at once to avcodec_decode_video2(), or might this indicate some other, larger issue?  If I don't collect them all, only one fraction of the image is clear at a time, with the rest of it totally blurred.<u></u><u></u></p>
</div><div><p class="MsoNormal">B) Why would the P-frames (sent to decoder one at a time) result in such additive artifacts?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
-Jesse<u></u><u></u></p></div><div><p class="MsoNormal"><u></u><br></p></div></div></div></div></blockquote></div></div>