Filters:
Languages
Toughness
Just bugs labeled...
Expand all
Collapse all
-
· link
To reproduce in master: 1. Have "normal" computer hardware. Instead of a Core i7 with a solid-state drive, use a Core 2 Duo with a regular hard disk drive. However, the issue will still be noticeable even on the super-fast computer, just a little bit less so. We can't expect users to be running brand new computers bought last month, we should expect them to run machines that are five years old. 2. Have a project file with a bunch of clips in the timeline. Texture (from http://jeff.ecchi.ca/public/sample-pitivi-projects/ ) can be a good test case. 3. In ~/.cache/pitivi, rename or delete the "thumbs" folder. 4. Load the project. Result: - Project loading takes a LOT longer than before. It used to be nearly instantaneous before the implementation of the clutter timeline and new thumbnailer. - Extremely sluggish/non-responsive UI during (and after) project loading. You will feel it, guaranteed. On a Thinkpad X61, the system load goes to 14 when trying to load the “Texture” sample project. Yet, as far as we have been told, we are not blocking on I/O anymore (in theory), so maybe we are now starving the CPU by doing too much work at once and at the wrong time, preventing the UI from having enough ressources to be reactive. Would be nice to do profiling to be sure. The current thumbnailer implementation does two things: - It generates thumbnails for the visible portion of clips in the timeline, in higher priority - It does background processing to process the parts that are not currently visible Potential avenues to investigate or solve the problem: - Defer work to when nothing else is happening. Thumbnailing should never happen while we're loading a project, playing or rendering. Be able to pause and resume background thumbnailing. - Do less concurrent work. Throttle the background thumbnailing with a scheduler? Depending on the number of available CPU threads/cores. Maybe always try to leave one core free, especially if the pitivi window is not the focus (ie the user is doing something else)? Or, more simply, instead of processing all clips at the same time, perhaps limit to processing only one clip at a time for the background queue? - Previously, it committed (writes the clip's thumbnail cache sqlite file to disk) for every single thumbnail in the clip, which quickly destroyed performance by saturating with unnecessary I/O. The current implementation now commits only once the clip has been entirely processed, which is lighter in terms of I/O but also a bit overzealous, in the sense that it would be sufficient to commit using a timer (ex: every 30 seconds or when the clip processing completes, whichever comes first). Otherwise, if you try to thumbnail a clip that is two hours long, nothing will ever get written to disk until it has been thumbnailed entirely (which can take hours) Somewhat related (or perhaps to be obsoleted): https://bugzilla.gnome.org/show_bug.cgi?id=591427#c21
-
· link
I'm suspecting the seeking code in mediafilespreviewer.py (the module used for the file chooser dialog and the media library preview feature) is quite basic, in the sense that it always does accurate seeks. To speed things up, we should leverage the new seeking types in GStreamer 1.x to scrub more quickly/efficiently while dragging the slider and do the final seek (when the mouse button is released) with an accurate seek.
-
· link
To reproduce, import the attached file, which contains two audio tracks and one audio track. Drag it into the timeline, only the first track is available.
-
A nice feature I've seen in some other NLEs is the peak meter that allows you to visually see when the sound is too loud (and will get distorted). It's kind of like 2 progressbars (if we want that stereo), but they would not be standard progressbar widgets, they would be green, yellow or red depending on how close to the max the sound is. And if the sound went off peaks during playback, a little warning icon would appear above (that warning is reset on the next playback). This has three uses that I can see: - seeing if your project has an equal volume across time (to prevent your audience from always adjusting the volume knob!) - comparing two clips with different volume levels, and adjust one of them to match the other - raise awareness (to newcomers) about sound that is so loud that it loses quality Don't know if that feature should be part of core or a plugin.
-
· link
I used a Sony DVD Handycam to record video on my 7-month OE. It takes mini-DVDs. This was great in most respects, as it meant that I could: * make backup copies to full-sized DVDs at internet cafes without installing software; * play the videos back in hostel DVD players; * toggle the subtitles on and off in a DVD player to have the time and date of recording on screen; * etc. The big difficulty is that, now that I am home, I have a stack of DVDs and it is very hard to import them into a video editing program to edit them. I have spent a lot of time ripping them perfectly to .iso images on my HTPC, so it would be great if any import "wizard" could handle .iso files as well as DVD discs. I understand that each clip (from when you hit record until you hit stop) is a separate chapter and each time that you take the disc out and put it back in is a separate title (I also think that, if you have too many chapters, it will start a new title even if you don't take the disc out). This makes working with the .VOB files a very unsatisfactory way to edit the movies. Ideally such an import would keep the video in its native MPEG format, so that there was no quality loss through transcoding. The best example of such a wizard that I can find is that of Roxio Easy Media Creator, described here: http://www.jakeludington.com/roxio/20071029_editing_dvd_camcorder_movies_with_easy_media_creator.html All of my DVDs are too big to post (1.4GB), so I will try to record something short so that you have something to work with. The camera is my mother's, however, so I'll do it when I am next there. I am more than happy to help with any work in this direction.
-
· link
Several Python scripts in PiTiVi start with #!/usr/bin/env python or #!/usr/bin/python Instead, #!/usr/bin/env python2 should be used so the scripts will work on systems where "python" is Python 3. You can find all files with this problem by running grep -ER '^#!/usr/bin/' . in the PiTiVi git directory.
-
· link
If you use "" as MODULES_CORE in pitivi-git-environment.sh (on distros that are recent enough that you don't havet to build glib, gobject-introspection and pygobject), you will not be able to run pitivi: PTV env:~/pitivi-git/pitivi (master)$ pitivi Traceback (most recent call last): File "/home/jeff/pitivi-git/pitivi/bin/pitivi", line 145, in <module> _init_gobject_gtk_gst_ges() File "/home/jeff/pitivi-git/pitivi/bin/pitivi", line 101, in _init_gobject_gtk_gst_ges gi.require_version('Gtk', '3.0') AttributeError: 'module' object has no attribute 'require_version' Indeed, if you check with ipython from within that environment, you'll see that the "gi" module does not have require_version nor "repository". The environment variables should be set so that they can fallback to libraries that are already available system-wide.
-
· link
If both gobject-introspection and pygobject are recent enough, $MODULES_CORE="". Otherwise, $MODULES_CORE="glib gobject-introspection pygobject". If just not sure of how the logic should go for that one. Also, we have to take care of bug 686341 for this to work properly.
-
· link
In file managers like Nautilus, Pitivi project files currently show up as a blank plain-text icons, which does not make it very easy to spot them (unless you're in a folder with only multimedia files). Ideally, there should be a video editing project icon associated with those kinds of files. I have some icons for that purpose, that have been sitting around in a dusty folder since 2009. I have attempted simply placing them in /usr/share/icons/hicolor/scalable/mimetypes as text-x-xptv.svg and text-x-xges.svg ...then doing: gtk-update-icon-cache --force --ignore-theme-index /usr/share/icons/hicolor/ ...but they still don't show up in Nautilus 3.6 (even if Nautilus does know the correct mimetype for my .xptv and .xges test files). If someone wants to fix this (and *prove* that it works - you can simply use a random icon for the sake of testing, initially), patches are welcome!
-
While the realtime trim preview feature combined with the automatic ripple (aka magnetic/gapless timeline) is enough for me to do precise cuts, it seems that "JKL" trimming is a big deal for many people. All it amounts to is: - binding the "k" key as an alternative shortcut for play/pause - binding the J and L keys to backward and forward playback, respectively. Pressing the J key once plays in reverse at 1x speed. Pressing it twice plays backwards at 150% speed. Thrice = 200% speed. This depends on reliable and efficient reverse playback in GStreamer. Pressing the L key does the same thing, but by playing forwards. Pressing the K (pause) key will reset the playback speed to 100% for the next time you press J or L.
