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

[James Stafford]

Hi Jesse,

> 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 
> <http://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.

Do you set the context->flags2=CODEC_FLAG2_CHUNKS for the context passed 
to avcodec_decode_video2()?
I think this is necessary in order for avcodec_decode_video2() to 
properly decode H.264 frames that span multiple calls to it.


--