Time Lapse video segmentation fault

[CaptainRon47]

I have been running my 'modified' version of this software for several years, using a Rpi and Zwo camera. Recently, the time-lapse video option has created mp4 files that do not run under the VLC viewer. The output of the avconv command shows a "segmentation fault' after creating the file. I have not updated any of my firmware or software in some time. This only began sometime this year, I think and I have not been able to determine the cause of the fault. Any help is appreciated.

thanks,
Ron

[EricClaeys]

@CaptainRon47 Your version of Allsky uses avconv to create the .mp4 file? And it is producing the Segmentation Fault? Try running which avconv then an ls -l on the location of the avconv command to see if it was recently updated.

If avconv is producing a Segmentation Fault, then most likely the file is incomplete and hence corrupt which is why it isn't playing in VLC.

SOMETHING has changed; our challenge is going to be to determine what.

[CaptainRon47]

Thanks for your reply.

The ls command and the version info is listed here:
lrwxrwxrwx 1 root root 6 May 25 2019 avconv -> ffmpeg

pi@allskyrpi:/allsky/scripts $ avconv -version
ffmpeg version 3.2.10-1deb9u1+rpt2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1+deb9u1) 20170516
configuration: --prefix=/usr --extra-version='1~deb9u1+rpt2' --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx-rpi --enable-mmal --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --arch=armhf --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
libavutil 55. 34.101 / 55. 34.101
libavcodec 57. 64.101 / 57. 64.101
libavformat 57. 56.101 / 57. 56.101
libavdevice 57. 1.100 / 57. 1.100
libavfilter 6. 65.100 / 6. 65.100
libavresample 3. 1. 0 / 3. 1. 0
libswscale 4. 2.100 / 4. 2.100
libswresample 2. 3.100 / 2. 3.100
libpostproc 54. 1.100 / 54. 1.100

the command I am using, in the timelapse.sh at the end of night, is:
avconv -loglevel debug -y -f image2 -r 25 -i $MP_IMG_DIR/PROCESS/%04d.$EXTENSION -vcodec libx264 -b:v 2000k -pix_fmt yuv420p $MP_IMG_DIR/output.mp4

I have turned debug on and I direct it to a separate file. If I run my 'usual' command on a subset of night time images (like 200) it works fine, it creates the mp4 file with no segmentation fault and the video plays on VLC.

I seem to recall this issue in the past and it might have to do with not getting an EOF on the last image, but somehow this started working and I usually don't look at the video's unless there is something really interesting in the startrails image (or a night of a meteor shower). I am trying it again on my last nights full image set (1386 frames) with debug info into a file. I will let you know what that shows.

thanks,
Ron

[CaptainRon47]

Well, as usual, with the debug logging turned on and writing it to a file, the process ran fine on the full image set from last night and the video plays fine in VLC. There are no errors shown in the error file nor in the std output file. So it is a mystery as why when incorporated in the usual process (note: I start taking daytime images right after it stops taking night images - based on sun altitude) the video fails (even thought it writes the file). Also, when I have rerun the timelapse command (without debug turned on) on older image sets, the video was created but had the segmentation fault. So summing it up: if I run my 'standard command - no debug, on a standard data set either after end-of-night or later, the video is created but with a segmentation fault that prevents it from being played by VLC. If I run the 'standard' command on a small subset of images, the video is created and runs. If I run the command, with debug turned on, on a previous night full set of images, the video is created and runs in VLC!? I will leave the debug setting turned on, in my standard shell file and continue to write the output to a re-written file so I can check it at the end of the night.

Not sure what else to do at this point.

thanks,
Ron

[EricClaeys]

@CaptainRon47 Ron, sometimes jumping on your left foot while chanting something helps. If not, try your right foot. :-)
But seriously, some other people have had similar problems, and when they increased the swap space on their PI things worked better. We figured when the commands ran at certain times there may have been lots of other commands running, using up memory, and the timelapse command failed to get enough memory and crashed.
The Wiki has a page on increasing swap.

[CaptainRon47]

I ran my 'usual' allsky software last night with timelapse video turned on and left the debug output to file in the avconv command line, the timelapse was created and works as in the past. I am not sure about it not working because of other things running as I tried to create a timelapse from previous data only running the avconv command line (w/o debug) after shutting everything down and rebooting and that had failed. Does anyone know if the allsky software halts image collection while it is creating the timelapse, or does the program run separate threads for multiple scripts? I will look into expanding the swap space, but as long as it is working with the debug output going into a file that gets overwritten the next night I am ok with that.

thanks,
ron

[EricClaeys]

@CaptainRon47 Ron, The timelapse, keogram, and startrails creation are done in parallel with image capture. In fact, cropping, checking for bad images, and uploading are also done in parallel. Basically the "capture" program takes the image, adds the overlay text, then saves the file and calls saveImage.sh in the background to process the image. At the end of night, the "capture" program calls endOfNight.sh in the background to do the keogram, startrails, etc.

[EricClaeys]

@CaptainRon47 If you have it working and are satisfied, I'd say leave it alone.