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

Chris Richardson (WTI) chris at gotowti.com
Fri Feb 8 16:28:38 PST 2013


Hi,

 

We use a similar set up for our software (LIVE555 -> FFMPEG decode) and it
is working well.  The first obvious difference I can see is that normally
the SPS and PPS precede the IDR frame (type 5) rather than the non-IDR frame
(type 1), so we have 7, 8, 5, 1, 1, 1 ., 7, 8, 5, 1, 1, 1, ..  For a quick
test, I generated a NAL sequence similar to what you are generating and
FFMPEG gave me many similar errors.

 

So I would ask, how are you generating the NAL sequence on the encoder side?
Is there a reason for generating 7, 8, 1, 1, 1 . 5?

 

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: Friday, February 08, 2013 3:06 PM
To: LIVE555 Streaming Media - development & use
Subject: [Live-devel] H.264 via RTP - ugly artifacts

 

Hello,

 

I apologize if this is noise - my question may well have nothing to do with
Live555, but I thought I'd post here in case anyone can help me rule it out.
It appears I'm successfully consuming H.264 via RTSP and acquiring frames in
my mediasink.

 

Next, I set up ffmpeg's decoder with the SPS and PPS, and then proceed to
pass all the raw NAL units from Live555 to avcodec_decode_video2(...),
adding the bytestream start code prefix and trailing zero byte (I add
0x00000001 before the raw NAL, and 0x00 after).  I've enabled debug output
in ffmpeg, and it appears to be happily decoding without errors, other than
the frequent, and perhaps expected log of the form: concealing 900 DC, 900
AC, 900 MV errors in P frame.  However, when I turn this into a displayable
RGBA buffer using swscale() and display the result -- there are lots of ugly
artifacts.

 

At certain resolutions, the I frames result in a pretty clear picture.
In-between, only part of the image is even reasonably decoded, and with half
to 3/4 of the image being an interpolated blur.  Even the healthier parts
exhibit a regular grid of dots and major glitches in regions where the
source video has motion.

 

I wanted to rule out Live555 as a potential source of such trouble - does
this sound familiar to anyone?  Advice where to focus?  A relevant log
follows...

 

Thanks!

Jesse

 

LOG:

 

Received 24 bytes NAL type [ 7 ]

Priming buffer started

Received 4 bytes NAL type [ 8 ]

Received 14 bytes NAL type [ 1 ]

Received 3112 bytes NAL type [ 1 ]

Received 3444 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 2143 bytes NAL type [ 1 ]

Received 1498 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 2395 bytes NAL type [ 1 ]

Received 3512 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 3808 bytes NAL type [ 1 ]

Received 2966 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 1909 bytes NAL type [ 1 ]

Received 1774 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 3915 bytes NAL type [ 1 ]

Received 3859 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 14 bytes NAL type [ 1 ]

Received 3219 bytes NAL type [ 1 ]

Received 3355 bytes NAL type [ 1 ]

Received 16 bytes NAL type [ 1 ]

Received 2304 bytes NAL type [ 5 ]

Priming buffer complete

[h264 @ 0x90a2400] concealing 900 DC, 900 AC, 900 MV errors in I frame

Picture decoded

Initializing decoder frame of size: 640x480

[swscaler @ 0x8898600] No accelerated colorspace conversion found from
yuv420p to rgba.

Received 6900 bytes NAL type [ 5 ]

[h264 @ 0x90a2400] concealing 900 DC, 900 AC, 900 MV errors in I frame

Picture decoded

Received 6945 bytes NAL type [ 5 ]

[h264 @ 0x90a2400] concealing 900 DC, 900 AC, 900 MV errors in I frame

Picture decoded

Received 73 bytes NAL type [ 5 ]

[h264 @ 0x90a2400] concealing 900 DC, 900 AC, 900 MV errors in I frame

Picture decoded

Received 40 bytes NAL type [ 1 ]

[h264 @ 0x90a2400] concealing 900 DC, 900 AC, 900 MV errors in P frame

Picture decoded

...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130208/e5d56197/attachment-0001.html>


More information about the live-devel mailing list