Call for Wishlists: Using Video in Drupal
10.06.2006
Short attention span version: I'm working for a startup (stealth-mode for now) and am requesting suggestions, feature requests, and ideas on a video module we'll be releasing back to the drupal community. We are also very interested in module ideas, and features that do not necessarily involve video, but that you think would be useful to websites that have a lot of videos. Either comment, or use my contact form to put your ideas, or wishes in my work queue.*
Our product's tech end is based on drupal. The vast majority of our work is to be released back to drupal under GPL (not an option, but a requirement for us). As a matter of fact, the rate of adoption of our modules by the drupal community are one of the main ways they are going to be measuing our performance. As you might imagine, we intend on being a very good friend of drupal.
Here's a short FAQ in answer only form:
- Yes, I suppose you could say video is going to be a big focus of our product.
- No, we're not building "the next youtube, only better, and with better social networking and tagging support". (Just to clarify, I have a policy of not joining startups full of looney, delusional idiots)
- Yes, I think we're building exactly the right thing and at exactly the right time.
- I'm sorry, for now, please excuse the conspicious omissions of what some would consider relevent information.
- Yes, I am aware that there is already a video module. I am also aware that its considered poor form to build modules that overlap. But, I'm also a realist. Time, and our requirements have led me to conclude that building our own module is the most sensible approach. It isn't my first inclincation to base the backbone of our site on a module that we don't have full control over. And perhaps, most importantly, the video.module's function priorities are wildly different from our module's functional priorities. For example, supporting all kinds of video formats is not one of our priorities (for the time being) ::shrug:: I'm all ears to reasons why we should consider developing the existing module.
Notes:
* maybe :-)
Syndicate
Head Drupal Chef at:
Recent comments
- There are very old, and
21 hours 31 min ago - Hey, this looks great,
22 hours 41 min ago - Look at those cankles, I'd
2 days 3 hours ago - Thanks for the tutorial.
3 days 13 hours ago - At the end of the day, I
5 days 15 hours ago - Yes, I understand principles,
6 days 7 hours ago - I've never watched the MTV
6 days 19 hours ago - Surely a conservative should
6 days 19 hours ago - You can use WAMP (Windows
6 days 23 hours ago - What does "progressively
6 days 23 hours ago
Comments
Drupal video installation profile
Hi. Thought it would be useful to add on to this thread even though it's dated now... We're developing a drupal video installation profile, here's a demo and more info: http://filmforge.koumbit.net. Would like to invite anyone and everyone who's built drupal video sites before to contribute to this project, since it will end up saving a lot of reinventing the wheel!
Thanks,
schock
Any Update on your new Video
Any Update on your new Video Module?
Not safe for the wild. We're
Not safe for the wild. We're using a system that needs explaining that we don't have time to give. The gist is, that any module, can change any part of any page. Look out for a module called js_elements that I'm going to be releasing soon. Its not a video module... but I think it will be much appreciated. Its basically a hook_elements based system that lets you easily add badass jquery effects to a page. The goal is to give people the power of jquery, but without the hassle of actually learning javascript.
timeline?
Hey november has passed, hows the video module coming along?
Well -- a lot happens in a
Well -- a lot happens in a month. We're not running behind, per se, but there have been some shifts in priorities. Namely, my focus is a remote site administration/content publishing package based off of the import/export api. The video module we've developed works great for our purposes -- but I don't think the open source community will find much use for it yet. Personally, I'm beginning to think some of our spin off projects may be off more value since 5.0's video module seems so much more playdoe like in terms of customization.
One of these days I'll have enough brain power to write some tutorials based on some of the things we're doing. Got lots of new form api, hook_foo(), and crazy-flexible approaches to building node templates without tpl.php files to share. The problem is this remote site admin project is sucking all of my brain power these days...
ffmpeg vs mplayer
Hiya Nick-
Wondering if you've evaluated ffmpeg vs mplayer for converting video to FLV. Yesterday I stumbled across this little piece of advice:
I don't know about the veracity of the claim, but it might be worth looking into.
Make it happen!
I'm glad your starting from scratch. The current video module is too bloated. There are odd file attachment bugs, image previews create their own nodes and it's just annoying. Sounds like your on the right track. Keep it simple and let other play with your module with api's.
And please provide flexible theme override functions. Keep it clean and I'll be really happy.
Thanks!
checkout flixn - nicest interface ive seen so far
ok, heres my drupal video module wish... a module that lets you have as neat an interface to uploading video content as flixn provide http;//www.flixn.com
now since I dont know the nature of your video business planned it may be that you might actually just want to purchase their tech and focus on other unique differentiating aspects of your business.
But in a way id hope not because it would prevent you from pulling together a drupal module of possibly similar neatness.
whatever wishing you all the best in your endeavour Nick, dont worry about any gripes in the way you approcah this, youve got a deadline to deliver on and that must be your n0. 1 priority, i respect those that can deliver, and anyway the most important respect needed is from those paying for this, and the end customers of your business startup. Which is likely to mostly depend upon the quality of useability you deliver.
Even from a drupal community perspective, I dont follow the argument that you should earn more respect if you integrate with the existing video module, surely more important is that the modules drupal admins can choose from get better and better. and sometimes that happens by breaking the old way things are done. besides think of drupal itself! i remember there were some comments about drupal itself needing to pay more attention to advancing its capabilities even if it broke things than being backward compatible, (which im not sure I totally agree with if drupal has hopes to become accepted in more enterprise type spaces) though personally i do like it - get a kick out of all the new things). Whatever if is apparently the case for drupal then its a bit odd to have the reverse in a less important context of contrib modules.
Anyway good luck Nick, rgds, mark
Making it easy to upload
we'll be sharing as much as
we'll be sharing as much as we can without completely giving away our business to competition (which is getting exponentially fierce...)
Moderation and scheduling tools are a major priority for us.
Customization of the flash player is a possibility. Skipping through videos is also probably something we'll have in 1.0 -- though we're taking a one node, one video approach. But that's why they built javascript.
I don't think CCK's 'hook free' node types are going to support our collection of modules, but finding ways for CCK integration is definately worth considering (if that makes any sense).
CCK is a real trouble maker for anyone who wants to extend their behavior with custom modules. I'd actually recommend against CCK all together for any node that is required to do more than contain media or info, sit in a taxonomy, and look like nothing special.
Views support won't be much of an issue, and I can only think of two places where it would make sense to define custom filters for views to grab a hold of (voting is the only one I can think of.. and we'll be using the voting api in the contribs). That would be version 2.0 though , though.
Right now, our focus is putting together a bunch of useful tools that any site with video will need. Most of our modules are actually independent of the video context (they could just as easily be used on a blog, or a forum). Our video node type will be special, however, in that its built specifically to make it easy to extend -- and with attractive looking results.
Responses
1) 16MB upload limit has nothing to do with video...that's from a combination of Apache and php.ini
2) play length: extend it so it is processed by ffmpeg on the command line to auto-fill that
3) same as above, use ffmpeg
4) this is post processing anyway -- a cron job can scan that directory, then create video nodes on the fly
5) look at filesystem module
6) and you'll want to generate these FLV files on the server, since most people only have AVI or MOV files as source. Did I mention ffmpeg?
There are many ways of working with open source software. If your performance is based on adoption...well, let's just say this isn't the best start :P
That being said, I think you should go ahead and create your video module as needed. I would probably *start* with the existing video module and change it as needed...since that will let you hit your deadline, I suspect.
It will be of most interest to people that have control over their own server, who can install FTP and ffmpeg, and so on.
Boris, I seem to recall
Boris, I seem to recall getting past the 16meg upload limit in the past by simply setting post data limit to 64megs (and I think I did something else).
I suspect your correct about who's going to be interested in this module. That said, we're also very serious about making this module inherently "simple" -- something which the video module currently can't do because of its wide array of support.
Can't be simple and do server-side processing
Nothing that requires server-side processing will be seen as simple (to install, at least). Look at the difficulties people have with the image module which just requires a folder and a simple PHP library...
I agree that the current video module has a wealth of options and could be simplified.
Oh, and look at this: Revver API / Whitelabel code and also Drupal Community Video Recipe: they built using a file field and CCK, using ffmpeg on the server side.
As always, you're welcome to use our dev wiki for compiling notes if you like.
(PS -- turn on line break filtering, please: I hate adding < p > tags manually...!)
The programmer who is taking
The programmer who is taking on the flv integration (e.g. play length, screen captures) has it working -- in theory -- but it relies on a ruby script, which we could translate to php, but not in a way that we could transport.
There are no native PHP solutions that we've found that we could include in a module. However, he seems to think that this sad fact is due to the fact that "it just hasn't been done yet". We've got a lot on our plate, but us writing a native php application for flv handling is on the table right now. Its probably not going to be in version 1.0, however.
That revver API looks pretty incredible, I've sent it on to my cohort to see what he thinks.
A few thoughts...
Not sure if you know, but there is ffmpeg-php which allows integration in php which makes creating a module a bit more possible.
The major barrier that I foresee is actually the codec question- because ffmpeg relies on a series of libraries, it means that every system that it's installed on has different requirements. I think ultimately it may be the case that the only way to address this is to compile a version of ffmpeg that has all the obvious libraries in it and distribute a binary for the major operating systems.
I've been slow in the process of creating the work that I did (http://www.tunaspecial.com/?p=162) into a module, but my basic direction at this point was the following:
I'd be happy to contribute the code that I've got if anybody is interested.
BTW- It looks like somebody is integrating ffmpeg directly into the video module here: http://drupal.org/node/82313
yesterday
this is pretty much the plan
this is pretty much the plan as of today. I ended up rewriting the video_upload module to function as a video_node module today. I decided on 4, and only 4 fields.
1. video file
2. the placeholder jpg (if none is provided, it will use a default placeholder -- which can be changed in admin/settings).
3. a description (optional).
4. a title
Sizes for teasers vs page views can be configured in settings. The module relies entirely on the native file system.
From the programable standpoint, the data is simple to work with. Its contained in an array that is accessable as
<?php$node->onn_video = array(
'video' => $file_object //name, path, mime, size, etc...
'image' => $file object,
'metadata' => array(values, to, be, decided, later)
);
?>
The module is purposefully lean. We're taking a 'lego' approach, and planning an api (for a few cases where the drupal API won't do) for the many other modules that will extend this module. Our hope is that the API will enable the existing video module to take advantage of our planned collection of modules with what is hopefully a small extension module, and a small update to the video module itself that allows it to interact with our API. So we've reinvented a wheel from the video modules many wheels -- but I feel that the simple video node type is the only wheel that really matters....
second the simple, and is there a timeline?
Keeping the interface simple is extremely important - the easier it is for people to post videos the more they'll use this feature, and I think we sometimes forget how wide a range of computer know-how there is out in the world. So the more that can be automated - thumbnails, detecting size, etc. - the better. Being able to embed video into another node type would be great too. And flexibility in terms of additional fields, like website or email fields, or other description field options would be helpful.
Any hints on what the timeline is for this? I've got a site I'm working on that I'd try and delay if this is coming soon.
thanks!
simplicity is everything.
simplicity is everything. Our world has too many options, and people have to make too many choices (imho). People often forget that a node form is a FORM. Do you like to fill out forms? How do you feel when you see a long form? People, I think, often would rather keep it simple, than have a comprehensive set of options for every possible circumstance.
Not to mention, the whole beauty of drupal is that you can easily extend parts for special circumstances -- so you're never truly bound to a certain way (assuming a module is coded with that kind of philosophy.)
The video_upload, (a plugin module for video) module already allows you to embed videos in any node type. Personally, however, I think a page is a page, and a blog entry is a blog entry. A video is a video. I'm not going to be using the nodeapi very much -- since, as you may have noticed, the outputted results are rarely inspiring.
An extension module is planned for profile integration into the video node type. My theory is that the existing capabilities of the core profile fields can be used in some rather suprising ways (e.g. as a controller for all sorts of user-specific wizbang bell and whistle features)
Timeline is sometime in November.
Simplicity
Nick, I agree with your view on simplicity. In order to gain adoption you have to make it easy for the most basic user to be able to figure it out. You can't have too many options or people will say screw that it's too much of a pain in the arse. They just want it too work.
I am also working on a Niche video site currently and playing with the current video module and it definately has too many options and I need to slim it down. My targeted users are very non-technical people and want as few steps and forms as possible.
-Jeff
thumbnail cloud and dropdown filtering whole video content
we'll be building 4 sizes of
we'll be building 4 sizes of images for each video by default.Building something like this depends on whether PHP is actually up to the task of manipulating the flv file. That remains to be seen, and is probably going to be a version 2 sort of thing. This is a killer feature, but its also one that could put us way off target for release if we spent to much time on it in the beginning.
video server portals integration
yes, but only if time
yes, but only if time permits.
And perhaps, most
Show Stoppers (we're working
Well, we aren't asking anyone to fit the video module to our needs. Rather, we're building one that fits ours, and I want to know if anyone out there has any features, suggestions, or ideas for us to implement. As for the show stoppers that prevent me from wanting to use the current video module (and most of these relate to the video modules supporting of multiple types of video...):1. The 16meg upload limit2. video.module requires you to enter the playtime of a video in minutes and seconds.3. we need to be able to automatically take a frame of the video for unplayed states, unless a shot is provided beforehand. 4. the option of adding videos through FTP instead of the node form. 5. (related to 4) automatic folder creation on a per-user basis. 6. we support flv files only (for now). The video module cannot accomplish 2 and 3 and maintain support for other formats. 7. we could always integrate/branch AFTER my deadline.8. Understand that I'm not the person who makes the call in the end. Right now, we're moving fast in terms of getting the hard parts out of the way -- and I think to we'd slow down if we were developing against the current video module.
It doesn't sound like you
It doesn't sound like you have a fundamentally different approach, just a different set of priorities. It sounds like your features would be welcome in the video module and vice versa.
This is a common scenario. In the short term, it's easier to reinvent the wheel, as working with someone else's code has a learning curve and it's more challenging to innovate where there are restrictions. All your proposals to change video.module will also be challenged, where if you just reinvent the wheel you're free to do whatever you want without having someone looking over your shoulder.
In the long run, you'll get more respect from the community (and thus more bug fixing and development) if you don't run from these challenges. In the end, we'll all have a better module for it. I guess you gotta do what you gotta do to meet this deadline. But don't expect to earn anyone's respect for a rushed job.
I don't expect respect, I
Respect
Sounds like nick is developing for a business and needs no respect. He has to do what's best for his site. If he gives the community the video module the community should be thankful and not berate him.
Post new comment