Search options (Page 80 of 133)

That is what I meant by

I was thinking the following:
Player screen:
- keeping the tools bar and the key image panel (the key image panel can be collapsed manually already)
- condensing the other controls on a single line. The playback buttons going right to the slow motion control, then the navigation bar, then the save buttons.

Capture screen:
- keeping the tools bar and recently recorded files panel. (the panel can be collapsed manually)
- condensing the rest on a single line. The next image and next video boxes going right to the delay control.

The advantage of this is it keeps the screens entirely functional while improving screen estate a lot. Seems like a good compromise.
However it might be easier (coding wise) to go with just the image. So feedback is important here

Bumping an old topic to add some info

- Currently the player is mostly single threaded. There is a second thread but just used for the timing ticks. Decoding and rendering both happen on the main thread (This can explain poor performances with HD videos).

- The file explorer loads thumbnails in a background thread.

- When you see a progress bar, it's generally indicating a task running in a background thread. (saving to file, applying image filters, loading image cache)

- In the capture screen the main thread is used for rendering. The actual grabbing from the device runs in a second thread.
Until recently the recording happened on the main thread as well. This caused the timing issue reported. (recorded video playing too fast).
This should be fixed in the next version as the recording happen in its own thread now.

There is plan for asynchronous decoding (A decoding thread would fill a queue and the main thread would consume it). We had discussed this with Phalanger some time ago, and I would like to try to address this this summer. (Either this or creating a good framework for generalized "trackibility" of the drawings)

In fact I'm considering a release in the next few days because there have been some wide internal changes and I would like to have them more thoroughly tested as soon as possible.

edit: new version is online.

It has to do with the encoding of the video.

Some codecs encode each frame independently, others mangle data from several frames to gain on the compression ratio.
For the latter case, the encoding is generally optimized for "forward decoding". Going back one frame means we actually have to go back to the previous key frame (last full frame), then decode back all the way to the target frame.

MTS uses AVCHD which uses this technique and other more complicated patterns (which sometimes confuses Kinovea to the point where the frames are not in order). Also, since this is HD video and decoding each frame takes some time, the issue is more visible than for lower resolution samples even if using similar encoding pattern.

If you are analyzing very short clips, you may constrain the working zone to 3 seconds or less, to trigger the "caching" of frames to memory.
Transcoding to an "intra-frame" only codec may also fix the issue. (MJPEG is such a codec but there are others)

edit: Oh, you mean it doesn't work at all ? Hum, yes, that might be one instance where the decoding process is confused. I'll have to dig deeper into this matter to see what is going on…
If you have the logs on Debug mode activated, you can see what it is trying to do and what is really happening.

On the topic of tools, several ideas could be mixed together in a bigger scheme:

- Stick figure tool to map body position during performance. (how many joints ? proportions ?)
- Lower-body only posture (to represent knee bending, hips level, used in podiatrics for instance)
- Full body posture
- Profile line (used during squat jump and other tests analysis for example)
- Drawing a stick figure to represent the body during an exercise or stretching position.

All these tools would share a lot of source code. They might all be represented by :
- a set of joints
- a set of segments linking some joints together.
- Constraints on segments ? Hierarchy ? (To be defined)

The idea would be to design a tool family that would work in a generic way for this type of joints+segments tools.
(instead of creating X static tools)

Specs:
- The set of joints, segments, constraints would be described in a text file.
- The user would be able to create his own files to expand his toolbox.
- Everything else like rendering and manipulation of the joints would be handled in a generic way.
- Some all-purpose instances would be bundled by default, like the ones cited above.

Input very welcome on:

- An already existing file format created for this purpose. (otherwise it will be XML with "as simple as possible" syntax)
Todo: look into stick figure animation software, software to design exercises or yoga positions, etc.

- Imagine yourself using such a tool. What do you expect when you drag a joint around ? What type of constraints ?

Thanks

edit: Checking on stick figure animation software. Very interesting usability.