After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 629131 - Ability to play back a timeline region (without changing the playhead position)
Ability to play back a timeline region (without changing the playhead position)
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: Timeline
0.13.4
Other Linux
: Normal enhancement
: 0.91
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on: 608682
Blocks:
 
 
Reported: 2010-09-09 04:01 UTC by james
Modified: 2012-04-05 20:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description james 2010-09-09 04:01:29 UTC
I would like to see slow play, as well as possibly a few second "test play from/to this point"... which does not reset the playhead marker, this would help in selecting the best frame to start/end a clip on when editing in the presence of audio (This would really need to be in conjunction with single frame steps which I understand are already planned).

Also, possibly the ability to enter the exact time index to set the playhead marker to manually.
Comment 1 Jean-François Fortin Tam 2010-09-11 00:28:44 UTC
Slow play: not sure, make an enhancement request.

Play from point A to point B without resetting the playhead: that's basically being able to play a "loop" by selecting a region of the timeline. This would depend on being able to create regions (so this depends on bug #608682). Renaming this bug report to reflect that.

Exact time index: that's bug #629327.
Comment 2 james 2010-09-11 01:32:30 UTC
> Slow play: not sure, make an enhancement request.

this is an enhancement request.

> Play from point A to point B without resetting the playhead:

I don't agree with your new title or the A-B/loop description, I don't want to play in a loop, I want to play a sort section either before or after the playhead to confirm that this is the correct place to add a cut, particularly to confirm how the audio in that clip would start or end, as this cannot be seen from a still video frame.
Comment 3 james 2010-09-11 01:34:07 UTC
On the point of the "loop" idea... it might be beneficial to play the last 2 seconds before the playhead or the first 2 seconds after the playhead in a loop while moving the playhead forwards or backwards frame by frame.
Comment 4 Jean-François Fortin Tam 2010-09-11 02:31:43 UTC
>> Slow play: not sure, make an enhancement request.
> this is an enhancement request.

I meant a separate bug report. One feature at a time :)


> I don't want to play in a loop

I wasn't clear enough. There are two modes here, depending on whether or not a "loop" button (or checkbox menu item) would be toggled:
- Limiting playback to the selection and resetting the playhead
- Limiting playback to the selection and looping, then resetting the playhead

Changed the bug title, you should be happier.
See also bug #569980, semi-related to your last paragraph in comment 2.
Comment 5 james 2010-09-11 06:55:24 UTC
The ability to play from point A to point B, either in a loop or otherwise is a perfect description of a capability the software would need in order to achieve this kind of feature.  I was just a little concerned that it speaks at a level below the actual UI feature I am/was proposing.  I guess we're just looking at it from a different angle.
Comment 6 Jean-François Fortin Tam 2012-04-05 20:08:24 UTC
I think that your initial need for seeing the exact frame you're trimming has been addressed by bug 569980. The rest is bug #608682 and bug #629327. If by slow play you meant jog/shuttle, that's bug #572432. And ideally, to do a precise cut based on audio, you want precise waveforms rather than some hack around the playhead. If the workflow in the upcoming 0.16 release doesn't suit you still, please clarify and file a new feature request report because it's getting really confusing otherwise. Thanks!