Op zaterdag 24-05-2008 om 13:47 uur [tijdzone -0700], schreef Brandon
Lewis:
First off, sorry for taking so long. This is a very important feature to have.
Stani Michiels wrote:
That having been said, sometimes you have to deal with gstreamer directly, even
in the UI. This is particularly true with seeking, which is what we are working
with here.
No problem, that is what I presumed and why I stated I probably will need
monitoring once I get stuck in gstreamer.
> - I would like to know how far gstreamer is in terms of frame precision
> seeking. Right now it seems gstreamer only supports seeking by time
> rather than by frame. So my first question is if gstreamer could provide
> a frame seeking through its api? If not we need to decide how we do the
> conversion between time in seconds and in frame notation: "00:00:00:00"
> especially when the fps is not an integer value.
> - for the shuttle function we need to be able to rewind or forward the
> clip with variable speeds which can be slower or faster. What is the
> best approach for this? To build it in the underlying pipeline or to
> have the pipeline paused and quickly seek in time?
I've looked into this before. GStreamer is too general purpose to be organized
around the concept of a frame. The best you can do is seek forward or backward
by some multiple of (1/FPS).
That is what I wanted to know basically. But still you have a problem in
that case with fps which are not an integer number even when gstreamer would
be very precise. The question is do we round the fps (let's say 23.9 to 24)
or do we keep the fraction (23.9) which could trigger bits of unpredictable
behaviour in the ui? My preference would be to keep the fraction.
Sometimes you'll get a new frame when you do this,
sometimes you won't. It depends to a large degree on the particular codecs with
which you are working. Some codecs support seeking backward better than others.
Most compressed formats do not really update the screen with complete frames,
but rather changes to the previous frames. Some codecs don't support seaking
well at all. Long story short: seeking isn't reliable, but it's the
only way you
can implement your jog/shuttle wheel.
I understand some codecs do not allow frame seeking. Do you have any idea
if they will show a consistent behaviour? (Will they fail in the same way or
will they sometimes succeed, sometimes fail when seeking to a specific
frame.)
FFW or REW means repeatedly seeking by some number of frames either forward or
backward of your current position. Positions sliders and the jog wheel are
easier to implement: you directly set the playback position to the mouse
coordinate or some function thereof.
Yes this should be doable.
For the shuttle feature, you'll need to
probably use an idle loop which seek the pipeline at an appropriate rate/number
of frames.
Can you specify the state of the pipeline? Is it paused or is it playing
with a certain 'speed' filter?
At least in theory. In practice, seeks often fail, and the design
will need to take this into account. If the media format doesn't support
seeking, for example, the jog/shuttle controls shouldn't be sensitive. Perhaps
failed seeks should trigger that as well.
If we have a white (or black list) of codecs we could configure this
indeed. However it would be nice if the automatic disabling of the shuttle
can be vetoed by a preference setting.
This is somewhat off-topic, but it's an important one nonetheless. When a seek
fails in pitivi, the user gets an obtrusive popup telling them that something
esoteric went wrong. That's poor UI design. Seek errors are so common that we
should have a specific means of handling this. Perhaps a "seek-failed"
thumbnail
that would propagate to the sink the pipeline, or a less obtrusive notification
could alert the user. This is especially likely to happen with poorly-supported
media formats or poorly encoded formats like video taken from certain digital
cameras.
That's indeed a good idea. For sure we can find a more suitable way to give
this feedback.
Better still, the moment the suspect file is imported, we should warn the user
that the media format they are using isn't well supported and offer them some
choices: 1) ignore 2) install alternate plugins 3) transcode media to a
better-supported format. In general, I think the user should always have the
option to transcode any source "in-place": i.e. transcode the source
and replace
all timeline instances of the source with the transcoded version. We should
suggest well-supported default formats like MJPEG, but of course,
allow the user
to transcode "in-place" to whatever format they wish.
> 2. GUI
> - I have been reading about creating widgets with cairo in gtk, so it
> should be possible to write a jog control.
> - I was at the Libre Graphics conference to present Phatch
> (http://photobatch.stani.be). I've talked there to some Tango developers
> about the lack of appropriate icons for video editing in current icon
> themes instead of the currently used music player icons. They seemed
> interested. So if we have a clear idea of which icons we need, we can
> try to contact them. In the meantime I have designed some svg icons for
> frame control.
> - Will the frame precision controls be shown by default or only in
> advanced mode?
Before you implement anything, show your sketches to video
professionals who use
NLE editors every day.
Well I am a professional (video) artist and I do quite a lot of video
editing myself. My videos have been shown at international festivals. I also
know some people who do video editing for a living. I have a master in
architectural science and visual arts, so I am not a programmer from my
education. (I just happen to fall in love with python, for which I wrote my
own editor to work with Blender.) As a strong supporter of free software, I
am looking forward to the day that I could use it for video editing. But
Pitivi still has a long way to go. When I saw there were no plans for frame
seeking I decided to step up and offer to implement it. This is at least
another very small step forward, but it would allow me at least to use
Pitivi for some simple tasks. I only develop software which I need and use
myself.
One danger is that the metaphor might be too literal. You
have to balance the use of metaphor with the usability constraints of keyboards
and mice. This basically means that while it's clear what your widgets do, they
could be frustratingly difficult to use, and as a programmer I am not qualified
to make that assessment (I use Vim for god's sake). If you don't know any video
professionals, I certainly do, I and I plan to show them your sketches in the
near future.
Well my sketch is already online on the pitivi wiki:
http://www.pitivi.org/wiki/FrameSeekingSeeking
I tried to keep it compact, well-layouted and familiar for people who use
professional video editing software. The controls shown there will just work
like they do in any other video software that provides them. That said, I'm
all open for collaboration and feedback so please show it to the
professionals you know, so I can start working on it sooner than later.
As for the visibility of the precision controls, I think they should be
ubiquitous. A slider is simply not a good means of finding an edit point when
the video is more than a few seconds long. Jog/Shuttle might take
users a bit of
practice to learn, but it's a more usable control. No amount of practice will
allow a user to find a specific frame in an hour-long clip with a horizontal
slider. There simply isn't enough precision in a horizontal slider that is at
most a couple thousand pixels wide and at worst a few dozen pixels
wide. I think
jog/shuttle controls are more respectful to the user: we're not treating them
like children when we give them industrial tools. This isn't commercial
software, and there's no advantage to using a deliberately crippled
interface if
we can do better.
I am glad to hear that. I feel the same. I was just prudent with it as I
saw an earlier discussion on multiple tracks in pitivi where it was stated
that would be too advanced for pitivi. This gave me the impression pitivi
prefered to have a really simplified 'grandma' interface.
(IMHO multiple tracks are a must for even not so serious video-editing, so
hard-wiring pitivi to one track would be a big mistake. But that is another
discussion for later. Let's first try to implement the gsoc proposals and
the frame seeking.)
The real solution is to come up with a combined control that
has elements of all three: slider for making large jumps, shuttle scanning
through clips, and jog for locating specific frames.
I am a bit confused here. Do you mean one control for these three purposes?
I never saw that in any video editing software. To be honest, that looks
quite unrealistic. But maybe you have a proposal or a sketch ready. Or I
just misunderstood...
Stani
|