[Libav-user] Force low-delay handling? question + feature suggestion

[Camera Man]

On 03/12/2012 04:49 AM, Alex Cohn wrote:
> On Mon, Mar 12, 2012 at 10:28, Camera Man<i.like.privacy.too at gmail.com>  wrote:
>> Where avcodec_h264_internal_fetch_most_recent() would get a copy of the
>> highest pts frame in the delay buffer, without changing or discarding it. If
>> this is possible (and I manage to write this ... I'm not sure I understand
>> all of h264 internals), then it would introduce a "lowest delay" from
>> bitstream to display - at the cost of not showing any out-of-order frames
>> (having an effectively lower frame rate - but much better real-time
>> latency).
> Your suggestion looks incorrect to me: the frames that you may skip
> this way could be referenced by the frames you want to display,
> therefore your result will be distorted.
What I want to do in that routine (again, I am not sure it is possible - 
you are probably right, but I want to explain myself better):

Let's say the stream is IPPP=1234, and the pts order is 1432. (I frame 
first, then P frames in reverse order). If I understand correctly, frame 
'2' can only depend on frame '1'.

Now, if I look into the decoder's delay buffer,
after the first decode, the highest pts in the delay buffer would be 1;
after the 2nd decode, the highest pts in the delay buffer would be 2;
after the 3rd decode and 4th decode it would still be 2.

I would be completely ignoring frames 3 and 4, which is fine -- as soon 
as I've seen 2 in the stream, I want to display it.

Assuming that there is actually NO reorder, Anton Khirnov suggested 
setting CODEC_FLAG_LOW_DELAY - I'll test that (together with your 
suggestion of zeroing num_reorder_frame) and update.
> You should decode as many frames as possible at any time. The question
> is - which frames to display. You can safely choose to always display
> the latest (in terms of pts).
The reason I want to reach into the delay buffer to find the highest pts 
picture, though, is that I'm doing this in real time - and with a 5 fps 
stream, the 4-picture lag between bitstream arrival and decode_video2 
resposne is about 1 second, which is too much for this application. If 
this was a pre-recorded stream, then I could just keep decoding until I 
get pictures and there wouldn't be any problem.