Created attachment 128779 [details]
mockup

Here is a no-bullshit, HIG-compliant mockup for a better render dialog. Comments welcome.

Created attachment 128784 [details]
mockup

Updated mockup, according to feedback from Brandon.

Created attachment 134866 [details]
mockup

New serie of mockups. Serious business.

maybe this transcoder would be a good source of ideas also for settings : http://programmer-art.org/projects/arista-transcoder

Created attachment 136602 [details]
mockup

Hi Jean-François,

I think your mockups are great. Since I opened a duplicate, I'd like to attach my mockup here. In general I like yours a lot better, I just think the filename and destination folder should appear right in the dialogue as seen in my mockup, instead of through a button.

If you think about it, that is the one setting that the user is bound to use under any circunstances. I don't think that extra click makes much sense.

*** Bug 585712 has been marked as a duplicate of this bug. ***

The full implementation of the ideas conveyed in my latest mockup seems to depend on bug #118142

Maybe we could also look at how Transmageddon does it.

http://abock.org/2007/01/06/audio-profile-configuration-for-the-masses may also be of interest, though it's old.

I've looked Jeff's mock-ups and the design is pretty good. Most features can be implemented right now:

- allowing the user to render only a portion of the current project
- separating render and render progress dialogs
- providing a pause control on the render progress dialog
- separating project settings from encoding settings (see below)

 Project settings would only include:
 - resolution
 - frame rate
 - project name
 - project description

 Encoding Settings
 - container format and container-format options
 - audio codec and associated options
 - video codec and associated options

By default, the project renders with the project frame-rate and resolution, but for convenience an easy way to scale the output video provided (preserving aspect ratio).

The biggest issue has to do with encoder- and muxer-settings. In the mock-up, there are encoder-specific controls for "quality" and "rendering method" which are statically defined. This is not going to work for a of reasons:

- sometimes the trade-off between size and quality, and other times between 
  size, rendering speed, and quality
- not all codecs have the same salient properties for controlling quality:
- some codecs have multiple, mutually-exclusive methods for controlling quality
- some codecs have no way of controlling quality.
- there are multiple encoders/decoders for some codecs, which may present 
  different but equivalent property interfaces
- the availability of particular codecs is dependent on the user's gstreamer 
  configuration. PiTiVi can't make any assumptions about which codecs are 
  installed

Basically, this UI design external logic for each supported codec. We need to avoid showing irrelevant controls (such as VBR quality when a constant bitrate is used), while at the same time avoid hiding important options on some codecs that may not be present on others (such as the number of cores to use while rendering H.264). And finally, we need to query the user's registry to make sure we present only those codecs which are actually available.

http://abock.org/2007/01/06/audio-profile-configuration-for-the-masses

The above link briefly discusses one possible implementation using a custom interface description language. It seems like this has been around for a couple of years, but I don't know what's become of it. We might be better off sticking with the simpler "preset" interface that would at least provide valid settings for commonly-used targets (PAL, NTSC, DVD, etc..).

I think I will move forward on the features which can be implemented at present, but we should make some kind of decision about the rest of the interface soon.

There is a problem with that idea. It is not usability-wise correct to have project settings and only be able to export with the same resolution/fps as in the project settings. You see, someone might want to export a 1080p video to youtube, but later, might want to export a DVD file. He/she would have to change BOTH the project and the render settings each time he wants to export differently. On any other video editor in the market, they let you change the resolution/fps/deinterlacing/aspect-ratio both in the project settings, and in the render settings. This is not duplication. It's flexibility. There's a difference.

Finally, what about de-interlacing? Where & when is that decided? If I have DV AVI or HDV m2t or AVCHD mts/m2ts files, which are usually interlaced, how do I decide if I want to edit interlaced or not, or if I want to export interlaced or not? And as importantly, where do I pick that I want interpolation instead of "blend fields" as my de-interlacing algorithm? (there are many de-interlacing algorithms, but these two are must-have on any video app)

Most of what you're saying makes sense, but I'm not sure which idea you're objecting to specifically. If would be more helpful if you could clarify -- perhaps by citing the appropriate comment -- which things you like and don't like.

I was talking about the plan of having a dialog for res/fps (in the project settings), but not having these options again when rendering out. With the current mockups, the project settings force their res/fps to the exporting process, which in my opinion, is not the correct way to do it.

And the second thing I mentioned that should be part of these screens in question, is deinterlacing (blend fields, interpolation, and the best of all, yadif).

In my opinion, setting res/fps should be done ONLY at render, and not be in project settings at all.

Westley, this is wrong. Without setup information the app will have to guess several aspects of the video, e.g. real frame rate (e.g. if it was shot in PF24 and not in real 24p, where it would require real-time pulldown removal as After Effects does it), or aspect ratio (some SD mpeg2 cams don't setup the widescreen flag). More over, when you ask the app to guess these setup aspects, and it gets them wrong, there's going to be a quality hit (e.g. if you shot something in 720p, but the app defaults editing to 1080p, the internal resizing will cost you CPU cycles).

And then there's the aspect of still images. If you start a project with some 12 MP 4:3 or 3:2 pics, how does the editor's preview screen has to behave when you later add an HD video in it? As you can see, there are many reasons to tell the app how to setup itself.

I understand you. PiTiVi should automatically choose the settings from what is in the timeline. E.g. if a NTSC video (480i) was in the timeline, PiTiVi would set it's settings to NTSC. If a PAL video was added (576i), PiTiVi would adjust to the "superior" format, so it would be a hybrid of 576i at 29.97 fps. This is just an idea however, and there would have to be ways of conversion.

As I explained earlier, what do you do when the first file put on the timeline is a still picture, or when you mix and match formats? I usually mix 60p files and 30p and 24p files on the same timeline for the music videos I shoot for some rock artists. 24p holds the band performance shots, 60p are the cuts with the "story" slowed down to 24p, and 30p slowed down to 24p for some intense parts of the story. It's impossible for the editor to know what my primary working fps is, since all the slow-downs are happen during editing, long after I have placed the clips in the timeline.

And while my case is not very common, just for my brother's kid baptism video we mixed and matched 25p PAL SD and 720/30p HD files (a friend of ours had an SD PAL camera, and I had with me a Kodak 720/30p digicam). And that's a "common" case of family usage. What if the PAL SD footage was just 5 minutes but the HD footage was 20 minutes, but I started the project with the SD footage? Why have PiTiVi default to SD settings, and then resize down my HD footage to fit to the SD placeholder?

And now that I mentioned the Kodak, I remembered that Kodak digicam's internal clock is not precise, so you end up with different frame rates on different clips (usually ranging from 29.95 to 30.200). Obviously, when I edit on Vegas, I setup a 29.97 project, and then I disable resampling (to avoid ghosting). If on PiTiVi you remove the ability to setup a project, then PiTiVi might pick the first clip's frame rate, which might be something like 30.042, which is definitely not what I want.

In other words, it might sound like "the complex thing to do" for a user to have to pick project settings, but it's the _right_ thing to do. From both final quality, and for stability and performance point of view for the editor.

That would all be well and good if PiTiVi and GStreamer worked the way you seem to think they do, but they don't. GStreamer allows mixing clips of various formats, and PiTiVi retains this behavior. This is different than the way in which many if not most editors to work, because they were designed in a single-format paradigm (in which all media has the same format [resolution, framerate, audio rate, etc]). I understand that FCP now has an "open-format" timeline, but I've not used recent versions of it. The point is that other editors typically force you to chose one specific format for the project, and PiTiVi doesn't force this choice until render time.

When previewing, PiTiVi outputs video at its native frame rate, with video output scaled to the size of the viewer widget, and audio converted to whatever your sound card prefers (this is done automatically). Internally, however, everything is handled in its native format. For example, you will notice the viewer widget changing shape ratio if you preview a timeline that mixes 4:3 and 16:9 sources. This would make a lot more sense if PiTiVI actually supported rendering to formats that allow variable aspect ratios, but we don't. Mainly it's just the easiest way to hook everything together and have it work, but it also avoids unnecessary up/down sampling of every clip to an arbitrarily chosen format.

When rendering, PiTiVi conforms everything to the given output format. Images are window-boxed if they don't match the output aspect ratio. Given the use-cases that Eugenia has outlined, this may not always be ideal; however, this is the status quo, and I don't see it changing for the moment. What Westley suggests actually makes more sense than what Eugenia suggests, because it most accurately reflects the "system model" that PiTiVi has.

In other words, at the moment there's no distinction between the effect that project settings and render settings have on the output: it's completely redundant functionality. The main difference is that "Project Settings" are saved into the project, while "Render Settings" aren't, and I admit that this is completely stupid.

When PiTiVi supports overriding a clip's native format (essentially treating it as if it had a different native format), it might make more sense to allow for a "Project Format". This would be the default format to which PiTiVi would conform every clip (but we still don't want to loose the freedom of working with variable-format sources, so this would be optional). Until then, having separate "Render Settings" and "Project Settings" is misleading. These controls should go in one place, or the other, not both. I think we should follow Westley's advice and eliminate formatting options from "Project Settings", making "Render Settings" persistent. Perhaps even rename "Project Settings" to "Project Info", since the dialog would be chiefly concerned with meta-data.

Actually, in hindsight i'm not totally sure that PiTiVi doesn't support variable-resolution/aspect-ratio output, so I shouldn't say that it doesn't. What i mean is that we don't explicitly support for outputting to something like DVB, which has aspect-ratio flags so that tv's display video using the proper aspect ratio. Such support could be added, in theory.

The way you are making it work right now is the wrong way for professionals. Conforming your [different] clips to universal settings for preview, is the right thing to do. And the reason for that, is this: keyframing.

If you have a 60p video, and you do keyframing work while editing, and at the end you want to export as 24p, you LOSE keyframing/precision information. And losing any kind of data, is the wrong model for any app. If I had the ability to setup my project settings to 24p, and then have the app remove the frames to conform to 24p, and THEN add keyframing, that would be ideal, because this way my output will MATCH my editing/preview process.

I don't disagree with having variable fps/res on a single output file (in fact, BBC was looking at this for future TVs), but the way things work right now, and what professionals need, come in contradiction with what you are describing.

Maybe you should offer both ways.

Basically, any frame-precision editing will get lost in these scenarios. Conforming first, and editing later, is the right thing to do at this point in time. Variable fps/res formats might not be widespread for another 10 to 15 years, so I don't see why you would go just for that, and not what users need *today*.

If you want to be future-proof, simply offer both ways. Have a dialog somewhere where the default is "automatic" for project settings, but let the user customize that dialog, and have the editor conform its internal/previewing process to these wishes on the fly.

I'm really not following you here. PiTiVi and GSreamer are not frame-based. All time-values, whether they represent edit decisions or keyframe timestamps are stored and manipulated in nanoseconds, which is what GStreamer uses internally to represent time.

A nanosecond is 10^-9 seconds. There are a *billion* nanoseconds in a second. A single frame of video at 60p is ~16,666,666 nanoseconds. A single audio sample at 44.1 khz is ~22,675 nanoseconds. We are representing time values to a greater accuracy than anyone should ever need to care about.

This isn't something we are doing to be cute, it's fundamental to GStreamer's architecture that it be able to represent time accurately.

We are not loosing any information until the movie is rendered.

>We are not loosing any information until the movie is rendered.

That's exactly what I'm talking about. I need to edit my video with keyframes and take frame-based decisions based on how the FINAL will look like. So if my bulk of my clips are 24p, I will be naturally exporting in 24p. But if it happens  that 1-2 of my clips in that timeline are 60p, and I need to use keyframes on these clips (e.g. for compositing or visual plugin usage), then I need to have a GUARANTEE that frame 5468 is going to be part of the final render, because I have a keyframe decision assigned to that frame.

This is why it's important to be able to "see" the 60p clips as 24p videos *while* editing.

You're talking about how precise you are internally, but you forget the actual use case. I need to be able to LOCK the preview ability to certain settings in order to take informed decisions when doing advanced editing.

> You're talking about how precise you are internally, but you forget the actual
> use case. I need to be able to LOCK the preview ability to certain settings in
> order to take informed decisions when doing advanced editing.

But my previous point still stands: We don't support doing this, and we probably won't for a while, and so it doesn't make sense to design the render dialog as if we did.

IMO, what I described should be the default case. Maybe I should file a separate feature request?

Definitely put that in a separate bug. All we're doing here is trying to clean up the render dialog so that existing capabilities are easier to use.

Update on the status of this bug: waiting for gst-convenience and gst-editing-services support to be included in PiTiVi, at which point I can begin hacking support for it into my branch and merge into master.

Update on the status of this bug: waiting for gst-convenience and gst-editing-services support to be included in PiTiVi, at which point I can begin hacking support for it into my branch and merge into master.

Having the possibility to switch output settings for previewing would be nice indeed. Was confused by all the rambling.

That would basically come down to applying the post-processing we're doing on audio/video at preview time (videorate, scaling, boxing, ...).

scaling/boxing could/SHOULD be done by the GPU (i.e. costing us nothing). And framerate conformance (by videorate) doesn't cost anything... except for a small extra latency (you need two frames to know which one to push out and at what timestamps).

Being able to specify a output Display Aspect Ratio will also be needed to properly fix videomixing (currently if you mix a 16:9 video and a 4:3 video... we have no way of knowing how to scale/position those two).

Instead of specifying a width/height, I'd prefer to see specifying a Display Aspect Ratio. So you'd basically end up having two selectors for previewing:
 [ DAR : 16/9  v ]  [ FPS : 24p   v ]

Will figure out some more about this (which should be discussed in another bug), it intersects with the work I want to do for speeding up videomixing and compositing.

Regarding deinterlacing, this should be used/applied at the source level based on whether you're outputing a progressive or interlaced project, I'm actually tempted to just *force* deinterlacing of all sources. And if we lose the minority of projects still stuck in the 1980s and really want to output interlaced content... tough.

Well, a lot of people want to burn DVDs, so you shouldn't force deinterlacing. Re-interlacing a previously de-interlaced content means quality loss. Instead, de-interlacing should be part of the project settings, where the user can select between: none, blend fields, interpolation, yadif when the "field order" is set either to "top field first" or "bottom field first" (instead of "progressive"). Then, the preview should adhere to that, and carry the selected algorithm over to the render settings IF the user exports interlaced.

Slightly off-topic question, is selective deinterlacing (known as "decomb" in Handbrake) feasible in pitivi? From what I've seen on http://trac.handbrake.fr/wiki/Decomb it basically is
- faster than deinterlacing every frame with yadif
- progressive frames keep their quality
- safer to leave "turned on" all the time

I'm guessing it is certainly not trivial to implement though, and I'm not even sure it makes sense in a video editor (compared to a dvd ripper :)

*** Bug 606389 has been marked as a duplicate of this bug. ***

The original intent of this bug report (cleaner rendering/project settings ui in general, customizable presets) will be addressed with Brandon's current work in pitivi git.

New project settings & render dialog are now in pitivi git master.
Separate bugs should be filed if there are remaining/outstanding issues.