Using vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 profile results in timestamp problems
Submitted by Heinrich Fink
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?