GStreamer-Sharp signal corrupts string[] return value.
Describe your issue
In an attempt to work around #3541, I've changed my pipeline to utilize splitmuxsrc instead of concat. I need to provide a list of specific files to splitmuxsrc. It appears glob format for the location property can't handle this case, so the only other option is a signal handler for format-location and return an ordered string[] of file locations. Unfortunately it seems that something is corrupting the string[].
Here is the format-location handler I've tried:
private void HandleFormatLocation(
object o,
SignalArgs args)
{
if (!RecordingFiles.Any())
{
return;
}
var files = RecordingFiles.OrderBy(p => p.StartDate)
.ToList()
.Select(p => p.Filename)
.Select(p => p.Replace("\\", "\\\\"))
.ToArray();
Logger.LogWarning("Getting files: {files}", files.JoinString(", "));
args.RetVal = new GLib.Value(files);
}
I've also tried changing the last line to this:
var value = new Value(typeof(string[]));
value.Val = files;
args.RetVal = value;
In the gstreamer log output, I get this in both cases (notice the smiley face character in place of D:/VideoRecording/Ubiquiti/video0000000.mp4):
[12:49:21 WRN] Getting files: D:/VideoRecording/Ubiquiti/video0000000.mp4, D:/VideoRecording/Ubiquiti/video0000001.mp4, D:/VideoRecording/Ubiquiti/video0000002.mp4
[12:49:21 ERR] MESSAGE: Pipeline error for view recording files:
Could not open resource for reading.
../gst/multifile/gstsplitmuxsrc.c(506): gst_splitmux_part_bus_handler (): /GstPipeline:pipeline0/GstSplitMuxSrc:concat:
Failed to prepare first file part ☺ for playback
Expected Behavior
There should be no corruption of string[] return value to format-location
Observed Behavior
There was corruption of the string[] return value to format-location
Setup
- Windows 10
- Computer
- 1.24.2
- No command line can replicate this.
Steps to reproduce the bug
- Create some files using splitmuxsink
- Combine those files using splitmuxsrc, gstreamer-sharp, and a format-location handler such as posted above.
How reproducible is the bug?
Always reproducible and always shows a smiley face.
Screenshots if relevant
Solutions you have tried
Looked through the GLib API to try to find all the ways I could pass string[], but I don't think there's any other way.
I looked around all the gstreamer-sharp examples I could find. I can't find any that do anything more complex than returning a boolean value in the signal handler.
I've also looked at https://github.com/GLibSharp/GtkSharp (which I think is what gstreamer-sharp uses) to see if there's any mention of bugs related to string[], but didn't find anything.
My current workaround is to copy all the source files to a separate folder and utilize the location property with splitmuxsrc to read all files in that folder. However, I don't particularly want to deal with all the extra I/O of doing that.