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!
-Jesse On Mon, Feb 11, 2013 at 2:16 PM, Chris Richardson (WTI) <[email protected]>wrote: > Hi,**** > > ** ** > > 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).**** > > ** ** > > What is the data source for these sequences? It does seem odd to me that > an encoder would generate these by default.**** > > ** ** > > Chris Richardson**** > > WTI**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Jesse Hemingway > *Sent:* Monday, February 11, 2013 11:33 AM > > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] H.264 via RTP - ugly artifacts**** > > ** ** > > 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.**** > > ** ** > > 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]...**** > > ** ** > > 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:// > media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov (UDP blocked, > as Ross pointed out).**** > > ** ** > > So two question:**** > > 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.**** > > B) Why would the P-frames (sent to decoder one at a time) result in such > additive artifacts?**** > > ** ** > > -Jesse**** > > ** >
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
