I'm looking for the next big thing in the Drupal video scene that is going to finally catch up and replace the video module. We've been using the video module at CCTV for a couple of years but it's too buggy to depend upon any longer. I don't think it even has an official 5.x release and this is leaving its future pretty dim in my book.
So, here I am looking for a replacement among many many many media management modules and I'm having a hard time navigating to the best solution. Regardless of self-hosting aspect of these modules, there are emfield, media field, video CCK, media mover, asset, openpackage video, Googtube, tons of video embedding helpers, and the fading video.module all in this arena (and probably more, so please add them below).
I've got two questions to raise:
- Short term, which of these modules is going to be the most stable for the immediate future? I've got hundreds of videos hosted on our server, and even more to upload, and the whole project is stagnant with the video.module.
- Long term, where do I focus my time, energy and money to bring around a really sound solution - like a media file management API into which media modules can tap? This was done recently with Image API, and was the discussion of a media BoaF discussion at Drupalcon Boston.
Thanks for the advice, I hope this is a fun discussion...
EDIT: Based on the discussion below, I felt it was important to rename the title of this post to reflect that we were looking for a solution for video delivery package rather than a single module. I think this characterizes the discussion more clearly.
Comments
File Field
My vote is for a combo of File Field and jQuery Media, which already works now pretty much out of the box. Also, I'm pretty certain as File Field (and its helper module(s)) will be a strong contender, especially as dopry is key in getting the hook_file patch in place.
Also look at http://groups.drupal.org/node/11810
Aaron Winborn
AaronWinborn.com (my blog)
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
All that really needs to
All that really needs to happen are 1) someone needs to write a migration script from the Video module to File Field (or another contender), and 2) docs need to be written up. Alternatively, the Video module maintainer(s) could update their module to leverage the ever-changing Drupalscape.
Aaron Winborn
AaronWinborn.com (my blog)
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Not an alternative
Fax8 is often unavailable since he started school in Spain last year. This is too bad, I've enjoyed working with him in the past when we first discovered the video module. I'm not confident that this video module will get any more renovation without routing around him.
I don't know how much of the video module needs to be ratified to make it happy again. I'd rather see a holistic solution come around, and while I don't have the chops to contribute to the writing, consider me candidate number one to test.
What documentation needs to be written on the File Field module?
Not one solution
I really think that there are a few issues at stake, and the issues have little to do with the particularities of video, but more with file handling and content delivery. I'd really like to see community move away from single solutions to sets of solutions with good integration, great documentation, and solid APIs. Though I'm the author of media mover, it's clear it isn't "the" solution, nor should it be. It fills a specific niche. Likewise we need the functionality of feed api, emfield, and asset. The more we work to make these modules play together and have good recipes, the more the entire drupal community will benefit.
I do think Aaron is right that we need to create an upgrade path- this is something that could be very helpful- but I'd like also to talk about an abstracted set of tools that module developers can utilize to create those solutions- we have helper modules like mimedetect, ffmpeg_wrapper. xspf_playlist could be abstracted more to play better with other people's content (asset module, emfield come to mind). flvmediaplayer (a wrapper for the jw flash player) could also be tweaked to be better deployed by other modules (there is integration with asset now). My point here being that we've got some awesome tools right now, but they could be that much better if they were integrated.
Ultimately, I don't want to see one module win- I want to see all of the talented developers working on multimedia work together to create solutions that leverage each others great work.
http://24b6.net
I'm down with that
I think a media file toolkit is an excellent approach and I'm with you on integrating all the tools that already exist. They are great tools. This has got the flexibility everyone wants and they could treat media on many different site implementations differently with the same basic tools. Awesome.
What recipes already exist that are stable enough to become the core of this media toolkit solution? If the answer is none, what work do we have ahead of us? Can we build a roadmap and try to get the good people in the media-oriented modules on track to the solution?
I couldn't agree with
I couldn't agree with arthurf any more. What really needs to happen is a separation of the key functionalities which all of the video modules try to wrap up into one huge module. I think Arthur's Media Mover is probably the best start in this direction.... funny I said that, since I wrote FlashVideo, but that is one thing I probably would have done different if I were to start over (which I don't see myself doing anytime soon). So with that said, if you need a specific approach, then the Media Mover, FlashVideo, Op Video, and others are probably perfect for your needs. You just need to compare your requirements to what these modules provide and then determine which is the closest fit.
I second arthurf's approach.
I second arthurf's approach. We've been relying heavily on emfield the past 6 months, and I love its simplicity. We've recently received grant funding to build out a Public Access TV installation profile (http://www.newschallenge.org/tools_for_public_access_tv), and are now in the planning stages to integrate Media Mover & possibly File Field. We've also been using FlashVideo on several sub-sites. Since our developers will already be working on integrating several of the video modules, I'd love to collaborate / divide and conquer. If we could get a road map going as Sean suggested, that would be a great start. Maybe as a wiki page on this group?
(p.s. we're hiring several full time developers to work on this project http://groups.drupal.org/node/11767. Competitive pay, great environment, if anyone knows someone who would be interested please pass it along!)
Brian Hiatt
Civic Pixel | Deproduction
303-800-5322
brian@civicpixel.com
Open Media Foundation
I like roadmaps
So maybe this should be flushed out in a separate post and given some top billing, but if the Drupal video community can come together and nominate the best path for creating a video package then lets get started. It's maybe a good time to talk about what would be the basic functionality required in media tool kit.
We're probably talking about a file upload method, a file transformation method, and then a presentation method. Regardless of how well they are integrated or not, a recipe that has been rising to the surface is something like:
FileField for uploads (requires other stuff including getid3 for ripping metadata).
plus...
Media Mover for making derivative files and thumbnails (requires ffmpeg).
plus...
jQuery Media for displaying media file types (requires jQuery).
This looks like a basic footprint for a media management and playback kit but some questions come up. These modules require jQuery and ffmpeg and getid3, is that cool or lame for ease of use and adoption rate? Where does Asset fit in, and what's it got over FileField? Can Media Mover deliver data to Emfield? Can we count on jQuery Media to become so simple that my grandma can use it to show videos of her cribbage victory?
And once a basic recipe comes together, can we get those modules better media namespace and get other module developers to get on board?
asset vs filefield
I'll answer your question about what asset has over filefield:
Here's an article with interesting comments on the subject: http://www.innovatingtomorrow.net/2008/03/31/fishbowl
Asset RC1 will be released tomorrow, after which I start the Drupal 6 migration.
Better File Management in Core
Asset is great for combining local and remote media. Though I still think File Field is more light weight for local media. But more importantly, we need to get a better File API into core. All our asset management modules need to work together. I don't want to migrate from upload, image, or filefield. I want one system underlying it all that will allow them to talk to each other more easily, and a system of hook notifications and modifications. And that needs to be in core, and until then, we need to be working together. Thus, I suggest building on top of File FIeld until something in core is availalbe.
I'm devoting this week to the Media Code Sprint. We're going to get better media handling into core. Come find drewish, dopry, and myself at #drupal in IRC if you're interested. (There's already a task for people who want to help, but might not be able to jump into documentation: http://groups.drupal.org/node/13420.)
Thanks,
Aaron Winborn
Drupal Multimedia (my book)
AaronWinborn.com (my blog, all about Drupal)
Advomatic (my work)
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Some questions, thoughts, and mental garbage ...
Great discussion. As a themer, I have little knowledge of much of the stuff that really goes on behind the scenes with these modules, but I love to see this push in what is definitely the right direction with API's that allow each module to focus on it's strengths and communicate with other modules that handle their tasks independently. I'm coming from a place of little knowledge, so ... lots of questions. Forgive my ignorance. :)
How to Handle Remote Hosted Files
The FileField+MediaMover+jQueryMedia solution sounds awesome to me. I've seen that FileField supports just about every imaginable type of file and is open to extension by other modules if certain more specific file handling is required. There seems to still be a lot of questions about how certain things will work in D6, but it seems that images will be best be handled by ImageField, but that that module will be built on top of FileField in D6 (???).
Does this solution account for having files that are hosted on remote services like YouTube and Revver? or is another module like EmField or FeedAPI required to make that work? Would it be good to have a way for filefield to store info about remote files as well (not putting them there or taking them down - that would be the job of MediaMover), so that the same API could be used to display/manipulate those remote files that is used to display/manipulate local ones? I personally feel that remote services add a lot of extra value in terms of extra exposure to outside communities as well as relieving server strain associate with hosting/serving large files.
Asset module may need a smaller niche
Asset adds a lot of admin functionality that would be great for users (required for most unsavvy admins), but it sounds like it may be trying to do too much. I think that it would be better off if it left the storage solution to FileField and focused on providing a nice interface by which admins could access these files and insert them into content using an admin friendly interface like the TinyMCE plugin. The huge advantage of this is that there are many modules that tie into filefield and build extra functionality onto it. If you have a proprietary storage solution, then you lose the benefits of those addon modules, and you have more code to maintain. ... just some thoughts, since I have no idea what it would take to integrate the asset wizard into filefield or if it's even possible.
file wizard
I've been thinking about this as well lately: leaving the storage up to filefield and emfield, leaving the output up to jQuery Media and putting the asset wizard on top of that. However it be, the asset module is switching over to the new fileapi and I will help create it however I can.
Great discussion going on
Great discussion going on here.
The above recipe (filefield + media mover + jQuery media) is exactly the solution I'm implementing (currently, the only gap for me is http://drupal.org/node/246368).
About ffmpeg: I think good documentation is key. There are plenty of great tutorials out there describing how to set up ffmpeg for a variety of uses. Perhaps we could try to come up with a tutorial of our own, or assemble a list of ffmpeg documentation resources.
FFmpeg
I've made the first part of a major push to making FFmpeg more friendly in ffmpeg_wrapper this week. I basically created a way that you can define configuration rules for an output type (eg: flv output requires mp3 or lamemp3 audio codec, specific bit rates, etc) and have drupal forms updated via AJAX with the new configuration data. You can see this in action in this screen cast:
http://www.24b6.net/2008/07/28/ffmpeg-wrapper-auto-configuration
The solution is good, but it's not perfect- the major constraint is to implement the handling of the form because it requires specific naming. Funnily, as I write this, I think I just figured out a good solution for it. At any rate, any module that wants to implement ffmpeg can use this, which I think is darn cool. Further, you can write your own conf files for specific outputs- mp4, avi, etc. which define what options a user can do. I'd like to get the community involved in this as it will take some time to get lots of these defined. Beyond this, I think maybe even creating basic configurations that can be stored for ffmpeg that define all the parameters (ie: here's a real audio configuration).
Anyway, I think we're moving to a point where the ffmpeg problem is going to be solved on an API level (plus, I provide a linux binary if you can't compile it, see http://mediamover.24b6.net/ffmpeg ). I know there will be bugs, but I think things are close to the point where we can worry about the next step up the chain.
http://24b6.net
Problems with various solutions
Here are some issues I've seen with most solutions. Jquery media suffers from both of these problems.
1 - Most video plugins assume you will show all videos at the same default size. That may work for youtube but it isn't good. If you want to make a screencast for example, a bigger size is much better. A different but somewhat related issue - the video players I've seen don't always allow you to switch to full screen mode. The flowplayer you have to pay for that, the mediaplayer doesn't allow it, etc.
So I would request people be able to override the width and height (and autoplay). The only tool I've seen so far that allows this is video_filter: [video:urltovideo width:X height:Y]
2 - Another major problem I have is that since these modules often use javascript and css to play the media, videos (or audio) don't appear in RSS feeds and RSS readers. That's a big limitation and step backwards, and unfortunately videos don't show up in rss feeds while using video_filter either. But otherwise it was a simple hack to extend video_filter to show local videos, too, not just youtube/google videos.
So to clarify, I think there are two assumptions that most video modules take that are wrong to take - that all videos are the same size, and that videos are only viewed in a browser at the site itself.
p.s. I tried jquery_media with a quicktime video, and no player controls appeared at all.