[Live-devel] H.264 via RTP - ugly artifacts

[Jesse Hemingway]

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)
<chris at gotowti.com>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:* live-devel-bounces at ns.live555.com [mailto:
> live-devel-bounces at ns.live555.com] *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****
>
> **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130211/135b48f7/attachment.html>