I downloaded pitivi-0.13.3 from Packman, distro OpenSuSE 11.2, hardware Dell Studio 15 (1555), Intel Core 2 Duo P7450 2.13GHz, 3Gb RAM. I have a complete GStramer codec collection, nonfree items recent from Packman, and GStreamer players such as Totem competently render MPEG2 from terrestrial (OTA) digital TV.
This is my first experience with nonlinear video editing, and so likely some of my assumptions are kind of naive, but I imagine that a report of a failed attempt could be useful to the developers, and possibly there is something recognizable that I am doing wrong for which a suggestion could be given. The goal was to condense 4 hours of Olympic coverage, 1080p (1920x1088px) MPEG-2, total about 24Gb, by removing commercials and non-preferred sports. I hear snickers from the list members. I retrieved the first two segments within about the first hour of coverage. This means I trimmed the initial portion, cut the clip at the end of the first wanted segment and at the start of the second, and deleted the clip inbetween. But Pitivi got hopelelessly bogged down and I was not able to find the end of the second wanted segment. It looks like Pitivi unpacks the entire 4 hours from the transport stream and decodes the A52 audio to produce the audio level graph on the timeline (which did not contribute to my project). In my case this was expensive of CPU time, and the program seemed to do it over frequently when clips were moved around. I learned to watch my CPU usage meter and to only click on the timeline when the program had finished doing the previous step. Even so, when I was hunting for the end of my second segment about an hour into the file, the program would not show a frame at the selected point, just showing a black frame in the previewer window. I discovered the preference checkboxes to not show waveforms or thumbnails, but turning those off didn't seem to reduce the CPU time used. It looks like some aspect of Pitivi was not able to do random access in the transport stream, or was not able to make effective use of the feature. Or possibly one of the codecs was unable to do random access. I don't know how to dump the exact pipeline that Pitivi was using. Also, for the A52 decoding Pitivi and/or GStreamer itself was not making effective use of multiple cores. I would guess, or infer from performance, how many cores there were, and spawn that many threads, and assign a few seconds of transport stream and/or audio to each thread round the robin. PiTiVi looks like a very nice program that could do what I need, but I guess I choked it by giving it too big of a file for the resources available. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key) ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Pitivi-pitivi mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
