The current code resulted in the motion_loop thread accessing (and
writing to) variables that should only be accessed in the
netcam_handler_loop thread, meaning we could see crashes.
We also introduce the necessary mutex around the remaining variables
in netcam_read_rtsp_image so:
a) we can be sure the netcam won't mess with the image buffer whilst
we're reading it
b) that any new image in 'latest' has actually been passed across the
threads and isn't lying in a register/CPU cache somewhere.
As per https://github.com/Motion-Project/motion/issues/224 the probem
code has been moved onto the netcam thread where it should be safe.
Nominally this may be less efficient (as we will resize every frame,
but motion_loop may process only some of those frames); in the long term
it may well be better to have the netcam_handler_loop send a full "image"
structure to the motion_loop thread (ie. including size and format
information), which the motion_loop thread would then be able to safely
resize.
Fixes#207Fixes#224
As the logging currently is, you can't see whether log messages came
from the netcam thread or the motion loop thread, and messages that
come from the ffmpeg thread appear to come from the main thread. This
makes debugging based on the log messages error prone at best.
As an added bonus any camera name is now included.
We now use ffmpeg's built in support for locking instead of trying to
lock ourselves before calling ffmpeg.
This may solve some race condition crashes.
Fixes#206
avformat_network_init only needs to be called once on startup and once
on shutdown.
The functions aren't thread safe, and we can't fix that by protecting
them with the 'global_lock' as other functions in ffmpeg that we call
and that access the same data are not protected by the global_lock
(and can't be protected by that lock).
Fixes#194 - the particular issue we're seeing there is something like:
thread 1: lock mutex
thread 1: deinit network
thread 1: init network
thread 1: unlock mutex
thread 2: lock mutex
thread 2: deinit network
thread 1: call into an ffmpeg operation
thread 1: ffmpeg complains "init network" not called
The original netcam_interupt disregarded interupts from the
connection routines which occasionally caused problems with
camera reconnections.
Also included is a change to use a enum and consolidation to
only use the status instead of two separate variables.
The presentation time stamp(pts) indicates the time which the movie
player should display a particular frame. In the previous changes
to the pts, we set the time basis to be in microseconds by specifying
the denomintor to be equal to 1000. This allows for additional precision
when we assign the pts when writing the frame. For the libav variant
the time basis assignment is ignored and instead the framerate is
used. The use of the framerate causes problems when it is small.
At 2fps, time intervals of 1 to 499 microseconds round to a pts
of zero, 500 to 1499 microseconds round to pts 1, etc. This
commit adds a variable to keep track of the last pts used in writing
the frame. If the newly calculated pts is not greater than the previous
pts, we just increment the pts by 1 which would be the full 1/framerate
increment. This could result visually twitchy videos at low framerates.
It could also have a compounding affect of eliminating the handling of
variable framerates and just fallback to a constant framerate video.
1. Updated motion_guide.html to reflect current options
2. Consolidated/Revised some of the header/lists to be simpler
3. Added the configuration option history by version cross-walk
The bsd compile pull revised the sed option to use -i.bak but
this left behind bak files. This alternative was found that was
indicated to also be compatible without leaving bak files.
