[x264-devel] Reference picture selection

[Arindam Biswas]

Thank you for your response. I will defenitely try out periodic intra
refresh.

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.
In the normal condition I am getting 5% packet loss and I am using rate
adaptation and
retransmission to recover from that.
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.
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?

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.

Thanks
Arindam


On Fri, Jan 1, 2010 at 11:35 PM, Jason Garrett-Glaser <darkshikari at gmail.com
> wrote:

> On Sat, Jan 2, 2010 at 2:14 AM, Arindam Biswas <send2ari at gmail.com> wrote:
> > Hi,
> > I am using x264 for live video stream encoding and then it is transmitted
> > over rtp. In my server application I get feedback from my rtp client
> about
> > which particular frame has been received by the decoder without any
> error.
> > So for my next frame encoding I want to reference from that frame which
> has
> > been received by decoder.
> > To do this I am dropping frame from my encoder's DPB.
>
> You might find periodic intra refresh a far better option for
> resilient streaming.  It'll be committed in a few days to weeks and
> there's a test patch in this thread if you're interested:
>
> http://forum.doom9.org/showthread.php?t=151733
>
> Unlike feedback mechanisms (e.g. ignoring refs in the DPB, sending new
> I-frames), it requires no extra latency.  When combined with
> one-slice-per-packet, it's been reported to be resilient to packet
> loss up to 15-25%.  Additionally, a new receiver can jump on the
> stream at any point without the need for keyframes.  Furthermore, your
> method has only two states for a frame: dropped and not dropped,
> despite the fact that one usually loses only one packet, not the whole
> frame, which may be rather inefficient, especially at high packet
> losses.
>
> But if you do want to implement what you're talking about, the best
> way to do it is to modify the reference list reordering functions.
> Dropping frames from the DPB is way too complicated and unnecessary.
>
> > I have checked h->frames.reference is a 16 size array, Does that mean
> x264
> > always keeps 16 frames in its DPB?
>
> No, that's just the max size.
>
> > If I find that received_poc is 10 frames earlier ( aasume poc=n) than the
> > current frame to be encoded and if it is available in my DPB then after
> > encoding at my client's decoder reference buffer will that nth frame be
> > still available for referencing?
>
> Only if your --ref is high enough.
>
> Dark Shikari
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100102/a8f83307/attachment.htm>