Re: Is it a good way to separate pipelines in order to dynamically change properties?

Nicolas Dufresne via gstreamer-devel <[email protected]>
Newsgroups gmane.comp.video.gstreamer.devel
Message-ID <[email protected]>
Le lundi 07 août 2023 à 20:07 +0900, geysee via gstreamer-devel a écrit :
> Hi,
> 
> Mr. Nicolas.
> 
> 
> I'm Kamiya.
> 
> 
> I'm trying to combine multiple files with the splitmuxsrc signal
> "format_location" you advised.
> 
> I haven't tried concat element yet. I thought that splitmuxsrc would be more
> suitable because of the large number of files.
> 
> 
> It succeeded when the return value of GStrv* type was initialized as an
> array.(code below)
> 
> 
> -----------------------------
> 
> static GStrv* formatLocationHandler(GstElement *splitmux, gpointer udata)
> 
> {
> 
>     gchar *locations[4];
> 
> 
>     locations[0] = g_strdup("C:/Rec/2023/07/26/1808_28911.mp4");
> 
>     locations[1] = g_strdup("C:/Rec/2023/07/26/1808_38919.mp4");
> 
>     locations[2] = g_strdup("C:/Rec/2023/07/26/1808_47902.mp4");
> 
>     locations[3] = nullptr;
> 
> 
>     GStrv *ret  = (GStrv*)g_new0(GStrv, 1);
> 
>     std::memcpy(ret, &locations, sizeof(locations));

You have 1 pointer allocated, but memcopy 4, this is going to overflow.

> 
> 
> 
>     return ret;
> 
> }
> 
> -----------------------------
> 
> 
> On the other hand, if the return value was dynamically allocated, it will be
> crashed after exiting formatLocationHandler.(code below)
> 
> 
> -----------------------------
> 
> static GStrv* formatLocationHandler(GstElement *splitmux, gpointer udata)
> 
> {
> 
>     gchar **locations = (gchar**)g_new0(gchar*, 4);
> 
> 
>     locations[0] = g_strdup("C:/Rec/2023/07/26/1808_28911.mp4");
> 
>     locations[1] = g_strdup("C:/Rec/2023/07/26/1808_38919.mp4");
> 
>     locations[2] = g_strdup("C:/Rec/2023/07/26/1808_47902.mp4");
> 
>     locations[3] = nullptr;
> 
> 
>     GStrv *ret  = (GStrv*)g_new0(GStrv, 1);
> 
>     std::memcpy(ret, &locations, sizeof(locations));

Same bug, it just worked by accident previously.

> 
> 
> 
>     return ret;
> 
> }
> 
> -----------------------------
> 
> 
> Could you tell me how to dynamically allocate the file list in
> formatLocationHandler ?
> 
> I am very embarrassed that it may be a basic problem with C language or GLib,
> but I have been unable to solve it for a long time, so I would appreciate your
> help.
> 
> 
> Best regards,
> 
> Kamiya.
> 
> 
> 
> SHIGEHARU KAMIYA/TOA wrote on 2023/08/03 12:04:11:
> 
> > 
> > Hi,
> 
> > Mr. Nicolas.
> 
> > 
> > Thank you for your reply.
> 
> > Your way looks nice!
> 
> > 
> > I am trying it now.
> 
> > I will let you know the results later.
> 
> > 
> > Thank you.
> 
> > Kamiya.
> 
> > 
> > "gstreamer-devel" <[email protected]>
> > wrote on 2023/08/03 07:09:52:
> 
> > > 
> > > Hi,
> 
> > > Le mar. 1 août 2023, 03 h 15, geysee via gstreamer-devel <
> > > [email protected]> a écrit :
> 
> > > > Hello
> > > > I am Kamiya.
> > > >
> > > > I have a question.
> > > >
> > > > Is it a good way to separate pipelines in order to dynamically change
> > > > properties
> > > > that cannot be changed in the PLAYING state, such as the location
> property
> > > > in filesrc?
> 
> > > 
> > > It can be a good method. But from what you described below, you may get
> > > easier results with concat element instead. splitmuxsrc should work, there
> > > is a signal to query the filename from your app instead of using the glob.
> 
> > > 
> > > >
> > > > I'm sorry for the long post, but the background of the question is as
> > > > follows.
> > > >
> > > >
> > > > 
> > > 
> > ----------------------------------------------------------------------------
> -----------------------------------------------------
> > > > I'm making a system that records video from a network camera while
> > > > dividing it into files.
> > > > If the file is split at 10 minute intervals, the file path will be as
> > > > follows.
> > > >
> > > > C:/Rec/2023/07/31/1330_00000.mp4
> > > > C:/Rec/2023/07/31/1340_00000.mp4
> > > > C:/Rec/2023/07/31/1350_00000.mp4
> > > >
> > > > With gstreamer C++ coding, I am trying to export as a single file by
> > > > specifying the date and time range from the divided recording files.
> > > >
> > > > If the date and time range is in one file, like 13:32 - 13:34, then the
> > > > pipeline below has been successful. (Properties are omitted)
> > > >
> > > > pileline : filesrc ! qtdemux ! h265parse ! queue ! qtmux ! filesink
> > > >
> > > > On the other hand, if the date and time range is split into multiple
> > > > files, like 7/31 20:00 - 8/1 10:00, this pipeline fails.
> > > >
> > > > First, I tried multifilesrc and splitmuxsrc, but the location property
> is
> > > > a glob pattern, it didn't fit the file path of date and time.
> > > > Next, I tried updating the location property of filesrc sequentially,
> but
> > > > I couldn't change the location when this state is PLAYING.
> > > >
> > > > So now I'm trying to divide the pipeline into two as follows.
> > > >
> > > > pipeline1 : filesrc ! qtdemux ! h265parse ! appsink
> > > > pipeline2 : appsrc ! queue ! qtmux ! filesink
> > > >
> > > > When pipeline1 reaches the end of stream, I change the state of
> pipeline1
> > > > to Ready.
> > > > Next I change the location of filesrc. Finaly I change state to PLAYING
> > > > again.
> > > > The State of pipeline2 is not changed.
> > > >
> > > > However this way has not been successful yet. There are more problems
> than
> > > > single pipeline.
> > > >
> > > > Currently looking into the following issues:
> > > > If there was single pipeline it was processed at high speed, but if the
> > > > pipeline is divided, the processing time will be as per the timestamp.
> > > >
> > > > Is it a good way to split the pipeline like this?
> > > > I would appreciate if you give me some advice.
> > > >
> > > > 
> > > 
> > ----------------------------------------------------------------------------
> -----------------------------------------------------
> > > >
> > > > Best regards,
> > > > Kamiya.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.