I have a WMV file that I need to host on my drupal 6.13 site (on ubuntu 9.x).
Is a there a relatively painless way to do this.
Do I need the "Video" module to do this?
Or can I just install a video player and point my WMV file to it?
My other concern is the user should be able to view this video on my site without needing to download anything, is WMV the appropriate format? I am worry about people viewing this on the mac and ios device.
Should I convert this to another format first?
Can I do all of the above with free software alone?
Thank a lot.
The de-facto standard, especially if you want to target iOS devices, is H.264: WMV is not going to cut it. Most Flash-based players (which you'll need for browsers like IE and Firefox that do not support H.264) also support H.264 video.
From a site administration standpoint, you'll need to either prevent users from uploading non H.264 video, or transcode the files once uploaded. This is not a trivial task, and you should use a contributed module for this. Video is probably the most far along in providing a turnkey video hosting solution.
There is also Kaltura, but it's a commercial service and they have historically failed to address privacy issues despite repeated warnings. There's a new maintainer in charge of the module, independent of the company, and the module may be safer to use than in the past.
Related
I have to propose a platform that allows streaming video services employing the MPEEG-DASH standard. This platform blocks must be implemented with open source tools. I proposed FFmpeg to encode and MP4Box/GPAC tool for encryption and packaging. For the DRM case my propose is to use Widewine (I didn’t find any other open source tool) which is compatible with dash.js (the player proposed by me), it can be integrated to Chrome and according to CastLabs it’s also compatible with MP4Box. So, I have to select an open source CMS, and at the same time I need it to be compatible with dash.js. I read that it’s possible to add any JavaScript to these CMS, that it’s only necessary to create some modules to do so. I’d like to know which one of the following CMS you suggest me: MediaDrop, Drupal or Wordpress.
I also have some doubts about the server. I know that in order to offer this service it only takes a traditional HTTP server. In a first moment I chose Nginx over Apache because the latter presents some problems associated to performance (the server will receive a large amount of simultaneous requests), nevertheless, I discarded Nginx (Nginx-rtmp module) due to its constraints: it’s only for live streaming (I need the service to be offered also on demand) and the inputs must be RTMP. I found something about Nginx-based VOD packager, do you know if this one can be used as a server to offer live and on demand streaming service?
when it comes to DRM you will need other systems than just Widevine to reach all browser platforms, e.g. PlayReady for IE/EDGE or FairPlay with HLS for Safari. Here you can find a overview of the DRM systems for the different browsers: https://bitmovin.com/player-drm-support/
When you already use ffmpeg + MP4Box to encode and package the content, you don't need a dedicated VoD packager support on your webserver, you can just the DASH/HLS content on the HTTP Webserver. Here you can find a tutorial for x264 + MP4Box, maybe that's useful: https://bitmovin.com/mp4box-dash-content-generation-x264/
I'm going to build a Classic Music website and the client already has several podcasts for about 3 min each, and I want to know if should I just add as QT / WMP file to listen and a ZIP to download, or should I use a web podcast hosting solution and just add the link to them?
...having full cross browser and os system (mac, windows, *nix, mobiles) in mind.
Thanks.
I'd recommend 3rd party hosting for the podcasts (mp3 files are the standard), and on the pages use a flash mp3 player on each podcast post, with a download link as well. Don't forget your RSS and iTunes either, subscriptions are a huge part of podcasting!
If you are expecting many downloads then hosting the files on your own site could run down your bandwidth pretty quickly. A third party host could solve this.
To keep costs down, start by hosting it yourself. The typical site is using WordPress and PodPress. Do release in MP3; any other formats is optional, but not really recommended these days. If you do host it yourself, just watch the downloads and plan to move to dedicated host as soon as you start getting popular.
Contact me offline if you have more questions. This isn't really a programming question.
Is there any reasonable method to allow users of a webapp to download large files? I'm looking for something other than the browser's built-in download dialog - the requirements are that the user initiates the download from the browser and then some other application takes over, downloads the file in background and doesn't exit when the browser is closed. It might possibly work over http, ftp or even bittorrent. Platform independence would be a nice thing to have but I'm mostly concerned with Windows.
This might be a suitable use for BitTorrent. It works using a separate program (in most browsers), and will still run after the browser is closed. Not a perfect match, but meets most of your demands.
Maybe BITS is something for you?
Background Intelligent Transfer
Service Purpose
Background Intelligent Transfer
Service (BITS) transfers files
(downloads or uploads) between a
client and server and provides
progress information related to the
transfers. You can also download files
from a peer.
Where Applicable
Use BITS for applications that need
to:
Asynchronously transfer files in the
foreground or background. Preserve
the responsiveness of other network
applications. Automatically resume
file transfers after network
disconnects and computer restarts.
Developer Audience
BITS is designed for C and C++
developers.
Windows only
Try freeDownloadManager. It does integrate with IE and Firefox.
Take a look at this:
http://msdn.microsoft.com/en-us/library/aa753618(VS.85).aspx
It´s only for IE though.
Another way is to write a BandObject for IE, which hooks up on all links and starts your application.
http://www.codeproject.com/KB/shell/dotnetbandobjects.aspx
Depending on how large the files are, pretty much all web-browsers all have built-in download managers.. Just put a link to the file, and the browser will take over when the user clicks.. You could simply recommend people install a download manager before downloading the file, linking to a recommended free client for Windows/Linux/OS X.
Depending on how large the files are, Bittorrent could be an option. You would offer a .torrent file, when people open them in a separate download-client, which is seperate from the browser.
There are drawbacks, mainly depending on your intended audience:
Bittorrent is rarely allowed on corporate or school networks
it can be difficult to use (as it's a new concept to lots of people).. for example, if someone doesn't have a torrent client installed, they get a tiny file they cannot open, which can be confusing
problems with NAT/port-forwarding/firewalls are quite common
You have to use run a torrent tracker, and seed the file
...but, there are also benefits - mainly reduced bandwidth-usage on the server, as people download also seed the file.
What's the best way for determining whether the user's browser can view PDF files?
Ideally, it shouldn't matter on the browser or the operating system.
Is there a specific way of doing it in ASP.NET, or would the answer be just JavaScript?
Neither, none, don't try.
Re dawnerd: Plug-in detection is not the right answer. I do not have a PDF plugin installed in my browser (Firefox on Ubuntu), yet I am able to view PDF files using the operating system's document viewer (which is not Acrobat Reader).
Today, any operating system that can run a web browser can view PDF files out of the box.
If a specific system does not have a PDF viewer installed and the browser configured to use it, that likely means that either it's a hand-made install of Windows, a very trimmed down alternate operating system, or something really retro.
It is reasonable to assume that in any of those situation the user will know what a PDF file is and either deliberately choose not to be able to view them or know how to install the required software.
If I am deluding myself, I would love to have it explained to me in which way I am wrong.
A quick google search found this. Useful for all kinds of plugins.
There are users that choose not to open PDF's in the browser and disable the plugin (this allows the file to be opened in the native application external of the browser window). It is better to let the user know that software is required to open something (whether it be PDF or not) than try to detect whether the plugin is available.
Another problem with detection is that what you need to look for changes from version to version (for example, see: "PDF.PdfCtrl.*" vs "AcroPDF.PDF.*" for the Adobe PDF viewer) and different browser implementations (the previously mentioned strings are used in IE for example, while Firefox uses a totally different manner of detection. Then we need to think of Opera and Safari and ???). Also, there are different vendors (think Foxit and Ghostscript, though I am not sure if they supply a plugin for the browser) where there may be differences in detecting the plugin.
For a script written in 2008 and some more information about the caveats see Detecting plugins in Internet Explorer (and a few hints for all the others).
After initially ignoring the advise on this page the architect went ahead with Acrobat detection, causing an inevitable support nightmare.
As ddaa mentions not all the scenarios can be accurately captured with Plug-in detection. Some users, for example, may choose to view PDF files with FoxIt Reader rather than acrobat. Some user's browsers don't flag that they are Acrobat ready, and certainly not always in the same way.
A better solution would have been to give the user a choice on how they'd like to view the relevant document. Personally, I don't like to have any website rely on a plug-in - it spoils the beauty of the web.
A quick glance at the present-day internet would seem to indicate that Adobe Flash is the obvious choice for embedding video in a web page. Is this accurate, or are they other effective choices? Does the choice of ASP.NET as a platform influence this decision?
Flash is certainly the most ubiquitous and portable solution. 98% of browsers have Flash installed. Other alternatives are Quicktime, Windows Media Player, or even Silverlight (Microsoft's Flash competitor, which can be used to embed several video formats).
I would recommend using Flash (and it's FLV video file format) for embedding your video unless you have very specific requirements as far as video quality or DRM.
Flash is usually the product of choice: Everyone has it, and using the JW FLV Player makes it relatively easy on your side.
As for other Video Formats, there are WMV and QuickTime, but the players are rather "heavy", not everyone might have them and they feel so 1990ish...
Real Player... Don't let me even start ranting about that pile of ...
The only other alternative of Flash that I would personally consider is Silverlight, which allows streaming WMV Videos. I found the production of WMV much better and easier than FLV because all Windows FLV Encoders I tried are not really good and stable, whereas pretty much every tool can natively output WMV. The problem with Silverlight is that no one has that Browser Plugin (yet?). There is also a player from JW.
One consideration would be whether video playback is via progressive download or streaming. If it's progressive download, then I would say use Flash because you get a wider audience reach.
For streaming wmv, it is out of the box functionality provided by Windows Media Services
For streaming flash, you will have to install a streaming server on your Windows box. Some options are:
Adobe Flash Media Server (Commercial)
Wowza Media Server (Free/Commercial)
Red5 Flash Server (Open Source)
If you have access to Microsoft Expression Encoder 2, you can use that to encode a video file and generate a Silverlight video player. Then if you have IIS 7, you can use Adaptive or Smooth Streaming also checkout Smooth HD for a really cool example.
You can also do streaming from the free Microsoft Silverlight Streaming Service. It's connected to a Windows Live account.
A consideration is that the client will need to have Silverlight installed, just like Flash, but Flash has been around longer.
<object width="660" height="525"><param name="movie" value="http://www.youtube.com/v/WAQUskZuXhQ&hl=en&fs=1&color1=0x006699&color2=0x54abd6&border=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/WAQUskZuXhQ&hl=en&fs=1&color1=0x006699&color2=0x54abd6&border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="660" height="525"></embed></object>
I have worked for a company that developed a system for distributing media content to dedicated "players". It was web based and used ASP.NET technology and have tried almost every possible media format you can think of and your choice really comes down to asking yourself:
does it needs to play directly out of the box, or can I make sure that the components required to play the videos can be installed beforehand?
If your answer is that it needs to play out of the box then really your only option is flash (I know that it is not installed by default, but most will already have it installed)
If it is not a big issue that extra components are needed then you can go with formats that are supported by windows media player
The reason why windows media player falls into the second option is because for some browsers and some formats extra components must be installed.
We had the luxury that the "players" were provided by us, so we could go for the second option, however even we tried to convert as much as possible back to flash because it handles way better than windows media player
"Does the choice of ASP.NET as a platform influence this decision?"
Probably not.