Truncated Video

Application Development
1

My post processing pipeline/application has been working fine for months, then all of a sudden, I get a video that is truncated upon output. This makes me think it is the video itself; however, it plays fine in VLC, ffplay, etc and nothing seems wrong with the video.

The processing pipeline I am using is the following:

GST_DEBUG=3 gst-launch-1.0 -e filesrc location=buggy.mp4 ! decodebin3 ! queue ! encodebin2 profile='video/x-h265' ! mp4mux ! filesink location=out.mp4

The input video is 80 seconds long and the output is 1.93 seconds?!

The only clue I receive is the following from the gstreamer output:

(gst-launch-1.0:82): GStreamer-WARNING **: 03:46:48.728: ../subprojects/gstreamer/gst/gstpad.c:5447:store_sticky_event:<decodebin3-0:video_0> Sticky event misordering, got 'segment' before 'caps'
0:00:01.505501846    82 0x7ad4400019a0 WARN                GST_CAPS gstpad.c:3275:gst_pad_query_accept_caps_default:<h265parse0:sink> caps: video/x-raw(memory:CUDAMemory), format=(string)NV12, width=(int)3264, height=(int)2464, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)15/1 were not compatible with: video/x-h265

Link to the video causing issues: buggy.mp4

Also, if I create a video with the same dimensions (3264x2464) using the videotestsrc element, the processing pipeline crashes for h264 with qtdemux internal data stream error?
create test video

gst-launch-1.0 -e videotestsrc timestamp-offset=1933000000 ! video/x-raw,width=3264,height=2464 ! queue ! nvh265enc ! queue ! mp4mux ! filesink location=testsrcinput.mp4

process test video

GST_DEBUG=3 gst-launch-1.0 -e filesrc location=testsrcinput.mp4 ! decodebin3 ! queue ! encodebin2 profile='video/x-h264' ! mp4mux ! filesink location=out.mp4
2

ffprobe says:
Duration: 00:01:22.60, start: 1.933000, bitrate: 7813 kb/s

That 1.933 looks familiar.

3

@tomoverlund, thank you for taking a look!

I agree, I noticed that, but missed the correlation to the output length. I tried adding timestamp-offset to the videotestsrc example; however, even with that ffprobe reports start: 0.000000.

Do you know how I could create a video and control that start property ffprobe is showing with gstreamer?

4

A little more info, I was able to create a “workflow” that reproduces this issue, I think this might be a bug in the demuxer?

Create a raw video with normal timestamps
NOTE: removing the pix_fmt flag will prevent the gstreamer pipeline from running at all

ffmpeg -f lavfi -i testsrc=size=1920x1080:rate=15:duration=10 -c:v hevc_nvenc -b:v 8000k -r 15 -pix_fmt yuv420p temp.mp4

Remux with explicit timestamp offset

ffmpeg -i temp.mp4 -c copy -output_ts_offset 1.933 ffmpeginputtest.mp4

Run gstreamer pipeline

GST_DEBUG=3 gst-launch-1.0 -e filesrc location=ffmpeginputtest.mp4 ! decodebin3 ! queue ! encodebin2 profile='video/x-h264' ! mp4mux ! filesink location=out.mp4
5

Oh no, while in GStreamer 1.26, the “buggy” file do play for the 1:20 length, the Sticky event misordering remains a proper bug. Can you file an issue in Sign in · GitLab providing steps to reproduce and link to this thread please.

6

@ndufresne thank you for looking at this! I will create a Gitlab issue right now.

Out of curosity, what pipeline are you using to play the video with? I am currently using GStreamer 1.26.1

7

Nothing fancy:

gst-play-1.0 buggy.mp4
1 Like
8

Here is the gitlab issue: Sticky Event Misordering when video has starting offset (#4408) · Issues · GStreamer / gstreamer · GitLab

1 Like