Posted by westis on July 4, 2010 at 2:37pm
Hi,
We are finally in the process of moving our entire site to Drupal and gradually start using the OM tools. I was thinking of starting with just managing our metadata in Drupal, that is shows and what you call projects (we organize only be member, but I suppose we'd have to use one project for each member).
However, trying to install om_show lots of other modules are also required, most of which we wouldn't use at this stage. Are all those really required to manage show metadata? Particularly I'm wondering about these:
- Creativecommons (what if we want custom licences, where CC is one but there are others too?)
- Ffmpeg_wrapper (what if we do our transcoding locally, since our web site is in a hosted environment?)
- Media_mover_api, mm_cck, mm_remove (same as above, will this be necessary or even possible if our web site is on a hosted server?)
Cheers,
Daniel Westergren, Open Channel Vaxjo, Sweden
Comments
You can disable dependencies
You can disable dependencies you don't need in om_show's .info file. I'm going to be reconfiguring om_show for Austin this week. Ffmpeg_wrapper, ffmpeg_wrapper_remote, media_mover_api, mm_cck, mm_remove will all be removed as dependencies. In addition to those changes, I am moving the storage of the MPEG path away from filefields to textfields.
http://groups.drupal.org/node/75798
Adding licenses in addition to Creative Commons is a little different. You can add additional agreements with CCK checkboxes to the om_show content type, but the Creative Commons module is doing more than simply adding a select list. The license is actually included in the HTML and feeds as machine-readable RDFa. Even if you offered additional license, users would still need to select a CC license since that is the only license with any universal meaning. Users could select All Rights Reserved in the CC options and then give your station permission to air the content with an additional agreement, but that way om_show is configured now that show wouldn't be available online.
Maybe om_show should be a bit plainer?
Hey Guys,
I'll put this thought here as I think its sort of inline with what is written above.
I've been playing around a bit with the Open Media Modules especially in regards to Cablecast integration. I personally believe that om_show should be a bit more abstract than it is, and that overall some concepts in the Open Media system have a bit too much overlap.
I believe while there have been a few facilities that have gone 100% Open Media, they are rare, and much more common is going to be stations that want to start gradually. I think its great that The Open Media project has a thorough goal of the entire PEG facility landscape, but It would definitely help in adoptability if the modules were more modular (no pun intended) and that pieces could be added as needed / wanted.
What I see as ideal is that om_show does nothing but handle a show's meta data, nothing to do the physical files or VOD content. This would allow small stations that simply want to be able to add other non open media drupal modules such as voting and comments to there shows can do so easily. Additional modules that extend the om_show would allow for keeping track of files, VOD, and syncing with different vendors etc.
The other thing I've noticed, at least with Cablecast integration. Is there can be too many places where the same thing is going on. I personally think that keeping shows in sync between drupal and a Head End system, should only be done in one place (ideally a vender specific submodule of om_show).
Again, these are my .02 cents. I know I'm a late comer to the Open Media stuff, but I wat to contribute.
-ray
Nerd at work
@raytiley This is the
@raytiley This is the direction things are heading. Obviously it is more time consuming to write code that utilizes fields that may or may not be there. The original idea driving om_show was that it would always have a schedulable MPEG associated with it. Otherwise om_timeslot_scheduler always has to check to see if a show could be scheduled instead of assuming the show could be scheduled. om_show nodes without MPEGs were considered an error, but this was based on applying Denver's workflow based on Telvue playback servers everywhere. When we started configuring Open Media modules at stations with different playback servers, our approach was to make the network environments look as much like Denver's as possible and ask the playback server vendor to add the API options we already had available on the Princetons.
Now that there are more stations involved and no longer a single vision driving the direction of development, determining what is common and what is custom at each implementation is even more important.
After Austin, I'll commit a version of om_show and om_timeslot_scheduler that uses an _path field for image, h.264, and MPEG. These will be text fields, not filefields. Much like MERCI's evolution, I expect options like filefield, filefield_local, and media_mover would become a submodules for om_show the way merci_inventory, merci_permissions, merci_printable_contract, and even merci_ui became submodules of MERCI. Next week, you should be able to configure om_show with path or filefield support.
While I just added the CCK field formatter to remove the JWplayer configuration for the template, I'm going to move JWPlayer support into a submodule as well.
The new structure will look something like...
om_show - just the metadata. Still depends on pbcore and creative commons.
While this work is being funded by channelAustin to better leverage their Content Agent encoder and Synergy playback, it is also a step towards an om_show module that could leverage CC Uploader or something like it in a shared hosting environment.
Moving from filefield to a
Moving from filefield to a textfield is a step backward. I believe time would be better spent either back porting the media module to Drupal 6 or modifying the emfield module. As a lot of what needs to be done is already implemented in those modules.
Also, Media Mover has nothing to with filefield, unless it is used to do the format conversion. Even with the text field Media Mover can still be used to upload/download files to external media converters and CDNs.
Regardless. I would suggest at least using emfield for the on-demand filefield. We've already done this at DMA and it works well for storing both local and remote files. Media Mover is even used to populate the field. The thumbnail could still be a image field file as no reason to store those remotely. That leaves the original file. Which could as well be thrown into a emfield. Then the custom_url plugin could be rewritten to support the required third party hosters.
Filefield requires access to
Filefield requires access to the files. In configuration like Austin's, that's not an option. We already have the om_show with the path configuration running here with Content Agent and Synergy. channelAustin needs to have something running before responding to Austin's RFP to continue running the station in November.
No one is removing support for filefield... we are simply allowing support for non-filefield configurations. As well as om_show_media, om_show_emfiled or any other configuration someone wants to build on.
For installation, are you
For installation, are you planning to have the om_show_path/om_show_emfield/om_show_filefield/etc submodules add the fields to the om_show content type? I'm supportive of more options, but concerned that more submodules and fields to support regarding file locations increases the work to keep the rest of the modules integrated.
As darrick proposed, I'm wondering whether there is a downside to Austin using emfield as opposed to a plain text field? For storing non-local, not-directly-drupal-managed files we've had pretty good luck with emfield in the past... it seems like supporting filefield and emfield (which will both have a migration path to Media later on in 7), would cover both cases of external/not-drupal-managed and internal/drupal-managed.
Also curious -- will om_show_filelister replace filefield_local with one file-lister module that works with emfield/filefield and the textfield? Or will those all need to be submodules as well?
Open Media Foundation
If someone wants to write and
If someone wants to write and maintain an emfield module for om_show, great. I'm not as worried about migrating channelAustin to Drupal 7 as I am the station will lose the contract to operate their channels because we left them with an unusable configuration they could never support. In 4 hours today we were able to get video onto their site and into their Synergy.
Excellent! That fits well
Excellent! That fits well with our workflow too. For the record, I'll describe our current workflow, to see how best we'd use the OM tools.
That is, although we try to give as much power to our members as possible, we have realized it's simply not possible to ask them to do all the steps. Then it wouldn't get done and we would have much fewer shows to broadcast. With the OM tools we hope to automate much of our currently manual processes, such as transcoding, publishing shows on the web and scheduling. However, we will need to have much of the control of this process in the hands of the staff.
By the way, we use a TelVue Princeton video server, so broadcast synchronization will be great too.
I'm all for Ray's suggestions and am happy to read about the work being done in Austin. Looking forward to try out the new versions next week, to start moving our show database to Drupal.
And thanks Kevin for always great responses!