Memory Leak?

[killerrats]

I was recording with this pipeline for more than 3 days. At the end of the
third day the memory was crazy big. it was above 200 mb in memory. Pipeline:

gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
h264parse ! mux.video splitmuxsink max-size-bytes=10485760 max-files=10240
muxer=avimux location=video%06d.avi name=mux source. ! rtpmp4gdepay !
aacparse ! mux.audio_0

I put together an application that uses the same pipeline the difference is that I checked the flow of the
 elements through the splitmuxsink to filesink and flows fine. It also is setting the next filename using the
format-location. For some reason still has the same problem. that one went up to 300mb of memory.

One thread here was saying to use async-handling=true. I haven't tried that
yet because well it will be several days before I get to see if it works or
not. Anyone know?



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[rland]

killerrats wrote
> I was recording with this pipeline for more than 3 days. At the end of the
> third day the memory was crazy big. it was above 200 mb in memory.
> Pipeline:
>
> gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
> h264parse ! mux.video splitmuxsink max-size-bytes=10485760 max-files=10240
> muxer=avimux location=video%06d.avi name=mux source. ! rtpmp4gdepay !
> aacparse ! mux.audio_0

You can run valgrind to check where
there may be memory leak，note that
pay attention to the "definitely lost" parts in summary. :)
Like this:
valgrind -v --tool=memcheck  --track-fds=yes  --leak-check=full
--show-reachable=yes --time-stamp=yes --undef-value-errors=no
--malloc-fill=0xc --free-fill=0xd --freelist-vol=100000000
--trace-children=yes --num-callers=50
--suppressions=gstreamer-1.0-1.14.0/common/gst.supp  --log-file=valgrind_gst
gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
h264parse ! mux.video splitmuxsink max-size-bytes=10485760 max-files=10240
muxer=avimux location=video%06d.avi name=mux source. ! rtpmp4gdepay !
aacparse ! mux.audio_0





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

I have windows that i'm using it on. but I did find a alternative which is
"very sleepy cs" and 14 day trial "Deleaker". They seem to work pretty well.



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

I found another program.  Process Explore
<https://download.cnet.com/Process-Explorer/3000-2094_4-10223605.html>  
that will tell me quite a bit of information. I found interesting that in
the beginning it showed 259 handles where active and then it increased as it
went along. It came back down to 259 not too long after. I have already left
for two days now and the handles have increased and never came back down to
259. Its now at 273 and my memory is from 15 and increased to 18 megabytes.
By tomorrow it probably will increase in memory because like always on the
third day.

<http://gstreamer-devel.966125.n4.nabble.com/file/t377034/RecordingProgress06-12-2018-01-57-PM.jpg>



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

Well increased 2 days later. this is a program I did my own console
application. I found out that the code I was using was 2016 source code on a
1.12.4 gstreamer.

The only thing I did was edit the splitmuxsink element. Got rid of the
second signal for format-location-full then did a couple of signals in the
filesink. Nothing that will effect the program that much.

gstsplitmuxsink.c

<http://gstreamer-devel.966125.n4.nabble.com/file/t377034/RecordingProgress06-14-2018-09-30-AM.jpg> 



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

I upgraded to 1.14.1 and used the command line gst-launch that I used in the
first post. It did the same thing as before. it got up to 2k files out of
10k files. doesn't seem to quit out or anything. The handles didn't increase
this time.

gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
h264parse ! mux.video splitmuxsink async-handling=true
max-size-bytes=10485760 max-files=10240 muxer=avimux location=video%06d.avi
name=mux source. ! rtpmp4gdepay ! aacparse ! mux.audio_0

I used software verify memory validator and here is of a report from memory.
it took 4 1/2 days or so to get to this point. I can't seem to figure out
why?

gst_launch_10_mem_06_18_18
<http://www.planetkorey.com/tmp/gst_launch_10_mem.html>  



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

So I did another test using the following pipeline. I added the tee for video
and audio side and queue after the tee to connect to the splitmuxsink.

gst-launch-1.0 --gst-debug=3 -e rtspsrc location=[IP] name=source !
rtpjitterbuffer ! rtph264depay ! h264parse ! tee name=vtee ! queue
max-size-buffers=50 ! mux.video splitmuxsink async-handling=true
max-size-bytes=10485760 max-files=360 muxer=avimux
location=D:/VideoStorageSplit2/video%06d.avi name=mux source. !
rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! tee name=atee ! queue
max-size-buffers=50 ! mux.audio_0

*my application:*
specified buffers in queues' has internal flow error
not specifying the buffers just keeps going.
this is using the same way as above not a edited version of splitmuxsink and filesink I did earlier.
<http://gstreamer-devel.966125.n4.nabble.com/file/t377034/GstreamerRecordPipeline.png> 

*command line:*
specifying the buffers in queues' has timeout but maybe the same for
internal flow error
not having the buffers keeps going.

*Overall:*
haven't tried on command line adding the tee with queues' and not specifying
the buffers.



-----
------------------------------
Gstreamer 1.12.4
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

rtspsrc location=[IP] name=source ! rtpjitterbuffer ! rtph264depay !
h264parse ! queue ! mux.video splitmuxsink async-handling=true
max-size-bytes=10485760 max-files=360 muxer=avimux
location=D:/VideoStorageSplit2/video%06d.avi name=mux source. !
rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! queue ! mux.audio_0

So I put in my application joining together the elements the above pipeline
is what I followed. The program ran for more than a day but it increased the
memory to 1gb. It said the flow of the pads through the pipeline were okay.
I make the program check them every hour. It tracked it until the program
crashed and had the following error. The one thing I do is I use the signal
from the splitmuxsink "format-location" but I only return the filename to
use.

(VideoConvert.exe:5440): GLib-ERROR **: gmem.c:165: failed to allocate
7974144 bytes

the following errors occurred before it.

2018-5-23 9:11:15: Checking bus
19:18:25.073758257  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c
:2182:gst_h264_parser_parse_slice_hdr: value greater than max. value: 4, max
2
19:18:25.075449813  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c
:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:18:25.210749970  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c
:655:slice_parse_ref_pic_list_modification_1: value greater than max. value:
166
, max 63
19:18:25.212307989  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c
:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference
picture l
ist 0 modification"
19:18:25.213589437  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c
:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:18:25.340195472  5440   031339D8 WARN       codecparsers_h264
gsth264parser.c:2182:gst_h264_parser_parse_slice_hdr: value greater than
max. value: 6, max 219:18:25.342064425  5440   031339D8 WARN      
codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr:
error parsing "Slice header"



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

rtspsrc location=[IP] name=source ! rtpjitterbuffer ! rtph264depay ! h264parse ! queue name=queue1 leaky=true ! mux.video splitmuxsink async-handling=true max-size-bytes=10485760 max-files=360 muxer=avimux location=D:/VideoStorageSplit2/video%06d.avi name=mux source. ! rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! queue name=queue2 leaky=true ! mux.audio_0

So I ended up adding some properties to the application. The memory seemed to shoot up to 77mb.

properties i set:
g_object_set(GST_OBJECT(pipe->rtpjitterbuffer1)
, "do-lost", TRUE
,"max-dropout-time",static_cast(20000)
,"rtx-max-retries",5
, nullptr);
g_object_set(GST_OBJECT(pipe->rtpjitterbuffer2)
, "do-lost", TRUE
, "max-dropout-time", static_cast(20000)
, "rtx-max-retries", 5
, nullptr);
g_object_set(GST_OBJECT(pipe->queue1)
, "leaky",2
,"flush-on-eos", TRUE
, nullptr);
g_object_set(GST_OBJECT(pipe->queue2)
, "leaky", 2
,"flush-on-eos", TRUE
, nullptr);

Element Name current-level-buffers current-level-bytes current-level-time
queue1 , 48693 , 17749538 , 4522319740088
queue2 , 0 , 0 , 4522319740088
1 Second later Check:
queue1 , 48703 , 17753183 , 4523247721948
queue2 , 0 , 0 , 4523247721948
1 Second later Check:
queue1 , 48714 , 17757192 , 4524269640878
queue2 , 0 , 0 , 4524269640878

---

Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

rtspsrc location=[IP] name=source ! rtpjitterbuffer name=rtpjitterbuffer1 ! rtph264depay name=vdepay ! h264parse name=vparse config-interval=1 ! multiqueue max-size-time=0 name=mq ! mux.video splitmuxsink name=splitmuxsink async-handling=true max-size-bytes=1048576 max-files=360 muxer=avimux location=D:/VideoStorageSplit2/video%06d.avi mq. ! splitmuxsink.audio_1 source. ! rtpjitterbuffer name=rtpjitterbuffer2 ! rtpmp4gdepay name=adepay ! aacparse name=aparse ! mq.

so I tried a new approach by using MULTIQUEUE. after 4 days of running constantly it still ran into the problem of increased in memory. anybody have any idea how to figure out why it does that? or how I can figure out why it does that? If i run a eos through the pipeline but it only has a portion out of the max file size i set. The file cannot be played.

---

Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

rtspsrc location=[IP] name=source ! rtpjitterbuffer name=rtpjitterbuffer1 ! rtph264depay name=vdepay ! h264parse name=vparse config-interval=1 ! multiqueue max-size-time=0 name=mq ! fakesink name=fakesink1 mq. ! fakesink name=fakesink2 source. ! rtpjitterbuffer name=rtpjitterbuffer2 ! rtpmp4gdepay name=adepay ! aacparse name=aparse ! mq.

I put together this pipeline and lasted for 3-4 days but quit immediately. The error in the pipeline was stream timeout. Could that actually not reach the splitmuxsink and make it increase memory making it not stop?

109:36:16.290710734 55172 03359998 WARN rtspsrc gstrtspsrc.c:3151:on_timeout: source 805bacc4, stream 805bacc4 in session 1 timed out
109:36:18.297746384 55172 033599C0 WARN rtspsrc gstrtspsrc.c:3151:on_timeout: source 805bacc3, stream 805bacc3 in session 0 timed out
Got EOS from element "pipeline0".
Execution ended after 109:36:18.012863821
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
109:36:18.312780510 Setting pipeline to NULL 55172...
033238E8 WARN rtspsrc gstrtspsrc.c:5915:gst_rtsp_src_receive_response: receive interrupted
109:36:18.318988152 55172 033238E8 WARN rtspsrc gstrtspsrc.c:8242:gst_rtspsrc_pause: PAUSE interrupted
Freeing pipeline ...

---

Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

Before Pipeline:

gst-launch-1.0 --gst-debug=3 -e rtspsrc location=rtsp://10.64.52.18:554/s2 name=source ! rtpjitterbuffer ! rtph264depay ! h264parse config-interval=1 ! tee name=vtee ! queue2 max-size-time=0 ! mux.video splitmuxsink async-handling=true max-size-bytes=1048576 max-files=360 muxer=avimux location=D:/VideoStorageSplit2/video%06d.avi name=mux source. ! rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! tee name=atee ! queue2 max-size-time=0 ! mux.audio_0

New Pipeline (being applied):

gst-launch-1.0 --gst-debug=3 -e rtspsrc location=rtsp://10.64.52.18:554/s2 name=source ! rtpjitterbuffer ! rtph264depay ! h264parse config-interval=1 disable-passthrough=TRUE ! tee name=vtee ! queue2 max-size-time=0 ! mux.video splitmuxsink async-handling=true max-size-bytes=1048576 max-files=360 muxer=avimux location=D:/VideoStorageSplit2/video%06d.avi name=mux source. ! rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! tee name=atee ! queue2 max-size-time=0 ! mux.audio_0

I used the before pipeline but got errors that are provided below. I searched around the internet for answers. I came across a post about the disable-passthrough because of timing for the mp4mux. I am now going to add the disable-passthrough to see if it works. I only tried this because of this post. Timing is lost when converting h264 video

The memory seems to increase and can't seem to figure out why. The timestamp on the video seems to be few minutes off. could that make the pipeline halt? I can only stop the pipeline otherwise it will just keep going but never record. It will only have the last buffering of the when it stopped working which would be hours ago if left for long time unless you catch it early enough. It seemed to catch the same buffer early on but I didn't make the code stop it I just kept it going and went on the record but it stopped again for some reason. I do realize that h264parse is in the gst-plugin-bad. could this be apart of why it doesn't seem to work or no? Errors in h264parse 19:08:57.925500807 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2195:gst_h264_parser_parse_slice_hdr: value greater than max. value: 11, max
219:08:57.926098941 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.054359882 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2198:gst_h264_parser_parse_slice_hdr: value not in allowed range. value: -7, range -6-6
19:08:59.054928453 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"19:08:59.194109996 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:655:slice_parse_ref_pic_list_modification_1: value greater than max. value: 268, max 255
19:08:59.194640849 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.195001718 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.256414589 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.256962008 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.321378548 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.321879075 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.392479818 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.393050429 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.458530205 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.459103364 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.621852723 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2182:gst_h264_parser_parse_slice_hdr: value greater than max. value: 4, max 2
19:08:59.622374912 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.622795925 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2195:gst_h264_parser_parse_slice_hdr: value greater than max. value: 4, max 2
19:08:59.623287532 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:22
19:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"19:08:59.659856040 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2182:gst_h264_parser_parse_slice_hdr: value greater than max. value: 7, max 2
19:08:59.660320378 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.660712593 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.661063012 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.661463128 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2182:gst_h264_parser_parse_slice_hdr: value greater than max. value: 4, max 2
19:08:59.661887454 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:22
19:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.662281453 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2195:gst_h264_parser_parse_slice_hdr: value greater than max. value: 4, max 2
19:08:59.662650731 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:22
19:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.663051357 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.663482564 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:22
19:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.663894402 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2195:gst_h264_parser_parse_slice_hdr: value greater than max. value: 3, max 2
19:08:59.664264445 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:08:59.664646211 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing "Reference picture list 0 modification"
19:08:59.664995102 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:09:00.923643711 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 2150 will be dropped
19:09:00.924338943 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 2946 will be dropped
19:09:00.924752311 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 1581 will be dropped
19:09:00.925140193 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 1655 will be dropped
19:09:00.925528841 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 1886 will be dropped
19:09:00.925892512 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 1966 will be dropped
19:09:00.926293902 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 2103 will be dropped
19:09:01.136799454 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2198:gst_h264_parser_parse_slice_hdr: value not in allowed range. value: 10, range -6-6
19:09:01.137318585 2748 033EEBB8 WARN codecparsers_h264 gsth264parser.c:2219:gst_h264_parser_parse_slice_hdr: error parsing "Slice header"
19:09:03.937139578 2748 033EEBB8 WARN h264parse gsth264parse.c:1237:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 893 will be dropped

----- ------------------------------ Gstreamer 1.14.1 ------------------------------ Windows -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [e-mail] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

Okay so I ran the application with the disable-passthrough. it actually
worked well. Though i did figure out that the memory increased a little
still. The memory seems to be stable for the most part. I also looked a
little further and saw that in splitmuxsink connects two queues to the
muxer. Since I added the leaky to the two that connect to the splitmuxsink I
added the leaky to the two queue inside splitmuxsink. It seemed to add
buffers and drop buffers as it goes along. seems to do well. without the
leaky on the queues' it will keep the buffers on the queues' and increase
the memory.

So far seems to be stable with leaky queue and disable-passthrough on
h264parse.



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thornton, Keith]

Hi,
having a leaky queue after the encoder will only work if you are only producing I-Frames. If you drop an IDR, all the following frames will refer to a non-existing frame in your recording. Normally it is better to drop the frames before the encoder.
Regards

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von killerrats
Gesendet: Freitag, 3. August 2018 19:03
An: [hidden email]
Betreff: Re: Memory Leak?

Okay so I ran the application with the disable-passthrough. it actually worked well. Though i did figure out that the memory increased a little still. The memory seems to be stable for the most part. I also looked a little further and saw that in splitmuxsink connects two queues to the muxer. Since I added the leaky to the two that connect to the splitmuxsink I added the leaky to the two queue inside splitmuxsink. It seemed to add buffers and drop buffers as it goes along. seems to do well. without the leaky on the queues' it will keep the buffers on the queues' and increase the memory.

So far seems to be stable with leaky queue and disable-passthrough on h264parse.



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

The pipeline with the splitmuxsink is almost similar to this:

gst-launch-1.0 --gst-debug=3 -e rtspsrc location=rtsp://10.64.52.18:554/s2 name=source
! rtpjitterbuffer ! rtph264depay ! h264parse config-interval=1 ! tee name=vtee ! queue ! queue ! mux.video_0 avimux name=mux ! filesink source.
! rtpjitterbuffer ! rtpmp4gdepay ! aacparse ! tee name=atee ! queue ! queue ! mux.audio_1

The file seems to play fine and no problems with the file. difference: 1. underrun sends constant message to the console memory increases slowly 2. the video file went from 1min to 18 seconds which i prosume is dropping frames like crazy. 3. In the beginning it showed a big number for the duration but now it shows the correct number of length of the video.

-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
h264parse ! tee name=vtee ! mux.video splitmuxsink max-size-bytes=10485760
max-files=10240
muxer=avimux location=video%06d.avi name=mux source. ! rtpmp4gdepay !
aacparse ! tee name=atee ! mux.audio_0

Okay I think i solved it. I set the queues properties in splitmuxsink with:
max-size-buffers=1000
leaky=2

the underrun doesn't add buffers to queues.

the only thing that happened was h264parse error:
"couldn't find associated picture parameter set with id: 2

In the beginning the video and audio are closer together but not matched
very well. The audio and video are about 0.5-1sec apart. after the h264parse
error the video seems to be about 1min off. The megabytes seems to be better
it goes up to 70mb then after awhile it goes back down to 30mb. When the
video starts it starts off at 11mb then will averagely be at 30mb.

so progress at this point.



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

gst-launch-1.0 -e rtspsrc location=[IP] name=source ! rtph264depay !
h264parse ! tee name=vtee ! mux.video splitmuxsink max-size-bytes=10485760
max-files=10240
muxer=qtmux location=video%06d.avi name=mux source. ! rtpmp4gdepay !
aacparse ! tee name=atee ! mux.audio_0

I changed the muxer to qtmux and seems to match the video and the audio very
nicely. The memory doesn't seem to go up like the avimux does. We will see
overtime.

I used mp4mux but in my other thread I got an error about the buffer has no
pts. That muxer worked very well for matching the audio and the video. Once
that error comes up the thing will halt and climb in memory like no
tomorrow.



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

well it looks like this works.
GstElement* parse = gst_element_factory_make("h264parse",NULL);
gst_base_parse_set_pts_interpolation(GST_BASE_PARSE(parse), TRUE);

In the long run it seems to not have underrun for the splitmuxsink like it
did without apply that gst_base_parse_set_pts_interpolation().



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

i put syn=true on the filesink in my application before adding the element to
splitmuxsink.
the recording long term works but for some reason it gets to a point to
where it can't record anymore. I check the splitmuxsink buffer and it is the
same for more than three times. it checks this every minute. the recording
last 5 days. Could that be trying to sync the video and audio together but
it can't put it together? The pipeline will continue going but won't switch
to a new file or end the current file. I have to end the pipeline myself if
it detects the same buffer. the file will end only with the current GOPs'. You won't be able to play them in gstreamer as it says no valid frames.

can the File descriptor in the filesink be the problem if it doesn't want to
write anymore? I am running the application on windows.



-----
------------------------------
Gstreamer 1.14.1
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[killerrats]

gst-launch-1.0 -e rtspsrc location=[IP] latency=66 name=source !
rtpjitterbuffer do-lost=true ! rtph264depay ! identity ! h264parse
config-interval=1 ! avdec_h264 ! openh264enc ! h264parse ! tee name=vtee !
mq.sink_1 multiqueue name=mq ! mux.video splitmuxsink async-handling=true
max-size-bytes=4194304 max-files=360 muxer=mp4mux location=video%06d.avi
name=mux mq.src_2 ! mux.audio_1 source. ! rtpjitterbuffer do-lost=true !
rtpmp4gdepay ! identity ! aacparse ! avdec_aac ! avenc_aac ! aacparse ! tee
name=atee ! mq.sink_2

found out if I do this for each side of the branches for audio and video.

depay -> parse -> decode -> encode -> parse -> tee

if i leave the decode -> encode -> parse out of it the pipeline won't do
that stopping point like it did. even the sync of audio and video works.



-----
------------------------------
Gstreamer 1.14.2
------------------------------
Windows
--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel