Wednesday, August 24, 2005

Getting started with Postgresql 8.0.3

from http://robinbowes.com/article.php/20050628195431479

Install postgresql using yum:

# yum install postgresql postgresql-server postgresql-devel php-pgsql

Modify /etc/init.d/postgresql to use /home/postgres for the databases and to log to /var/log/postgres

# vi /etc/init.d/postgresql

#PGDATA=/var/lib/pgsql
#if [ -f "$PGDATA/PG_VERSION" ] && [ -d "$PGDATA/base/template1" ]
#then
# echo "Using old-style directory structure"
#else
# PGDATA=/var/lib/pgsql/data
#fi
#PGLOG=${PGDATA}/pgstartup.log
PGDATA=/home/postgres/data
PGLOG=/var/log/postgres/pgstartup.log

Create the data and log dir and set ownership:

# mkdir /home/postgres /var/log/postgres
# chown postgres:postgres /home/postgres /var/log/postgres

Start up postgresql

# service postgresql start

Change the superuser password:

# su - postgres

# psql -d template1 -U postgres -c "alter user postgres with password 'newpassword'"

Now modify pg_hba.conf (/var/lib/pgsql/data/pg_hba.conf):

# "local" is for Unix domain socket connections only
local all all md5
# IPv4 TCP/IP connections
host all all 127.0.0.1/32 md5

This allows access using the local unix socket or local tcp/ip connection but only for postgresql users.

Restart postgresql: service postgresql restart

Tuesday, August 23, 2005

MOVIESS logo/icon

here's our project's icon..

gawa ni Jenny Cheng yan..astig db?

Jen, minodify ko lang ng konte kc yung circular nde na mapapansin kapag niresize natin into 48px by 48px..:) sana ok lang po..:D



Sunday, August 21, 2005

Status report

Our application just run in nokia 6630.. yey! Though we haven't tried it on the other phones, it's ok we can proceed to the next step at least alam namin na medyo may mapupuntahan na kami. (applause!)

Now, we're looking for someone with nokia 7610. It's not our first priority but sana may makita kami ASAP para matest na rin yung application namin. Pag nagrun yung app namin sa nokia 7610, baka yun na lang bilin namin (IF EVER may pera kami) coz its cheaper. I wonder, kamusta na kaya yung request naming phone sa department.. :D

Next Step: Setup the Server
We decided to use linux as our server since yun yung mas malaking partition sa pc. So we have redhat and debian. kaso when i was just trying to install postgresql as our database daming error na nde ko maintindihan. I tried it again but no to avail. What I am planning is remove na lang yung debian/redhat and mag-install na lang ng fedora. That would be the fastest way I think para maayos na kagad ang server namin.

Progress Report – 2005-Aug-13

posted by LJ

When Jenny and I were just trying to make a program that records video from a mobile phone using the emulator, it displays "Record is null" (or a similar message). We thought that it was just because of the emulator. So we tried it also on a SE k500i and got the same result. We consulted Ms. Avestro regarding our problem. She said that not all Java phones support the MMAPI or only have partial support for it. We tried to come up with a solution and got the following:

1. Use Java and JNI to use C++ and access the camera.
Ms. Avestro told us that she had not encountered such a solution yet. Secondly, we cannot just use a Java phone using this implementation. If ever we go this path, we'll be needing a Symbian phone but this will only make the problem more difficult.
2. Research if we can use other java packages or specifications to achieve our goal.
We researched but couldn't find other technologies for the problem. It seems that J2ME is the only specification or package that can be used for video recording using Java.
3. Use pure C++.
The last option would be to use Symbian's C++ API to control the camera and record video clips. C++ will also be used to make the interface for the application. The downside to this approach is that only Symbian phones will be supported instead of the more common Java-enabled phones.

We have decided to go with option number 3. Ms. Avestro lent us some technical training material for development using the Nokia Series 60 API for C++. Therefore, we have to use a Symbian phone instead of a Java-enabled phone. We're looking for candidate phone units for the project. Right now, we're still deciding on what specific Nokia Series 60 phone to use. The decision probably won't be made until we are sure that we can successfully record video clips using our application. We are currently studying the Nokia training material.

Jenny and I have already done some GUI applications using Nokia's SDK and Emulator. We haven't tried it on a live phone, though. The SDK already has a library for controlling the camera but we're a bit concerned if it will work on a real phone and go back to our previous problem about controlling the camera.

Our lab computer already has the needed applications for mobile development. The installed applications include ActivePerl, Visual Studio 6, Nokia Development Suite and a JRE version 1.3.1 for the Nokia tools.

Saturday, August 13, 2005

ARMI, ARM4 and Thumb

Full article here.

There are currently three build variants for ARM based devices—ARMI, ARM4 and Thumb.

ARMI executables will work with the other two build variants. Typically you should build the ARMI binary executable variant for compatibility with the maximum number of real devices.

ARM4 builds give maximum performance at the expense of increased code size.

Thumb builds will reduce the code size at the expense of a slight reduction in execution speed.

Thursday, August 04, 2005

Updates!

Media Format: 3gp vs. Mpeg

In our project, we need a streamable media format. Both 3gp and Mpeg are in this form.

Why streamable? Because in streamable format, we do not have to wait until the recording is complete -- we can already transmit, play or save the recorded data while the recording is in progress. No local buffering is required. And this is what we need.

Implementing Video Recording

RecordControl is one of the more difficult controls to provide since it requires a video encoder, preferably capable of real-time encoding. In addition to encoding the video, it should be capable of encoding any related audio stream and ensure that the resulting file or stream has the audio and video streams interleaved and synchronized for later presentation.

If the source stream is already compressed, synchronized, and streamable, then the RecordControl might only need to copy the original stream from the appropriate point in the media and insert any required headers and footers to the stream. This makes the file complete and playable at a later time. In the case of MPEG, all packet headers must be modified with new timestamps. There might be similar issues with other media types. For example, the QuickTime file format requires an index chunk that contains byte positions of individual frames of video. The MMAPI RI does not provide a RecordControl for the MPEG video player.

Note that recording is an optional part of MMAPI. If an implementation does not support recording, it will return null when the user tries to obtain a RecordControl object by using player.getControl("RecordControl"). An implementation might support recording only for a subset of formats. For example, it might support file writing for a WAVE audio player but not for an MPEG video player.



Friday, July 22, 2005

Nokia Developer's Suite for J2ME™, Version 2.0

View the complete article
The key features of the Nokia Developer's Suite for J2ME™, Version 2.0 are:

Full development cycle when integrated into Borland JBuilder and Sun ONE Mobile Edition
Also works in stand-alone mode with additional external tools
Support for MIDP 1.0 and MIDP 2.0
Series 60 MIDP Concept SDK Beta 0.3, Nokia edition
Deploys on devices using IrDA, USB, and RS-232 (Windows)
FTP-upload capability, including WML deck
Supports application signing with public/private key model
Audio converter
Support for Series 30, Series 40, and Series 60 devices

Taking Pictures with MMAPI

view the complete article

The Mobile Media API (MMAPI) enables MIDlets to play and record audio and video data. The exact capabilities depend on the device implementation. Currently the only device that supports MMAPI is the Nokia 3650 mobile phone. This article describes how to build a simple camera application using MMAPI.

Tools for MMAPI Development

The first challenge of building an MMAPI application is finding the right tools. The J2ME Wireless Toolkit 2.0 includes support for MIDP 2.0, MMAPI 1.0, and WMA 1.1. At first glance, it looks like this is all you need — but the Nokia 3650 runs MIDP 1.0, not MIDP 2.0. To develop MIDP 1.0 applications, you'll need the 1.0.4 version of the J2ME Wireless Toolkit and an emulator that supports MMAPI.

Sun offers such an emulator, available from the MMAPI home page. While this emulator will allow you to build MMAPI applications, it does not support image capture, so it can't be used to test a camera application.

Nokia has an emulator that does support image capture, part of the Nokia Series 60 MIDP Concept SDK Beta 0.2, available from Forum Nokia, Nokia's developer web site. The file name is nS60_jme_concept_sdk_b0_2_014.zip. Linux developers should be able to use the Nokia Developer's Suite for J2ME, Version 2.0. The following installation instructions apply to Windows only.

Install the Nokia SDK in the \wtklib\devices directory (or copy the Nokia_Series_60_MIDP_Concept_SDK_Beta_0_2 directory there after installation is complete). Next time you run the J2ME Wireless Toolkit, you'll have an additional emulator available, Nokia_Series_60_MIDP_Concept_SDK_Beta_0_2. When this emulator is selected, you can build MMAPI applications and test them as well. The emulator itself looks very much like the Nokia 3650.

MMAPI Device Testing

There's no substitute for testing on real devices. In the long term, many devices will support MMAPI, even though the Nokia 3650 is the only MMAPI device available just now.

There are several ways to deploy a MIDlet on the Nokia 3650. I transfer files via infrared between my laptop and the device. You can also use Bluetooth or do an OTA installation.

Getting a Video Capture Player

The first step in taking pictures (officially called video capture) in a MIDlet is obtaining a Player from the Manager. A special locator, capture://video, indicates that pictures will be captured from the camera using a default image size.

mPlayer = Manager.createPlayer("capture://video");

If the device does not support video capture, a MediaException will be thrown. You can check ahead of time to see whether video capture is supported; if it is, the system property supports.video.capture will be true.

The Player needs to be realized to obtain the resources that are needed to take pictures. If you haven't learned or don't remember what "realized" means, read through Mobile Media API Overview or The J2ME Mobile Media API.

mPlayer.realize();

Showing the Camera Video

The video coming from the camera can be displayed on the screen either as an Item in a Form or as part of a Canvas. A VideoControl makes this possible. To get a VideoControl, just ask the Player for it:

mVideoControl = (VideoControl)
mPlayer.getControl("VideoControl");

If you wish to show the video coming from the camera in a Canvas, initialize the VideoControl, then set the size and location of the video in the Canvas, then make the video visible. The following example (the constructor of a Canvas subclass) shows how to place the video two pixels in from the sides of the Canvas. If the incoming video cannot be placed that way, the constructor tries using the full screen. Finally, it calls setVisible() to make the camera video visible.

public CameraCanvas(SnapperMIDlet midlet,
VideoControl videoControl) {
int width = getWidth();
int height = getHeight();

mSnapperMIDlet = midlet;

videoControl.initDisplayMode(
VideoControl.USE_DIRECT_VIDEO, this);

try {
videoControl.setDisplayLocation(2, 2);
videoControl.setDisplaySize(width - 4, height - 4);
}
catch (MediaException me) {
try { videoControl.setDisplayFullScreen(true); }
catch (MediaException me2) {}
}
videoControl.setVisible(true);
}

Showing the camera video in a Form is slightly different. Instead of calling VideoControl's initDisplayMode() method with USE_DIRECT_VIDEO, use the USE_GUI_PRIMITIVE value instead. On MIDP devices, you'll get back an Item you can place in a Form to be displayed.

Form form = new Form("Camera form");
Item item = (Item)mVideoControl.initDisplayMode(
GUIControl.USE_GUI_PRIMITIVE, null);
form.append(item);

Progress Report

Video Streaming: A Preliminary Report
Jenny Cheng, Jeffrey Louie Quiambao, Lily Joy Regalado

Since it has already been agreed upon by J2L, JSP and our thesis adviser that the media format to be used is 3gp, our group has been researching on technologies that we might possibly use and other related issues.

Introduction to Streaming

We have found steps in processing a video and a few related literature:

1. Acquiring a video is basically shooting a scene with a camera or gathering pre-recorded content.
We have found that MMAPI (Mobile Media API) can control a camera, audio, etc. It has also method that can set the location where to save the video. Video is fetched in this location and uploaded to the server.

2. Capturing the video includes digitizing the video into a standard format.

3. Editing the video. If broadcasting live, this can be the encoding of the streaming video directly from the source.
Editing the video means avoiding certain types of transitions and keeping the scene changes to a minimum to improve video encoding. In live streaming, this stage is skipped.

4. Encoding the clip is the encoding the source into streaming format, targeting network bandwidth(s) or set of bandwidths and choosing a codec.
Compressing or encoding the video is the process of altering the file to reduce its size. Usually, the resulting transformed digitized video file from recorded video is far too big to transmit over the Internet. Our target media format is 3gp. Most of the mobile phones support 3gp format. 3gp is already in a streaming format. It is also popular because it has a smaller size than other media formats, therefore no more encoding operations will be performed.

5. Mounting to server is streaming all relevant files to the streaming server.
We are looking at the Darwin server, an open source server for streaming via RTP or HTTP.

6. Delivering a clip. If the presentation is ready, it is in this stage when the clip made or broadcasted to different devices.

On this six stages, we are deeply looking at the first five stages, delivering the clip from the server to different devices are not very much of our concern.

Setting-up Video Streaming

The following is an option for our group:

1. Download & install Darwin Streaming Server (DSS) from http://developer.apple.com/darwin/projects/streaming/. It is an open source application.
2. Convert current video and audio files to 3GP file.
3. After the video file has been converted to a 3gp file, we can now upload it into the Darwin Streaming Server.
4. To then view it on phone, it must have Internet access. Enter the address of the server e.g. rtsp://my-server/my-file.3gp

We had to address the following issues: platform and media format. We chose Linux to be our platform.

File format is the wrapper for the encoded tracks within the file. There must be a sort of coherency between file format and codecs. The format is important for the server, because it must understand how to handle data in the file and how to properly packetize them according to RTP standards. For example Darwin needs hinted files, but other servers don't. Formats are MP4/3GP, codecs are Mpeg4 or H.263, and protocols are SDP/RTSP/RTP. So, for file based streaming, the file format is important because the streaming server must understand it, but for live streams, the file format does not exist, instead the server must know how to handle the streams, which arrive live from the encoder. As it was said before, we have agreed on using 3GP.

Outsourcing streaming services

We are looking at the differences between Live and On Demand. To stream live content in real time, we’ll need an application powerful enough to encode in real time. This is more expensive than encoding for archival purposes, wherein the media content is stored on a streaming server and is delivered on demand when an end user makes a request, and hence real time encoding is not required. Content that is streamed live is usually also recorded for archival purposes and can actually be enhanced with good editing tools for future playback.



References:
Tips For Capturing. Retrieved July 15, 2005 from http://www.clickandgovideo.ac.uk/capturing2.htm

Steaming Video: Thery, processes and Applications. Retrieved July 13, 2005 from http://aaaprod.gsfc.nasa.gov/teas/TEASStreamingVideo.ppt

Popwire. Retrieved July 13, 2005 from http://www.pats.no/events/workshop1/presentasjoner/ARTS%20pre%20March%200319.pdf

http://www.mobiledia.com/forum/topic30163.html

http://www.via.ecp.fr/via/ml/streaming/2005-05/msg00009.html

Tuesday, July 19, 2005

Suggested outline for Research Plan

from http://www.cau.edu/acad_prog/comp_sci/comp_sci_grad.html

1. Statement of Research Question
2. Why is this important or interesting?
3. What are some of the issues that need to be addressed?
4. What is the approach to the problem? (General Approach)
5. Detail related or background work
6. Detail the work done to date
7. Detailed Research Plan
8. Research Schedule

Next Deliverable

on July 23
Submit article summaries (literature search) and research plan
(e-mail to spancho@acm.org)