[x264-devel] Reference picture selection

[Jason Garrett-Glaser]

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