GitLab

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...

Pause can be toggled until every single ClipWorkflow of every single TrackWorkflow has been paused.

This reverts commit c277adec.

This reverts commit e7b6d21a.

Performance are really improved, ie previewing is as fast as watching a video in VLC

Removed tiny debug

It just lacks RenderPreviewWidget to query only one frame at a time.

(coming soon :p )