[Bug 773084] gstavviddec posts incorrect latency

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773084

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #4 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Oops, in fact we only consider the reordering of b-frames. But the way it's
implemented, there is no other delay information that can be used.

As of now:

 latency = gst_util_uint64_scale_ceil (
        (ffmpegdec->context->has_b_frames) * GST_SECOND, info->fps_d,
        info->fps_n);

So we are looking for a number of frames that we scale in millisecond using the
framerate. Not sure that exist, but if we had a live stream with rate != 1,
that match would not be correct. Let's ignore for now. Looking at the doc, I
found the following to impact the latency:

if (thread_type == FF_THREAD_FRAME)
  frame_latency += thread_count

vbv_delay is deprecated, and not implemented in anything useful. It's also
specific to MPEG2 Video. In H264, this encoder parameter does not affect the
decoding delay.

There is delay, and video_delay, which I guess were supposed to be sine
aggregated delay, but in fact they are only partially implemented (apedec,
opusdec, mpegvideo_enc, some filters and gifdec). Nothing interesting really.
video_delay is no implemented anywhere useful, it is also not documented.

So all in all, I think the correct formula would be:

  frame_latency = ffmpegdec->context->has_b_frames

  if (thread_type == FF_THREAD_FRAME)
    frame_latency += thread_count

  latency = gst_util_uint64_scale_ceil (frame_latency * GST_SECOND,
info->fps_d,
        info->fps_n);

But, if the pipeline is live, we always set thread_type to FF_THREAD_SLICE to
avoid the extra delays. So in the end, our formula is mainly the best we can
do.

Now, has_b_frames is a confusing name, so there could be a bug in the
implementation. It's name makes it look like a boolean, but it's a size:

  Size of the frame reordering buffer in the decoder.

I think you should trace that value to help further with this bug report.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.