Thank you for your response. I will defenitely try out periodic intra refresh.<br><br>I am streaming 480P and 720P video over wireless and using vlc media player at client end for playback. I have configured x264 keyint max 15, keyint min 5, and 8 slices per frame.<br>
In the normal condition I am getting 5% packet loss and I am using rate adaptation and <br>retransmission to recover from that.<br>But in case of interference the loss is going as high as 50% and I am seeing stall, artifact in vlc media player and some times vlc player just gives up.<br>
After checking wireshark packet capture I found consecutive 5 to 10 frame loss in case of interference. This is the reason why I was thinking about dynamic reference picture selection based on client's feedback. Will this technique help in this kind of scenario?<br>
<br>Can you suggest me if there is any other techniques, special kind of encoder profiling which can be quickly implemented on x264/ patch available in order to reduce stalls, jerks, artifacts at vlc player end.<br><br>Thanks<br>
Arindam<br> <br><br><div class="gmail_quote">On Fri, Jan 1, 2010 at 11:35 PM, Jason Garrett-Glaser <span dir="ltr"><<a href="mailto:darkshikari@gmail.com">darkshikari@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sat, Jan 2, 2010 at 2:14 AM, Arindam Biswas <<a href="mailto:send2ari@gmail.com">send2ari@gmail.com</a>> wrote:<br>
> Hi,<br>
> I am using x264 for live video stream encoding and then it is transmitted<br>
> over rtp. In my server application I get feedback from my rtp client about<br>
> which particular frame has been received by the decoder without any error.<br>
> So for my next frame encoding I want to reference from that frame which has<br>
> been received by decoder.<br>
> To do this I am dropping frame from my encoder's DPB.<br>
<br>
</div>You might find periodic intra refresh a far better option for<br>
resilient streaming. It'll be committed in a few days to weeks and<br>
there's a test patch in this thread if you're interested:<br>
<br>
<a href="http://forum.doom9.org/showthread.php?t=151733" target="_blank">http://forum.doom9.org/showthread.php?t=151733</a><br>
<br>
Unlike feedback mechanisms (e.g. ignoring refs in the DPB, sending new<br>
I-frames), it requires no extra latency. When combined with<br>
one-slice-per-packet, it's been reported to be resilient to packet<br>
loss up to 15-25%. Additionally, a new receiver can jump on the<br>
stream at any point without the need for keyframes. Furthermore, your<br>
method has only two states for a frame: dropped and not dropped,<br>
despite the fact that one usually loses only one packet, not the whole<br>
frame, which may be rather inefficient, especially at high packet<br>
losses.<br>
<br>
But if you do want to implement what you're talking about, the best<br>
way to do it is to modify the reference list reordering functions.<br>
Dropping frames from the DPB is way too complicated and unnecessary.<br>
<div class="im"><br>
> I have checked h->frames.reference is a 16 size array, Does that mean x264<br>
> always keeps 16 frames in its DPB?<br>
<br>
</div>No, that's just the max size.<br>
<div class="im"><br>
> If I find that received_poc is 10 frames earlier ( aasume poc=n) than the<br>
> current frame to be encoded and if it is available in my DPB then after<br>
> encoding at my client's decoder reference buffer will that nth frame be<br>
> still available for referencing?<br>
<br>
</div>Only if your --ref is high enough.<br>
<br>
Dark Shikari<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div><br>