<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Chris Richardson<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>WTI<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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"'> live-devel-bounces@ns.live555.com [mailto:live-devel-bounces@ns.live555.com] <b>On Behalf Of </b>Jesse Hemingway<br><b>Sent:</b> Monday, February 11, 2013 11:33 AM<br><b>To:</b> LIVE555 Streaming Media - development & use<br><b>Subject:</b> Re: [Live-devel] H.264 via RTP - ugly artifacts<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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]...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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">media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov</a> (UDP blocked, as Ross pointed out).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So two question:<o:p></o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal>B) Why would the P-frames (sent to decoder one at a time) result in such additive artifacts?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Jesse<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Feb 11, 2013 at 10:10 AM, Jesse Hemingway <<a href="mailto:Jesse.Hemingway@nerdery.com" target="_blank">Jesse.Hemingway@nerdery.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Thanks Jeff,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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:<o:p></o:p></p></div><blockquote style='margin-left:30.0pt;margin-right:0in'><div><p class=MsoNormal>uint8_t nalStartSequence[] = { 0x00, 0x00, 0x00, 0x01 };<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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). <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Jesse<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Sun, Feb 10, 2013 at 5:29 PM, Jeff Shanab <<a href="mailto:jshanab@smartwire.com" target="_blank">jshanab@smartwire.com</a>> wrote:<o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>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)<o:p></o:p></span></p></div><div><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="100%" align=center></div><div><p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif";color:black'> From:</span></b><span style='font-family:"Tahoma","sans-serif";color:black'> <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<o:p></o:p></span></p><div><p class=MsoNormal><span style='font-family:"Tahoma","sans-serif";color:black'><br><b>To:</b> LIVE555 Streaming Media - development & use<o:p></o:p></span></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-family:"Tahoma","sans-serif";color:black'>Cc:</span></b><span style='font-family:"Tahoma","sans-serif";color:black'> LIVE555 Streaming Media - development & use<br><b>Subject:</b> Re: [Live-devel] H.264 via RTP - ugly artifacts</span><o:p></o:p></p></div><div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div><p class=MsoNormal><snip><o:p></o:p></p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>_______________________________________________<br>live-devel mailing list<br><a href="mailto:live-devel@lists.live555.com" target="_blank">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><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><span style='color:#888888'><br><br clear=all><span class=hoenzb><o:p></o:p></span></span></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></body></html>