Video contents with Drupal: my analysis

Maybe you can add SWF Tools in there somewhere. SWF Tools is like an API for Flash players and flash replacement.

That sounds nice.

I also did a little analysis here http://groups.drupal.org/node/2795 and like your one. You tried to draw almost what I was describing in the article.

I proposed video thumbnailer and converter can be based on transformer API module and implemented just like imagecache.

Video filters also sounds clear for me.

I'm not sure about Video CCK and video node should be presentation layer. Both of them look like video core and will define the way video should be stored.

By the way, don't you think your approach can be used for audio data as well, not only video? We can expand to "media" instead of just "video".

Regards,
Dmitry Kresin, ARDAS group (ARDAS group)

I created Media Mover (which is still in progress, but somewhat functional). It's intention was to cover some of these aspects, but also slightly different ones. In a nutshell, it provides a hook framework to write modules which do some of the following:

• harvest files (could be from drupal's files table, could be an ftp server, could be email, etc)
• process files (could be ffmpeg, could be something else)
• store files (could be s3, could be something else)
• post process (set a flag, action, etc)

From doing this work, what I personally think is critical for the drupal video (and audio and images!) community is writing a driver for ffmpeg and having a distribution of ffmpeg that people can easily download that allows for all kinds of process type modules to access. For example, ffmpeg can be used to process audio- useful for creating audio thumbnails, etc. I'm really excited about the ffmpeg helper module and would be great to use this as a basis for all kinds of file processing. Whatever api gets worked out for this module should also be extensible for repurposing.

In my module, I have options to use ffmpeg's watermarking, file truncation, etc to do some of this work, but this largely duplicates some of the video module's functionality- again, joining forces here is super important!

Secondarily, there are questions about storage which are perhaps going to be answered by the drupal file system work that has been on going. I'm pretty sure that answers that are relevant for video storage are also going to be useful for other aspects of drupal.

Additionally, I think the one thing that your (great!) diagram is missing is the harvest aspect- how does video module find its files? Having the ability to integrate ftp servers, email boxes and other content types which may have uploaded content could really make the module have a larger potential usage. This was my intention with having a "harvest" process as part of my module. Of course, this is something that has been important for my projects, so it may or may not be interesting to other people.

Finally, I think having actions integration is going to be really important so that video files can be processed post upload and/or by different servers. This would help reduce potential load on large video sites.

I'm not sure about video node. Do you think it is required since almost every site needs to extend video node with some fields. The situation looks like in e-commerce package, they created Product type and noone is using it, instead people use CCK to create nodes with various fields and then make a product of them. Nevertheless, ecom guys still support Product node just as a default product - to make e-com package work correctly when there is no CCK installed.

The problem is CCK isn't still a core:)

So, probably video node is required...

Regards,
Dmitry Kresin, ARDAS group (ARDAS group)

One of my major complaints with Drupal and file handling is scalability. Very few of the media upload modules support user based directories for files. Imagefield has some recent support for this. If every module developer could get on board with supporting the token module as an option then we'd be all set. It's very easy to include and would allow things like making sub directories with a uid or maybe the first letter of the username. Then these directories could be spread across different mounted disks/arrays for scalability and performance. There are inode limitations to the number of files in a directory (varies by operating system). Also, a large number of files will greatly reduce performance on file read operations. If you want to run a big media site via drupal, you really can't without hacks because the single folder approach (even divided by three image/audio/video) is not scalable. Also, if you want to see all of one users files you have to do some db hunting or maybe a view. It's very nice to be able to just blow away a user and directory to get rid of offensive content.

So, how about a standard "best practice" of looking for the "token module" for file uploads? I really wish the core maintainers could get this into upload. It's been hacked in the past and never made it into core. I don't see why, it's pretty basic and necessary if drupal is going to get real with scalability.

The mediafield cck module is interesting because it tries to reuse code that is shared between audio and video files. Video and audio share many of the same problems and transformation issues. Flash players etc. It seems to me that CCK will at some point get fully integrated into core, the process has begun. So, why not start your presentation layer with something like mediafield which is quite a bit of the way there as a simple field type for CCK to read getid3 etc. This module could easily support other modules to allow for transformations into other formats like flash. That way these transformations are just plugins. Some folks will want real-time transformation, others will need batch due to volume. The code handlilng the submitted data needs to know whether to call a real-time or batch process. This could be done via a plugin module. Have a default behaviour which saves the file, no transformation which can be extended via modules. The mediafield settings page could allow options for tranformation plugins. Also for display plugins. Should this data be displayed using the "acmeflash player" or whatever. Hey, i like acmeflash! Anyway ...

I like media mover and think it could be broken into a smaller plugin module for large sites that need batch processing. I'd still separate out the storage into a more general feature for Drupal as a whole. Maybe this storage issue needs to be started like CCK -- get it working as a module and then impress the core developers to integrate it into core? Storage is such a basic function that I think many are scared to use a custom solution outside of core since it could go unmaintained and then you're left on an island in terms of fixes, upgrades etc. There are a number of storage mechanisms that have come and gone, sadly.