Video support

[Christopher Allan Webber]

The codebase is maturing quickly towards something where we could
implement video support pretty soon.

There are several parts to this project:


-  Implementing multi-media class support (this probably needs its
   own ticket)
-  Add video processing code. We need someone with gstreamer
   experience... if someone can construct a generic gstreamer video
   encoding pipeline that would help things along by a lot.
-  Allow for dropping in multiple-media-type image support (again,
   part of the first bullet) and add one for video

If someone can help me with bullet #2 this can move along a lot
faster..

[Elrond]

Joar, could you please take a look at this bug and see if it needs
updating due to your video work?

[Christopher Allan Webber]

It probably does, and I'll start making comments here about Joar's
branch:


-  Looking pretty great generally; I'm very excited :)
-  Certain things duplicated between video/processing and
   images/processing... particularly:
   
   -  The errors classes... these should just be imported out of
      mediagoblin/process\_media/errors.py
   -  mark\_entry\_failed should be imported from
      process\_media/**init**.py

-  There are some images in media\_types/video/presets/ and I can't
   figure out how they're used. Seems curious..
-  Nice job of breaking out the event handling!
-  What's up with the changed cloudfiles.py code?

Lastly, I notice that the way you're dispatching things to the
specific media manager is in the view. I don't think this is wrong,
it's a specific call... but I'm too tired to formulate thoughts on
this correctly. Ping me on IRC or I'll update this with more
coherent thoughts.

Great job so far of turning my outline of how this should work into
action!

[Christopher Allan Webber]

Assigning to Joar!

[Christopher Allan Webber]

More feedback to come, but as discussed on IRC, probably best to
not require additional dependencies in setup.py. Instead, we should
document the need to install such dependencies on video-related
sections of the docs.

[Christopher Allan Webber]

-  Seems to work great!
-  Should make keeping the original or deleting it an option.
   Probably by default it should be deleted... I uploaded a 78 MB
   video, and it made a 15MB lower-res WebM version. Personally, I
   don't need or want the huge one.
-  Is 640p.webm for all filenames the best option? Maybe we should
   take the original filename and change it to ORIGINAL-640p.webm
-  There are still a number of issues of duplicated code. Maybe it
   makes sense to move these to process\_media/util.py:
   
   -  mark\_entry\_failed (both)
   -  create\_pub\_filepath (both)

-  There are some unnecessary imports in the processing files
-  process\_media/**init**.py still has the old code

Something that could be spun off into a separate bug, but still has
to be done before the month's release:


-  We need a way to disable video support, even if a "stopgap"
   quick solution.

Also important, but not critical:


-  Do we want to tell users somehow that certain media types are
   enabled on their particular instance? (Maybe we even want them to
   pick the appropriate media type?) Wonder what schendje thinks of
   this..
-  Maybe we could save the current percentage of conversion in the
   celery status? That's definitely okay to be a separate bug though.

[Christopher Allan Webber]

Also, some tests are failing! Those should be fixed.

[joar]

Hi Chris, these are the points I have taken action on:


-  DONE Add way to disable video support
-  DONE Fix tests
-  DONE Centralize ProcessMedia
-  DONE Find a home for mark\_entry\_failed and
   create\_pub\_filepath
-  DONE Change medium filename to {original}-640p.webm
-  DONE Update image processing to the one in master
-  Moved process\_media/**init**.py => processing.py, merged
   process\_media.errors and processing.py.

[Christopher Allan Webber]

Hey Joar,

Haven't done a full review yet, but I notice something in one
commit:

::

    +    <script type="text/javascript" 
    +        src="{{ request.staticdirect('/js/lib/video.js') }}"></script>
    +    <script type="text/javascript" 
    +        src="{{ request.staticdirect('/js/video.js') }}"></script>
    +    <script type="text/javascript" src="http://html5.kaltura.org/js" > </script> 

these files don't exist?

Not sure what /js/lib/video.js or even just /js/video.js are
supposed to do, but you could commit them if something useful. I
also wonder that if we're going to use the Kaltura skin if we
should package it with the program? If we do, it should go in the
extlib directory and be symlinked in, probably.

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/495 .

[Christopher Allan Webber]

Oh, why isn't this closed?

This is done :)