It was blue sky today so I made a test video with all the equipment 313L through the town of Ieper with a car & laptop. Im still getting visible frame drops every few seconds (with a skip like effect) Does anyone have any fix for this other then using a smaller resolution?
The laptop is a Dell 2ghz P4mobile with 512mb ram with a liveCD
You dump video stream and then view it? Or real video(view in real time)?
May be video system too slow(for real video)? Which video adapter(ATI,Nvidia etc) ?
Which resolution of picture and frame rate?
I dump (record) the video stream. The skipping is visible in the same spots in the raw Mjpeg.avi & also in the lossless YUV version I use to edit the stream as well as in the finished Mpeg4 version. On both the laptop & PC. Does anyone else have skipping? I only have a 2ghz P4 mobile so the video I see while filming is not very smooth at all but good enough to see the quality of the picture.
I still think that the best test is to try 2 computers recording in parallel and see if drops occur at the same time. If yes - problem can be in the camera , if no - PC software is responsible.
What is the bit rate/frame size reported by the streamer(s)? 90% quality is rather high and the bottleneck can be in streaming compressed data out.
I can not easily do this test with two PCs. My editing PC has the wrong type of hard drives & I guess I would need some kind of hub or cable splitter? I shall upload a clip so you can see what the problem is. I do not mind frame drops if they are spread out but these drops come all in one time. Did you have these jumps when making the snakeriver clip at 15fps? That video still makes me have hope ;-)
Are you have skipping full frame or part of frame?
Which parameters of video stream(fps quality picture size etc)?
Im using 90% quality & all frame rates from 15fps to max (22.9fps) 313L set to 48/90mhz. 10fps has no drops that are visible. It looks like it skips almost a whole second at about 5second intervals, when the streamer is set to use all available frames. I will head down the shop in a minute & try a 7200rpm FAT external hard drive. Im recording to the laptop drive which could be only 4200rpm (Ive just been reading about laptop Hdrives!). I have 4 external 7200 rpm drives but they are all NTFS!
Can you try recording video from white surface and from surface with a lot of small items on white(for example, grid) whit 15 to 22 fps?
Are dropping frames from white surface? From grid?
Dropping frames with 50% quality on 22 fps?
The dropped frames seemed to be lower or less noticeable with 50% quality
http://tacx-video.com/testmpg.avi (its 22mb! ) the overall quality is lower then the video I made in the hills a few weeks ago. I think I got a setting wrong or perhaps the focus was not 100% or it was vibration. The colour looked ok but I got these patches of bright green on anything orange ;-) .
Yes, I know about the problem with over-saturation (it shows where it is both too bright and colored) - it is not so easy to fit extra bits in the calculations in 313 - it is too full. But I'll do that when will get a moment.
Quick fix is to use lower saturation when shooting and increase it when you are recoding video anyway.
I did a little more testing this morning & I feel strongly that the problem is caused before the data reaches the streamer. I used a smaller resolution to produce 50fps & then asked the streamer to send 20fps which would be a fairly small file & low data rate for the PC to handle & the skipping is still very visible. The only way to remove the skipping is to lower the information thats hitting the streamer by using higher compression & lowering the quality.
I noticed also that the khutchin streamer uses all the frame rates even if the check box is left blank so you have a slow motion video (with skips). The alexlp streamer seems to work ok.
I hope this helps, if there is a easy solution to this I would like to know about it before I go to Spain as I really want to use this thing above 80% quality if possible.
Regards all Phil
>I noticed also that the khutchin streamer uses all the frame rates even if the check box is left blank
Can you write frame size and last string in monitor page when running my streamer?
Next commands must provide best recording.
Before run mencoder In root console (Ctrl+Alt+F2) type:
# echo 524284 > /proc/sys/net/core/rmem_max
Switch to GUI with Alt+F5
In camera through telnet:
# renice -20 `pidof eth_thread`
# renice 19 `pidof boa`
# echo 524284 > /proc/sys/net/core/wmem_max
# echo 524284 > /proc/sys/net/core/wmem_default
The best way to limit the frame rate is to put the limit in the main page and press "update" button - that will change the rate the sensor will be running. Limiting frame rate in the streamer can case just frame drops.
You can control the number of frames produced by the sensor using "?" link (and refresh it - you can do it even when the streamer is running). Some streamers report percentage of the dropped frames and number of frames sent.
What is the data transfer rate they are showing? That can be a limiting factor, but if your drops last long (not just single frames) it is much more likely that a problem is related to recording on disk - not with the camera. NTFS you are using does not work well with Linux - it is a secret unpublished format.
It is also possible to increase the size of a buffer for the network interface so data will be accumulated while hard drive is serviced.
I use a FAT32 hard drive on the laptop & today I got a new 160gb external FAT32 drive for the PC to test the camera. The results are that the faster PC could make a skip free file at 90% 15fps 48/90mhz where the Dell laptops file (with the camera still powered with the same settings) was full of skips using the same external (but via a the card bus) when using the laptops hard drive the skips were less. Im going to now do a second test just to be sure & then I have to think about making this a good excuse for upgrading ;- ) . There is something with write speed thats causing the problem so I was wrong to think it was the 313. A Laptop with a native USB2 port & a FAT hard drive should solve the problem but a little extra speed should help also.
The problem could be the Laptop:PC has to show a full screen image in Mplayer. This has to eat all the cpu power. I wonder if its possible to watch a smaller image & record the full monty?
I didn't realize that you view the video at the same time, not just recording. Unfortunately we do not have yet such software that will allow you to have some "viewfinder" preview without eating up all your CPU power, but it is definitely possible and we really need it for multi-camera systems. The most computational-hungry part of the JPEG decoding is DCT and it is possible to save time by using abbreviated ones - libjpeg has them but they are not currently used in mplayer. It is also possible to make Mplayer skip frames.
Hi! It's been quite a while since I've seen what's happened with the Elphel cameras, but one of the programs I worked I think might help this problem.
We used 2 Elphel cameras as the 3d (polarized projection) vision system for a test rover (http://www.deathbots.com/gallery/AmboyCrater). I ended up using pbuffers in OpenGL (libjpeg to decompress the images) in order to display synchronized images coming from 2 cameras on the same machine at up to ~40fps without really killing the machine. I was "recording" in the background, but that was really just saving the individual jpeg frames, I wasn't moving it directly into MPEG movie format (this ended up being a REALLY bad idea, but it shows that it handled the ridiculous amount of disk access fine). It also allowed you to change all of the camera settings thru the GUI (there's pictures of this in the above gallery).
Please correct me if I'm wrong, but this sounds somewhat like the solution you might be looking for. The final setup used Carbon and internal OS X calls, but I also got it working on the Qt platform, which ran fine on Windows and Linux for crossplatform situations (and might run fine on Mac now, but that wasn't the case last year).
If you'd like, I can try to put together another version of this package. Unfortunatly I don't actually have the cameras here any more, but I could at least see what I could hack together without them.
I did try without Mplayer but the avi header info was not made again. Thinking about it now this could have been something else I did though . I think that the real problem is like you said earlier with write speed I better try all this out again! forcing Mplayer to show a low frame rate or resolution would be a solution & probably give you a smoother image. It would be hard to film without knowing what the image was like & being able to change the settings when needed.
can you tell - what exactly ave you done, what version of the Live CD that avi file made by mencoder with "ovc copy" did not have the right headers? I know Quicktime doesn't like it (probably just because of the codec name) but VirtualDub that I tried opened it correctly. Can you post such file (provided it was made with 1.3rc4)?
Im looking at the files now from this afternoons testing & I have 3 files that were faulty (from about 30 files made with a big clock & my hand moving up & down) with the latest LiveCD 'rc4 ' using the record to disk check box. One file I marked Landy 22fps at 50% quality & this ended up with a height of 25599pixels & no width! The other file with summery data had the correct size '1280x1024' but no duration (its 72mb in size) & a frame rate of 1000 ? The other file had no summery. The second file that I recorded in town last week does not play in media player but the first one does. I can not see any change as I had left the stream on while making the second avi. All the settings were spot on the same & the file looks to be normal but something about it does not gel with media player. I can open it in virtualdub & vegas though!
I can upload one of them but the smallest is 72mb & the largest 144mb .
I can do some more testing tonight & see if I can record without dropped frames if I start with mplayer & then turn it off
When recording with mencoder I can see two places were things can go wrong.
First - when you start it and it gets the frame size from the stream - this part I fixed (or at least believe I did) myself - when either mplayer or mencoder starts it should write the actual frame size, not 0x0 on the console. Can you watch that and see if the size was read correctly from the stream (just before recording starts) or not?
The second place is what mencoder does when gets <cntrl-C> - it is that moment when it builds the index and the header.
And I have no idea how it does that. Probably we should make a small application just for recording. And it will be definitely possible to restore the broken files - if to forget about the file header, inside it is just a sequence of regular JPEG images with their own headers and no gaps.
I don't think that Mplayer was really helping - it seems as just a luck. Probably the problem is what happens at <cntrl-C>.
It is rather easy to make the program that will take that avi, scan for the JPEG markers and cut it into individual JPEG images (nothing to add - just skip to the starts with 0xff,0xd8 (this sequence of 2 bytes can never happen inside the frame data) and ends with 0xff,0xd9. And everything inbetween and these 4 bytes make a normal JPEG file. So bad videos are not lost.
Hi Kyle this would be great, I'm off on Saturday & I'm supposed to record a route in Spain so any help would be appreciated.
saving just Jpegs would be ideal for me.
Looking at the pictures of your desk I see you have the same mass of cables I have here! After a while you just give up & they start to grow & take over.
Well, I wouldn't get your hopes up about it being done by Saturday, as I'm REALLY busy right with work at the moment, and I havn't touched this code base in a year, so there's gonna be some ramp-up time. Also, since I don't actually have a camera at the moment, I'm going to need to create a camera simulator (i.e. something to shove jpegs over the network in the format and protocol I usually use), which might take a bit more time. However, I'll try to keep everyone up to date on what happens.
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.