Feedback Features
From PiTiViWiKi
Add feature requests here, comment on existing features, ... Once a feature is clearly defined, a bug entry on Bugzilla will be created.
Contents |
Features not implemented but recommended
Frame by frame
A frame by frame mode allowing users to flick through a source video /final project video on a frame by frame basis. Primarily for editing concerns as the timeline is only ideal for second-by-second editing and in most cases, 3 or 4 pixels on the scale is representing 24+ frames, which make it impossible to edit out bits which do not fall on a whole second /the odd frame the scale will let you select.
I'm sure this feature was to be implemented, but i saw no buttons ^^
- bilboed : frame by frame is tricky. Framerate up/down scaling is only done when rendering or when going through effects that need common framerates. If you have a simple timeline with two sources, one having 25fps and the other 30fps, then frame-by-frame has to be every 1/25s during the first source, and every 1/30s during the second source. There still isn't a convenient way in GStreamer to be able to do seeking at the frame level, so it has to be done using time. Maybe an intermediate solution would be to seek forward/backward by 1/<project fps> seconds.
- Filed on bugzilla : http://bugzilla.gnome.org/show_bug.cgi?id=353857
- dotsony : submitted a patch for this to bugzilla
Additional player buttons
- Playback with video filters enabled /disabled (only the filters assigned to the timeline)
- Play back with audio filters...
- Double screen /split screen mode. (show original video /filters side by side)
- Test filters: test filters on the project or source videos before having to add it to the timeline. if "playback with video filters" is enabled, then any filter assigned to the timeline /source are also rendered.
- Jog/shuttle: Advanced navigation features that allows user to quickly locate very precise edit points in pipelines. Ideally these features would be always accessible via an external control interface (called a "jog/shuttle wheel" on professional setups), but since most users won't have this it can be approximated with the mouse. For both of these modes, the inital horizontal position of the mouse is saved and continuously compared against it's current position. A scale factor should be used to keep the rate of seek appropriate for the current level of timeline magnification. Also, if the playback head moves beyond the edge of what is visible in the timeline, the scroll position of the timeline should be adjusted to keep the playback head in view (a feature conspicuously absent from some major commercial products).
- Jog mode
- Speed of playback becomes framerate * jog_scale_factor * (current_mous_pos - initial_mouse_pos)
- feedback in form of slider that moves with mouse coordinate
- should have a click-to-activate, click-to-deactivate semantics so that user can avoid holding down mouse button (tiring during long seeks)
- should have a small "deadband" to make stopping easier
- Shuttle mode
- position of playback head becomes initial_head_pos + shuttle_scale_factor * (current_mouse_pos - initial_pos)
- feedback comes from motion of playback head
- alternatively activated through mouse scroll wheel
- only active while mouse button is depressed, as user will quickly run out of space
- Jog mode
Source video edit
A new window that opens up or simply a new timeline allowing users to edit a source clip. This is ideal for slicing and dicing source clips before adding them to the project's timeline as it will be a much cleaner view :) - source should be updated with an additional clip (see below). If this will open up in the timeline then something, such as a button is needed to switch back to the project timeline.
This can also lead onto other features such as a source video having several edited versions such as clips with or without advertising, credits etc. The best way to implement (in my opinion) is to have the original source clip in the sources list have a drop down arrow to open up alternative edits. If PiTiVi offers a means to save these individual sources with their edited drop down version, this would make a great feature for people who have to constantly use the same clip over and over again with various variations (for example, an intro movie /in 3 colours?)
So basically, they can load "intro movie.source" into their source list which in itself, has 3 video files; a red, green and blue variation.
- bilboed : bug item : http://bugzilla.gnome.org/show_bug.cgi?id=353864
Features not implemented but of low priority
Save project before "record"
see: #The record button /project video saving
Multiple project settings
To be able to set up different pre-configured (custom) settings similar to "DVD PAL" in the video output box but user defined and user named. This should be for each smaller section (such as the video output section) and for the entire selection.
Multiple source importing
A feature lacked by most programs. Users probably want to import several clips or even entire folders.
- bilboed : you can already do this partially. Just drag several files into the source list. Behaviour for (sub)folders still needs to be implemented : http://bugzilla.gnome.org/show_bug.cgi?id=352400
- lukus001: I was thinking more on the lines of: File > import sources and being able to click several files in one session instead of repeated sessions. However I didn't know about the drag and drop functionality with the main window *must make sure to document in manual* :)
- Bugzilla : http://bugzilla.gnome.org/show_bug.cgi?id=353861
Confusing features
The record button /project video saving
A save video option under File is probably more logical and easier for new users to understand. As it stands, users need to click on the drop down box, select the Project: [Name] option to even be able to record, which again is rather confusing.
- bilboed : bug item : http://bugzilla.gnome.org/show_bug.cgi?id=352402
Audio /video layers
At the moment we have an audio /video track but how will PiTiVi manage audio in video? If it's placed in the audio track it may get confusing to manage being seporated from the video. The video and audio track section should be treated as folders, Video and audio should go in "layers" on a two tier basis (video on top, audio below in the same layer). Post if you need an image to illustrate :)
- bilboed : Audio should be in a separate layer from the Video. If you add an video file with audio, the audio and video parts are added in separate layers BUT they are "attached", meaning that any transformation to any one of them (like cutting, changing the start/stop, applying a transition) is applied to the "attached" version. In the code, I think it's currently called the 'brother'. This is needed to allow maximum flexibility in the editing process.
Incomplete features
Additional player buttons
Player does not have all play back options functional (skip to begining /end, Fast forward /rewind). Additional buttons proposed: see #Additional player buttons
- bilboed : bug item : http://bugzilla.gnome.org/show_bug.cgi?id=353863
Threaded background rendering of effects
When filters/effects are applied to timeline objects, PiTiVi could start background threads to render those effects, allowing the user to continue working on the timeline.
- bilboed : currently filters are applied in real-time. We still don't have any effect heavy enough to require pre-rendering.
Batch Importing
Importing from a tape source should preserve the original timecode so that the stream can be re-captured. This would be useful for, say, importing at low resolution for editing, then recapturing at high resolution to produce the master. It's sortof like a digital "work print"
Low-quality preview mode
The resolution / quality of preview transitions should be much lower than the one used to generate the output of the movie.
- bilboed : currently preview is done in the native resolution of the videos, scaling is done in hardware. If we have different resolutions of the sources, we could be able to come up with a way to switch to the lower quality sources when working/previewing.
Buggy features
Record /Save
Various settings produce various results. From not saving at all to crashing the client. Due to this fact I think it would be wise if users are forced to save the project before exporting in a certain video format especially whilst PiTiVi is in development.
- bilboed: most of these issues are bugs at the GStreamer plugin level. I was thinking about doing a small script that would test encoding 5s of audio/video in all possible combinations of codecs/container formats supported by GStreamer to quickly figure out those issues.
Project settings reset
File > Project settings resets after reloading the client.
- bilboed : already filed as bug item [Remember configuration] : http://bugzilla.gnome.org/show_bug.cgi?id=335547

