[Live-devel] H264 dropped P frames

[Jeff Shanab]

Thanks. I do understand how the event model works (Quite eloquent BTW).

The fact that it throws away complete NAL units if a piece of a fragment has loss explains why it appears as dropping NALs.

Here is the only part I cannot figure out. Why does it not lose any packets if I use OpenRtsp on the command line.
Why does VLC have no problem with the video live.

Almost like the sender is not following standard flow control and only a simple flat out copy will grab it fast enough. This is not high resolution or large NALS.
21k for a key frame 1K-2K for the P-Frames 30fps with a GOP size that varies but averages 38.
My class is almost identical to the PLayCommon.cpp + OpenRtsp.cpp code. I have a memorySink, filter, and async file writing queue.






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.

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, May 02, 2013 4:04 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 dropped P frames

Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn't clear out the buffer? Then it hits the max, dumps it and starts over.

No, but note that if - as with all payload formats - if one frame (in this case, one H.264 NAL unit) is fragmented over multiple RTP packets, then if any one of these RTP packets gets lost, then the entire NAL unit will get discarded.  That's why - yet again - H.264 encoders should not create excessively large NAL units.

In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry:

**********
            It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it MUST be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets.
**********

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130502/254e0458/attachment.html>