GitLab

StackedBuffer are used now, on the clipworkflow's side.

Pool is now "MemoryPool" and a new pool has been created.
It comes with a StackedBuffer class to release buffer that will be
filled by new clipworkflows

A bit more refactoring for the same price.

Width and heigth are handled from config (but changes are not well
handled, and should lead to crash in some cases)

The call to this method have been removed to, thus probably improving
stability

When loading a clip, media player was launched in play state, then paused, then unpaused.
Not it's just launched in a play state.
Preloading still use this method, as it's not supposed to play before we explicitly ask for it.

When loading a clip, media player was launched in play state, then paused, then unpaused.
Not it's just launched in a play state.
Preloading still use this method, as it's not supposed to play before we explicitly ask for it.

When loading a clip, media player was launched in play state, then paused, then unpaused.
Not it's just launched in a play state.
Preloading still use this method, as it's not supposed to play before we explicitly ask for it.

When loading a clip, media player was launched in play state, then paused, then unpaused.
Not it's just launched in a play state.
Preloading still use this method, as it's not supposed to play before we explicitly ask for it.

This reverts commit bd9b98fa.

Conflicts:

	src/Commands/Commands.hpp

Revert "End of a track is now handled by a signal emitted from the ClipWorkflow, in horder to avoid hangs up"

This reverts commit f2ef00a9.

Conflicts:

	src/Workflow/TrackWorkflow.cpp

End of a track is now handled by a signal emitted from the ClipWorkflow, in horder to avoid hangs up

However, at the moment, the first frame isn't displayed... we need to move the position slider to get one...

IE you can pause the preview, but still change the position, and the render gets updated.

This is really much cleaner than the old versions...