Thanks very much for your reply, and I appreciate the time you took.  By accident, the message you replied to was not sent to the list.  The one I sent to the list was more enlightened, I think.  Nevertheless, I will reply to the one you sent.

>>BUT:  I really, really think that the program should be smart enough to use the same value as the input file, or at least use a realistic value with reasonable quality.  Bug report?

>That's a tricky one... ideally yes. In practice I'm not sure how the program should "guess" intelligently.
>What could be the subject of a bug report is "better/higher default values for the bitrate/quality"... but that would probably be a gstreamer bug instead of a pitivi one.

Yes indeed.  But the default quality is terrible, and the damage is done to PiTiVi, not gstreamer.  It's a big turnoff for users, and it makes PiTiVi look bad.  If it were my program, I would fix it instantly.  It is surely a very easy fix, but who knows how long it would take gstreamer to fix it?  That's my suggestion, anyway.

I can understand that there may be programming difficulties in deciding the correct default, but from a design point of view, I think this is not the right place to arbitrarily reduce the quality.  Considering all the time it takes to edit a video, you don't want to reduce the quality by default.  You can always reduce the quality later -- while authoring a DVD, for example -- but you can't put it back.

I'm NOT going to file a bug report, because I don't know enough about video software internals.  This time I'm going to leave it to someone else.

>Actually, I do have the power to confirm gnome bugs, and I do when it is easily reproducible *and* confirmed by others. Confirming my own bugs without external validation is a dangerous slope.  ...I'm just being careful with my own heisenbug reports :)

If you want me to bless it, consider it confirmed.  Heisenbugs are bugs too.  :-)  Do you need more information on conditions?

>If you take a look at pitivi's bug list, you will notice that more than half of the bugs are "NEW" (confirmed).

Yes, sorry, I see that that's right.  Some other projects don't confirm anything, and it's very discourteous to outsiders.

>> > 5. The playback button sometimes becomes unresponsive. Sometimes it
>> > starts playing a minute or two later, after the playback marker has
>> > been moved, leading me to think I have accidentally moved a clip and
>> > hidden it somehow.
>> Hmm, I don't know of such a problem... it would help a lot if you could
>> pinpoint the exact steps to reproduce this in a bug report (and any
>> errors being output in the terminal).

Performance problems usually occur while working on a large file.  The first step would be "open the attached 2-GB file".  I can try, but I have no idea how to simulate that with a minimal example.