[Bug 789415] New: vtenc: vtenc_h264 causing too many Redistribute latency...

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 789415
           Summary: vtenc: vtenc_h264 causing too many Redistribute
                    latency...
    Classification: Platform
           Product: GStreamer
           Version: 1.12.3
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: mtisza at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ! videorate ! video/x-raw,
format=UYVY, width=1920, height=1080, framerate=30/1 ! queue ! vtenc_h264 !
fakesink

I’m running gstreamer version 1.12.3 built from git source, on a 2017 15”
Macbook Pro, w/macOS 10.12.6.

The relevant output:
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.154950000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 5
fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.235169000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 6
fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.241439000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 5
fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.253913000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 6
fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.278467000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 7
fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:00.288046000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 6
fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.371569000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 7
fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:03.043466000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 6
fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:03.065692000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 5
fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:03.090887000 72088 0x7ff6d7010370 INFO                   vtenc
vtenc.c:1070:gst_vtenc_update_latency:<vtenc_h264-0> latency status 0 frames 4
fps 30/1 time 0:00:00.133333332
Redistribute latency...


The vtenc_h264 element is calling gst_video_encoder_set_latency() seemingly way
too often.  It results in gst-launch printing "Redistribute latency..." quite
often (several times per second sometimes).

What's happening seems to be the element keeping track of the underlying
encoder's pending frame count.  If the pending frame count ever changes
(checked every frame), then it calls gst_video_encoder_set_latency().

Is it not the case that instead of tracking exact latency each frame and
forcing a pipeline latency redistribution every time it changes at all, the
element should just check if the latency is greater than the currently
configured range (checked via call to gst_video_encoder_get_latency()) and only
call gst_video_encoder_set_latency() if it's outside the range?

I will attach a patch that works for me shortly.

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