File at 1 per sec, too fast

Questions? Suggestions? Need help? Talk about anything related to Yawcam...
Post Reply
Mike Scott
Posts: 30
Joined: Fri Feb 15, 2013 6:47 pm

File at 1 per sec, too fast

Post by Mike Scott »

If the FILE option is used and set to 1 sec per frame capture, it misses the odd one. Not always the same one, but over 60 seconds it will typically skip 1 or 2, sometimes 3. I suspect this is simply a case of the task/s take longer than 1 second. So thinking about writing a stand alone bit of code to grab a still every second. Dedicated to just that task it has a better chance.

From the code in template_js.html I see the file containing the steamed frames is called out.jpg and looks like it comes from .yawcam/stream/ but I find no such file there, or anywhere on the disk. Even checked for hidden files.

Can anyone tell me where the file is ?
z3r0c00l12
Moderator
Posts: 1210
Joined: Wed Jan 14, 2009 3:50 am

Re: File at 1 per sec, too fast

Post by z3r0c00l12 »

Yes, that's exactly the case, every shot takes roughly 200 ms from what I see, so even though it's set to 1 fps, you still get a few missing. Normally, in an hour, you would get 3600, but I get an average of about 3200 per hour when set to 1 fps.

There isn't much that can be done to fix that.

I added {tstampMS} in the filename, so you can see the milliseconds and see the time difference between each shot.
Mike Scott
Posts: 30
Joined: Fri Feb 15, 2013 6:47 pm

Re: File at 1 per sec, too fast

Post by Mike Scott »

Thanks for the confirmation. My plan is to write a small VB app to make the snap shot. The VB app being dedicated to just that one task (file copy) it would have a much better chance at keeping up with 1 fps. Face it, yawcam is doing a hell of a lot of (great) other things at the same time, so it has to run out of steam at some point. PC performance as well as what else is running must also have an effect, as well as HDD speed. But i'm using SSHD so cannot get faster than that. But cpu is only 1.6gHz. Not a snail, but not the fastest either.

So, need to know where the mysterious out.jpg is located ?
z3r0c00l12
Moderator
Posts: 1210
Joined: Wed Jan 14, 2009 3:50 am

Re: File at 1 per sec, too fast

Post by z3r0c00l12 »

I just had to try this, after seeing the topic, not the best solution, but it may suit your needs.

Enable Motion Detection.
Enable "Save File".
In the settings, point it to a folder, with a filename that includes the milliseconds.
Set the image array to 9999, with interval 500 ms.
Set flood control on and to 4998 seconds.

What it will do is, once there is motion, it will save approx. 2 fps for 5000 seconds, then it will stop until the motion is triggered again, saving another 10000 pictures at 2 fps.

Hope you can use that in your case.
malun
Site Admin
Posts: 1589
Joined: Sun Jan 04, 2004 1:29 pm

Re: File at 1 per sec, too fast

Post by malun »

To be honest, Yawcam could keep track of the time it takes to grab and save the picture and then subtract this time from the interval.
But then it becomes a bit more complicated... Now it's simple and I usually like simple ;-)

The out.jpg is not saved to disk. This file is generated in memory and supplied on the fly to the webserver.
This means you could write a program that grabs the file from Yawcam's web server (http://localhost:8081/out.jpg) every second and saves that.

/malun
z3r0c00l12
Moderator
Posts: 1210
Joined: Wed Jan 14, 2009 3:50 am

Re: File at 1 per sec, too fast

Post by z3r0c00l12 »

Malun, I've tried writing such a script before, but my attempt failed. When I investigated, and cross-referenced the HTTP requests from my script to the ones generated by the browser, I saw that my script did add the "referrer" line in the HTTP request and Yawcam didn't return the jpg.
malun
Site Admin
Posts: 1589
Joined: Sun Jan 04, 2004 1:29 pm

Re: File at 1 per sec, too fast

Post by malun »

Okay, my bad. The stream output will not respond with the image if not the stream has been started...
It's possible to go directly on the http output though.
I made a small python test script that works fine:

Code: Select all

#!/usr/bin/python

import urllib
import time

x = 0
while x < 10:
   print "Downloading image "+str(x)
   urllib.urlretrieve ("http://localhost:8888/out.jpg","out"+str(x)+".jpg")
   x += 1
   time.sleep(1)
/malun
Mike Scott
Posts: 30
Joined: Fri Feb 15, 2013 6:47 pm

Re: File at 1 per sec, too fast

Post by Mike Scott »

Not saved to disc but in memory! That explains why could not find it :-) Thanks for the info and the same python code, I get the concept. The motion detect idea will not work for my requirement. I need 60 snap shots at 1 sec intervals, overwritten every minute. And it must not miss a grab, as the time ref in the file name represents 30 degrees on a camera panning at 1 rpm. if a grab is missed them what I see is a minute old. eg: file named image_02.jpg shows the image from the camera as it passed through 60 degrees.

Don't know what code z3r0c00l12 tried, I am using VB6, so will try and see.
z3r0c00l12
Moderator
Posts: 1210
Joined: Wed Jan 14, 2009 3:50 am

Re: File at 1 per sec, too fast

Post by z3r0c00l12 »

I was attempting to use AutoIt.

Here's a sample of the code, where I stopped trying/didn't require the code anymore:

Code: Select all

Global $id = id()
Global $url = "http://192.168.1.5:8081/out.jpg?q=30&id=" & $id & "&r=" & _DateDiff("s","1969/12/31 19:00:00",_NowCalc()) & @MSEC
Global $img = @YEAR & "-" & @MON & "-" & @MDAY & "_" & @HOUR & "." & @MIN & "." & @SEC & "_" & @MSEC & ".jpg"

While 1
	If InetGet($url,"C:\Yawcam\" & $img,1) <= (2 * 1024) Then
		FileDelete("C:\Yawcam\" & $img)
	EndIf
	Sleep(500)
WEnd

Func id()
	Local $Return = "0."
	For $x = 1 to 17
		$Return &= Random(0,9,1)
	Next
	Return $Return
EndFunc
Mike Scott
Posts: 30
Joined: Fri Feb 15, 2013 6:47 pm

Re: File at 1 per sec, too fast

Post by Mike Scott »

Made some progress on this, but not a solution. Just a better upstanding of the problem :-)

Http://localhost:nnnn/out.jpg I could not get to work as it is looking for a file, and as Malun point out, it's not a file, it's in memory. I am surprised Mulan got a python app to read it. You know something I don't ??

So in VB6, on the same PC as the yawcam, I created a webbrowser and pointed it to Http://localhost:nnnn (mine is not set at 8888, so nnnn means whatever port your streaming is set to). I have modified the template_js.html so it would not automatically trigger a reload of the image every n seconds. In its place I triggered it from VB6. To my dismay, when triggering it at 1 per sec, it still missed the odd one.

Conclusions: It's the IP that is the problem. yacam and the VB6 controlled web browser are on the same PC, so the traffic, whilst in IP format, is not going out over the internet. It's all in the one PC. IP, as used in the internet, intrannet, extranet, or even within the one PC if using http://.... is very robust, but very unreliable. The unreliability is not normally a problem as the resilience of the IP system overcomes the unreliability. If browsing a web page via google you don't notice it, just the page is a bit slow getting to you. But in a time critical application, it sticks up like a sore thumb :-(

Accessing something via IP is not time wise reliable. The reason it misses the occasional pic is the IP has not delivered n pic when there is a delay in the IP, before the second is up, and n+1 comes into affect.

So I am back to square one. The only truly reliable way to get 1 snap shot every seconds without missing one, is to access it in memory and thus not use IP. A grab from memory and dump in a file (which is what yawcam does. Problem is yawcam is doing lots of other stuff as well and runs out of umph)

Mulan, Only way I see to overcome this is a small dedicated app outside of yawcam that does the grab from memory and dump to file. Looking at my 1.6Ghz PC cpu usage, my attempt was using less than 20% of CPU time, so I looks like it could grab frames as fast as 200ms, if not having to wait for IP. Any info on how to get at the image in memory? (when Http://localhost:nnnn/out.jpg does not work)
z3r0c00l12
Moderator
Posts: 1210
Joined: Wed Jan 14, 2009 3:50 am

Re: File at 1 per sec, too fast

Post by z3r0c00l12 »

As malun has explained, it's not a matter of Yawcam doing too many things at once, it's just a matter of timing.

Take this for example:
Yawcam is set to 1 fps.
Yawcam begins taking a shot at 12:00:01.000 (this process takes a few milliseconds to complete).
Yawcam saves the shot at 12:00:01.236.
Yawcam waits 1 second. A.K.A sleep
Yawcam begins taking another shot at 12:00:02.236 (Roughly, there could be a few more millisecond delay before the action is started).
Yawcam saves the shot at 12:00:02.472.
Yawcam waits 1 second. A.K.A sleep
Begins taking another shot at 12:00:03:472.
...
Begins taking another shot at 12:00:04:708.
...
Begins taking another shot at 12:00:05:944.
...
Begins taking another shot at 12:00:07:180.

After a few seconds, the accumulated delay between each shot and sleep makes it seem like Yawcam skipped a second, but in fact it's actually because the 1 second interval takes slightly more than 1 second to execute.
Mike Scott
Posts: 30
Joined: Fri Feb 15, 2013 6:47 pm

Re: File at 1 per sec, too fast

Post by Mike Scott »

Thanks for the explanation. But doesn't solve my problem. Getting the out.jpg via IP is unreliable due the variations in the IP delivery.

I wrote a vb6 app today that obtained the out.jpg in a webbrowser control embedded in the VB app, and could copy the image to memory and then dump it to file as a .jpg. But even when using it on the same PC as the yawcam (so no internet or LAN), the IP access just hiccuped to much to be reliable.

Only way I see, is a stand alone app running an accurate 1 second interrupt routine. Not sleep. and that saving the image directly from yawcam's memory to file. But I expect there will be problems one app accessing the memory area of another (even if I new where it was).

Beginning to look like there is no solution :-(
malun
Site Admin
Posts: 1589
Joined: Sun Jan 04, 2004 1:29 pm

Re: File at 1 per sec, too fast

Post by malun »

I'm surprised that your VB app didn't get the full 60 images per minute when running on the same network.
Usually TCP/IP is very reliable on the same LAN.

You are right in that an interrupt every second (no sleep) would be the best way to guarantee that you get 60 images per minute.
I'm afraid it could be a bit tricky to add this option in Yawcam right now.
I'll have to make some tests to see what's possible.

/malun
Post Reply