I have a new problem! The frame rate of the camera now seems to change on its own? I did a filming trip yesterday but unfortunately I was only able to get a max of 19fps & sometimes it would fluctuate causing the finished video to become unusable. Settings were the same as normal. Its something that has started since I used the limit bandwidth function on the klutchin streamer about a week ago. Im not sure if its the cause of the problem. I have today reinstalled the firmware but this seems to make no difference.
Every time I feel like I can relax something new comes up! :-)
How are you limiting the frame rate - the best way is to put it in the "frame rate" field of the main window and press "update" button. Then you may verify the result with the "?" link. If you put "0" or empty, than the sensor will run at maximal it and the compressor can do. That way you control the sensor rate so all the streamers will work (you do not need to change anything in their settings - let them run at the maximal rate (determined by the sensor).
Did you try other streamers - is there any difference?
Did you have such problem before?
Ive tried this but the dialogs box that pops up when recording always has its own (always changing & lower then expected) fps . Before the camera would record at flat 22fps (full screen) always unless I set a lower frame rate via the index page.
Ive messed something up somehow in the last week. It started when I limited the bandwidth to something like1000kbs & the frame rate became 6fps now I can not seem to turn it off. Even with all the updates Ive done.
Im going to try a older fpga as its been a week or so since I upgraded.
Thanks again Phil
The true sensor frame rate is the one that shows in the window that opens on the "?" link. There is no way that the stream can have different than this one - only by dropping some frames.
If you put in that main window some frame rate and "?" shows lower - than it just can not run faster. Look again at the "?" window:
Is the exposure time lower than 1/frame rate?
Is the sensor clock 48 MHz?
Is the FPGA clock 90 MHz?
Maybe you did not restore /etc/init.d/fpga to the 48/90 after you reflashed the camera? When you do that everything is set to the defaults, including the configuration files you edited. I would recommend you to use ftp and have a local (on your HD) copy of te files you edited in the camera (make similar directory structure so it will be easier to find were to put the files)
Fixed I think! I was just reading the 333 article you made & in there you say it pumps out a bandwidth of 70mb/s I opened the khlutchin streamer & changed the limit bandwidth to 70,000 kb/s this raised fps to 20-21fps I then did 80,000kb/s & I was back at 22fps!
I have a feeling that this streamer somehow can save a setting in the camera which can only be reset with the streamer.
Ive just made a 3rd file & the fps is going awol again! I guess I will try a even older fpga.
I always set everything up the same way & the ? has 22.1fps 90/48mhz 90%quality Exposure at default 20ms. I have many files at 22fps that were made when I had the skipping problem before.
I don't think there is any sense to go to the earlier versions of the FPGA - it can mess up things even more. Can you send me the copy of your status page that opens at "?" link.
As for frame rate dropping lower than "?" page shows - it can happen if the CPU/network is near the limit. That can be if the compression quality is high _and_ the scene is complex (a lot of high spatial frequency details). If that is the case (the bitrate is high) I would try the following:
1. Find the static test pattern/view so you can easily reproduce the problem.
2. Try at lower compression quality - see if the problem qoes away.
3. Try several alternative streamers (i.e. by Spectr - it uses very different implementation) and see which one does better for you (no skipping at higher quality).
If even the fastest streamer can not do that - well, CPU can not push it faster over the network - it is already twice faster than original software by Axis was sending the data.
In that case you have just 2 choices - reduce compression quality or lower the frame rate (on the main page).
As for the FPGA - there is no difference in compression quality - it can compress even with 100% setting at the full speed (but it will be too much data to push through the 100 Mbps network).
I filmed this morning & finally got some usable film I think (its rendering to a lossless avi format). The only way I could get 20fps was to shrink the image a bit to 1280x900 (so there will be some short black bands top & bottom) & use 80% quality. The ? page had 25fps but the max I could actualy get was 20fps. I can not understand why the camera was always stable at 90% 22.1fps up until last week. I film until 2gbs & let the file close by its self, this way virtual dub makes its own header & the file becomes much faster to navigate in windows. Some of the files were a steady 19fps-20fps then all of a sudden I see 15fps - 10fps? Mplayer was running the whole time so I was just making new files so its as if the camera speed is dictated by what it sees now. A few weeks ago it was fixed. If I set 15fps it will now record at 10fps. I have the ? file & will post it as soon as I finished rendering.
If you were getting 20 fps while sensor was running at 25 fps ("?") you obviously have frame drops, that could be in one of 2 places - streamer (software, not FPGA) in the cameras and PC.
Some of the streamers allow you to see the "outgoing" frame rate (or frames per 10 seconds in khlut) and also the actual bit rate. What do they show? Any difference between the streamers?
If there is no difference betrween streamers and/or the reported (by the streamer) frame rate approximately matches the sensor one - the problem is on the PC side again.
here is the ? data
Its something that appeared recently about the time that the skipping was fixed. It happens mostly when making a second file. It could be something with the anti skip buffer echo 30 5 00 5 etc ? I shall try some other numbers but sometimes I do see that the slow recording frame rate will be transfered onto the ? data page.
Its still uploading but I'm about to go to bed so I will post the link now. Its a little demo video tour of my town in Belgium that I quickly made last Sunday morning on a rather gray day. There is a little text I added just for interest (press pause if you want to read it). It uses a fixed mount with no tilting into the corners so it gets a bit 'jerky' on the bends.
Sorry forgot to say its 250mb !
Thank you - I've got that file. Nice views!
I thought I had everything working today, I made a new mount thingy for the car with a pan & tilt camera mount, two suction cups & a load of Alloy tubes! I plugged everything (laptop ;313L & mount)into a 12v - 230v converter to power the lot off the car battery. Started up the camera & at 85% quality it was chugging along at 18fps? If I plug into the mains I get an instant 20-22.1fps? Could the car battery (with a 150watt inverter) or a generally unreliable power supply effect the camera fps?
Did you solve the last problem with "squares" by reducing the FPGA clock down from 90MHz - the images clearly indicated this type of the problem. I would recommend doing that even if the problem seems to go away by itself - when the clock speed is marginal, performance may depend even on the camera temperature variations.
As for the dependence on the power source - I can not think of any reasons for that. There are several stages of power supplies and DC-DC converters, so internal power should be stable in any case. And internal circuitry resets the camera if internal power goes lower then required.
Most likely reason for skipping frames (on any side - camera or computer) is the "complexity" of the scene (amount of high frequency components - details in the images). So if it did work at say 22 fps and certain compression quality, but then the scene changed (i.e. bush branches got into frame) the image size increased and the required bandwidth increased. I would recommend testing the maximum qulity settings at such frames with a lot of small detailes (i.e. web of branches) to make sure everything works for the most complex frames.
Now Im finally understanding (I think) how this camera works. By the computer the scene is not so complex with mostly large objects close to the camera. If I set to 70% quality the camera will be pushing out about 8 Mb/s. Now if I pick the camera up & poke it out of the window I can get it up to 23 Mb/s ! (if I point towards the ground,tress etc).
I guess if I keep the iris open, stay below 70% quality & Exposure faster then say 30ms (to be safe) I should be ok. Alas Its raining so I may have to do a test drive later. I think its a bandwidth issue
I was curious & did a test drive in the rain (with the camera inside!). I was able to finally film OK with high steady frame rates if I stuck to the rules in the post above. Low 65-70% quality & a fast exposure with the iris open so as much light as possible is hitting the sensor. I used the windows VLC method as its so simple but I had the dreaded skipping frames problem back!.... (plus the grid).
Tomorrow I will try the Live CD again in hopefully better weather. I feel the mysteries of the 313L are starting to penetrate my thick skull !
If the mesh is as you described earlier (does not appear on the static images and doesn't change with lowering FPGA clock) - it is very little I can help as it is in the client software.
So what was wrong with the recording using Live CD? I thought at some point you've solved the skipping problems by adjusting performance parameters. It is probably easier to solve the remaining problems in the system that is open source and so much more flexible.
The last problem with the live cd is the 2gb files. I have to keep an eye on the comandline box & make a new file every 18minutes+ - . If this problem could be solved so it just makes a new file I could just worry about the image & tilting the camera into the corners etc. I will do a new test run in a minute with the live cd. We should be recording a 7hr long classic (Amstel Gold) with the camera this Sunday so its a lot of files to make in a car thats bouncing all over the place!
I made a skip free 1280X1024 video in the car but used 60%. It was a gray day with wet roads so I suspect that when its sunny say in the mountains I maybe able to use 80%? It seems much harder to get the camera in focus with Mplayer then with VLC.
Could you look sometime at the VLC program? Its open source & is available for Linux also. The picture it receives from the camera has a slight grid but also seems sharper with deeper colour depth (the sky is captured in detail rather then being washed out). It maybe an illusion if nothing is done to the image in Mplayer. It seems interesting though, perhaps the grid just helps find that spot where its in focus which can be hard outside in daylight with a cheap laptop screen!
regards & thanks for the help Phil
I filmed the http://www.amstelgoldrace.com ! we had the 313L on the lead car outside on its special mount that tilts into corners but the damp mist kept building up on the lens & we had to film from inside. We ended up with 27gb of 70% quality Mjpeg at 1280x900 25fps. I filmed upside down once inside the car as space was limited with the little suction mount we used (I was not going to mess about with fpga in a bouncy car). Anyway the set up worked & we got some great video! I made a new file ready while it was recording so when the file reached 2gb I just needed to press one button to start the next file. The funny thing is all the TV coverage of the race was canceled due to the poor misty weather! We had the camera faced forward towards the road & crowds so we have nice clear (smooth liveCD) images of just about everyone of the 1000s of spectators!
I will get some pictures up soon & upload a little demo video that you can use if you like. Its incredibly cool video but a big shame the weather was so poor (dark gray mist).
One nice thing with the mist is that the frame rate stayed high !
Here are some frame grabs from the finish line.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.