[mythtv]

[Peter Marriott]

Hi Eric,

My thoughts so far after reading only the published docs (not the source 
yet) from the motion.sourceforge.net site.

The bits that caught my eye from the motion docs:
1) --with-libavcodec=DIR
 Specify the path for libavcodec (part of ffmpeg)

I believe that this is the same base that the Nuppel video codec that 
MythtV uses was developed from.  So one possibility would be to modify 
motion, hopefully only slightly to be able to record files using the nuv 
format.

So the way I see it, motion would begin recording the motion detection in 
the nuv format, motion would notify myth that a recording had started and 
you could jump to the view recording page to see the recording from hte 
start, and fast forward to live etc.  Not sure how feasible this is, but 
it should be possible.

2) Loopback device support....  this should mean motion could hang out in 
the background, so that mythtv could use the same video feed recording to 
its standard ringbuffer.  

3) xml-rpc --- Motion provides a really easy way to control it, so a 
quick and dirty approach could provide some functionality quite quickly.

At this stage I am leaning towards integrating motion if at all possible 
as it seems to be a stable and fairly advanced system.    

Cheers
Peter

-----Original Message-----
From: "Eric C. Cooper" <ecc at cmu.edu>
To: Peter Marriott <peter at bms.net.au>
Date: Wed, 5 Feb 2003 09:17:32 -0500
Subject: Re: [mythtv] Add-on ideas?

> > I will have a read up of the docs and see if I can come up with a
> > proposed integration with myth.  I'll let you know.
> 
> After a little bit of poking around, I thought of two possibilities.
> The best (and naturally the more difficult) way seems to be to
> integrate tightly with the NuppelVideoRecorder code.  The motion
> algorithm needs to examine each incoming frame, so that logic would be
> used to decide when to start recording to disk.
> 
> An easier, more decoupled approach would be to build a separate module
> that plays just the "moving bits" of existing recordings.  Of course
> that doesn't save any disk space.  I suppose this could be extended to
> edit out the non-moving portions, as a way of reclaiming the disk
> space as a background task.
>