The timelapse feature of media-video/motion appears to be broken, and I believe that ffmpeg is the actual cause. Recording video on motion events (in MPEG 4) works as it did in the past, but I am no longer able to record timelapse movies (in MPEG 1). Indeed, setting ffmpeg_timelapse to anything but zero causes the following repeat error:

The offending file does not exist but the ownership for the respective directory (/home/motion/front/daily) is correct (motion:video); this directory has been created by motion itself some time earlier. I suspect that the EINPROGRESS error code is thrown by ffmpeg and is a red herring.

The working version of motion has been emerged Sat Aug 18 22:11:02 2012. The ffmpeg version at the time was 0.10.3. The recent rebuild of motion happened because of the change in ffmpeg library versions and broke things as described above. I tried this with ffmepg 1.0.7 (current stable) as well as 0.10.7 (same result). I believe that the appropriate USE flags are set; they are as follows:

I have a similar problem, though the error is slightly different, and I suspect as you do, that ffmpeg is at fault... maybe... the function and/or binary for ffopen is no longer available?

Yours has actually been popping up all over the place (with no fix). It would appear that both our errors are thrown by ffmpeg_open. Both our errors appear to come from the blacklisting of the mpeg1 format in ffmpeg. At least this is what I concluded following my very brief investigation on the matter. Indeed, I found an interesting comment in ffmpeg.h (from the motion sources):

Code:

/* Open an mpeg file. This is a generic interface for opening either an mpeg1 or
* an mpeg4 video. If non-standard mpeg1 isn't supported (FFmpeg build > 4680),
* calling this function with "mpeg1" as codec results in an error. To create a
* timelapse video, use TIMELAPSE_CODEC as codec name.
*/

This file also contains the definition of this codec name as follows:

Code:

/* Define a codec name/identifier for timelapse videos, so that we can
* differentiate between normal mpeg1 videos and timelapse videos.
*/
#define TIMELAPSE_CODEC "mpeg1_tl"

The piece of code that throws our errors seems to be the following (from ffmpeg.c):

By this time the file format checks are done (and presumably succeed), yet avio_fopen() fails (sorry by the way for the previous version, I was looking at the file before applying the Gentoo patches). I am ovbiously not familiar with either motion or ffmpeg so I am not sure what to make out of all of this. I will try to dig further but this will not happen for another couple of week at least (maybe more).

Should anybody be able to shed light on the matter it would be much appreciated._________________Quid latine dictum sit altum videtur

Sorry for the long silence. I have filed a bug report upstream and it went unanswered for more than a month. The project appears dead to me, which is a pity really. I could really use a working motion as to the best of my knowledge there is no other Gentoo package doing anything similar. Should anybody have any suggestion on the matter I would be more than happy to hear it._________________Quid latine dictum sit altum videtur

I sort of solved my problem, in the sense that I have a working "motion" once more. The bad news is that what I ended up with is a horrible workaround: I built a minimal ffmpeg-0.5.13 (I can confirm that 0.8.15 has the same problem as the current version as far as motion is concernet; I did not try any other version of ffmpeg) in a non-standard location and then I built motion against it! All of this is outside the Portage system.

By "minimal ffmpeg" and "non-standard location" I mean the following ffmpeg configuration:

By "building motion against the old ffmpeg" I mean that I took the motion source (3.2.12), applied motion-3.2.12-workaround-v4l1_deprecation.patch from the Portage tree (ffmpeg-*.patch are not necessary for ffmpeg-0.5.13), and then configured it as follows:

(whether mysql and psql are needed is of course a matter of local need and might or might not be necessary).

Obviously instead of just the executable "motion" now the thing must be launched as "LD_LIBRARY_PATH=/usr/local/ffmpeg/lib motion" but things are otherwise running as before.

This is obviously the lazy way out (and ugly as hell), but I did not have the time for anything nicer. By the look of their bug report pages the upstream seems to be dead. I might look into a correct fix in the future but I am not sure when will I find the time for this._________________Quid latine dictum sit altum videtur

This indeed seems to make motion work well, with one obvious, minor issue: the timelapse video is now truncated every time motion is restarted. I understand that the APPEND_PROTO trick no longer works but I am wondering whether there is any other way of specifying such a behaviour (to append to the file rather than overwrite it).

I know nothing about the ffmpeg API, otherwise I would not be asking. I will try to experiment myself but since you know your way around the thing already I was wondering whether you may have some pointers on the matter...

Quote:

Big thanks to bruda for all the groundwork narrowing down the problem!

No need for any thanks indeed, as you were the one actually fixing things._________________Quid latine dictum sit altum videtur

I looks like the appending trick is no longer possible, since the relevant functions are no longer exported from ffmpeg. av_register_protocol() is now ffurl_register_protocol(), which is private. My head still hurts from sifting through the code!

The workaround is to specify in motion.conf the timelapse file name to include the time, as in the motion-triggered capture files. In that way, when motion restarts, it will create a new file. The nice side effect is that you will know immediately if and when motion was restarted

I looks like the appending trick is no longer possible, since the relevant functions are no longer exported from ffmpeg. av_register_protocol() is now ffurl_register_protocol(), which is private. My head still hurts from sifting through the code!

Hrm, OK, that's life I guess. Thank you for clarifying this so that I do not have to look into the API myself.

Quote:

The workaround is to specify in motion.conf the timelapse file name to include the time, as in the motion-triggered capture files. In that way, when motion restarts, it will create a new file. The nice side effect is that you will know immediately if and when motion was restarted

Good point, that seems to do nicely; overall I can say that I have now a fully working motion once more. The whole thing should go into the official tree since their version of motion is crippled.

In any event, your help has been much appreciated. Many thanks._________________Quid latine dictum sit altum videtur

This happens at the end of ffmpeg_open() from ffmpeg.c in the motion source, with the full set of patches from https://github.com/mapmot/moverlay applied. I am clueless when it comes to the ffmpeg API so any help is much appreciated.

The reason I am putting all of this in this thread rather than a new one is because the effect of the issue is the same, namely that timelapse videos cannot be recorded anymore; the rest of the functionality is still fine.