Motion - Motion With Myth TV

MotionWithMythTV

Introduction

MythTV is a Linux open-source project to provide PVR (personal video recorder) features on a computer. MythTV servers are usually operating 100% of the time and have connected TV cards and sizeable amounts of HDD storage. Thus they are ideal platforms for hosting 'motion'. With its low CPU requirements, 'motion' will not load a MythTV server excessively and can share its storage space.

This details the addition of motion to a MythTV server using MythDora 4.0. MythDora is a combination of MythTV and Fedora Core Linux 6.

Note: This article does not show how to use a MythTV-configured video capture card, or a composite input of a TV tuner card, for motion detection. It shows how to set up a netcam-based 'motion' system only.

Detailed Description

MythDora 4.0 is a live CD and DVD that will install onto the PC it is run on. After installing, motion can be installed and configured to use the /storage area that MythDora has set up.

MythDora includes LVM (logical volume management) which allows partitions to be re-sized at will, or extra hard disks added to partitions later on. This is useful if the Motion video directory becomes larger than originally planned.

I have only been using MythDora to host 'motion' for a short time and do not know it well. I have compiled it without V4L support, to avoid any conflicts with TV tuner cards, etc that MythDora is accessing. There are likely to be issues with 'motion' accessing video capture cards at the same time as MythTV. It may well be possible to use a capture card that is not configured for use by MythTV, but I have not done this.

Attached Files

None.

Installation

MythDora 4.0 is a "live CD" and DVD that will install onto the PC it is run on. Beware: it is designed to overwrite hard disks during the installation! Only use on a 'test' or new setup that you do not value the HDD contents of.

After completing the MythDora installation (for which there are various guides on the Internet), Motion can be installed.

MythTV creates a /storage area which is where MythTV stores all its video files.

The standard user login on a MythTV server is 'mythtv'. I su'ed to root and created a directory within /storage called motion, so I had /storage/motion which is for the motion video and image files. I also created a new user called 'motion' with a directory /home/motion to compile the motion source in (MythDora 4.0 is installed complete with gcc and make - nice!)

Then, logged in as user 'motion', I chose to compile from source, since I had patches to add (any rpm package would not include these), so I started by downloading motion-3.2.8 into the directory /home/motion. I added the patches I wanted at that point.

Important Notes: MythDora 4.0 requires some symbolic links to be set up before Motion will configure successfully. This is due to the particular arrangement of Mythdora's ffmpeg header files.

Motion's configure script checks for the presence of libavformat.so and libavcodec.co and libavutil.so. MythDora only provides files with names ending in .so.51.12.1 (example). So make the following links (beware that the actual library numbers libavcodec.so.*x.y.z* might be different on your system):

# cd /usr/lib
# ln -s libavformat.so.51.12.1 libavformat.so
# ln -s libavcodec.so.51.40.3 libavcodec.so
# ln -s libavutil.so.49.4.0 libavutil.so
# 
# cd /usr/include
# ln -s mythtv/ffmpeg ffmpeg

Here are my links:
# ls -l /usr/lib/libav*
lrwxrwxrwx   1 root root       21 Aug 17 15:39 libavcodec.so -> libavcodec.so.51.40.3
lrwxrwxrwx   1 root root       19 Aug 17 15:40 libavutil.so -> libavutil.so.49.4.0
lrwxrwxrwx   1 root root       22 Aug 17 15:55 libavformat.so -> libavformat.so.51.12.1

# cd /usr/include
# ls -ld ffmpeg
lrwxrwxrwx  1 root root     13 Aug 17 16:02 ffmpeg -> mythtv/ffmpeg

Then configure Motion a way that excludes Video4Linux and points to the correct ffmpeg directories. (The top part of this article explains why V4L is not included). I also do not use MySQL, so that is also configured-out.

# ./configure --with-v4l=no --with-mysql=no --with-ffmpeg=/usr

# make 

Motion's .conf files can then be set up to store images and video files in /storage/motion to your taste.

-- SimonW

Latest news, I have found a problem with ffmpeg films while running Motion on the MythDora 4.0 platform. Strangely, it only affects 1 of my 3 netcams.

I am not certain of the cause, but it could be the ffmpeg version (which was SVN 8743). The ffmpeg version I have successfully used is 8780.

I do not know if upgrading the ffmpeg version to 8780 or the latest (10198) would work, as there may be dependencies in MythTV program.

I will experiment with Motion with the most recent SVN which is 10198 and see if the problem is still there, then I can go back to the MythDora system and upgrade the ffmpeg, knowing that Motion will work. And then I can see if MythTV is affected. It's a good job that it is only a 'testing' system so far.

-- SimonW - 23 Aug 2007

I think there was something incorrect in my Motion config files when I noticed the problem with no ffmpeg output from one of my netcams.

Since then I have experimented with a clean, re-installed MythDora installation and also tried a second copy of ffmpeg on the system (the 'known working' Motion Sourceforge copy). None of those setups gave the problem I first reported.

I am again running Motion compiled against the MythDora standard ffmpeg installation, which is:

# ffmpeg -v
FFmpeg version SVN-r8743, Copyright (c) 2000-2007 Fabrice Bellard, et al.
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --mandir=/usr/share/man --enable-shared --enable-gpl --enable-pp --enable-swscaler --enable-pthreads --enable-x11grab --enable-dc1394 --enable-liba52bin --enable-libdts --enable-libfaac --enable-libfaadbin --enable-libmp3lame --enable-libogg --enable-libtheora --enable-libvorbis --enable-xvid --extra-cflags=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables --disable-strip
  libavutil version: 49.4.0
  libavcodec version: 51.40.3
  libavformat version: 51.12.1
  built on Apr 23 2007 23:45:21, gcc: 4.1.1 20070105 (Red Hat 4.1.1-51)

I still needed to make the symbolic links mentioned above, but then I did not need to specify the ffmpeg location any more. I configured Motion with simply:

# ./configure --with-v4l=no --with-mysql=no 

# make 

Without my patch for what I call 'Movie Rollover' ( see OneFFMpegWithEventNumbersUpdatingPatch ) you cannot make Mpeg-1 motion films. My patch over-rides Motion's self-limitation about making Mpeg-1 files with non-standard frame rates due . There is a history of ffmpeg frame rate problems arising from API changes, discussion of which can be found elsewhere on the Motion wiki...

Using my patch, I can get ffmpeg films covering 1-hour intervals, using Mpeg-1 with a 25fps frame rate. The files play at a fast rate but that is ok for reviewing a day's motion quickly. For further investigation of any time point, the film can be stepped through frame-by-frame. I use Media Player Classic and VirtualDub on a Windoze system.

I am not seeing any problems apart from being unable to compile one of the helper programs I use, ffmpeg2theora. It does not seem to pick up the 'unusual' ffmpeg header locations on MythDora and will not compile. By the way, ffmpeg reports it was compiled with 'enable-libtheora' but this is just a decoder.

So I have moved away from using Ogg Theora as an archive format and am still choosing what to use for the long term. An MPEG-4 format could be ok, since once the files are more than 24 hours old, appending to the files is no longer required. That is why I use MPEG-1 output from Motion, until the files are 24 hours old.

So in conclusion, MythDora 4.0 can host a Motion system with a few symbolic links added to permit Motion to locate the ffmpeg installation. Once this is done, it compiles and runs ok. Though without my patch, using Mpeg-1 output is not permitted, like on any recent ffmpeg version.

-- SimonW - 26 Sep 2007

It pays to keep up with the news. It turns out that Theora encoding (written by Paul Richards) has been added to an SVN version of ffmpeg. It is referenced here: http://ffmpeg.mplayerhq.hu/changelog.html

It also turns out that feature is in the ffmpeg in MythDora 4.0 ... so perhaps I do not need to find another file format after all!

So exciting is this that I write here before testing out the encoded file.

The encoding command is: # ffmpeg -i .mpg -an -vcodec theora -b 1000000 -y test.ogg

I shall report again when I have inspected the quality of the encoded output.

-- SimonW - 27 Sep 2007

It seems that perhaps the theora encoder in ffmpeg is not totally ready. I could not play the created files successfully.

Creating Ogg Theora files using VLC (which is already installed on MythDora 4.0), works though:

#vlc inputfile.mpg vlc:quit --sout '#transcode{venc=theora,quality=8}:standard{access=file,mux=ogg,dst=outputfile.ogg}'

The generated file plays on Windoze Media Player Classic. The vlc:quit makes VLC terminate after creating the output file.

The above example worked for me with a 3Mb MPeg input file, output file about 0.5Mb in size. However, with large input files I got segfault occurring repeatably. I've even updated to 0.8.6c of VLC. Example:

$ vlc -I dummy /motion/raw/2007/09/27/20070927_movie20_cam2.mpg vlc:quit --sout '#transcode{venc=theora}:standard{access=file,mux=ogg,dst=mon.ogg}' 

> Completed OK

$ vlc -I dummy /motion/raw/2007/09/27/20070927_movie11_cam2.mpg vlc:quit --sout '#transcode{venc=theora}:standard{access=file,mux=ogg,dst=mon.ogg}' 

> Segfault

-- SimonW - 01 Oct 2007

I could not solve the problem of vlc segfaulting with large mpeg input files, and I did not want to move away from Ogg Theora for my archive format, so I returned to the problem of getting ffmpeg2theora to compile under MythDora 4.0. As I stated above, the 'configure' process of this package would not detect the unusual ffmpeg component locations in MythDora 4.0, so configuration failed.

I solved the problem, which turned out to be complex, but very pleasing in the end. My process was:

1. Download & untar ffmpeg2theora latest SVN version. Do not configure/make yet!

2. Run the get_ffmpeg_svn.sh script to get a local SVN copy of ffmpeg into a directory 'ffmpeg' below ffmpeg2theora's directory. The script then automatically configures and makes it.

3. Download & install the up-to-date version of libtheora (this step was critical to success on MythDora 4.0 since the libtheora included is not the latest. Do:
$ configure --prefix=/usr ; make ; make install

4. Configure ffmpeg2theora to use this 'new' ffmpeg, with the following command:
$ ./configure --with-ffmpeg=./ffmpeg

4. After the configure step, edit the ffmpeg2theora Makefile to correct the following problems:
  • Add '-lpthread' to the end of the variable ffmpeg2theora_LDFLAGS since the linker requires that library
  • Correct the linker line so that the LDFlags are presented after the objects (this solves 'unreferenced identifier' errors)
ie. before:      $(LINK) $(ffmpeg2theora_LDFLAGS) $(ffmpeg2theora_OBJECTS) $(ffmpeg2theora_LDADD) $(LIBS)
    after edit:  $(LINK) $(ffmpeg2theora_OBJECTS) $(ffmpeg2theora_LDADD) $(LIBS) $(ffmpeg2theora_LDFLAGS)

5. Execute 'make' which then completes successfully and ffmpeg2theora is compiled.

6. Remember that the changes made in the Makefile will be lost if configure is run again....

As I say, using the current versions of package(s) was probably not the reason for success. The critical thing was the Makefile errors in ffmpeg2theora. I also saw the same errors in the 0.19 released version. I will email the project's maintainer.

So I have ffmpeg2theora working on MythDora4.0 (Fedora Core 6). It handles very large mpeg-1 input files with no problem!

-- SimonW - 04 Oct 2007

Some clarifications included above, since I have been through this process again.

-- SimonW - 02 Nov 2007

Users Guide

Comments and Bug Reports


Topic revision: r11 - 02 Nov 2007, SimonW
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.