Esteemed PiTiVi developers, I have implemented a nearly working "Publish to YouTube"-feature for PiTiVi. I'd like to make it actually work, but I've hit a snag that some of you might be able to help with. I will now present the work done so far, and in the end ask for help on this problem.
Source code: https://github.com/maghoff/pitivi/tree/work ("work" branch) Additional dependency: I use Google's gdata library. On Ubuntu it is sufficient to do "sudo apt-get install python-gdata" This should be enough to get it running. == Core == I've added a core component in pitivi/youtube_glib.py. This module offers a class, AsyncYT, which is an asynchronous wrapper on the gdata.youtube.service.YouTubeService-class that integrates with the glib event loop. AsyncYT delegates its work to a background thread which uses the blocking gdata-API. It is doable to rewrite this to avoid threading given an HTTP library that integrates with glib. libsoap doesn't seem to have Python wrappers. AsyncYT offers authentication and uploading. The upload function accepts a file or file-like object. pitivi/youtube_glib.py contains a magic string which is necessary to make things work, the DEVELOPER_KEY. This has been assigned to me by Google, here: http://code.google.com/apis/youtube/dashboard/gwt/index.html I've registered this key for the PiTiVi-project. == UI == I've added a new window, pitivi/ui/PublishToYouTubeDialog.{py,glade}. I am not used to GTK or Glade, so I might have done some stupid things here. It is a GtkAssistant, to reflect the necessary workflow. I have tried sprinkling this code with TODOs where I think it would help if you guys took a look (plus some places where I'm lazy). The Assistant takes the user through four pages: 1. Login 2. Entering of metadata (similar to what you do in the web interface to YouTube. Only title and description are supported for now) (2.5. Configuration of codecs?) 3. Rendering and uploading (just a progressbar) 4. Publicizing; send mail, etc. I've not started implementing this page. It shouldn't be necessary to gather all the metadata before starting to render and upload, but a rewrite would require using the 2.0 API, which is only documented at HTTP level as far as I can see, so then we're back to the HTTP requirement. == Rendering and uploading == I've tried copying the rendering-related code from EncodingDialog, and it seems to be working. Now, I know the renderer can make a file as output and AsyncYT takes a file as input, so I figured a good old named pipe would be a good fit for communicating between these components. It is a pretty good solution, because it makes sure we don't hog the CPU more than we need if we are bandwidth-limited. A temporary named pipe is created in a temporary directory (tempfile.mkdtemp()) to facilitate this. I have managed to get the YouTube component to accept a named pipe. However, when I try to get gstreamer to write to the pipe, it terminates just after starting with the following error messages (formatted for mail): ERROR [ 4722] [0x7feb9dc67700] "<Pipeline at 0x7feb88056d50>" pipeline nov. 14 16:54:59 handleErrorMessage: error from /GstPipeline:pipeline1/GstBin:bin5/GstFileSink:filesink0 (__main__.GstFileSink): Could not perform seek on resource. (gstfilesink.c(595): gst_file_sink_event (): /GstPipeline:pipeline1/GstBin:bin5/GstFileSink:filesink0: system error: Illegal seek) (pitivi/pipeline.py:851) ERROR [ 4722] [0x7feb9dc67700] "<Pipeline at 0x7feb88056d50>" pipeline nov. 14 16:54:59 handleErrorMessage: error from /GstBin:bin5/GstFileSink:filesink0 (__main__.GstFileSink): Could not perform seek on resource. (gstfilesink.c(595): gst_file_sink_event (): /GstPipeline:pipeline1/GstBin:bin5/GstFileSink:filesink0: system error: Illegal seek) (pitivi/pipeline.py:851) So it seems that gstreamer tries to seek in the file -- which is a pipe -- and it unsurprisingly doesn't work. I was under the impression that seeking while generating video output should not often be necessary. Can we make gstreamer avoid this? With hopes that we can make this into an actual feature, Magnus Hoff ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Pitivi-pitivi mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
