<p dir="ltr">On 28 Nov 2012 20:21, "serdel" <<a href="mailto:serdel@toya.net.pl">serdel@toya.net.pl</a>> wrote:<br>
><br>
> I implemented a simple algorithm which kept track of previous frame and the<br>
> current one and checked if the sequence is correct. If it wasn't I didn't<br>
> put the frame to the avcodec_decode_video2 function and stayed that way<br>
> until next sequence has started. It brought the desired results until one<br>
> unlucky moment where there was no missing packets in live555, but the main<br>
> frame still got decoded incorrectly (positive return value and 0 as<br>
> got_picture_ptr) and the same situation all over again. Why doesn't<br>
> flushing the buffer help here? I am now thinking about reinitializing the<br>
> whole ffmpeg on that occurrence, but it seems brutal...<br>
><br>
><br>
> On Wed, 28 Nov 2012 18:48:45 +0200, Alex Cohn <<a href="mailto:alexcohn@netvision.net.il">alexcohn@netvision.net.il</a>><br>
> wrote:<br>
> > On Wed, Nov 28, 2012 at 2:27 PM, serdel <<a href="mailto:serdel@toya.net.pl">serdel@toya.net.pl</a>> wrote:<br>
> ><br>
> >> 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<br>
> >> normal<br>
> >> work, avcodec_decode_video2 returns positive value of bytes used and<br>
> sets<br>
> >> the got_picture_ptr to the positive value. On SPS&PPS the return value<br>
> is<br>
> >> -1 and got_picture_ptr is 0. This is a normal sequence and works<br>
> >> perfectly<br>
> >> without any errors or lags. The problem appears when some packet is lost<br>
> >> 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<br>
> >> 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<br>
> >> positive<br>
> >> value of used bytes, but the got_picture_ptr is 0 - not a normal<br>
> >> 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<br>
> frames.<br>
> >> This keeps on going a couple of 'full seqences' (SPS&PPS,NAL_IDR_SLIC<br>
> and<br>
> >> following NAL_SLICE) and finally on some of the frames jumps bakc to<br>
> >> normal<br>
> >> work (avcodec_decode_video2 return is positive and got_picture_ptr is<br>
> >> 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<br>
> >> in<br>
> >> the screen which would indicate some lost frames - no, the picture keeps<br>
> >> on<br>
> >> from where it froze and is just delayed to the sender stream by those<br>
> 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>
> >><br>
> ><br>
> > It looks as if the decoder expects an I-frame after SPS&PPS, so it<br>
> refuses<br>
> > to accept P-frames. This does not readily explain your finding that it<br>
> > takes a couple of "full sequences", but this is at least some start.<br>
> ><br>
> > The remedy then would be to delay feeding SPS&PPS to decoder until you<br>
> have<br>
> > a complete I-frame from RTPS. If LIVE555 throwed this frame away, then<br>
> > throw away SPS&PPS and proceed with the following frames.<br>
> ><br>
> > Note that H264 stream is not error-resilient, and you can see all kinds<br>
> of<br>
> > artifacts when some frames are missing. Things can become especially<br>
> nasty<br>
> > if the stream uses B-frames (not in 'Ultrafast' profile). But at least<br>
> this<br>
> > way you will hopefully not have the movie freeze for few seconds.<br>
> ><br>
> > Sincerely,<br>
> > Alex<br>
> </p>
<p dir="ltr">So, you sometimes receive frames that fail to decode. How often does it happen? And what is your GOP length and FPS?</p>
<p dir="ltr">BR,<br>
Alex<br>
</p>