ges-launch: repeat frame and render result to short
Describe your issue
From a live source (v4l2src) and a h264/mp4 encoding, the playback with ges-launch and a given duration is not accurate.
First to generate the video bigger than 3s, here is the following command
gst-launch-1.0 -v -e v4l2src ! timeoverlay ! videoconvert ! x264enc ! h264parse ! queue ! qtmux name=mux ! filesink location=/tmp/live.mov
And then try to clip the initial video to 2.0 seconds
$ ges-launch-1.0 +clip /tmp/live.mov layer=1 duration=2.0 inpoint=0.0 -f "video/quicktime:video/x-h264" -o /tmp/result.mp4
In this case the result will miss one frame at the end and one frame will be duplicate in the beginning.
Should have one more frame in the result
By investigating a bit more the issue, I realized that the issue came from the
videorate element we are using in a nlecomposition which is recomputing the buffer's timestamp and change the timeline to loose one frame in this use case.
This use case below is what ges-launch is using as a pipeline (cleaned up) and reproduce the exact error faced in the original use case.
$ gst-play-1.0 "nleurisource uri=file:///tmp/live.mov caps=video/x-h264 inpoint=0 duration=2000000000 ! decodebin ! identity ! videorate ! identity ! videoconvert ! autovideosink" > result.txt 2>&1
This use case below is tricking
videorate to not change the timestamps and this includes all the frames with timestamps from the original file:
$ gst-play-1.0 "nleurisource uri=file:///tmp/live.mov caps=video/x-h264 inpoint=0 duration=2000000000 ! decodebin ! identity ! videorate drop-only=true ! identity ! videoconvert ! autovideosink" > result.txt 2>&1
- Operating System: LINUX
- Device: Computer
- GStreamer Version: 1.19.1
- Command line:
Steps to reproduce the bug
See #observed behavior
How reproducible is the bug?
Always but the timestamps can differ a little bit
Screenshots if relevant
Solutions you have tried
I tried to use drop-only=true. I'm wondering if it's necessary to use the
Related non-duplicate issues
No issues with non live source (videotestsrc) seen that the timestamp are consecutive and the gst segment starts from 0.