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.
{iPhone}
On Feb 8, 2013, at 6:28 PM, "Chris Richardson \(WTI\)" <[email protected]>
wrote:
> 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: [email protected]
> [mailto:[email protected]] 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
> ...
> _______________________________________________
> live-devel mailing list
> [email protected]
> http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
