<div dir="ltr"><div><div>Ye, x264. <br><br>Thanks for the advice, seem to work much better now :)<br><br></div>Cheers,<br><br></div>Attila<br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">-----------------------------------------<div>

DTU Computing Center - <a href="http://www.cc.dtu.dk" target="_blank">www.cc.dtu.dk</a></div><div><a href="mailto:attila@cc.dtu.dk" target="_blank">attila@cc.dtu.dk</a>, <a href="mailto:gbaras@student.dtu.dk" target="_blank">gbaras@student.dtu.dk</a>, <a href="mailto:s070600@student.dtu.dk" target="_blank">s070600@student.dtu.dk</a></div>

<div><br></div></div></div>
<br><br><div class="gmail_quote">On Sat, Jul 6, 2013 at 6:46 PM, Faraz Khan <span dir="ltr"><<a href="mailto:faraz@screenhero.com" target="_blank">faraz@screenhero.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Are you using x264? x264 has this awesome option called intra_refresh - set that to one and use the keyint_max stuff to specify how quickly you want a intra refresh. It can be as quick as 2-3 times the framerate. With that, the decoder would magically recover even if you have 100% packet loss :) <div>


<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 6, 2013 at 9:42 AM, Attila Sukosd <span dir="ltr"><<a href="mailto:attila.sukosd@gmail.com" target="_blank">attila.sukosd@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Faraz,<br><br>Thanks a lot for your fast reply! I guess I will try to do it as you say, reconstruct the frame out of the arrived NALUs and feed that to the decoder at once.<br>


Did you run some tests on what happens in case some of the NALUs get lost due to packet loss?<br>

<br></div>Best,<br><br></div>Attila<br><div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">-----------------------------------------<div>DTU Computing Center - <a href="http://www.cc.dtu.dk" target="_blank">www.cc.dtu.dk</a></div>




<div><a href="mailto:attila@cc.dtu.dk" target="_blank">attila@cc.dtu.dk</a>, <a href="mailto:gbaras@student.dtu.dk" target="_blank">gbaras@student.dtu.dk</a>, <a href="mailto:s070600@student.dtu.dk" target="_blank">s070600@student.dtu.dk</a></div>




<div><br></div></div></div><div><div>
<br><br><div class="gmail_quote">On Sat, Jul 6, 2013 at 6:35 PM, Faraz Khan <span dir="ltr"><<a href="mailto:faraz@screenhero.com" target="_blank">faraz@screenhero.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">Atilla,<div>We tried this and came to the conclusion that ffmpeg is probably not designed to handle a single NALU at a time. You can get the parser to work in a sort of unreliable fashion if you turn on Annex-b headers in your encoder (we were using x264). However the parser may still be unable to read frames. The only reliable way is to not use the parser and feed the entire frame (directly) to ffmpeg decode. For this to work you would need some rtp magic / a jitterbuffer to accumulate these NALUs back into the entire frame. This works just fine with annex-b headers/repeat headers using x264.</div>





<div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Sat, Jul 6, 2013 at 6:49 AM, Attila Sukosd <span dir="ltr"><<a href="mailto:attila.sukosd@gmail.com" target="_blank">attila.sukosd@gmail.com</a>></span> wrote:<br>





</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div>Hi guys,<br><br>There was this thread about decoding NALUs one-by-one with parser2/decode2 and I'm having exactly the same issue.<br>





<br></div>I have x264 creating a bunch of NALUs, in annex_b and repeate_headers, and trying to decode them one by one on the client side. When I concatenate all the NALUs per frame into one large packet, and feed that directly into avcodec_decode_video2, everything is fine, the decode is successful.<br>







</div>However, when I try to feed single NALs directly to avcodec_decode_video2, it spits out a bunch of errors. After searching for a while on the net, I read some place that certain types of NALs affect the rest of the data stream, and they need to be group together. <br>







</div>I've tried to run the NALs through av_parser_parse2 and tried to decode the output buffer when the output size was larger than zero, however, after looking at the output buffer contents, it seems like while the output size seems reasonable (around the size of the NALs or a combination of a number of previous NALs), the output buffer content contains 3-4 bytes, and the rest is zero.<br>







<br></div><div>The decoding looks like this:<br><br> ret = av_parser_parse2(decoder->pParserCtx, decoder->pCodecCtx, decoder->tmp_data, &outsize, buff, size, 0, 0, AV_NOPTS_VALUE);<br> printf("%p buff, %p outdata, consumed %d, %d bufsize, %d outsize\n", buff, decoder->tmp_data,ret, size, outsize);<br>







 disp_buff(decoder->tmp_data, 50);<br> <br> if (outsize <= 0) return 0;<br><br> decoder->avpkt.flags = AV_PKT_FLAG_KEY;<br> decoder->avpkt.data = decoder->tmp_data;<br> decoder->avpkt.size = outsize;<br>







<br>  got_picture = 0;<br>  if ((ret = avcodec_decode_video2(decoder->pCodecCtx, decoder->pFrame, &got_picture, &decoder->avpkt)) < 0) {<br>                LOGE(__FUNCTION__, "H264 decoding failed!\n");<br>







                return -1;<br>  }<br><br><br></div><div>Could someone shed some light on if I'm really off the right track? or am I just missing something very trivial?<br><br><br></div><div>Best Regards,<br><br></div>







<div>Attila<br></div></div>
<br></div></div>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><br><div>--</div><div>Faraz Khan</div><div>Simple Collaboration Screensharing</div><div><a href="http://www.screenhero.com" target="_blank">www.screenhero.com</a></div>





</div>
</font></span></div>
<br>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><br><div>--</div><div>Faraz Khan</div><div>Simple Collaboration Screensharing</div><div><a href="http://www.screenhero.com" target="_blank">www.screenhero.com</a></div>


</div>
</div>
</div></div><br>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><br></div>