1,336

(4 replies, posted in Français)

Oui il peut y avoir des soucis avec les fichiers encodés en H.264 (c'est le cas des fichiers .MTS) mais normalement ils sont supportés.
À l'occasion, ça m'intéresse quand même de savoir si le problème du chrono négatif est toujours là dans les versions plus récentes smile

edit: j'ai reproduit le souci avec la dernière version également; sur des fichiers .m2ts.
Le curseur de navigation fait également des allers retours pendant la lecture hmm

1,337

(4 replies, posted in Français)

Hmm, étrange.
Si c'est sur la version 0.8.7 ça vaudrait le coup d'essayer avec la version expérimentale car l'identification de la position des images a été légèrement modifiée.
Une image donnée pouvait être associée à la mauvaise position (à quelques images près) ce qui aurait pu donner ce genre de bug.
Si c'est déjà sur la version 0.8.13 (ou autre à partir de 0.8.8), alors il faudra investiguer plus loin.

1,338

(16 replies, posted in Cameras and hardware)

For the framerate it depends on the camera. Sometimes it is set and fixed at server side, and we just retrieve whatever the server sends. Other times, you can specify parameters in the URL.

For example for AXIS network cameras, here is the list of possible parameters.

The final URL might look like this:

http://<CameraIP>/axis-cgi/mjpg/video.cgi?resolution=640x480&compression=10&color=0&text=0

This will really depend on the camera API and capabilities though. The camera manual should cover the details.

I'd assume little difference in term of image quality between JPEG and MJPEG streams, as MJPEG is just a series of JPEG-compressed image inside a container (there is no temporal compression as in most other video encoding methods)
Some (most ?) cameras might only support one of the two stream type.

1,339

(16 replies, posted in Cameras and hardware)

Well, hopefully none of this will be necessary as network cameras should be natively supported in the coming versions. At least those exporting MJPEG or JPEG streams.
(With many thanks to the AForge.NET framework, already used in Kinovea for Directshow devices and image filters)

I tried to keep the workflow unchanged for users using classic capture devices.
The network camera will be seen as another device in the device list that you will have to select, and then change the parameters.

Here are some screenshots of the updated interface :

http://www.kinovea.org/screencaps/0.8.x/devicenetwork.png

Then when you reopen the source configuration you may change the actual source. (here, receiving WebcamXP JPEG stream from another PC on the local network)
http://www.kinovea.org/screencaps/0.8.x/devicenetworkconfig.png

The most recently used network camera will be automatically tried.
The URL list will also keep the last 5 addresses that succeeded, for quick jump.
The network camera alias will not use the same mechanics of disconnection monitoring. If there's nothing coming from the other side, it will just stay black. (But as soon as the source is live again, it is displayed.)

This also makes for a cheap camera split : Stream the source (e.g using WebcamXP), then open two capture screens in Kinovea both connected on the host. Each stream gets its own buffer so you can play/pause/delay independently.

Of course much testing will be needed wink

1,340

(16 replies, posted in Cameras and hardware)

(Moved posts in a new thread)

1,341

(16 replies, posted in Cameras and hardware)

OK, I hadn't realized that AForge.NET already provides access to JPG / MJPEG streams of IP cameras through another API smile
I was able to serve the webcam with WebcamXP and then reconnect to it with AForge as a JPG stream on http://localhost:8080/cam_1.jpg with very good frame rate.
Also tested some open network camera streaming from Internet.

It works well, now what's needed is a way to integrate this in the existing code and user interface, and more testing.

1,342

(16 replies, posted in Cameras and hardware)

jon wrote:

Is there anyway of accessing this "config" dialog in Kinovea? It would allow image adjustment of a webcam as well as more advanced configuration of cameras (e.g. IP cameras).

Ah, thanks for the heads up about this internal configuration page. It'll be covered for next version.

jon wrote:
joan wrote:

Currently I'm trying to do the opposite : spoofing an IP camera using an USB webcam to see how the program reacts to it…

Any luck so far? Actually, I've been trying to do this myself too. The closest thing to broadcasting a webcam was with Webcam XP. You've probably looked at this too but it was the best software i could find to stream a webcam feed through a LAN.

Yes I had tried with Webcam XP, and I could see the webcam from across the network. However I don't know what to do from there. I will probably need the other way around now, IP to Directshow, but I'm not sure how the Directshow driver is supposed to know about the source…

Hi,
I tried to progress on this one, but I'm afraid there nothing I can do at this point.
Copying what I wrote in the bug tracker. If any one has other ideas…

First issue : file reports negative duration.
Due to this we were having the end of selection before the start of selection and were stuck on frame 1.
The duration might be computed using the super seeking trick (seeking to 10 hours forward in the future to find the last P-frame)
(This gives me 4.72s for your file)

Second issue : backward seek errors out.
Due to this, the super seeking technique is not usable after all, because we can't reset to start of file after we have used it.

Assigning an arbitrary duration (ex: 15 seconds) allow the file to be read, but only once.
Conclusion: as far as I can see, this cannot be fixed at Kinovea's level. The duration must be properly stored in the file or ffmpeg to support this type of files.

---
VideoFile - [Container] - Duration (s): -9223372036854,78

VideoFile - Seeking to [0]
VideoFile - Error during seek: -1

Slightly pimped up the angle tool visual and added invert menu.
http://www.kinovea.org/screencaps/0.8.x/angle0.8.14c.png

Hmm, maybe the grabbing area should be expanded a little.

Regarding the angle, there is only one tool, you have to revert it yourself to get the other angle.
Maybe this could be exposed via the right click menu to ease things up though…
http://img863.imageshack.us/img863/7431/angles.png

Consolidating:

14 - Make the last recorded clip automatically appear in the playback screen as soon as the stop-button is pushed (+ automated speed setting).
15 - Shortcuts.
16 - Rearrange "recorded video" toolbar from freshest to oldest.
17 - Display thumbnail for saved images too. (?)

Comments
14 : will probably go straight to the "Most probably not in this version" category. I don't want to delve into managing these "Capture then Playback" scenarios right now because I don't have a clear picture of how and when this is used.
For future reference, please open a new thread for "Capture + Playback automated scenarios" and describe the perimeter of the feature.

16 : Duh ! Why didn't I think of that tongue

About 9 - The ability to hide / show the "configuration" mini panel.
I am referring to the existing feature allowing one to collapse the 3 bottom lines of the capture screen into one (by clicking on the word "Configuration" for example).

I think the set of shortcuts for the playback screen could be used for similar functions for the capture screen :
- Space bar => start/pause frame grabbing.
- Esc => pause grabbing.
- Left/Right arrow => move delay slider left or right. (only if frame grabbing is paused or any time ?)
- home => reset to 0s delay.
- end => go to maximum delay.

Could be interesting to slightly change the capture screen interface as soon as you hit pause, and make it go left to right instead, like a mini player. In that case the navigation shortcuts would be reverted… sad

What is a sensible shortcut for "start/stop recording" ? We don't want it to be hit inadvertedly. Maybe CTRL+Return ?

1,348

(2 replies, posted in Bug reports)

If I recall correctly this happens for systems with .NET 4.0 installed but not .NET 2.0 or 3.5.
.NET 4.0 is a completely different beast from the previous one and programs will not necessarily be compatible.

Regarding capture, please check this topic : Capture - How should it work ? for a list of intended addition shortly. Add what you think is missing.
The scenario you describe about naming should be addressed with point 3.

1,350

(8 replies, posted in Bug reports)

songtitle wrote:

Open these AVI files with Kinovea for analysis.
Save Kinovea 8.13 files as MP4 (I can't read these codec 20 files in Quicktime and other programs)
Convert saved Kinovea MP4s to AVI MJPEG (readable by QT, Win Media Player, youtube, etc.)

The last step of conversion should not be necessary…
To read the files exported by Kinovea in other programs you may need to download the Xvid codec or the "FFDShow tryouts" codec, or use VLC. YouTube should accept them right away without conversion.