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

[Jesse Hemingway]

Thanks Jeff,

I tried out your suggestion of caching and passing the 7,8 frames before
every keyframe, so my sequence looked like
7,8,5,7,8,5,7,8,5,1,1,1,1,1,1,7,8,5,7,8,5,... however, I got exactly the
same visual artifacts.  I think I'm also safe on the prefix endian-ness, as
I pack my buffer with:

uint8_t nalStartSequence[] = { 0x00, 0x00, 0x00, 0x01 };


I'm pretty stymied, especially in light of the fact avcodec_decode_video2()
is not reporting any errors, other than the disturbingly-consistent DC, AC
and MV concealment on every frame (the error count is a constant function
of the picture dimensions).

-Jesse


On Sun, Feb 10, 2013 at 5:29 PM, Jeff Shanab <jshanab at smartwire.com> wrote:

>  I had the same problem a while back. I also use live555 feeding
> libavcodec.
> While the standard only says you need to have a 7 and an 8 before the
> first 5 and that after that the 5 or 1 is valid, I have had decoding
> trouble because of it.
> So while all the following are technically legal
> 7,8,5,1,1,1,1,5,1,1,1...
> 7,8,5,1,1,1,1,1,1......
> 7,8,5,5,5,1,1,1,5,1,1,1,5,1,1,1 (some axis cameras by default)
>
> It is the decoder not live555 that needs the 7,8,5 at the beginning of
> every key frame.
> I have gotten arguments about this, It seems to vary by version. The 7 and
> 8 packets are so small compared to
> the key frame slices [5] and the diff frames [1] that I just cache them
> and inject them if missing. Not only do I get
> Rock solid playback, I do not need to worry about a second user starting
> late on a multicast or trouble when I seek.
>
> BTW each and every frame needs the 0x00 0x00 0x00 0x01  (4 bytes, aka
> network byte order. not a 32 bit byte that could end up with endian issues)
>  ------------------------------
> * From:* live-devel-bounces at ns.live555.com [
> live-devel-bounces at ns.live555.com] on behalf of Jesse Hemingway [
> jhemingw at nerdery.com]
> *Sent:* Friday, February 08, 2013 8:36 PM
>
> *To:* LIVE555 Streaming Media - development & use
> *Cc:* LIVE555 Streaming Media - development & use
> *Subject:* Re: [Live-devel] H.264 via RTP - ugly artifacts
>
>   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.
> <snip>
>
> This message and any attachments contain confidential and proprietary
> information, and may contain privileged information, belonging to one or
> more affiliates of Windy City Wire Cable & Technology Products, LLC. No
> privilege is waived by this transmission. Unauthorized use, copying or
> disclosure of such information is prohibited and may be unlawful. If you
> receive this message in error, please delete it from your system, destroy
> any printouts or copies of it, and notify the sender immediately by e-mail
> or phone.
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Jesse Hemingway
Interactive Developer | Co-President <http://www.nerdery.com/copresident>
The Nerdery
(952) 582.6507 // office
(612) 205.4682 // mobile
jesse.hemingway at nerdery.com
http://nerdery.com/people#hw <http://nerdery.com/Hm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130211/884c9990/attachment.html>