Showing posts with label flash. Show all posts
Showing posts with label flash. Show all posts

Saturday, March 26, 2011

Download Flash videos

Today there is a lot of websites with video contents. Most of them use flash as the platform to deliver the video contents to web browsers.

There can be many reasons to prefer to download the contents instead on watching them online, but unfortunately, many sites do only allow to watch the video contents while the user is connected to the corresponding website.

Older versions of flash player (previous to fall of 2010), just created a temporal file containing a cached copy of the video content. This way, getting a copy was an easy task: The user had just to locate the file containing the cached video to make a copy of such a file.

Current versions does not seem to create anywhere such a copy of the video.

In recent versions, such a file has been hidden trying to difficult to get a copy of the contents shown in the player. The trick is to use a deleted file as video cache. This way, the user is unable to find this file, at least in the usual way.

Here, we present a simple script whose goal is to get a copy of the deleted cache video file used by the flash player:


#! /bin/bash

RECPATH=/tmp
PIDS=`ps aux | grep libflashplayer | grep -v npwrapper | grep -v grep | awk '{print $2}'`
for PID in $PIDS
do
FFILES=`ls -la /proc/$PID/fd/* | grep Flash | awk '{print $8}'`
for FFILE in $FFILES
do
FNAME=`tempfile -d $RECPATH -p vid_ -s .flv`
cp -f $FFILE $FNAME
echo "Recovered file: "$FNAME
done
done


Usage:

Using your favourite editor, create a script with the above commands.
Place it on any convenient location (for all users, like /usr/sbin, or just for your own ~/scripts ), and do not forget to give it execution permissions, i.e:


$ sudo vi /usr/sbin/capture_flash


Copy the above lines to this file. You can change the destination folder location (/tmp in the sample script) or modify the script to receive the destination as a parameter.


$ sudo chmod +x /usr/sbin/capture_flash


Open your browser, point to a site containing a flash player. Let the player buffer the full video contents and then execute the script.


$ capture_flash


Now you will have a copy of the video being played in the embedded viewer. You can rename it, and eventually move it to a more convenient location.


Explanation:

First of all, the script obtains the PID of all running instances of flash player. The npwrapper is excluded, considering that you can be running the 32 bit version on a 64 bit system


PIDS=`ps aux | grep libflashplayer | grep -v npwrapper | grep -v grep | awk '{print $2}'`


The script iterates through the identified PIDs examining the file descriptors associated with every process. Flash cache files can be identifies easily since they are the only ones containing the pattern 'Flash' on their names. Here we obtain references to the deleted cache files (unreachable and invisible otherwise).


FFILES=`ls -la /proc/$PID/fd/* | grep Flash | awk '{print $8}'`


For every flash file identified, the script generates a unique name on the destination directory, and finally copies the file descriptor of the deleted cache file to an ordinary file.


FNAME=`tempfile -d $RECPATH -p vid_ -s .flv`
cp -f $FFILE $FNAME


You got it!

Note: The script has been successfully tested on Firefox 3.6.x and Chromium-browser 10.0.x with flash 10.2.x running on Ubuntu 10.04 x86_64. Comments and improvements are welcome.

Friday, September 17, 2010

Flash Player Square: Native 64 bit support

On 15 September, Adobe announced in a blog the availability of Flash Player Square: A preliminary release of a future version of Flash player offering full native 64 bit support.

You can find additional information about its features, as well as links to download this version on the Adobe website.

Since the installation instructions for Linux are rather terse, I wrote the following instructions for those wishing to install the player on computers with Ubuntu.

Install Flash Player "Square" on Ubuntu 10.04 x86_64




If we have a look to the filesystem of our computer running Ubuntu looking for the location of the Flash player related files, you will see references to it in multiple sites. We can also note that the installation has been done using the alternatives way, which we will benefit from in the installation of Square. Using alternatives we are going to install the prerelease version without removing the stable one. This is precisely the purpose of alternatives: To allow several pieces of software offering the same service to coexist without interfering to each other.

In the filesystem we can observe the following entries related to Flash Player (Remember that we are talking about a 64-bit distribution):

First, the library containing 32-bit version of the player:
/usr/lib/flashplugin-installer/libflashplayer.so


Furthermore, something to run the player through a wrapper. This wrapper allows the execution of 32-bit code on 64-bit environments:
/var/lib/flashplugin-installer/npwrapper.libflashplayer.so

And finally, the references used by various applications that may require the flash player:
/usr/lib/iceape/plugins/flashplugin-alternative.so
/usr/lib/iceweasel/plugins/flashplugin-alternative.so
/usr/lib/firefox/plugins/flashplugin-alternative.so
/usr/lib/midbrowser/plugins/flashplugin-alternative.so
/usr/lib/mozilla/plugins/flashplugin-alternative.so
/usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so
/usr/lib/xulrunner/plugins/flashplugin-alternative.so


Note that the previous references are just symlinks to files in the directory that stores the configuration of the alternatives tool:
/etc/alternatives/iceape-flashplugin
/etc/alternatives/iceweasel-flashplugin
/etc/alternatives/firefox-flashplugin
/etc/alternatives/midbrowser-flashplugin
/etc/alternatives/mozilla-flashplugin
/etc/alternatives/xulrunner-addons-flashplugin
/etc/alternatives/xulrunner-flashplugin


All these entries are also symbolic links. This time pointing to a single target: The 32-bit version of the player ready to be executed through the wrapper:
/var/lib/flashplugin-installer/npwrapper.libflashplayer.so


In the next steps, we are going to install the Square version of Flash player using alternatives. Doing thing in this way, we do not need to uninnstall the current version. Additionally, if something goes wrong we can easily go back to the stable version.

Installation steps:

Go to the download page from Adobe and get the 64-bit version for Linux.

Then, create an installation directory (with a name and location consistent with the stable version) in order to uncompress the new player there.
sudo mkdir /usr/lib/flashplugin-square
cd /usr/lib/flashplugin-square
sudo tar -xzf ~/Descargas/flashplayer_square_p1_64bit_linux_091510.tar.gz


Install the alternatives for those programs that are going to use the new player. Note that Firefox does not use the entry called firefox, but the mozilla one. If you want to do some testing with Firefox, just execute the following command:
sudo update-alternatives --install /usr/lib/mozilla/plugins/flashplugin-alternative.so mozilla-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60


Restart the browser and you will have the 64-bit flash player (version 10.2.161.22) ready to be used with no wrapper.

At any time we can switch between the two versions with the following command:
sudo update-alternatives --config mozilla-flashplugin


And finally, if we to use the Square version of Flash player in any other product, just repeat these operations for the product in question
sudo update-alternatives --install /usr/lib/iceape/plugins/flashplugin-alternative.so iceape-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60
sudo update-alternatives --install /usr/lib/iceweasel/plugins/flashplugin-alternative.so iceweasel-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60
sudo update-alternatives --install /usr/lib/firefox/plugins/flashplugin-alternative.so firefox-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60
sudo update-alternatives --install /usr/lib/midbrowser/plugins/flashplugin-alternative.so midbrowser-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60
sudo update-alternatives --install /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so xulrunner-addons-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60
sudo update-alternatives --install /usr/lib/xulrunner/plugins/flashplugin-alternative.so xulrunner-flashplugin /usr/lib/flashplugin-square/libflashplayer.so 60


After several tests we obtain excellent results: The player is very stable (no crashes) and everything seems to work properly.

If you want to do some kind of benchmark test or comparison, we recommend you to have a look to this site.

(You can find a Spanish version of this entry here)

Update (20110117): Updated the download link pointing to the new download location.

Monday, September 21, 2009

Flash Development on Linux (III): swc libraries

In this stage, we already know how to set up our Flash development environment on Linux, and how to compile basic programs in Flash (Actionscript).

If we intend to develop something a bit more advanced, it is very common to need precompiled libraries. These libraries are packaged in the form of .swc files, so we are going to know how to create such libraries, and how to use them once created.



The AXDT plugin form Eclipse includes a simplified version of the Flex SDK provided by Adobe. The SDK from Adobe includes additional tools, and in this scenario, in order to create a swc library, we need the component compiler (compc). This compiler can be found included with the Flex SDK tools.

The installation of such environment presents some minor difficulties that we are going to solve here:

First of all, we go to the Adobe website to download the open source Flex SDK. In this tutorial we have worked with the version 3.4.0.9271 (Aug 18, 2009)


$ sudo mkdir /opt/flex3

Then, we will choose an appropriate directory to unpack the compiler in such place. Notice the -a option: It is necessary in order to convert text files (CR/LF characters) properly.


$ sudo unzip -a -d /opt/flex3 flex_sdk_3.4.0.9271_mpl.zip

Optionally, you can remove the files on the bin directory intended for other platforms


$ sudo rm -f /opt/flex3/bin/*.exe /opt/flex3/bin/*.bat

Once uncompressed, we need to give the execution permissions to the files in the bin folder. The zip file definitely was created on a non-Linux system.


$ sudo chmod +x /opt/flex3/bin/*

To illustrate the usage of the component compiler, we are going to create the .swc library file corresponding to the Away3D library. Away3D is an open source flash 3D library which is quickly becoming one of the most popular Flash libraries on its field.

Once again, we download the source code of the library. Since we are developing for Flash 9, we download the 2.x version. If you intend to develop Flash 10 programs, you can go with the 3.x version. In our sample, we are working with the 2.4.0 version.

We create a directory for the library inside our workspace directory and uncompress there the away3D source code.


$ mkdir $HOME/workspace/away3d
$ unzip -a -d $HOME/workspace/away3d away3d_2_4_0.zip

The component compiler, apart from having a very limited documentation has a syntax a bit inconvenient. We can not indicate to the compiler to include all the classes under a directory tree, but we have to enumerate all the classes that we want to pack into the .swc file. In the case of the Away3D library, that means that the command line to invoke the compiler must contain the name of about 320 classes (including their package names).

To avoid that, we are going to create a compilation script in a more or less automated way. Since I am not an expert on shell scripts, suggestions on how to improve / ease this script are welcome.


$ cd $HOME/workspace/away3d
$ echo '/opt/flex3/bin/compc -compiler.source-path . -output ./away3d.swc -include-classes \' > compile_away3d
$ find . -name '*.as' | grep -v 'away3d/test' | sed -e 's/\.as/ \\/g' -e 's/\.\///g' -e 's/\//\./g' -e '$s/ \\//g' >> compile_away3d
$ chmod +x compile_away3d


The compile_away3d script file now has the command line necessary to compile the library, excluding the sample sources under the test directory. All we need to do right now is just to invoke the compilation script. Have a look inside it before if you are interested in a closer examination or do not worry about it if you just want to compile the library disregarding the details.


$ ./compile_away3d

Once in this step, if the compiler complains about a duplicate variable definition on the lensFlare.as file (line 118), everything is going right.

The as3 language manages the scope of the variables in a different manner than the usual one (as, for example in C++ or Java). Block scope does not exist, and the minimal scope for variables is the whole function. There is a bug related to that in the current latest stable version (2.4.0) of the Away3D library (the bug has already been corrected in the svn version), so we change a fragment of code in the lensFlare.as in order to avoid having a duplicate variable declaration. The change consists just in getting the variable declaration (ctVal) out of the conditions, and declare it just once.


if(useBurning && _burnClip)
{
var ctVal:Number;
if(_burnMethod == LensFlare.BURN_METHOD_BRIGHTNESS)
{
var bsVal:Number = 5*burnFactor/_projectionLength;
bsVal = bsVal < 1 ? 1 : bsVal;
bsVal = bsVal > 3 ? 3 : bsVal;
//TweenMax.to(_burnClip, 0, {colorMatrixFilter:{contrast:bsVal, brightness:bsVal}});
//TODO: setup colorMatrixFilter tween without TweenMax
ctVal = 500*burnFactor/_projectionLength;
_ct = new ColorTransform(1, 1, 1, 1, ctVal, ctVal, ctVal, 0);
_burnClip.transform.colorTransform = _ct;
}
else if(_burnMethod == LensFlare.BURN_METHOD_COLOR_TRANSFORM)
{
ctVal = 500*burnFactor/_projectionLength;
_ct = new ColorTransform(1, 1, 1, 1, ctVal, ctVal, ctVal, 0);
_burnClip.transform.colorTransform = _ct;
}
}


Now, the library compiles without any kind of problem. We will see the away3d.swc file (about 590KB size) on the current directory.

Wednesday, September 16, 2009

Flash development on Linux (II)

Once you have set up your Flash / Flex development environment on your Linux box, you are ready to compile your first application.

Open Eclipse with the AXDT perspective

Create your first project. This is done under the menu item File -> new -> AXDT project.... Give a name to your project and select a directory (usually under the directory that you chose as your workspace).



After the creation of the project, you can start to add your source files. The compiler supports both kind of files: as3 (ActionScript) as well as .mxml files. We are going to compile a sample from the AXDT site.

Go to the menu and choose File -> new -> AS3 file



Choose the folder to store the source file (usually src). Optionally you can organise your code in packages. Using packages is optional but becomes more necessary as you project grows. Better being used to manage packages from the beginning. The sources will be placed in a subdirectory tree structure according to the package structure. Finally, give a name to your source file: As in many other OOP languages, the file name must be the same as the name of the class defined in such source file.

After the creation of the source file, write down (or copy + paste) the file contents. At this point, your environment should look more or less like this:



Once created and saved your source file, you can compile it. Just click on the menu item Run -> Run As -> Compile and Open a SWF File. You will see some options to configure the compiler but do not worry about such options right now. You can maintain the default values.



If everything has gone right, you will see your Flash application running on the Eclipse IDE . The swf file created will be placed on the target location (default is deploy), so you can copy such file and publish it on your website.

Tuesday, September 15, 2009

Flash development on Linux

Recently I am getting more and more interested in flash development. Since the adoption of actionscript 3 (as3) as programming language Flash is becoming more and more a serious option to develop applications

The main inconvenient that I find is the fact that the development tools are almost just available for the Windows environment. This is an operating system that I stopped using almost two years ago, and I do not have any intention to come back to such family of operating systems.

I am into free software, so I will try to do flash development based on open source tools as much as I can.

This is my development environment:
A four years old Pentium IV based computer, running a 32 bit version of Ubuntu 9.04

Eclipse (you will need to have Java -JRE- installed in order to run Eclipse)
AXDT: This is a set of plug-ins for the Eclipse platform that enables the user to write ActionScript3 code in such a framework.

We can start having a look at the installation instructions on the AXDT site.

The first step is to download the "Eclipse IDE for Java Developers". In our particular case, we will choose the 32bit Linux version (eclipse-java-galileo-linux-gtk.tar.gz)

Then we will have to uncompress that somewhere on our hard disk. We have chosen to install it on the /opt directory.


$ sudo tar -C /opt -xzf java-galileo-linux-gtk.tar.gz


After that, we launch the Eclipse application. First thing will be to choose the workspace directory. We can maintain the default option: just a directory called "workspace" under our home directory.

In the menu, we choose Help -> Install new software...

Click on the "Add..." button, and type the following:

Name: Eclipse IMP
Location: http://download.eclipse.org/technology/imp/updates/



On the lower right corner of the main Eclipse window, you will see an indicator. The program is getting a list of available software components. Some seconds after that, it will show you those components. Do not choose anyone in this moment, and continue to the next step.

Name: AXDT
Location: http://update.axdt.org/



Choose (at least) the following packages:
Axdt AS3 Feature
Flex3SDK Feature



Then click on the "Next >" button, accept the licence and proceed to install the AXDT + Flex SDK framework.

If the system complains about unsatisfied dependencies or requirements, be sure to have installed the basic packages of the Eclipse base environment. I have found in some installations that such repositories are not initially enabled.

Name: Galileo
Location: http://download.eclipse.org/releases/galileo

Name: Eclipse project
Location: http://download.eclipse.org/eclipse/updates/3.5

Once installed, restart Eclipse

Go to the menu: Window -> Open perspective -> Other... -> AXDT



You are now ready to start to develop Flash / Flex programs on your Linux box. You can find a simple example of how to compile your first Flash program on Linux.

Thursday, February 19, 2009

Multiframe DICOM to Flash video

Following with the series of articles dealing with web based visualization of DICOM images, we are going to ilustrate a way of viewing multiframe ultrasound DICOM images.

As in the previous article, we have used just open source software for every action or transformation carried out.

This solution appeared in one ocasion when we were looking for a quick solution to share some cardiology studies among cardiologists. We wanted a solution with minimal software requirements, and fully multiplatform, in order to ease and promote the migration to open source workstations in public healthcare organizations.

One of the goals was to preserve the original quality of the contents, so we should preserve the original frame rate of the sequence as well as the original image quality (lossless transformations).



1.- The first step is to extract individual frames of the multiframe object. This step can be done using the dcmtk tools.

$ dcmj2pnm +Fa +ob multiframe.dcm /tmp/multiframe_


Use the +o modifier to indicate the output format. +ob to generate BMP, +on to generate PNG (You can test other available formats, but be careful to avoid loosy formats, such as Jpeg)

2.- Optional step: Obtain the frame-rate if you want to maintain the original values. I am not sure if the video format used (.flv) has a maximum allowed frame rate (59.94 is mentioned in some sites). O the other side, you will need a powerfull machine if you want to display the output at such high framerates. Anyway, you can alway create a slow motion version of the original content using lower framerates. If you choose this option, you must inform the user about the variation with respect to the original content.

$ dcmdump +P "0018,0040" multiframe.dcm


3.- Once you have done the extraction of the frames, you should convert the set of images to the desired video format (.flv in this example). We have tested with ffmpeg and mencoder. Both of them have their own advantages and limitations. Be sure to have the necessary codecs (flv) installed on your system.

Example 1: Assuming a framerate of 30 fps, bmp frames, and maintaining the original size (800x564 in our case).

$ ffmpeg -r 30 -i /tmp/multiframe_.%d.bmp -f flv -s 800x564 -sameq -an -r 30 multiframe.flv


Example 2: If you prefer to try with mencoder (png frames, 30 fps):
$ mencoder "mf:///tmp/multiframe_.%d.png" -mf fps=30:type=png -ovc lavc -lavcopts vcodec=flv -o multiframe.flv


Below, there is just an illustrative video, but you can see the full quality DICOM multiframe ultrasound video.

Saturday, February 14, 2009

Flash DICOM viewer

Some days ago, I passed the mark of seven years working in the field of healthcare related software. Due to the fact of working in this area, I have had the opportunity to learn about some topics and concepts that otherwise could remain just unknown for me. One of the topics that I find of particular interest is that related to medical imaging.

There has been a huge work during many years in order to create a standard for medical imaging. The result of such work is DICOM. At the begining most manufacturers preferred to tie their clients by the use of propietary and closed formats. Fortunately, in the last years most manufactures have chosen to follow the standards (with more or less success) opening a very interesting field for software development related to medical imaging.

One of the difficulties when dealing with DICOM imaging is the fact of having many differences compared to other image formats. In general, we can not use tools intended for other kind of images (such as those coming from digital cameras) to work with DICOM medical images.

The manufacturers of hardware equipment for medical imaging acquisition do usually provide their own diagnostic stations with specialized software, so the doctor (radiologist, cardiologist) can interpret the images.

Apart from the main diagnostics stage, it is often interesting to distribute images along with the medical report. If a doctor has derived a patient to radiology, the doctor would appreciate the inform with the results being attached to some key images. Given the fact that the medical data is evolving in order to replace the traditional paper by electronic reports, it becomes a necessity to provide remote access to medical imaging.

So, we can distinguish two kind of viewers: Diagnostic viewers, intended for those practicians that should emit a diagnostics from the examination of the image, and simplified viewers, intended just to allow the possibility of viewing the relevant imaging data, acting as a complement to the medical report.



If we want to achieve a fast and efficient deployment of an imaging viewing solution, we must consider a web based DICOM viewer. Since we are not dealing with simple imaging formats, we must consider environments able to act as RIAs (Rich Internet Applications), and that narrows a lot the available options.

For the development of a web based DICOM viewer, we can consider the following frameworks:
  1. DHTML: javascript, DOM, ...
  2. ActiveX
  3. Silverlight / Moonlight
  4. Java: In the form of Java Applet (browser embedded), Java Web Start applications or the new Java FX platform.
  5. Flash based viewer
Let us see the advantages and limitations of every possible option:
  1. The first option may have limitations in order to manage and being able to perform some tasks in DICOM images, such as lightning or darkening images.
  2. The second option (still adopted by many manufactures) has not ever been considered in our case, since one of the goals is to achieve a real multiplatform solution. That is a real must if we consider the fact that many public administrations and healthcare departments are migrating their systems to Linux based stations.
  3. The third one is something that deserves to be tested. If it is a real multiplatform environment, that can be an option for development of a web DICOM viewer in the form of a RIA.
  4. The option number four sounds really good. In fact a Java Web Start DICOM viewer would be a killer app in this field.
  5. The fifth option sounds good, but Flash (Actionscript) has many differences compared to Java: May be it is more limited as a programming language, but has many possibilities regarding the user interface and to present information to the user. We have chosen to start working in Flash, just to test what we can achieve.
Our first development was Stratos-viewer, a simple flash based DICOM viewer, but powerful enough in the cases where no advanced utilities were necessary. An online demo of the viewer is available.



Addendum (2009/02/18):
References to other flash based DICOM viewers: