Issue with appsrc Rejecting GST_FORMAT_TIME Segment in Live Pipeline

Application Development
1

Environment

  • GStreamer Version: 1.26.5

  • Binding: go-gst v1.4.0 (Go bindings for GStreamer)

  • OS: Windows

  • Pipeline: appsrc ! bayer2rgb ! capsfilter caps=video/x-raw,format={RGB,BGR,RGBA,BGRA},framerate=30/1 ! videoconvert ! d3d12videosink sync=false

  • Source: Custom UDP source feeding Bayer (RGGB) video frames via appsrc

Problem

When using appsrc as a live source with format=GST_FORMAT_TIME, the pipeline fails with a fatal Internal data stream error when sending a time-based segment event. The error occurs regardless of whether the segment event is sent before or after the pipeline reaches the PLAYING state. Debug logs show:

WARN basesrc gstbasesrc.c:4255:gst_base_src_push_segment:<source> segment format mismatched, ignore
ERROR appsrc gstappsrc.c:1633:gst_app_src_create:<source> Couldn't set new segment segment event: ..., time 99:99:99.999999999, ...
WARN appsrc gstappsrc.c:1740:gst_app_src_create:<source> error: Failed to configure the provided input segment.
ERROR: Could not configure supporting library.
WARN basesrc gstbasesrc.c:3187:gst_base_src_loop:<source> error: Internal data stream error.

Without the segment event, appsrc defaults to a bytes segment, causing gst_segment_to_stream_time: assertion 'segment->format == format' failed warnings with d3d12videosink, but the pipeline streams successfully. Switching to d3d11videosink eliminates all errors and renders correctly with valid PTS set via SetPresentationTimestamp.

Observations

  1. Segment Format Mismatch:

    • appsrc is configured with format=GST_FORMAT_TIME, is-live=true, and do-timestamp=true.

    • Despite this, it emits a bytes segment: creating segment event bytes segment start=0, offset=0, stop=-1, rate=1.000000, ....

    • Sending a time segment via gst.NewSegment().Init(gst.FormatTime) is rejected, causing a fatal error.

    • The go-gst bindings lack SetStart/SetStop for GstSegment, limiting configuration, but defaults (start=0, stop=-1) should be valid for live streams.

  2. d3d12videosink vs. d3d11videosink:

    • d3d12videosink produces gst_segment_to_stream_time warnings due to the bytes segment, but streams if no time segment is sent.

    • d3d11videosink tolerates the bytes segment and renders without issues, using manual PTS from SetPresentationTimestamp(time.Now().UnixNano()).

  3. Caps Negotiation:

    • Caps negotiate correctly (video/x-bayer,format=rggb to video/x-raw,format=RGBA or RGBA64_LE with framerate=0/1).

    • Recent logs show RGBA64_LE (16-bit), possibly due to framerate=0/1, but this doesn’t cause the error.

Workaround

  • Switch to d3d11videosink: Eliminates all errors and renders video correctly with valid PTS.

  • Remove Segment Event: Avoid sending time segment to prevent appsrc rejection.

  • Manual PTS: Set PTS via SetPresentationTimestamp (e.g., 1757714207596254700), which works reliably.

  • Variable Framerate: Use framerate=0/1 if the UDP source deviates from 30 fps.

Suspected Bug

  • appsrc defaults to GST_FORMAT_BYTES for live sources, ignoring format=GST_FORMAT_TIME.

  • Sending a time segment event (even after PLAYING) is rejected, causing a fatal error.

  • This may be a GStreamer 1.26.5 issue or a go-gst event handling limitation.

Questions

  • Is this a known issue with appsrc in GStreamer 1.26.5 for live sources?

  • Are there specific configurations to enforce GST_FORMAT_TIME in appsrc?

  • Any workarounds to send a time segment without rejection, given go-gst’s limited segment API?

Code Snippet

source.SetProperty("format", gst.FormatTime)
source.SetProperty("is-live", true)
source.SetProperty("do-timestamp", true)
source.SetProperty("caps", gst.NewCapsFromString("video/x-bayer,format=rggb,width=1920,height=1200,framerate=30/1"))
// Segment event (causes error):
segment := gst.NewSegment()
segment.Init(gst.FormatTime)
source.SendEvent(gst.NewSegmentEvent(segment))

Request

Can anyone confirm if this is a bug in appsrc or suggest a way to enforce GST_FORMAT_TIME without errors? Logs and full code available if needed. Thanks!

2

I’m not too familiar with every aspect of appsrc, but it could be a bug in the bindings.

If you can, try to switch to the newer unreleased bindings (will get merged at some point, currently very close to final).

This PR implements auto generated code from the official gstreamer docs, so the chance of bugs should be lower. They aren’t 1:1 compatible with the 1.4.0 though, and the 1.x.x versions will get retracted once this is merged.

If any Methods are missing, then they might need manual implementation. Any feedback is welcome on the PR.

3

Thank you for your response and possible fix. I am currently inundated with other tasks but I will work on trying this when I have time available and post an update here.