GNOME Bugzilla – Bug 635094
Support uploading/publishing to YouTube directly from the UI
Last modified: 2015-10-20 12:56:45 UTC
User story: As a cat owner, I want to get my cat videos onto YouTube as conveniently as possible. A "Publish to YouTube" menu item in the UI would accomplish this. I have already started working on it, and put my work at https://github.com/maghoff/pitivi
I had a look at it his morning and it looks like a really good start. The code seems fairly clean though I haven't gone over it line-by-line. The UI seems about right to me. I could recommend some cosmetic tweaks, and Jeff could probably recommend some more, but fundamentally it looks good. As for the render/upload, I see what you mean about the seeking. I can't really comment on how to do that properly. I'm positive that it's doable, you just need to ask the right people.
Elaborating a bit on the "As for the render/upload, I see what you mean about the seeking"-part: My approach for implementing YouTube-uploading is to take these two components that I haven't written -- gstreamer and Google's youtube module for Python -- and get them to talk to each other. I was thinking a named pipe would be well suited for this. However, when I ask gstreamer to render to a pipe it tries to seek in it as if it were a regular file, causing an error and a termination of the rendering. This behaves in the same way in the regular "Project->Render"-rendering (Just use mkfifo on the command line and render to this file) and the "Project->Publish to YouTube"-thing I am trying to make (which makes it render to a temporary named pipe). Today I also discovered that in some configurations gstreamer will not try to seek. I think using ogg as a container does not need seeking. However, when I try to use WebM it seems to always require seeking. Can we tell gstreamer to "make this a WebM, but avoid seeking"?
Okay, the gstreamer seeking thing is solved. Solution: Require settings for an output format that doesn't need seeking. An example of this is WebM with streamable=true. This solution is satisfactory because it is a good idea to limit the amounts of settings for the user. We could offer a few sensible presets, to give the user some control of bandwidth and possibly cpu usage.
This bug has been migrated to https://phabricator.freedesktop.org/T2682. 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.