For more information please visit our online store or contact us link
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.
- When a limit is reached, GstVS will wait for the next reference frame (if needed) and the current file will be closed.
- A new file is opened by sending the header in a discontinuous buffer followed by the reference frame.
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:
|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
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.