[Bug 758640] New: Using vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 profile results in timestamp problems

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 758640
           Summary: Using vtenc_h264 in RTSP media factory with low frame
                    rates and 'main' h264 profile results in timestamp
                    problems
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: hfink at toolsonair.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When testing low frame rates like 1/1 in our RTSP server code using vtenc_h264,
we have observed time stamp problems in the client, which are likely due to
some timestamp problems already on the server side. This can be reproduced as
follows:

Use gst-rtsp-server's test-launch example with the following launch line: 

./test-launch "videotestsrc is-live=true ! vtenc_h264
allow-frame-reordering=false realtime=true max-keyframe-interval=1 bitrate=6000
! video/x-h264,profile=main,width=1920,height=1080,framerate=1/1 ! rtph264pay
name=pay0 pt=96"

Then simply play back the stream using gst-play-1.0. This will result in the
client complaining about timestamps problems ("warning: There may be a
timestamping problem, or this computer is too slow.", etc).

Now, simply changing the above launch line to use profile=baseline instead of
profile=main, makes the example work flawlessly: 

./test-launch "videotestsrc is-live=true ! vtenc_h264
allow-frame-reordering=false realtime=true max-keyframe-interval=1 bitrate=6000
! video/x-h264,profile=baseline,width=1920,height=1080,framerate=1/1 !
rtph264pay name=pay0 pt=96"

My knowledge about the h264/RTSP specific parts is too little that I can make a
lot of sense out of this, but I did a little bit of digging, and here are some
facts I found which might be relevant:

(1) using profile=main works with x264enc, although x264 seems to fall back to
constrained-baseline, when being configured to not use any B frames and use
intra encoding only

(2) Changing between profile=main and profile=baseline doesn't change the
latency 
introduced by vtenc (which is unnecessarily high here, but that's another
story), i.e. the timing of the buffers being emitted out of vtenc is the same

(3) Changing the frame rate to 2/1 (instead of 1/1) makes it also work with
profile=main.

I was able to narrow our bug down so far and make it reproducible using
standard GST tools, but I need help to further narrow it down. Especially, we
can't say for sure whether this is (a) a bug of vtenc/VT toolbox (b) a bug in
rtph264pay or (c) a bug somewhere further down in the RTSP server. Any ideas?

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