Video segmenter

From RidgeRun Developer Connection
Jump to: navigation, search

RR Eval SDK download button.png RR Pre built demo image download.png RR Contact Us.png


The Gstreamer Video Segmenter - GstVS is an extension of the conventional GstQTMux element that allows splitting recordings into multiple files constrained by a size and/or a duration. We use the term segmented file to describe a partial recording that was created using this Video Segmenter Technology. These recordings can be audio, video or audio+video. Each segmented file can be viewed independently or a simple host application can recombine them or play the segmented files back to back so the user experiences uninterrupted playback. If the recording contains an encoded video stream, then it is guaranteed that the file will start with a reference frame. All this extra functionality is added without interfering with the normal GstQTMux operation. The Video Segmenter Technology does not drop frames between the files.


The Video Segmenter Technology GstVS supports the following features:

  • Segmented file can be constrained to a maximum size.
  • Segmented file can be limited by the duration of audio and/or video in the file.
  • Support for Audio, Video and Audio+Video recordings.
  • Non-invasive with normal GstQTMux operation.
  • Uses key frame detection so each segmented file starts with a full reference frame.
  • No data loss between video segments.

Video Segmenter Technology requires the audio and/or video capture and processing be done using GStreamer.

Getting the Code

Video Segmenter Technology is delivered as a RidgeRun SDK add-on.


  • The buffers start flowing normally into the file. Buffer's size and duration are accumulated to check against the limits.
Figure1. Buffers flow normally while the size and the length of the file is monitored.
  • When a limit is reached, GstVS will wait for the next reference frame (if needed) and the current file will be closed.
Figure2. The file is closed when a limit is reached.
  • A new file is opened by sending the header in a discontinuous buffer followed by the reference frame.
Figure3. A new file is opened by sending a discontinuous buffer.

Basic Usage

The video segmenter is designed to be used along with GstMultiFileSink which will automatically start a new file when a discontinuous buffer is received. A typical video recording pipeline will look like:

gst-launch videotestsrc ! x264enc ! qtmux target-file-size=10485760 target-file-time=300 ! multifilesink next-file=1 location=video%d.mp4

Here, the important things to notice are:

Element Element property Description
qtmux target-file-size=10485760 The files will be limited to a maximum size of 10MiB.
qtmux target-file-time=300 The files will be limited to a maximum of 5 minutes (300 seconds).
multifilesink next-file=1 This indicates multifilesink to start a new file with every discontinuous buffer. This setting is mandatory.
multifilesink location=video%d.mp4 Multifilesink will replace the %d with an internal index corresponding to each recording.


Time limited video recording

The following pipeline produces 1 minute videos.

gst-launch videotestsrc ! x264enc ! qtmux dts-method=0 target-file-time=60 ! multifilesink next-file=1 location=minute_%d.mp4

Size limited audio+video recording

The following pipeline produces 1 MiB A/V recordings

gst-launch qtmux dts-method=0 target-file-size=1048576 name=mux ! multifilesink next-file=1 location=megabyte_%d.mp4 \
videotestsrc ! x264enc ! mux. \
audiotestsrc ! ffenc_aac ! mux.

Size and time limited video recording

The following pipeline produces a 1MiB or a 1 minute video, whatever occurs first.

gst-launch videotestsrc x264enc ! qtmux dts-method=0 target-file-size=1048576 target-file-time=60 ! \
multifilesink next-file=1 location=megabyte_minute_%d.mp4

Additional Considerations

When dealing with encoded streams the segmenter will wait for a key frame for starting a new video. This means that the videos can end up with a size or length bigger than the one specified. This can be significant when the I-Frame intervals are big.