[Libav-user] Force low-delay handling? question + feature suggestion
i.like.privacy.too at gmail.com
Mon Mar 12 10:14:18 CET 2012
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
> 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.
More information about the Libav-user