After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758640 - Using vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 profile results in timestamp problems
Using vtenc_h264 in RTSP media factory with low frame rates and 'main' h264 p...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-25 10:20 UTC by Heinrich Fink
Modified: 2018-11-03 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Heinrich Fink 2015-11-25 10:20:01 UTC
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?
Comment 1 Nicolas Dufresne (ndufresne) 2018-09-21 22:01:34 UTC
I've hit a timestamp bug with rtph264pay today, where the first slice (I'm encoding with 4 slices per  frames) have the previous frame timestamp. Though I only reproduce so far with alignment=nal or no alignment. I can imagine if it's your case that at very low rate, all frames would end up late. I'll file a separate issue, but will link it here, in case you are still available to test.
Comment 2 GStreamer system administrator 2018-11-03 13:43:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/329.