X10 Community Forum
🖥️ActiveHome Pro => Plug-ins => iWatchOut/iWitness => Topic started by: MDW on November 10, 2006, 10:57:58 AM
-
Welcome to all AHP users. These forums are my link to sussesfull operations with AHP. Thanks to all in advance. This is my first post, so please be patience. I have made many changes trying to get everything to work, I dont know what is the default anymore. When I record for 1 minute and then play it back, it compress down to 15 secs or so... . (using the installed program or windows media player) I tried changing the compression to different codecs in Video Settings under preferences, with no luck - even to no-compression. Can someone tell me what the default codec is? Are there some settings some where else that I changed that may have caused this? I tried re-installing, remove and installed and can't seem to find my mistake. Also tried searching thru the listed forums but also was unable to locate---(being a newbie with formus might be my problem there) Anyways, It did work at one time, I'm think. It just that I have made so many changes, added and remove modules and macros in the 3 months that I owned the software, I do not know what is default anymore. Thanks Again to all.
-
According to my install of AHP, the default video codec is:
"Cinepak Codec by Radius"
Compression set to 100
KeyFrame set to every 15 frames
and under Configure : Compress to Color is checked.
This may or may not be the default codec for all installs, but it is one of the original Windows codecs, from way back. I do not have any idea what you playback issues are resulting from, but if I get a few minutes, I will replicate your experience and will get back to you.
-
Will make changes and do some testing. Of course having it this way is one way to save disk space. It just makes it harder to exact frames from the file, at least to my knowledge.
Thanks for the idea
-
MDW:
Well, I tried a couple of things and found some more oddities:
1: Tried to record a video of an entire sweep. [takes 120 seconds to complete 1 full sweep] iWitness would only record about 60 seconds of the sweep, no matter what I did. I have about 200Gb free on the hard drive and verified that I did not inadvertently change anything in the video preferences. I also experienced the same issue you had, the video played back @ approx. 2x the recorded speed. Also, I tried recording @ two different resolutions 320x240 and 640x480, and there was no visible difference in the quality of the playback. Neither playback came close to the picture quality displayed in the live feed window.
2: I was unable to change the codec permanently. I could change in the video codec, but it would NOT save when I clicked on Close. If I reopened the Preferences>Video Settings, the codec was back to "Cinepak Codec by Radius". I'm not sure that this is by design, but it should be resolved so we can use some of the newer and faster codecs. ie DivX/MP4
3: The system I am running is a fairly fast system. AMD64 3400+ w/ Nvidia 6100 onboard video, 512M ram and 250Gb HD.
This system normally idles @ 0% under Task Manager, and a PF usage of under 200M. When I start AHP, and open 1 Camera window, my PF usage jumps to 470M, and averages 35% CPU Usage. If I'm recording it runs well over 65% CPU Usage.
As a comparison, I can record fullframe 720x480 live video @ 30fps, on an old AMD Athlon 2600+ w/ 512M, and CPU Usage runs @ <30% and PF Usage is under 300Mb.
Looks like there's considerable work yet to be done regarding the full functionality and optimization of the software.
-
tjdavj:
That sounds like you really put it thru the mill. I got better quality using the mp4, but same results. I manage it to get the settings saved on the codec DivX and got the results I was looking for. It also seemed to record only 1 minute intervals if a "record" went on for over two minutes, size around 2.4 mg each. My system OS is windows media edition, xp pro, fairly beefy machine.
At least I got some of the old confidence back knowing you was able to duplicate the problem and it not a user goof.
I do appreciate the effort you used.
-
MDW:
What format [NTFS or Fat32] is the partition you are saving your video files too? (I seem to recall that there is a maximum file size issue when using FAT32) My partition is NTFS, so I am just checking..
I wonder why I can't get the Codec to save when I close the preferences page. Will work on that..
Glad I could help.
-
tjdavj:
ntfs,
The way I got mine to stick was as soon as I click on the "close" button, saved the file, closed down, opened back up, vefied, closed down again then re-booted this time.
There might have been a setting in the DivX option, but wasn't too sure at what I was looking at.
I get a few AHP crash messages now and then, but at least no blue screens.
-
Thanks, I'll give your process a try. I will let you know if it works.
-
MDW:
First, thanks to you, I now have the DivX 6.1 Codec loaded and operational.
Now some more interesting observations:
Video recording observations: [using DivX 6.1 Codec]
Ok, here's an explaination of terms:
Capture Resolution - pretty obvious
Real record time - The actual real time it recorded.
Playback time - the time it took to playback the captured video.
[It was the same when using the X10 viewer or Media Player]
File size - Size of file written to disk.
Capture Resolution Real record time Playback time File size
640 x 480 ~ 60 sec. 30 sec. 3.09Mb
320 x 240 ~ 60 sec. 45 sec. 4.60Mb
At this point, I'm totally at a loss to explain the results of this test. Theoretically the 320x240 capture file should be approx. half the size of the 640x480 file considering that they are both capturing @ 30fps. Instead I have a lower resolution file that requires half again as much diskspace to record the same length timelapse.
I would appreciate it if someone could run the same tests and post their results, or explain this behaviour.
TIA
-
tjdavj:
I did some testing and basically got same results.
640x480 = 3.7 mb w/ 35 secs of viewing with 1 minute of recording
320x240 = 6.2 mb but with 1 min of viewing with 1 minute of recording
My version of Codec DivX is 5.2.1
VERY Interesting results with 2 different machines and 2 different versions
Changed some of the options in the DivX configuration panel within AHP and the results produced different file sizes but the ratio being the same>
more resultion created samller file vs less resolution creating a bigger file
-
Do you think it's possible that it's actually recording fewer frames per sec. (say 15) when recording @640x480? That would account for the condensed playback speed.
But still, the file size issue really has me stumped. There is NO way the 320x240 files should as big as they are.
I'm going to look for a utility that can count framerate and run the 640x480 file thru it.
Will get back to you.
-
I cant be completely sure that this is what you are seeing.
But many codec's have a target bit rate for streaming video.
That is why the files stay relatively the same size no matter what resolution.
If you set the Codec to 700kbps and record for 1 second the the codec will do its best to keep the file around 700k.
The amount of work the codec has to do is effected by the size of the image and the amount of movement from frame to frame, and of course the codec setup parameters.
If you are trying to encode a large image 640 x 480 and there is a moderate amount of movement and your target bit rate is low. You will more than likely start dropping frames. Dropped frames show up during playback as a sped up video.
Basically the program thinks things are recorded at 30fps and it plays back at 30fps but only 15fps has been saved.
Try increasing the target kbps - click on the target quantizer button on the XviD configuration it will change to target Kbps you will be able to specificy something higher say 1000kbsp.
Getting AHP to save your parameters is a whole other problem. Based on my limited experiance with the video setup interface so far, I can't be completely sure anything I set will take. That is not meant to be a ding at AHP. I know from pratical experiance that getting a program like this to work is extereamly hard. I also know they will have it working fine in the end.
Its still the neatest thing out there.
-
ajleduc: Thanks for the info, but I'm not sure it applies to this issue.
But many codec's have a target bit rate for streaming video.
This isn't streaming video, It's just captured video written to a file.
Also, since we are not using a streaming codec, there are no parameters available that allow us to define or control bitrate.
That is why the files stay relatively the same size no matter what resolution.
But they don't stay the same size! Look at our figures in the previous posts. There is a 50% INCREASE in file size in the 320x240 capture.
Basically the program thinks things are recorded at 30fps and it plays back at 30fps but only 15fps has been saved.
This is the same conclusion I came to when recording @ 640x480.
Getting AHP to save your parameters is a whole other problem. Based on my limited experience with the video setup interface so far, I can't be completely sure anything I set will take. That is not meant to be a ding at AHP. I know from pratical experience that getting a program like this to work is extremely hard. I also know they will have it working fine in the end.
I've done a few video captures from multiple sources, using different software and have never seen this happen before. I will be attempting to capture the X10 camera and VA11A interface using another software package to see if it is the AHP software or possibly the VA11A interface. I will update this thread when I have more info.
While I do agree that AHP works, There's still alot of work to be done, and X10 has never been very good at post release fixes.
Thanks again for the explanation, I just wish it were that simple.
-
After contemplating this for a few hours, I think I have an explanation for the slow recorded framerates @ 640x480.
I actually figured this out a couple of years ago, and promptly forgot about it, but from some former research I did, I think the framerate limitation is a result of using the USB 1.1 interface. If I remember correctly, it looks like the VA10/11A interface is providing both the digitized video for the iWitness display and also provides the captured digitized video data for storage on the hard drive. Due to the limited bandwidth of USB 1.1, it is unable to send both data streams @ 30 fps. Obviously, it prioritizes the iWitness display higher than the recorded data.
At this point, this is the best explanation I can come up with, but I would be very interested in finding out if anyone has a USB 1.1 cam that can both send 640x480 @ 30 fps, and also record 640x480@30 fps at the same time.
I am also checking the design limitations of the chips inside the VA11A, which will either confirm or deny the above assumptions.
-
OK, I just confirmed that the Video Capture VLSI Chip "Sunplus SPCA506A1 has a maximum capture rate of 15-20 fps @640x480.
Here is the link to the spec sheet:
http://mxhaard.free.fr/spca50x/Doc/Sunplus/spca506a/ca506a1v10.pdf
I know that this is not that big of a deal, but it would be nice if the software reflected this information.
This still does not explain why we see drastically larger file sizes when capturing video at lower resolutions, but I'm working on it.
-
What you might be seeing in file size I think has to do with they type of compression. A higher res image would compress more because of more like pixels then a low res image where it can't compress as much. (Just a thought)
I will have to look when I get home but I think theres an option to record with no compression at all? If so that would be a good test to see what file sizes the 2 resolutions create.
-
KDR,
Actually that's a great idea! I'll give it a try too, and we can compare notes.
-
I think I can help with the file sizes.
I made a mistake in my previous post where I indicated streaming video.
What I should have said is constant bit rate.
When ever I see constant bit rate I think streaming.
One of the purposes behind constant bit rate is to guarantee a bit rate for a stream.
--- Anyway ---
Whether you specifically setup it up or not the codec is using constant bit rate in its encoding.
My proof of this is as follows.
640x480 = 3.7 mb w/ 35 secs of viewing with 1 minute of recording
320x240 = 6.2 mb but with 1 min of viewing with 1 minute of recording
6.2mb / 60 seconds = 0.10333333 mb/s
3.7mb / 35 seconds = 0.10571429 mb/s
The numbers are to close to not be significant.
Therefor you are recording at a constant bitrate and the problem is dropped frames.
Further I am guessing the 35 seconds reported is more like 35.8 seconds.
I am assuming the 320x240 number is accurate at 6.2mb.
Back to algebra (sorry!)
6.2mb/60seconds = 3.7mb/x
(6.2mb/60seconds)/3.7mb = 1/x
3.7mb / (6.2mb/60seconds) = x
35.8 = x
As for the reason you are dropping frames that appears to be from a previous post the hardware.
I suspect also the amount of work you are asking the computer to do also plays a roll.
On my computer a 4.3ghz hyperthreaded 1gb ram 160gb sata harddisk bought specifically for video software development.
I am seeing numbers like 40% cpu usage with the display showing.
Upwards to 100% or more (more being when I hit 100% and start sucking down ram) when I turn on recording.
I have just started setting up my system to work with x10 and have a long way to go.
One thing that occurred to me that may be obvious to you ---
I figured I would get a external harddisk put it in the rafters store video to that.
That way if someone ripped me of I would still have the harddisk hidden.
The other night while I was testing I realized I just created a huge bottle neck.
Not only is the external disk slow(er) than my sata drive its USB same USB controller as the VA11A.
da...
newbies do become users but sometimes these things take time.
-
Thanks for the explanation, makes a lot of sense..
On my computer a 4.3ghz hyperthreaded 1gb ram 160gb sata harddisk bought specifically for video software development.
I am seeing numbers like 40% cpu usage with the display showing.
Upwards to 100% or more (more being when I hit 100% and start sucking down ram) when I turn on recording.
Interestingly, I see the about 40% usage when viewing display @640x480, but it goes to about 65% when recording, and I'm using a 2.2Ghz Athlon64 3400+, 512M of ram, 250Gb SATA. As I previously stated, when capturing live video @ 720x480 from my Satellite receiver, using MS Movie Maker and Nvidia VIVO, I typically see around 35% usage. Doesn't make a lot of sense to me.
Not only is the external disk slow(er) than my sata drive its USB same USB controller as the VA11A. da...
Are you saying that it's plugged into the same USB controller as the VA11A, whereas bus speed is dropped to USB 1.1 [11Mbps]?
or that it only supports USB 1.1 [11Mbps]?
newbies do become users but sometimes these things take time.
Hey, if you're not a newbie, you're not learning anything.. LOL
-
Interestingly, I see the about 40% usage when viewing display @640x480, but it goes to about 65% when recording, and I'm using a 2.2Ghz Athlon64 3400+, 512M of ram, 250Gb SATA. As I previously stated, when capturing live video @ 720x480 from my Satellite receiver, using MS Movie Maker and Nvidia VIVO, I typically see around 35% usage. Doesn't make a lot of sense to me.
I haven't done anything to improve the performance of the computer yet as far as x10 is concerned.
To be honest I am that new to x10. I am still just getting through the, O I need this software package, O I need this hardware, O now I need this software package...... I think I have finally got all the pieces to start getting things up and running.
As far as capturing video from the Satellite, is it possible that the compression is being done on the video card in hardware. Where x10 is using a software codec using some of your CPU time?
Are you saying that it's plugged into the same USB controller as the VA11A, whereas bus speed is dropped to USB 1.1 [11Mbps]?
or that it only supports USB 1.1 [11Mbps]?
Yes I plugged it into the same USB controller and dropped it to 11 Mbps.
It supports USB 2.0.
Thats the Da...
-
As far as capturing video from the Satellite, is it possible that the compression is being done on the video card in hardware. Where x10 is using a software codec using some of your CPU time?
You are correct, the nVidia VIVO has a hardware encoder, but so does the VA11A.
here's the link to the spec sheet:
http://mxhaard.free.fr/spca50x/Doc/Sunplus/spca506a/ca506a1v10.pdf
video compression is done "on chip" so as to minimize bandwidth requirements thru the USB interface.
At this point, I'm kinda confused as to how the codec figures into this, since I see very little or no difference when using different codecs in AHP.. The differences can easily be accounted for as I am recording live video. I think I have to use a "canned" video feed as a "standard" to test the various codecs against.
Yes I plugged it into the same USB controller and dropped it to 11 Mbps.
I'm surprised that you don't have more USB controllers on the motherboard, at least a PCI USB card is fairly inexpensive.
-
You are correct, the nVidia VIVO has a hardware encoder, but so does the VA11A.
here's the link to the spec sheet:
http://mxhaard.free.fr/spca50x/Doc/Sunplus/spca506a/ca506a1v10.pdf
video compression is done "on chip" so as to minimize bandwidth requirements thru the USB interface.
At this point, I'm kinda confused as to how the codec figures into this, since I see very little or no difference when using different codecs in AHP.. The differences can easily be accounted for as I am recording live video. I think I have to use a "canned" video feed as a "standard" to test the various codecs against.
YUV420 is some compression but the codec compresses further.
From the TV decoder you are getting 24 bits per pixel
YUV420 compression - for each group of 2x2 pixels it drops 6 bytes of data.
Basically you end up with 12 bits per pixel.
But that still needs to be compressed further.
For example, if you were to take a 640 x 480 video at 30 frames per second, 12 bits per pixel that would be 13 almost 14 mb per minute.
With the codec they get it down much further.
I was thinking your NVIDA card may do codec style compression in the hardware which MS Video Maker is taking advantage of.
I am not totally sure of that though, the more I think about it I am guessing not.
To give you an idea of what can be done, and this does push the limits of the computer.
I have taken the feed from 4 firewire video cameras producing 640 x 480, 30 fps (BW image 8 bits per pixel) at the same time. Converted, Filtered, Analyzed, saved (compressed) the data and displayed the results. The app can run for hours and is still responsive to the user.
I think the real problem is x10 handling of video.
In there defense, in order to get the speed described above we basically said.
We will specify the computer, one similar to mine described in previous post, and we only support 1 operating system XP.
Its a lot easier when you can do that vs trying to support every operating system in the world.
Whats optimal for one OS isn't for the other etc.
But it still comes down to, they are only taking the feed from one camera.
I'm surprised that you don't have more USB controllers on the motherboard, at least a PCI USB card is fairly inexpensive.
I do have more controllers 4 to be exact.
I just plain wasn't thinking.
-
Thanks again for the info, I think further testing with the codecs is the next step.
I think the real problem is x10 handling of video.
I couldn't agree more!!
Also, glad to hear that you don't have to buy any USB cards.