<div dir="ltr">On Wed, Nov 28, 2012 at 2:27 PM, serdel <span dir="ltr"><<a href="mailto:serdel@toya.net.pl" target="_blank">serdel@toya.net.pl</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am using ffmpeg to decode an rtps (live555) streaming. I decode each<br>
frame separately in a standard sequence. The normal sequence is SPS and<br>
PPS, then NAL_IDR_SLICE and finaly NAL_SLICE until next SPS&PPS. On normal<br>
work, avcodec_decode_video2 returns positive value of bytes used and sets<br>
the got_picture_ptr to the positive value. On SPS&PPS the return value is<br>
-1 and got_picture_ptr is 0. This is a normal sequence and works perfectly<br>
without any errors or lags. The problem appears when some packet is lost in<br>
frame transmission (WiFi transmission with some noise around). Live555<br>
rejects the rest of the packets for this frame so the entire frame is lost.<br>
In almost all of the cases it is the  NAL_IDR_SLICE frame since it is<br>
usually about 20 times bigger than NAL_SLICE frames. So when the next<br>
NAL_SLICE frame arrives complete the avcodec_decode_video2 returns positive<br>
value of used bytes, but the got_picture_ptr is 0 - not a normal behaviour.<br>
The worse thing is that this continues to happen to every next NAL_SLICE<br>
frame and to the next NAL_IDR_SLICE with it's following NAL_SLICE frames.<br>
This keeps on going a couple of 'full seqences' (SPS&PPS,NAL_IDR_SLIC and<br>
following NAL_SLICE) and finally on some of the frames jumps bakc to normal<br>
work (avcodec_decode_video2 return is positive and got_picture_ptr is also<br>
non-zero positive). On this occur the screen picture freezes for 2-3<br>
seconds and continuous running with no jump_over! You don't see any jump in<br>
the screen which would indicate some lost frames - no, the picture keeps on<br>
from where it froze and is just delayed to the sender stream by those 2-3<br>
seconds.<br>
<br>
I tried detecting this situation and when it occurs I run<br>
avcodec_flush_buffers() followed by  avcodec_decode_video2 with a dummy<br>
empty AVPacket to somehow reset the coded state but it didn't help. Does<br>
any one have any other suggestions?<br></blockquote><div><br></div><div>It looks as if the decoder expects an I-frame after SPS&PPS, so it refuses to accept P-frames. This does not readily explain your finding that it takes a couple of "full sequences", but this is at least some start.</div>
<div><br></div><div>The remedy then would be to delay feeding SPS&PPS to decoder until you have a complete I-frame from RTPS. If LIVE555 throwed this frame away, then throw away SPS&PPS and proceed with the following frames.</div>
<div><br></div><div>Note that H264 stream is not error-resilient, and you can see all kinds of artifacts when some frames are missing. Things can become especially nasty if the stream uses B-frames (not in 'Ultrafast' profile). But at least this way you will hopefully not have the movie freeze for few seconds.</div>
<div><br></div><div>Sincerely,</div><div>Alex</div></div></div>