Search options (Page 53 of 129)

This camera module is quite interesting : ELP-USBFHD01M from Ailipu Technology. (You may find it on your favorite Chinese reseller at about 35€ + shipping).

It is based on an Omnivision OV2710 sensor which does 1920x1080@30fps, 1280x720@60fps and 640x480@120fps.
They apparently implemented MJPEG compression on all of these sensor outputs and the camera is UVC compliant.
It comes with various M12 lenses options so the lens might be interchangeable.
It is not clear whether it has manual exposure or not. I just ordered some to find out if it delivers on the specs.

I have also yet to find a 60fps USB 2.0 camera with more than 640x480 resolution.
- The PS3Eye does 640x480 @ 75fps.
- The logitech C910 is apparently also capable of 640x480 @ 60 fps. The option was removed in the C920 for some reason.
- The C920-c (business version?) is reported by some sources as 960x720 @ 60 fps but I can't verify.
- I don't know about the C930 or C615.
- There is also a Chinese clone Gucee that claims 640x480 @ 60 fps.

1080p @ 60 fps is nowhere to be found…

It shouldn't be a bandwidth problem for the recent Logitech cameras like the C920 because unlike the PS3Eye and other cameras they have on-board MJPEG and H.264 compression. Maybe the compression chip is not fast enough to keep up, or they just didn't bother with it as it's less likely to interest their primary market.

The next options are USB 3.0 and GigE cameras, but the price jump is painful. Also the stream is raw so now it's the PC-side and the hard-drive that have to cope with compression and writing speed.

Opening files is different from live capture. Opening files should be no problem, the SD card is seen as a storage device.

I have no direct experience with the cable you mention and haven't passed the page through translation, however note that a cable for FPV is bound to be analog (to limit latency) and will connect to a radio transmitter rather than a PC.

Other video out options that I know of on the GoPro are the small preview stream over WiFi (not supported in Kinovea) and the HDMI out which needs an additional dedicated capture hardware (of which I do not know if they are well supported in Kinovea or not).

First of all I'm very sorry for the lost file. Let's get to the bottom of this so that doesn't happen again.

I'll try to summarize my understanding of the issues, please correct me if I'm wrong.

1. Your workflow is to record video pairs with two Sony DSC-H20 using the internal memory cards. Then you transfer the files manually to the computer. (No live capture).
2. You record a single master video for each camera.
3. For each camera master video, you then create several sub sequences. You do this using Kinovea, setting a working zone and saving it.

Issue 1: When reopening a pair of sub-sequences, the endpoint and duration do not match, although the original working zones matched.

4. For each pair of sub-sequence, you open the files in Kinovea, create a new working zone to fix the endpoint from issue 1.
5. You save the fixed-up sub-sequences again.

Issue 2: When saving one of the video, the other video file becomes corrupted.
Issue 3: QuickTime cannot open any video after it has passed through Kinovea saving.

Please correct any misunderstanding.

Let's also name things:
1. Creation of master files A and B in the cameras.
2. Creation of files A1, A2, …, A12, and B1, B2, …, B12 in Kinovea.
3. Creation of files A1fix, A2fix, etc. and B1fix, B2fix, etc. in Kinovea.

The major issue is #2, file corruption.
There is one critical bug that can cause this, it happens when you overwrite an open file. For example, if you open A12 and B12, fix A12 endpoint, then in the Save File dialog you either save it back to A12 or B12. Please create a backup of your files before attempting a reproduction of the issue.

I'll add the necessary check to prevent this failure.

edit: analysing the log, I think it is indeed what happened:

1673000 - DEBUG - [Main] - VideoReaderFFMpeg - [File] - Filename : Part11-030-Oil.MP4
...
1683468 - DEBUG - [Main] - VideoReaderFFMpeg - [File] - Filename : Part11-462-H2O.MP4
...
1802000 - DEBUG - [Saving] - FrameServerPlayer - Saving selection [1001]->[225225] to: Part11-030-Oil.MP4
...
1823468 - DEBUG - [Saving] - FrameServerPlayer - Saving selection [1001]->[238238] to: Part11-462-H2O.MP4

Ok, in order to understand the origin of the issue, please test with SnapshotMaker from AForge.NET sample applications (third one).
- Can you enumerate the video resolutions?
- Can you connect the camera?

Thanks

The primary target of the C920 being video call, web casting and the like, the "infinity" focus is quite short (a few meters). When used in the field, we'll usually want to focus farther to get the clearest images possible. 
Check out the "Hubble-fix" from wxforums.net, the result is quite striking!

Thanks for the sample!
I reproduce the problem right away. Unfortunately at the moment I cannot fix it.

It is a unusual file in the sense that it actually has a variable framerate. Basically inside a video file, in addition to the global framerate, each individual frame has a timestamp. Here the video framerate is set to be 4fps, for 5526 frames (23 minutes). What Kinovea does when asked for the next frame is: 1. decode one frame and display it, 2. check the actual frame timestamp, 3. update the frame position in the timeline. This approach works to correct small variations or non integer frame intervals.

It doesn't work with this kind of videos because there aren't really 5526 individual frames. It might be an encoder optimized for screen capture. When the image doesn't change, no frame is saved in the video at all. Whenever the screen does change though, a frame is stored with the proper timestamp. Thus the sequence of timestamps is highly non linear and depends on the content dynamics. But when Kinovea reads the file back, basically being a constant framerate player, it jumps from frame to frame and eats the time gaps in between, giving a much accelerated result.