Is netcat eating all memory?

[Anonymous]

I've created a 720p ini with two video feeds w/o audio, a scrolling text, two small fixed pictures and a "dynamic picture frame". The output is available by av_output2tcp_server.
Everything is working like a charme - except the picture frame, in which I change and fadein/out a picture every ten seconds done by a bash script.
Over the time the memory snowmix consumes grows up till it dies at the end. If I leave out the script, nothing happens and snowmix runs till end of days.
I'm sure that nc (bsd netcat) is the culprit here, but I dunno why. Is that a bug in nc maybe? Or is snowmix keeping the telnet channel open so hours later I've hundreds of open telnet sessions? Am I'm doing something wrong?

Thanks in advance - You did a great job with snomix!

Oliver
(Sorry, can't create an account in sf.net cause of "system error" when trying to register)

    -------------------- script
    #!/bin/bash

    function send2snowmix {
        echo "${1}" | nc 127.0.0.1 9999
    }

    while true ; do
        find <PATH> -iname '*.png' | sort -R > PICS
        while read PICFNAM; do
            cp ${PICFNAM} /tmp/actualpic.png

            send2snowmix "fadein-image"
            sleep 9

            send2snowmix "fadeout-image"
            sleep 1
        done < PICS
    done
    exit

-------------------- ini/macro
command create fadein-image
message start fading in
image load 5 /tmp/actualpic.png
image alpha 5 0.1
image alpha 5 0.2
image alpha 5 0.3
image alpha 5 0.4
image alpha 5 0.5
image alpha 5 0.6
image alpha 5 0.7
image alpha 5 0.8
image alpha 5 0.9
image alpha 5 1.0
command restart fadeout-image
command end fadein-image

command create fadeout-image
message start fading out
image alpha 5 0.9
image alpha 5 0.8
image alpha 5 0.7
image alpha 5 0.6
image alpha 5 0.5
image alpha 5 0.4
image alpha 5 0.3
image alpha 5 0.2
image alpha 5 0.1
image alpha 5 0.0
message stop fading out
command restart fadein-image
command end fadeout-image

[Peter Maersk-Moller]

Hi Oliver.

Thanks for the nice words. A couple of things.

1) To really help, I need for you to attach all the config files and scripts you are using, that is scripts and config files different from standard.

2) Loading an image during production with Snowmix is a potential source of unpredictable delay because you can not guarantee that it will take considerably less than a frame period. But it is doable and in your case, that is what you have decided to do.

3) When you execute the command macro fadein-image or the fadeout-image, then in your case, all the lines in the macro gets executed within a single frame period. I don't think that is what you want to do.

To get the fadein effect there are many methods. Here are two:

# Method #1
command create fadein-image-loop
    message start fading in
    image load 5 /tmp/actualpic.png
    image alpha 5 0.1
    next
    image alpha 5 0.2
    next
    ...
    next
    image alpha 5 1.0
    message stop fading in
command end fadein-image-loop
# Writing the name of the command macro ending has no actual effect
# but it helps you understand your script
command afterend fadein-image-loop
command create fadein-image
    # This macro resets the execution pointer of the macro fadein-image-loop
    command restart fadeout-image
    loop
command end fadein-image
# The command macro fadein-image-loop needs to be added to
# the command macro you have assigned to Snowmix using the
# command "overlay finish". We assume the name is Show
command addatline Show 1 fadein-image-loop
# This way the command macro fade-in-loop is called once for every frame.

You will need to create a similar setup for fadeout-image and fadeout-image-loop. Please note that when a macro is called, meaning it is executed, the command macro is executed from where its internal execution pointer is until it either meet a line with the reserved word 'next', or 'loop'.

In method 2, we will use the animation feature of Snowmix.

# Method #2
command create fadein-image
    message start fading in
    image load 5 /tmp/actualpic.png
    image alpha 5 0.1
    image move alpha 5 0.1 10
    loop
command end fadein-image
command create fadeout-image
    message start fading out
    image move alpha 5 -0.1 10
    loop
command end fadeout-image

Thats is much simpler and maybe also more simple to understand than the first method. However the first method is more along the lines of your original script and thoughts.

For the emory leak, I need your config files to check. Currently I am not sure how well if works to reset a macros execution pointer from within the macro it self. But it seems to work.

Another source of memory leak will be if your version of netcat does not disconnect. Try executing the following command:

    echo "system info" | nc localhost 9999

If this command does not disconnect from Snowmix by it self, you have a problem you need to solve. SOme netcat, netcat is nc, need the argument "-q 0" or "-q 1" to work.

Let me know how it goes

Best regards
Peter

[Anonymous]

Thanks a lot, Peter!

I've implemented Method #2 which works great. It fades in/out more smoother than before by the way. Damn, didn't spotted that image move alpha. But I'm working on it, learning by trying and I have some interesting ideas I'd like to try out and post when successful.

'echo "system info" | nc localhost 9999' returns immediately with output. So I assume nc disconnects properly. That was the first thing I've checked ;) Tried different parameters, like -q 0/1 in the past, but without changes in memory exhausting.
While I'm writing this and savouring the fades, I can see that memory still gets eating by snowmix. So I'll clean up things in ini and scripts and attach that here laterly.

-
Oliver

[Anonymous]

Cleaned-up stuff attached. I think everything needed (ex. videos) is included. In script 'input2feed1' you've to set path to video(s).

Many many thanks in advance!

Oliver

[Anonymous]

Nearing a solution. NC is not the culprit, but the 'image load ...' command - that means it's seems to be snowmix itself.

When using your mentioned macro

command create fadein-image
image load 5 /tmp/actualpic.png
image alpha 5 0.1
image move alpha 5 0.1 10
loop
command end fadein-image

memory consumption climbs slowly, but continuously. After some hours, depending on amount of RAM, all free memory is gone and snowmix dies.
When prefixing 'image load 5' to delete image #5 before (re)loading (next) image, memory consumption also climbs, but substantially slower than before.
When commenting (both) 'image load's so that only the pre-loaded image (outside/before macro) appears, it fades in and out in peace when calling per NC and memory consumption is stable at one point.

So it seems to me IMHO, that either 'image load' was not designed to reload (a) picture(s), is not documented correctly, or simply it's a bug and this command isn't freeing the reserved memory when deleting/replacing/reloading.

Correct or am I'm right? ;)

Oliver

[Peter Maersk-Moller]

Hi Oliver.

You are right on several points.

1) The command image load was intended only to be used a few times and only before your Live video production starts due to unpredictable delay.
2) The command image load seems to have a memory leak when freeing the png image structure. Currently I'm freeing individual elements as libpng earlier described. Now it appears that I should use a libpng call to free the whole png structure that libpng creates. It will get fixed in next release.

Until next release, you can work around this by loading the image as a video feed instead of as an image. That is also secure from a production point view as this does not create an unpredictable situation where the video mixer is in danger of being locked up waiting for a hard disk to spin up.

Here is how you do it:

1) Define a video feed in Snowmix for loading images and set the longest period you want to be able to show an individual image. So something like this assuming the feed has been created:

    # 1000 = 40 secs @ 25 fps
    feed idle 4 1000

2) The externally you have a script like this:

    gst-launch-1.0 -v filesrc location=./SOMEFILE.png" !\
        decodebin    !\
        videoconvert !\
        videoscale   !\
        videoconvert !\
        'video/x-raw,format=BGRA,pixel-aspect-ratio=1/1,interlace-mode=progressive, width=1024, height=576' !\
        shmsink socket-path=/tmp/feed4-control-pipe shm-size=25952256 wait-for-connection=1

Obviously you now need to overlay a feed an not an image and obviously you need to change the alpha for a feed and not an image when fading, but feeds and images are so alike that it will almost be the same jusy using either feed commands or virtual feed commands or shape commands depending on how you choose to overlay.

The gst-launch-1.0 pipeline will linger for a duration set with the feed idle command. So you need a script launching the pipeline in the background, then send a fadein-feed command, then wait for as long as you want, then send the fadeout-feed command and then kills the pipeline started in the background and then restart with a new image. Admittedly there can be a smaller unpredictable delay between two images. To eliminate that you will need two video feeds for images, then start #1 and the fade-in #1. Then start #2 and afde-out #1 and fade-in #2 and then start #1 with a thirds image, then feed #2 out and #1 in etc. This will also work.

Best regards
Peter

[Anonymous]

Great, thanks a lot, Peter. As I found this out, I thought that has to be a bug, respectively an "unpredictably behaviour".
Will implement your suggestion the next days and report as I'm too busy coming weekend :( but I'm sure this will work fine.

Best regards,
Oliver

[Anonymous]

..couldn't wait and made this script. Works as you suggested. Hooray! Fading this feed has to wait, but this shouldn't be a problem. Think I can wrap up this little first project the next days...
Congrats! You've just earnt something from your wishlist! Please be patient...we've to check howto buy/send this across countrys :)

Very best regards,
Oliver

[Peter Maersk-Moller]

Memory leak when loading new image into an already loaded image slot, has been fixed in version 0.5.1.

Best regards