GNOME Bugzilla – Bug 609136
Proxy editing
Last modified: 2015-10-20 13:00:07 UTC
Proxy editing is the ability to swap clips by a "proxy" version that is more suited for editing, and then using the original, full-quality clip to do the render. It's definitely a very nice feature when you have HD footage and your computer is not beefy enough to handle realtime playback. This should be integrated into pitivi's set of features so that it works transparently and reliably for users that want to use this feature. To some extent, all it really amounts to is: - batch encoding clips into low resolution, easily seekable/editable clips - automatically replacing the URIs in the project with different URIs - dynamically swapping them again when rendering - build the ability to do all that in the GUI I've never used proxy editing myself, and I'm unsure if: A- proxies should be automatically replaced by their originals at render-time B- the user must manually ask (with a gui of some sort) to "replace all the clips to their originals" Approach A seems to make more sense to me at first glance.
I'm not sure whether this is the right time or place to raise the issue about what proxy format would be used. So which (open/libre) audio/video/container combination and with what parameters. The container Ogg or Matroska, both are open and well supported. I'm not sure which format is better supported in gstreamer for fast-seeking, etc. The audio Vorbis? Maybe always downmix to stereo? It's a no-brainer I guess? The video VP8 or Theora (or Dirac). In my view it should probably be well supported and a relatively lightweight codec which probably means Theora would probably be preferable. (But even VP8 has a profile for Mobile, with less resource intensive motion compensation). The resolution (assuming 16:9 aspect ratio for now): 640x360 720x576 (anamorphic, like DVD) 960x540 (like Apple iFrame) i-frame only? or a "long-gop" strategy, with a ~15 frames i-frame interval, or do we stick with a ~60frame i-frame interval which is common in normal video. Which bitrate/quantizer scale? Just some food for thought :)
Just some thoughts lately: clips should always automatically use the full-quality versions (not proxies) for the render - unless a "draft" (preview) render mode is active. Regarding audio: I doubt it makes sense to downmix the audio channels. Maybe use a standard codec like vorbis, but not touch the amount of sound channels... also, audio is not going to be computationally expensive, compared to the video stream.
A quick status update on this: - I wrote a specification of what we want for this to work, from a pitivi standpoint and from a GES API standpoint: http://wiki.pitivi.org/wiki/Proxy_editing_requirements - In GSoC 2013, Anton Belka has been working on the basis for this in GES. We'll see how soon this becomes merge-ready, at which point I'll probably start playing with the Pitivi side of things :)
About your hesitation concerning codecs (MJPEG or VP8) : I don't know if it has to be taken into account but with recent release of GStreamer (1.2) [1] and the very-soon-to-be-realeased new version of gstreamer-vaapi [2], hardware accelerated (de)coding will be available for some GPU and codecs. I may be wrong but VP8 usually is not handled by GPU on the desktop at present time. Whereas for instance Intel HD Graphics within Clarkdale, Sandy Bridge, Ivy Bridge, & Haswell processors can handle MPEG2 & H.264 decoding (HD Graphics within Sandy Bridge, Ivy Bridge, & Haswell processors can even handle H.264 encoding) [3] On the other hand, On2 Technologies had always argue that VP8 required far less processing than H.264 by nature anyway. I let you decide if it has to be taken into account or if hardware acceleration is not going to make any difference for proxy editing. [1] https://bugzilla.gnome.org/show_bug.cgi?id=611032#c17 [2] https://gitorious.org/vaapi/gstreamer-vaapi/source/b242c5874b62cbc67920cba17d2cb3e90c4cd222: [3] https://01.org/linuxgraphics/community/vaapi
(In reply to comment #4) > Whereas for instance Intel HD Graphics within Clarkdale, Sandy Bridge, Ivy > Bridge, & Haswell processors can handle MPEG2 & H.264 decoding (HD Graphics > within Sandy Bridge, Ivy Bridge, & Haswell processors can even handle H.264 > encoding) [3] That defeats the point of proxy editing. We want proxies to be able to decode and apply more effects while still being able to render in real-time. Unless all the effects start being done using OpenGL, any HW accelerated decoding will be useless. So this is no argument in choosing a format for proxies.
This bug has been migrated to https://phabricator.freedesktop.org/T2455. Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi. See http://wiki.pitivi.org/wiki/Bug_reporting for details.