Search options (Page 102 of 129)

Yes, it would mean programming a specific web player.
Technically it may be an interesting challenge, but I'm not sure about the added value: if you want to share a video with the drawings overlaid, you can save it in this way and upload it as is. If you want to share a bare video with the drawings as a separate file so the viewers can recombine them later, you can also easily do so (although the combination will have to happen in Kinovea).

Still, it would be interesting in regard to the key images positions and comments, things that are lost when simply saving with drawings painted on. But the web player would have to be capable of handling them.
I am going to focus on the desktop application, but if anyone wants to leverage the XML data in any way for web oriented usage, you're welcome. The format is hopefully relatively straightforward.

Hi,
The current way to do this is as follow:
in the first video, do File > Save and choose "Save only the key images data." This will save your 4 drawings to a .kva file.
Then click on the second video to select it, and do File > Load key images data and open the file you just saved.

It has been suggested to have more "simultaneous effect" actions when working with two screens. (for exemple, the speed sliders are now locked together).
So maybe a special mode where any additions and modifications to drawings on one screen would be propagated to the other would be nice. That'd make this use case easier.

Ok. This may be related to the flickering issue reported by TeamTermin. I also experienced that with Windows 7 on a friend's machine…

Yes, this should be fixed in the next version. Thanks.

I think it is important that the capture works well for a single screen first

Currently we can't find out if the captured stream has rectangular pixels. (image format 4:3, 16:9, if different than the resolution).
Can you try to determine if this location problem is linked to this issue ?
Is it the same with other drawings or just the observational refs ?

It is available in the latest experimental version (0.8.9)

Yes, it was designed like that
Basically, it looks for a number in the entered file name and increase that number to suggest the next file name. Hopefully you just have to hit rec/stop.
For exemple, if you set filename to "attempt 5", the next will be created as "attempt 6". (You can still manually change it if needed).
- If several numbers are found, only the last one is incremented.
- If none are found, a "- 2" is appended ("attempt" -> "attempt - 2" -> "attempt - 3", etc.).
Same applies for the image snapshot file.

Hi,
"Error -2010" : Which player is giving this error ? Is it also Windows Media Player ?

Here is how various players should behave with videos created in Kinovea :

- VLC : should work out of the box.
- SMPlayer : should work out of the box.
- Media Player Classic : You will need to install a codec for MPEG4 ASP (for example Xvid).
- Windows Media Player :
1. You will need to install a codec for MPEG4 ASP (for example Xvid).
2. If using MKV container, you will also need to install the appropriate demuxer (for exemple, Haali Media Splitter)

It is also possible that the save failed and the file is corrupted somehow. Do you get the same error over and from different attempts, even with the codec installed or in VLC or SMPlayer ?
Can the file be read back in Kinovea ?

Thanks.
Regarding the flickering, I think I have an idea of where that could come from. The frame buffer is very basic right now and needs to be made more robust.

Ah yes.
Probably it should be constantly monitoring the connection, raise an indicator when it's down, and simply resume frame grabbing when it's back up.
I would assume the connection cut would stop any ongoing recording operation…

Yeah, currently the file will default to .mkv, and to change to .avi or .mp4 you have to explicitely add the extension in the file name edit box.
I agree, that is not obvious at all, and it's impossible to know which formats are actually supported.

I'll add a combo box to pick output container format.
However the actual codec used and parameters, which is ultimately what impacts file size and image quality, will still be non-modifiable for a while. Because that will involve a more complex interaction schema on user interface and on encoding library ends. I'm not sure I want to deal with the complexities of encoding / transcoding right now.

So by default Kinovea will output large files with (hopefully) good image quality (under the MPEG4-ASP codec). And the file size reduction will be left as a post process step for the user.
(By the way, there's a new kid in town for easy video conversion - Miro Converter - free and open source).

Je remonte le topic pour indiquer que cette fonction est dispo à partir de la version 0.8.9