Thankyou to Andrey, Oleg and Sebastian-
These developments are very assuring!
Not only is there the immediate solution of reducing php calls, but-
Combined with the proposed fix to the streamer will enable very high
datarates to be achieved!
This is exciting :)
On Tue, Oct 18, 2011 at 6:25 AM
good idea!
On Mon, Oct 17, 2011 at 21:24, Andrey Filippov
wrote:
> Sebastian, nice job!
>
> You may try to adjust coring value - that will allow you to change file size
> more gradually than in 1% increments.
>
> Andrey
>
> On Mon, Oct 17, 2011 at 1:14 PM, Sebastian Pichelhofer
> wrote:
>>
>> I
Sebastian, nice job!
You may try to adjust coring value - that will allow you to change file size
more gradually than in 1% increments.
Andrey
On Mon, Oct 17, 2011 at 1:14 PM, Sebastian Pichelhofer <
sebastian.pichelho...@gmail.com> wrote:
> I ran a full measurement cycle.
>
> With and without
I ran a full measurement cycle.
With and without streamer enabled, I also reduced the AJAX call
frequency in camogmgui to once every 5 seconds to not give PHP an
additional CPU load in the camera. All values are averaged over 5
seconds.
JPEG Quality and data-rate are relative not absolute as the
Nathan,
I was able to reduce the PHP's cpu usage and could run recording
1920x1088@25fps, quality 93, with streamer working, single frame size
~300K-~400K,
streamer ~60% cpu, camogm ~30% cpu (same w/o streamer).
The problem is that the php calls (status requests) are "too frequent" so
that they e
Sebastian,
This program is currently not supported, there were some FPGA changes in the
camera after it was released, so something may break. The purpose of the
project was to have audio support, other than that I do not it may have
performance advantages.
Andrey
On Mon, Oct 17, 2011 at 8:37 AM,
I created a new wiki page about cammkv, an alternative HDD recorder:
http://wiki.elphel.com/index.php?title=Cammkv
I was wondering if it performed better than camogm since it was coded
from scratch by Andrey Latin.
In my tests I tried to continuously increase datarate until it would
overflow (ssh
Nathan,
As I remember MPlayer can handle dropped frames nicely, and it will not be
_many_frames in sequence lost - otherwise the recording will overrun the
buffer on it's own, without the streamer. "Nice" mode fro the streamer is
good as it will try to avoid frame drops on recording to the very en
What would the implications be for the host PC recieving the stream?
If the streamer goes to sleep for n frames... Wouldn't the host PC "think"
that the connection is lost?
On Wed, Oct 12, 2011 at 3:36 PM, Andrey Filippov <
support-list@support.elphel.com> wrote:
> Nathan,
>
> The intended solut
Nathan,
The intended solution would be to tell streamer minimal size of the camogm
buffer to maintain. And make the streamer "nice" - when the streamer is
awaken by the driver (it happens at each frame, if needed - can sleep for
several frames or until frame #xxx is ready, but it would not take mu
Forwarding a short discussion regarding datarate limitations recording to
HDD while running streamer simultaneously. Continuing discussion here so
that others may benefit.
*Problem: *
Cannot record to HDD with high datarates when streamer is running.
*Cause:*
Streamer running with high datarate r
11 matches
Mail list logo
