How can I set the segment length in a "filesrc" element in GStreamer?

I am looking to limit the segment length sent out by my “filesrc” element in my GStreamer pipeline to .25 seconds. Currently I suspect it to be around 3 seconds considering the latency between modifications I am making on elements in the pipeline after keystrokes and seeing the result displayed to me.

“GstBaseSrc” has a segment property that should do what I am looking to do, and “FileSrc” inherits it, but I can’t seem to get it to take the setting of the property.

I have tried to retrieve, modify, and set the segment duration property like this:

        data.source  = gst_element_factory_make ("filesrc", "source");
        
        GstSegment segment = {0, 0, 0, 0, 0, 0, 0, 0};
    // get segment from file src
    g_object_get (G_OBJECT (data.source), "segment", &segment, NULL);

    segment.duration = .25*GST_SECOND;

    g_object_set (G_OBJECT (data.source), "segment", &segment, NULL);

    // gst_base_src_set_format(GST_BASE_SRC(data.source), GST_FORMAT_TIME);

    // add elements to pipeline
    gst_bin_add_many (GST_BIN (data.pipeline), data.source, data.demuxer, data.decoder, data.videorate, data.encoder, data.muxer, data.sink, NULL);

When I run this code, I get g_object_set_is_valid_property: object class 'GstFileSrc' has no property named 'segment'

Is there a way I am missing to set this value?

Why do you think GstBaseSrc has a “segment” property?

If it did it would show up in gst-inspect-1.0 filesrc.

It has a segment member in the object structure, but that’s not for application use.

In any case, filesrc doesn’t really have a concept of time, that’s only something a demuxer or parser has later in the pipeline.

I’m not quite sure I understand what the problem is that you’re trying to solve - could you explain that in more detail?

Segment can be seen as a property of GstBaseSrc property here:
https://gstreamer.freedesktop.org/documentation/base/gstbasesrc.html?gi-language=c#GstBaseSrc

The issue I’m having:

When making adjustments to the videorate plugin’s rate property in my pipeline (during runtime), it seems to be processing through a certain amount of frames before the rate change takes effect while spitting out the video. This delay is about 3 seconds, although when I speed up the rate, the delay also speeds up. It is very hard to figure out through any available documentation what this block of time is and how it is set, but the thought of segments came about through reading through source code and understanding about pads receiving segments of data, and trying to tie it together with my understanding of streaming not related to GStreamer.

Again- pretty new to this and documentation is not very descriptive, so I appreciate your understanding with me having to take some shots in the dark.

Thanks for taking the time to respond!

That’s a “member” not a (GObject) property. Properties are listed in this section :slightly_smiling_face:

If this was a normal playback pipeline the usual thing to change the rate would be to do a (flushing) seek to the current position with a new rate.

In newer/current versions of GStreamer there’s also something called ‘instant rate change’ which Jan talks more about in his GStreamer conference talk here.

However, I’m not sure if this will work well with the encoder in the mix, would need to be tested.

I suspect the 3-second delay in your case comes from the encoder - is it x264enc by any chance? If so, you may want to use x264enc tune=zerolatency.

Thanks for the clarification re member vs. property!

With “instant rate change” I have had success with that method but only with an autovideosink or glimagesink. When using tcpclientsink it doesn’t work, because (at least in the ways I have tried) it is setting playback rate on the player-side, rather than the server-side.

I will take a look at the flushing seek concept. We are using x264enc, I will give this a shot too and report back.

Currently looking at an approach to this with appsink and dropping/duplicating frames as needed before pushing to appsrc, because my larger application can benefit from this on demand pulling of frames and some space to process them anyway.

Thanks so much for your help!