Creating successives files from appsrc source

[kroketor]

I'm trying to create a pipeline who manages a stream who cames from Opencv and store the video creating successives files.

I have created this pipeline who shows the video without problem:

gst-launch-1.0.exe appsrc name = source ! clockoverlay name = clock ! textoverlay name=text ! videoconvert name=conv ! autovideosink name = videosink

But when i try to do the same storing the video i'm not having good results, this pipeline works and creates archives but they don't seem to work properly, the video is almost frozen:

gst-launch-1.0.exe appsrc name = source ! clockoverlay name = clock ! textoverlay name=text ! videoconvert name=conv ! x264enc ! splitmuxsink name = sink max-size-time = 30000000000 location = video%02d.mp4

I have sought examples about linking appsrc and splitmuxsink or videconvert and splitmuxsink but i haven't found nothing that works correctly in this case.

[Arjen Veenhuizen]

Are you sure you apply proper timestamps at the appsrc (do-timestamp=true)? Did you try sync=false on splitmuxsink? You can also try to set is-live=true on the appsrc.

[kroketor]

Thanks for your advice, i had yet the do-timestamp=true and the is-live=true, i forgot to include this in my first post, sorry. I had included the sync=false but the result is the same.
When i reproduce one of the videos that i create with my pipeline it freezes after a couple of frames, if i jump anywhere in the reproduction bar occurs the same. I´m using VLC to reproduce the video and the appsr is in push mode.

        app.appsrc = gst_bin_get_by_name(GST_BIN(app.pipeline), "source");

        g_object_set(G_OBJECT(app.appsrc),
                "stream-type", 0,
                "is-live", TRUE,
                "block", TRUE,
                "sync", FALSE,
                "do-timestamp", TRUE,
                "format", GST_FORMAT_TIME, NULL);

[Arjen Veenhuizen]

Verify that basic muxing works (splitmuxsink uses mp4mux internally), e.g.:

gst-launch-1.0.exe -e appsrc name = source ! clockoverlay name = clock ! textoverlay name=text ! videoconvert name=conv ! queue ! x264enc ! queue ! mp4mux ! filesink location=test.mp4

Furthermore, make sure that an EOS is sent on the pipeline before tearing it down, otherwise you can get issues with a missing MOOV atom. You can use the "end-of-stream" signal (see gst-inspect-1.0 appsrc) on the appsrc to sent the EOS.

[kroketor]

Thanks for you response Arjen.
I think, and i can be totally wrong, that the problem is not there, i have other program with one pipeline that works correctly with splitmuxsink, so the mux should work fine, i think. I did it earlier, but now i need to process the stream with opencv before it gets into the pipeline. The source and the sink is the same, i believe that the problem is in the middle of the pipeline and probably between videoconvert and x264enc elements but i don,t know alternatives that works better than the current pipeline.

rtspsrc name = source latency = 5000 location = rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov ! rtph264depay name=depay ! h264parse name=parse !x264enc ! splitmuxsink name=sink max-size-time=30000000000 location=video%02d.mp4"

[Arjen Veenhuizen]

In the first post you mentioned that you at least go some playable frames, so that means that the pipeline actually goes into PLAYING mode. Little chance that anything goes wrong "in the middle of the pipeline". Does the filesize of each segment match expectation (e.g. roughly bitrate * duration)? The splitmuxsink has its bugs.

Perhaps you need to timestamp each GstBuffer yourself before pushing it into the appsrc with the running time of the pipeline, in Python it would read something like:

buf = Gst.Buffer.new_allocate(None, len(rawData), None)
buf.fill(0, rawData)
clock = self.elementPipeline.get_clock()
if(clock != None):
	base_time = self.elementPipeline.base_time;
	abs_time = clock.get_time();
	newPts = abs_time - base_time
		
	buf.pts = newPts

	self.elementAppsrc.emit("push-buffer", buf)

You can also try to see if mpegtsmux works in your case, e.g. set the 'muxer' property on splitmuxsink to 'mpegtsmux'.
[Edit] Fixed typo.

[kroketor]

Thanks for your reply Arjen.
I've tried with the mpegtsmux value fot the muxer property and it works worst, when i reproduce the video it only reproduce the first frame with no movement, with  mp4mux it had a little of movement (less than a second) whenever you jump in the reproduction bar.

I'm working on C++ and i don't know Python but i have this part of the code that i believe that manage the timestamp like you say, please, correct me if i'm wrong:
               
                rep >> video;
                size = video.rows * video.cols * video.channels();
                data1 = video.data;

                buffer = gst_buffer_new_allocate(NULL, size, NULL);
                gst_buffer_map(buffer, &map, GST_MAP_WRITE);
                memcpy((guchar *)map.data, data1, gst_buffer_get_size(buffer));
                GST_BUFFER_PTS(buffer) = timestamp;
                GST_BUFFER_DURATION(buffer) = gst_util_uint64_scale_int(1, GST_SECOND, 5);
                timestamp += GST_BUFFER_DURATION(buffer);

                g_object_set(G_OBJECT(app.appsrc), "caps",
                        gst_caps_new_simple("video/x-raw",
                                "format", G_TYPE_STRING, "BGR",
                                "width", G_TYPE_INT, video.cols,
                                "height", G_TYPE_INT, video.rows,
                                "framerate", GST_TYPE_FRACTION, 1, 1,
                                NULL), NULL);
                g_signal_emit_by_name(app.appsrc, "push-buffer", buffer, &ret);

The filesize of the segments is almost the desired (30s), their length are between 28 and 30.

I have been seeking information and i'm startin to think that, like you say, the root of the problem could be a bug. What alternative i have to the use of the splitmuxsink in my case?

[Arjen Veenhuizen]

You could pipe the output of your pipeline to ffmpeg (using a filesink and a named pipe for example) and use its segmentplugin to create mp4 segments. This way we can deduce whether it is a problem in splitmuxsink or not.

[kroketor]

Sorry Arjen, i don't really understand your advice at all. I'm new with gstreamer and i haven't work with ffmpeg.

I guess that you sugest that i must use a filesink to obtain an archive and then use ffmpeg to segment it. In this case the problem is that my source is an ipcamera and i want to store all that it records so i dont have and EOS, so i guess that i can't use filesink.