Friday, March 31, 2006


0 Abstract

0 Acknowledgment

1 Introduction
1.1 Statement of the Problem
1.2 Objectives
1.3 Scope of the Study
1.4 Significance of this Study

2 Review of the State of the Art
2.1 Security
2.1.1 AES - Advanced Encryption Standard
2.1.2 CBC - Cipher Block Chaining
2.1.3 RSA - Rivest-Shamir-Adleman
2.1.4 MD5 - Message Digest 5
2.2 Streaming
2.2.1 HTTP - Hypertext Transfer Protocol
2.2.2 RTP - Real-time Transport Protocol
2.2.3 J2ME - Java 2 Micro Edition
2.2.4 Wireless Toolkit
2.2.5 Nokia Prototype Standard Development Kit
2.3 Video Sharing
2.3.1 [Existing Mobile Streaming]
2.3.2 [Existing Webapp Streaming]

3 Methodology
3.1 Cryptosytem
3.1.1 Registration
3.1.2 Transmission
3.2 Streaming
3.2.1 Request - Reply
3.2.2 Transmission
3.2.3 Playback
3.3 Profiles
3.3.1 User
3.3.2 Video

4 Experiments and Analysis
4.1 The HAMSTER Video Database
4.2 Performance of Public Key Cryptography
4.3 Performance of AES
4.4 Performance of HTTP Streaming

5 Conclusions
5.1 Conclusions
5.2 Summary of Contributions
5.3 Future Research

6 References

7 Appendices
A Acronyms
B Screenshots
C Developers Manual
D Users Manual

Friday, March 24, 2006


Baka meron pang ibang ganito dito.

Wednesday, March 22, 2006

Prefetching and Buffering

Saturday, March 18, 2006

Nokia Untrusted Domains

May prob sa Nokia ang app natin kasi hindi pwedeng magdownload at i-write sa phone memory. Viewing lang. So webapp na lang ang downloading. Or i-bluetooth. SERVER-->PHONE-->PC.

Magkakaroon din tayo ng problem sa decryption/encryption dahil may temp variables ako na nagwrite kasi important siya sa pagconvert ng int[] array to streams.


Friday, March 17, 2006


Ei, pwede po ba tayong makagawa ng Icons for our SINFINITY Mobile forms, :D

Dun po sa candy icons (parang dun sa Pintig), sana makagawa po for Sinfinity.

a. Sinfinity logo (small, medium, large)
b. Online and offline users logo parang smileys sa YM (small)
c. Stream Video [view-only] (medium)
d. Download Video (medium)
e. Generic bullets for list (small diff colors)
f. Generic arrows. (small) Kasi na-implement ang first, 2nd, 3rd degree friendship.
g. Sign-up logo (small, medium, logo)
h. Login logo (medium)
i. Connecting... Waiting... "timer / gauge" gif (medium)
j. Video logo (medium, large)
k. Friends logo

Nice din sana kung meron tayong Nokia THEME. Di ba may THEMES ang MMS Nokia phone. Sana meron ding SINFINITY theme. Mayroong THEME-creator ang Nokia SDK. :D Parang ito yung magiging Wallpaper or Background desktop ng Nokia Main menu. :D Try ko ring aralin since meron naman tayong SINFINITY logo.


Di ba ang HAMSTER is the platform. Iba pa rin yung services, right?
Kaya nabuo ang SINFINITY, right? So given ang HAMSTER, marami tayong services na
pwedeng gawin right? Sa Feb 25 at possibly sa URC, gusto ko sana
i-propose the following services...

1. SINFINITY -- siyempre ito ang Service Foundation. Iniisip ko na yung one-stop sign-in sa lahat ng services. Parang yung SINFINITY kasi ang storage and sharing service natin. So kapag nag-sign sila sa service natin, pwede na rin nilang makuha yung ibang services.

2. MOR.PH or MORF ( MObile Reality PHilippines or MObile Real Feed ) - a.k.a. RSS/XML feed with Video Streaming. So depende sa categories na gusto mong matanggap, may darating sa yung Broadcast Messages. So kung News, Sports... Tapos kung gusto mo siyang ma-view, eh di i-HAMSTER natin.

3. VBOX, BlogBOX (Videoke Bluetooth On-the-go Xtreaming) - Bluetooth On-the-go Xtreaming is an extension of our HAMSTER. Pwede kasi yung isang node dun sa piconet ay nakaconnect sa HTTP so parang siya ang MASTER sa piconet na yun, tapos pwede niyang i-stream ang video files in its network. Tapos yung video file na ito ay Videoke! Inspired by KMast ng 165 Juniors at ng All-Star K! Pwedeng solo o group videoke singing. Tapos depende sa genre/artist na trip ng isa o ng grupo, darating sa kanila ang available na videoke.

Ayun po.

Hindi ko naman po ni-rerequire kayo na gumawa pa ng classes or mag-code for 2 and 3. In fact, ok na ang SINFINITY. I believe din na mas mapakita pang lalo ang kagandahan ng HAMSTER if we feature other services.

Actually yun pong 2 and 3 eh akin pong future development projects . Nilahad ko lamang po dito baka kasi magulat kayo sa presentation / demo kapag isinama ko. Ayaw ko namang maka-offend. Yung BOX Bluetooth On-the-go Xtreaming na rin kasi ang magiging basis ng master's thesis (nyak! ang aga!) seriously at freelance softdev (lagot sa HP!)

The table is open naman for other services na maisip ninyo. Naaalala ninyo ba ang mga possible applications na cite natin sa marketing congress? We can create our own service development project for each field di ba?

Ayun po.

Nokia Development


1. Carbride_j_v1_0_1
2. nS60_jme_sdk_3rd
3. nptsdk_jme_v4_0

Installation Options:

Select 'Integrate with Eclipse'


Currently, we're experiencing problems with Nokia supported classes. Kahit na gumagana ang classes natin sa J2ME. We have to tweak the code to support Nokia platform. Ang obvious pa lang na nakikita ko ay ang FileConnection classes. Ito dapat ang ginamit at hindi ang Classes. Hindi pa ako sure sa ibang classes na kailangan i-tweak. But this is (kinda) frustrating. Of course, we all want to deploy these stuff sa Nokia phone ni Phillip at ng Globe di ba?

If hindi mahabol sa 25, mapipilitan akong gumamit ng Bluetooth. So from the emulator phone, stream niya ito to Bluetooth-enable device. Parang yung sa Pintig natin. Disappointment.

Pero hindi naman dapat makaapekto ito. Motivated pa rin naman dahil at least tapos na ang 'HAMSTER Foundation' or the basic functionalities.


Thursday, March 16, 2006


1. Finally, nagawa ko na rin ang Player ng video stream
2. We don't need the XML thingy na. Although, maganda talaga ang XML, pero magastos sa bytes. I mean, mas hahabang DataStream ang isesend kesa sa 'bulok'-y way / protocol.
Kahit separated with colon ':' lang yun the least number of bytes naman. 25Cents din yun kada kb.

TroubleShooting File Transfer

Wednesday, March 15, 2006

New Assignment

1. To handle a graceful exit among Socket Multithreaded Server and Socket Clients.

Here's where the SignUpModule got its base code.

Currently, the exit is so 'bulok'-y.

Kapag nagclose ang isang client, namamatay din ang server dahil magkakaroon ng IOException na result ng exit ng client. The server should always run. Kahit ilang mag-connect and disconnect sa kanya.

Kailangan magclose ni client, dahil sa SignUp process natin, after niyang mareceive ang ACK. User can exit na.

2. See '24 - Final Season' post below.

3. I'm handling 0002 and 0003. Yung 0002, tulad ng nabanggit ko dati, depende sa SQL queries ang magiging form ng forms. Yung 0003. Ang problem ay yung transmission. May narereceive naman na packets from the server. Pero hindi ma-realize ng player ang stream maybe due to packet loss or reordering. Or sobrang laki ng files. Kaya kailangan ng buffering / prefetching.

4. If hindi pa rin ma-handle ang 0003, i'll try RTP and ProxyServer T_T . Yung Proxyserver ang nasa gitna ng mobile at HAMSTER server para maghandle ng packets.

5. Yung 0005. Hindi pa magagawa kasi dapat ma-ensure na nareceive nang tama ang packets.

Basically, once natapos ang [0001] o [0002 at 0003], notify. Para malaman kung anong module ang pwedeng gawin. It can be a module na hindi nakalista dito.

6. Gusto ko na sanang matapos ang [0001] at [0002 at 0003] kasi we can start document na. After kasi nito, na-solve na natin prob stated. Optimization na lang. Tapos we can add several SQL queries and additional web services. This is when we sell our project based on our features and services.

The Past

Why XML for future work?

Current HAMSTER client and server protocol in exchanging requests and responses is SO primitive. So 'bulok'-y.

Strings are upstreamed with the following format.

[response/request code]:[command1]:[command2]...[commandN]

Once received, they are tokenized.
Then, conversion is needed. Integer.parseInt() and so on.

But with XML...

XML as a Message Format


One of the major uses of XML is for exchanging data between heterogenous systems. Given almost any collection of data, it’s straightforward to design some XML markup that fits it. Since XML is natively supported on essentially any platform of interest, you can send data encoded in such an XML application from point A to point B without worrying about whether point A and point B agree on how many bytes there are in a float, whether ints are big endian or little endian, whether strings are null delimited or use an initial length byte, or any of the myriad of other issues that arise when moving data between systems. As long as both ends of the connection agree on the XML application used, they can exchange information without worrying about what software produced the data. One side can use Perl and the other Java. One can use Windows and the other Unix. One can run on a mainframe and the other on a Mac. The document can be passed over HTTP, e-mail, NFS, BEEP, Jabber, or sneakernet. Everything except the XML document itself can be ignored.



Yes, we can store and retrive BLOBs into and from database!

But they're gone after the transaction.



In Postgres, Large Objects are very special beasties. To create them special lo_create function is used that stores the result in a regular table. Large object support is broken in Postgres - pg_dump cannot dump LOBs; you need
to develop your own backup mechanism. To export Oracle raw data type it has to be the latest version of postgres jdbc driver. jdbc7.1-1.2.jar.does not work. Also, autocommit should be off, because the LargeObject reference is only valid within a transaction. As soon as the sql is executed to get the large object reference, it is autocommitted and then this reference can't be used anymore since the transaction ended. To turn autocommit off use the setAutoCommit() method in Connection:
Connection con = DriverManager.getConnection(url,user,password);

Switch to MySQL?

Not yet. Future work na lang. Let's store na lang the directory path where the video and thumbnail is stored.

Advantage: Encryption and decryption become easier. I suppose.

Tuesday, March 14, 2006

Documentation Template & Req

A Generic Thesis Skeleton
1. Introduction

This is a general introduction to what the thesis is all about -- it is
not just a description of the contents of each section. Briefly summarize
the question (you will be stating the question in detail later), some of
the reasons why it is a worthwhile question, and perhaps give an overview
of your main results. This is a birds-eye view of the answers to the main
questions answered in the thesis (see above).

2. Background Information (optional)

A brief section giving background information may be necessary, especially
if your work spans two or more traditional fields. That means that your
readers may not have any experience with some of the material needed to
follow your thesis, so you need to give it to them. A different title than
that given above is usually better; e.g., "A Brief Review of Frammis

3. Review of the State of the Art

Here you review the state of the art relevant to your thesis. Again, a
different title is probably appropriate; e.g., "State of the Art in Zylon
Algorithms." The idea is to present (critical analysis comes a little bit
later) the major ideas in the state of the art right up to, but not
including, your own personal brilliant ideas.

You organize this section by idea, and not by author or by publication.
For example if there have been three important main approaches to Zylon
Algorithms to date, you might organize subsections around these three
approaches, if necessary:

3.1 Iterative Approximation of Zylons
3.2 Statistical Weighting of Zylons
3.3 Graph-Theoretic Approaches to Zylon Manipulation

4. Research Question or Problem Statement

Engineering theses tend to refer to a "problem" to be solved where other
disciplines talk in terms of a "question" to be answered. In either case,
this section has three main parts:

1. a concise statement of the question that your thesis tackles
2. justification, by direct reference to section 3, that your question is
previously unanswered
3. discussion of why it is worthwhile to answer this question.

Item 2 above is where you analyze the information which you presented in
Section 3. For example, maybe your problem is to "develop a Zylon
algorithm capable of handling very large scale problems in reasonable
time" (you would further describe what you mean by "large scale" and
"reasonable time" in the problem statement). Now in your analysis of the
state of the art you would show how each class of current approaches fails
(i.e. can handle only small problems, or takes too much time). In the last
part of this section you would explain why having a large-scale fast Zylon
algorithm is useful; e.g., by describing applications where it can be

Since this is one of the sections that the readers are definitely looking
for, highlight it by using the word "problem" or "question" in the title:
e.g. "Research Question" or "Problem Statement", or maybe something more
specific such as "The Large-Scale Zylon Algorithm Problem."

5. Describing How You Solved the Problem or Answered the Question

This part of the thesis is much more free-form. It may have one or several
sections and subsections. But it all has only one purpose: to convince the
examiners that you answered the question or solved the problem that you
set for yourself in Section 4. So show what you did that is relevant to
answering the question or solving the problem: if there were blind alleys
and dead ends, do not include these, unless specifically relevant to the
demonstration that you answered the thesis question.

6. Conclusions

You generally cover three things in the Conclusions section, and each of
these usually merits a separate subsection:

1. Conclusions
2. Summary of Contributions
3. Future Research

Conclusions are not a rambling summary of the thesis: they are short,
concise statements of the inferences that you have made because of your
work. It helps to organize these as short numbered paragraphs, ordered
from most to least important. All conclusions should be directly related
to the research question stated in Section 4. Examples:

1. The problem stated in Section 4 has been solved: as shown in Sections ?
to ??, an algorithm capable of handling large-scale Zylon problems in
reasonable time has been developed.

2. The principal mechanism needed in the improved Zylon algorithm is the
Grooty mechanism.

3. Etc.

The Summary of Contributions will be much sought and carefully read by the
examiners. Here you list the contributions of new knowledge that your
thesis makes. Of course, the thesis itself must substantiate any claims
made here. There is often some overlap with the Conclusions, but that's
okay. Concise numbered paragraphs are again best. Organize from most to
least important. Examples:

1. Developed a much quicker algorithm for large-scale Zylon problems.

2. Demonstrated the first use of the Grooty mechanism for Zylon

3. Etc.

The Future Research subsection is included so that researchers picking up
this work in future have the benefit of the ideas that you generated while
you were working on the project. Again, concise numbered paragraphs are
usually best.

7. References

The list of references is closely tied to the review of the state of the
art given in section 3. Most examiners scan your list of references
looking for the important works in the field, so make sure they are listed
and referred to in section 3. Truth be known, most examiners also look for
their own publications if they are in the topic area of the thesis, so
list these too. Besides, reading your examiner's papers usually gives you
a clue as to the type of questions they are likely to ask.

All references given must be referred to in the main body of the thesis.
Note the difference from a Bibliography, which may include works that are
not directly referenced in the thesis. Organize the list of references
either alphabetically by author surname (preferred), or by order of
citation in the thesis.

8. Appendices

What goes in the appendices? Any material which impedes the smooth
development of your presentation, but which is important to justify the
results of a thesis. Generally it is material that is of too nitty-gritty
a level of detail for inclusion in the main body of the thesis, but which
should be available for perusal by the examiners to convince them
sufficiently. Examples include program listings, immense tables of data,
lengthy mathematical proofs or derivations, etc.

Comments on the Skeleton
Again, the thesis is a formal document designed to address the examiner's
two main questions. Sections 3 and 4 show that you have chosen a good
problem, and section 5 shows that you solved it. Sections 1 and 2 lead the
reader into the problem, and section 6 highlights the main knowledge
generated by the whole exercise.

Note also that everything that others did is carefully separated from
everything that you did. Knowing who did what is important to the
examiners. Section 4, the problem statement, is the obvious dividing line.
That's the main reason for putting it in the middle in this formal

Now, on to the last two requirements for CS 199, which are:

(1) Final demo

(2) Final bound copies of the thesis report

You have to finish (1) before you submit (2), but you can e-mail to me
drafts so that I can review (2) before you print and bind the report.

For (1), each group is asked to e-mail me their preferred date to demo
their application. The possible dates are: March 15, 18, 22 and 25.
The demo will be done during CS 199 class hours.

What is involved in a demo? You have to give me, on a CD or thumb
drive, an installer for your applications, with installation
instructions (text file also on the CD) if necessary. I should be able
to install and run your application from scratch. Please prepare test
data if it's necessary for your application (sample video clip, sample
malware, etc).

For (2), you have to give two hard-bound copies of the thesis report
by Saturday, April 1. The report should also include a CD with an
installer of the applications, the source code with compilation
instructions, and a soft copy of the thesis report in PDF format.

The Latex template for (2) is in the Files section of our Yahoo groups.

Please take note of the deadlines, particularly graduating students
whose grades are due by April 3.



to be encrypted:



video table except thumbnail and content

24 - Final Season


0001 Handle Graceful Exit of SocketServer and SocketClient
0002 Player(InputStream)
0003 Mobile Forms + SQL Query
0004 XML
0005 Encrypt / Decrypt Entities
0006 Bluetooth
0007 Push Registry
0008 Session


0001 Documentation

Storing Binary Data

Monday, March 13, 2006

Final Stretch

Date : Task

12 : Documentation (MIDlet, HTTPConnection)
13 : Develop - ServerSocketConnection (Client, Multithreaded Server)
: Integrate - RSA (Decrypt, Encrypt)
: Integrate - TEA (Decrypt, Encrypt)
: Integrate - MD5
14 : QualityCheck - HTTPConnection
: Integrate - AES (Encrypt, Decrypt)
: Develop - Mobile Forms
15 : Integrate - Data Access
16 : Develop - Bluetooth
17 : Develop - Push Registry
18 : Develop - Session
19 : Documentation (AES, RSA, Socket)
20 : Deployment - Nokia 6630
21 : Deployment - Nokia 6630
22 : QualityCheck - Nokia 6630
23 : Documentation (JMF, Recommendation, Future Works)
24 : Preparation - Presentation Slides

Sunday, March 12, 2006

J2ME Socket


Push Registry



Documentation Topic Sentences 1

The Server

HAMSTER server is a Hypertext Transfer Protocol (HTTP) server because it uses HTTP to communicate with its two types of clients - mobile clients and web browsers.

It is also a Java-based web server which uses two important classes, and

Both types of clients communicate through HTTP messages.

The Clients

Mobile clients are running in Java 2 MicroEdition (J2ME) Platform under Mobile Information Device Profile 2.0 (MIDP) and Connected Limited Device Configuration 1.1 (CLDC) profiles. Currently, the MIDP technology supports the standard HTTP protocol.

Web clients can be users accessing the web server using an Internet browser or through sockets in a Java application (or applet).

Mobile Phones

MIDP 2.0 / CLDC 1.0

Nokia ser. 40
Nokia ser. 60
Siemens 65x

MIDP 2.0 / CLDC 1.1

Nokia ser. 60, ser. 80, ser. 90,
Siemens 65x, 75x



Sign Up Module

Sign Up process is not advisable through web application because when we POST our form, we submit the values in clear. The only time we can manipulate the POST-ed data is when we process the data by the classes, which are located at the web server.

So, the Sign Up process can be done with Java application. That is, an application capable of contacting a web server. And this is a network-comma-socket programming.
Socket Multithreaded Server and Client
Socket Programming in Java - SMTP Example
Java Web Server and JSP

Servlet Conventions

1. Group .jsp and .html template files and place them in 'templates'.
2. .jsp 'data processors' should be named with prefix "do_" (i.e. do_login.jsp, do_signup.jsp)
3. Use data access objects rather putting the SQL queries and updates to the code

HAMSTER Database Data Dictionary - Unofficial


video_access_number int8 NOT NULL,
category varchar(50) NOT NULL,
CONSTRAINT by_category_pk PRIMARY KEY (video_access_number, category),
CONSTRAINT category FOREIGN KEY (video_access_number)
REFERENCES video (video_access_number)
CONSTRAINT video_access_number FOREIGN KEY (video_access_number)
REFERENCES video (video_access_number)

video_access_number int8 NOT NULL,
"language" varchar NOT NULL,
CONSTRAINT by_language_pk PRIMARY KEY (video_access_number, "language"),
CONSTRAINT "language" FOREIGN KEY ("language")
REFERENCES "language" ("language")
CONSTRAINT video_access_number FOREIGN KEY (video_access_number)
REFERENCES video (video_access_number)

category_title varchar(50) NOT NULL,
CONSTRAINT category_pk PRIMARY KEY (category_title)

video_access_number int8 NOT NULL,
"comment" varchar(500) NOT NULL,
CONSTRAINT comment_pk PRIMARY KEY (video_access_number, "comment"),
CONSTRAINT video_access_number FOREIGN KEY (video_access_number)
REFERENCES video (video_access_number)

format_code varchar(20) NOT NULL,
file_extension varchar(10) NOT NULL,
pixel_width int8 NOT NULL,
pixel_height int8 NOT NULL,
CONSTRAINT format_pk PRIMARY KEY (format_code),
CONSTRAINT format_uk UNIQUE (file_extension, pixel_width, pixel_height)

myself varchar(50) NOT NULL,
friend varchar(50) NOT NULL,
CONSTRAINT friendship_pk PRIMARY KEY (myself, friend),
CONSTRAINT friend_username FOREIGN KEY (friend)
REFERENCES subscriber (username)
CONSTRAINT myself_username FOREIGN KEY (myself)
REFERENCES subscriber (username)

"language" varchar(30) NOT NULL,
CONSTRAINT language_pk PRIMARY KEY ("language")

username varchar(50) NOT NULL,
video_access_number int8 NOT NULL,
CONSTRAINT ownership_pk PRIMARY KEY (username, video_access_number),
CONSTRAINT username FOREIGN KEY (username)
REFERENCES subscriber (username)
CONSTRAINT video_access_number FOREIGN KEY (video_access_number)
REFERENCES video (video_access_number)

username varchar(50) NOT NULL, -- unique user identifier
"password" varchar(32) NOT NULL, -- user password
CONSTRAINT subscriber_pk PRIMARY KEY (username)

video_access_number int8 NOT NULL,
content bytea NOT NULL,
is_private bool NOT NULL,
is_free bool NOT NULL,
video_title varchar(200) NOT NULL,
is_flagged bool NOT NULL,
date_uploaded date NOT NULL,
view_hits int8 NOT NULL DEFAULT 0,
download_hits int8 NOT NULL DEFAULT 0,
thumbnail bytea NOT NULL,
CONSTRAINT video_pk PRIMARY KEY (video_access_number),
CONSTRAINT video_uk UNIQUE (content)

Friday, March 10, 2006

Session: A Nice To Have

Every e-commerce application must support session tracking. Unfortunately, MIDP (Mobile Information Device Profile), a J2ME (Java 2 Platform, Micro Edition) technology, supports only the standard HTTP protocol, which is stateless. In this article, Michael Juntao Yuan and Ju Long explore ways to add session support into the current MIDP network API framework. They discuss the implementations, usages, and relative merits of three approaches: using cookies, rewriting URLs, and embedding session information in XML documents.

Servletting. Wait Lang.

Matagal nang ok ang user authentication pero this time by POST na siya to a servlet [UserLogin]. In clear nga lang ang pagsend ng data so I need the encryption thing already.

Huling priority na para sa 'kin ang user sign up kasi hindi pa naman siya open to the public.

Gumagana na rin kanina ang update account. And the retrieve thumbnails, of course. Haha.

Problem is, right now hindi na gumagana bigla yung servlet. Nagsstop siya sa isang blank page at hindi nag-r-response.sendRedirect(""). Hindi ko maintindihan kung bakit.

Eniwei, kung sakaling kelangan ng servlet for the mobile to request for data, I suggest na by POST na lang ulet, at mejo fill in the blanks na lang sa class na 'to:

package rijndael;

import java.sql.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class GetVideoDataServlet extends HttpServlet {

public GetVideoDataServlet() {

public void doPost(HttpServletRequest request, HttpServletResponse response) {
try {

RijndaelConnect connection = new RijndaelConnect();
HttpSession session = request.getSession(true);
connection.executeQuery( SQL query for retrieving data );

while(connection.getResultSet().next()) {
Encrypt video data;

Manipulate SQL query;


} catch(Exception e) {
} finally {

Wednesday, March 08, 2006

Java Servlet

1. Dowload Java Servlet package.
2. Include servlet.jar and server.jar in the libraries of the development workspace.
3. Run startserver.bat

BigInteger is a BigProblem

Java Cryptography

J2ME BigInteger Support

Monday, March 06, 2006

Minimum Requirement (done stroke)


01M. http_request(username)
02W. process(username)
03D. unique = check_db(username)
04P. if unique [ generate(server_public_key)
05P. send(server_public_key)
06W. http_response(server_public_key)
07M. encoded = aes_encrypt(username, password, server_public_key)
07M. encoded = dsa_encrypt(username, password, server_public_key)
08M. http_request(encoded)
09P. decoded = aes_decrypt(encoded, server_private_key)
09P. decoded = aes_decrypt(encoded, server_private_key)
10P. password = extract(decoded)
11P. encrypted_password = tea_encrypt(password)
12D. store_db(username, encrypted_password)
13W. http_response(OK)
14X. close_connection()


15M. encrypted_login = md5(username, password)
16M. http_request(username, encrypted_login)
17W. process(username, encrypted_login)
18D. encrypted_password = retrieve_db(username)
19W. password = tea_decrypt(encrypted_password)
20W. hash = md5(username, password)
21W. if (hash = encrypted_login) [ http_response(ok) ]


22M. http_request(query)
23W. process(query)
24D. data_set = select_tables(query)
25W. http_response(data_set)
26M. filename = process(data_set, user_input)
27M. http_request(filename)
28W. process(filename)
29D. data_video = select_tables(filename)
30P. encrypted_video = aes_encrypt(data_video, password)
31W. http_response(encrypted_video)
32M. data_video = aes_decrypt(encrypted_video, password)
33M. play(data_video)
33X. close_connection()

M = mobile (jonas)
W = webapp dao (ia)
D = database (phillip)
P = pki / aes logic (jonas)

Tuesday, February 28, 2006

Important Note HTTPRealPlayer

password key should be int[] not string

Monday, February 20, 2006


Kimpo, Phillip

1. Entity Relationship Diagram (Feb 20)
- video (filename, category_1, category_2, free_or_ppv, owner, etc., thumbnail?)
- user (etc.)
2. Population of Table (Feb 20)
3. Store and retrieve raw video stream/file by SQL command line (Feb 21)
4. Queries (Feb 21)
5. Correctness of queries by SQL command line(Feb 22)
6. Check webapp connection from Ia to database (Feb 23)

Lucero, Ia

1. JDBConnection (Feb 20)
2. Store and retrieve text information from database (Feb 21)
3. Store and retrieve raw video stream/file from Phillip (Feb 22)
4. Screenflow (Feb 20)
5. Player for HTML (Feb 21)
6. Implementation/Deployment of PKI_Decrypt from Jonas (Feb 22)
7. Implementation/Deployment of AES_Encrypt from Jonas (Feb 22)

Roque, Jonas

1. AES Mobile (Feb 20)
2. PKI Mobile / Server (Feb 21)
3. Player for Other Formats (Feb 21)
4. Post data to web app (Feb 21)
5. TEA Mobile / Server (Feb 21)
6. Servlet (Feb 22)

Saturday, February 18, 2006

J2ME Video Streaming Project


Friday, February 17, 2006


Wednesday, February 15, 2006

Nokia 6630

More J2ME

Saturday, February 11, 2006

Neurons Needed

Finally, at exactly 4:00 AM, I was able to build the rewritten AES code from desktop source program to its mobile counterpart. I was excited because I got rid several problems such as non-existence of java.IO.File in J2ME, midlet user interface refamiliarization, and importantly, elimination of file writing.

Press Run.
Input Username, Phone number, Password. OK
Press Send.
Select file to encrypt and to decrypt. OK
Press Select.



As of 4:43 AM, after taking a nap, pagkatapos magkasama kahit sa panaginip lamang, I inferred that it was caused by creating array of int whose size is Integer.MAX. Good luck, talaga!


It works!

JMF Media Players

Thursday, February 09, 2006


t*ng*n*ng postgres yan.

(good luck sa pag-port sa ibang pc.)

Deadline: February 11, 2006

  • AES Midlet Version
  • RTP Demonstration kahit End-to-End ay both Desktop
  • JavaPhone connects to HAMSTER Web Application
  • MobileHAMSTER and ServerHAMSTER exchange of username and password
  • MediaPlayer in Phone

MMAPI, RTP and WebApp Useful Links

Wednesday, February 08, 2006

Eclipse JDK

DemoHAMSTER - for demonstration purposes

  1. Create New Project
  2. Set a Project Name
  3. Create Project from an Existing Source
  4. Browse directory
  5. Next
  6. Add necessary jar files and libraries
  7. Finish
  1. Run >> Run...
  2. Create a new SWT Application configuration
  3. Select Main class
  4. Specify arguments separated by white space
  5. Specify working directory (necessary for absolute and relative path of files needed)
  6. Run

Same Mill Bee

Seelvester, a popular cat I suppose and ancestor of Hamster referenced the same source code from these URL's

Ma'm Susan once told us these classes work. Yes, I believe so but these works for two desktop PCs. Seelvester Project wasn't able to program the MIDlet version of these RTP Transfer. They only worked on the cryptography in MIDlet.

Mahaba-habang inuman pa ito!


Our pet HAMSTER can already

... play WAV audio. (tada!)
... play MIDI audio. (always something there to remind me...)
... play MPG video na rin (over the network pa! http!)

Ew! RTP na!

'c' in Java

Hey, guys! I finally figured how to control that pest, I just imported the class this way:


Imagine! That little 'c' makes a big difference!

Well, I'm continuing exploring the magic of 'c' in Java.

By the way, I got the bigger C in a tutorial. That page should be edited! Er!

Tuesday, February 07, 2006

Sinfinity Webapp Update

The web application has been rewritten from static HTML to JSP, though progress has been halted -- we still haven't obtained the database from the other group.

The webapp has been hosted on Ia's domain, though it seems that JSP capability isn't switched on by default by Filcode. We're contacting them now.

More updates soon.

Can't Control the Video Control, Er

I had already installed both WTK 2.2 and WTK 2.3 thinking that the version caused it. But, no!

I'm not sure if the selected media or device has no video capability. I'm assuming that running the MIDlet in an emulator will go perfectly when emulator is supposed to be "ideal" phone.

The compiler is not happy when it cannot find the class Video Control in when it is supposed to be there. The jar is not broken, for sure!

Wah! I'm trying the AudioControl instead!

JMF and J2ME

  • JMF 2.1.1e was installed @ MH215
  • D:\Program Files\JMF2.1.1e
  • J2ME Wireless Toolkit 2.2 was installed @ MH215. Version 2.3 Beta was previously installed but JSR135 (Waahh! 135!) does not work properly. Can't locate Video Control class.
  • C:\WTK22
  • Java Home: D:\Program Files\Java\jdk1.5.0_06

JMF Useful Links

Sunday, February 05, 2006

Web Application Update

  • Apache Tomcat 5.5 was installed @ MH 215
  • D:\Program Files\Apache Software Foundation\Tomcat 5.5
  • admin account created, password can be seen and modified, woohoo!
  • D:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\tomcat-users.xml
  • Sample JSP Examples tested, cool!
  • PostgreSQL 8.1 was installed @ MH 215
  • D:\Program Files\PostgreSQL\8.1
  • user: postgres
  • password hint: [yahoo!]

poor man's key generation

jonas, ito muna gamitin mo for key generation... although we're still deciphering if the generated strings/bytes are valid keys (see last part below; pero nakaspecify naman sa method na 1024-bit ang keysize eh).

Example File:
Output files: Found here.
Algorithm: DSA (not sure if DH is included by default.)

[public|private][n], where n:
1=whole key instance is written to file
2=key.getEncoded() is written to file, returns byte[]
3=String conversion of (2) is written, returns String

character count of public vs private [n] files in Notepad++:
1=700 vs 594 (doesn't help)
2=471 vs 362
3=732 vs 543

Monday, January 30, 2006

To Do List

  • Java Media Framework
  • Multimedia and MIDP 2.0
  • The Seelvester Project

Friday, January 20, 2006

To Do List

  • Database that stores decrypted video clips
    • Entity Relationship Diagram
    • SQL Connector
  • Web Application
    • Preview
    • Flag
    • Forging (Vulcan / Friendster) :D
  • AES-MAC-Counter
    • Initialization Vector Generator- Randomize, it's easy anyway
    • User AES Key Generator
    • Salt inclusion
    • Counter CBC
      No need!
  • Transfer Protocol
    • Buffer
    • RTP

Tuesday, November 29, 2005

For Nov 30:

For all groups, please submit a brief (one-page)
update of your groups progress so far. I will visit
the NEC thesis lab tomorrow during class hours and
will later be in my office at MH 207. You can choose
to hand it over anytime during that period.


Trabaho na! :D

Tuesday, October 18, 2005

The Anti-Portfolio

"Bessemer Venture Partners is perhaps the nation's oldest venture capital firm, carrying on an unbroken practice of venture capital investing that stretches back to 1911. This long and storied history has afforded our firm an unparalleled number of opportunities to completely screw up."

Wonder why? Click on the link to find out.

(It's a whole lot better if you find out now than later. ^_^)

I don't know about you guys, but Venture Capitalists are not a familiar lot to me, until I joined PESO. But anyway, this is why Bessemer's Anti-Portfolio is all the more amusing. It's a list of famous companies they passed on investing. HP, Apple, eBay, FedEx, Google, Intel, Lotus, Compaq, PayPal, IBM, Cisco Systems... Will the absurdness ever end?

They're so un-bitter about it that I wonder if it's even true.

Beyond the humor of the story is a greater lesson, of course, especially to us Marketing apprentices (aka the VC lapdogs).

Never say die. Getting turned down the first time will just be the start of a string of many other rejections.

The greatest ideas aren't the easiest to recognize. They'll never know what genius hit them.

And we, shall laugh hardest, laugh last.

Tuesday, September 13, 2005


Highly secure Adaptive Mobile multimedia Streaming Service
Panel Presentation: September 14, 2005, 1:00 PM

Yes, that's a hamster. And the dingbat at the back was to fill the white space up. But it
does fit in well.

Monday, September 12, 2005

Finalist, Engineering Marketing Congress

Saturday, September 03, 2005

PKI Relevant Links

Sunday, August 21, 2005

Second Progress Report

The group has chosen the Advanced Encryption Standard (AES) Rijndael algorithm to be implemented in our system. To immerse ourselves in the intricacies of Rijndael, we first read the following related literature:

1) J. Daemen and V. Rijmen, AES Proposal: Rijndael, AES Algorithm Submission, September 3, 1999.
2) Specification for the Advanced Encryption Standard (AES), Federal Information Processing Standard (FIPS), Publication 197, National Bureau of Standards, US Department of Commerce, Washington D.C., November 26, 2001.
3) J. Daemen and V. Rijmen, Answer to "New Observations on Rijndael", August 11, 2000.
4) J. Daemen and V. Rijmen, Rijndael Presentation Slides, NISSC 2000, October 23, 2000.

Though Rijndael implementations in our language of choice, Java, already exist, we decided to code the algorithm from scratch. Each group member was assigned a Rijndael component to work on.

As of this writing, we have written the code for Rijndael’s round transformation, which is composed of the ByteSub, ShiftRow, MixColumn transformations, and Round Key Addition. We have also finished with the Key Expansion, which is vital to the Round Key Addition component

Monday, August 15, 2005

Rijndael: Essential Links - Rijndael Home Page (Sacred ground.) - link to the pdf file of the rijndael specs (1mb) - 3rd to the last pdf link ang importante

update 08/16:

Saturday, July 23, 2005

Research Plan

I. Statement of Research Question
How can we ensure the security of video streaming from a server to a mobile device, both real-time and non, and if appropriate security mechanisms are found, which will be best suitable for implementation on our system?

II. Why is this important or interesting?
Video streaming from a server to a mobile device allows for hassle-free and virtually unlimited storage of mobile phone multimedia data. This is a commercially viable proposition; however, no wise company will invest in a system that is vulnerable to attacks by adversaries, such as professional pirates and casual hackers. Thus, the need for an impregnable system replete with authentication, encryption, and other security features.

III. What are some of the issues that need to be addressed?
The Secure Real-time Transport Protocol, a library for which exists in C, is a prime choice for any attempt at secure video streaming. However, the protocol has not yet been implemented in Java, the group’s language of choice.

IV. What is the general approach to the problem?
It has been decided that several key features of the SRTP are going to be ‘emulated’ in our system by creating lightweight versions of encryption (highest priority), authentication, and replay protection. If possible, existing Java security classes will be used. Also, we will build user interfaces (UIs) for the server-side Administrator account and the WAP client.

V. Detail related or background work
We have found more or less a dozen papers on topics such as secure multicasting over wireless, mobile phone security protocols, secure scaleable streaming, network security, general and specific video format encryption algorithms, and the RFC paper on SRTP itself. These papers are detailed in our First Progress Report.

VI. Detail the work done to date
The two groups assigned to the project have discussed which video format/s to use, and presently 3GP is in the forefront. Much research has been done, and we have compiled a catalog of related literature to review (and have already been reviewed). These papers can be found in detail in our First Progress Report. Also, we have identified a prime ‘sample’ mobile device on which to test our system, the 02 XDA, and have reviewed its various compatibilities and features. A thesis blog has also been set-up, the URL of which can be found at this paper’s header.

VII. Detailed Research Plan
We will conclude our literature review shortly, and proceed to apply our new knowledge to the system’s implementation. We will prioritize the creation of encryption mechanisms, then proceed to authentication. If time permits, we can implement replay protection. If the aforementioned are deemed to be stable and ready for deployment, we will proceed to creating a UI for the server-side Admin and the WAP client. Further extensive testing will follow, such as simulated attacks on the system’s security.

VIII. Research Schedule
By August, the group will commence the coding of encryption mechanisms, and this will continue for a month. By September, we can begin on the authentication, and shortly before the end of the semester (mid-October), we hope to finish with replay protection. UIs for the server-side Admin and WAP client can be done within the first weeks of the second semester, after which further troubleshooting and documentation can be accomplished.

Tuesday, July 19, 2005

Deliverables for July 23

(from UPJ2L)

on July 23
Submit article summaries (literature search) and research plan
(e-mail to spancho[at]

Article summaries: Let's follow a format of one paragraph per paper.
Research plan: Er... o_O


Re: Ia's Recent Post

In Ia's recent post, she mentioned the following (regarding secure multicasting):

"Minimal Set of Security Requirements:
  • Confidentiality
  • Authenticity
  • Traffic backward secrecy: newcomers should not be able to read former traffic
  • Traffic forward secrecy: former members should not be able to read present & future traffic"
Of the last two, I believe only the fourth one concerns us. For example, when a "subscriber" ceases to be in the Telco's official list of paying members, he should not be able to access any new video streams or the video archives (same w/ an e-group). However, when a new subcriber joins the list of paying members, he/she should be able to view past videos, so item #3 isn't a problem for us (this actually depends on the Telco's strategy; but then, the catch-phrase "Over 10 gigs of stored videos of your favorite Pinoy stars, ready for your downloading!" to potential subscribers will prove to be very attractive.

Guys, what do you think?

Pseudo-Summary of Network Security (Tanenbaum)

From Chapter 8 of Computer Networks (4th Ed), Tanenbaum

Possible main threats to our system:
  • casual intruders who have fun snooping on others' private video streams and/or test out security systems
  • professional intruders who steal data (i.e. the paid video streams on the Telco server/s) and pirate it
Data Link Layer security -- use link encryption (easy to implement on packets on a point-to-point line)

Basics of Cryptography
  • cryptanalysis - breaking ciphers
  • cryptography - devising ciphers
  • cryptology - item one and two combined
  • Decryption(Encryption(P)) = P
  • substitution ciphers, transposition, one-time pads
  • Principles: redundancy, freshness (protect against replay attacks)
Symmetric Key Algorithms
  • Data Encryption Standard (DES) // Triple DES
  • Advanced ES (AES) // Rijndael (great security and speed; best-known symmetric key encryption algorithm together with DES)
Cipher Modes
  • Electronic Code Book Mode
  • Cipher Block Chaining Mode
  • Stream Cipher Mode
  • Counter Mode
Cryptanalysis Developments
  • Differential cryptanalysis
  • Linear cryptanalysis
  • Power analysis (3v for 1 bit, 1v for 0 bit)
  • Timing analysis (if-then-else loops have predictable time durations which can be exploited)
Next: Public Key Algorithms

Friday, July 15, 2005

Notes: Two Security Papers

Secure Multicast in Wireless Networks and Mobile Hosts
Danilo Bruschi and Emilia Rosti
Dipartimento di Scienze dell’Informazione, Università degli Studi di Milano, Via Comelico 39/41, 20135 Milano, Italy

"Since cryptography is employed to satisfy such requirements, the design of efficient key management scheme is the critical aspect for the realization of a secure multicast primitive."

Critical Factors:
  • Members' limited computational power
  • Host mobility
  • Tracking keying material during handoff
  • Role of MSSes (mobile support stations)
  • Non-trusted, Semi-trusted, Fully-trusted
Minimal Set of Security Requirements:
  • Confidentiality
  • Authenticity
  • Traffic backward secrecy: newcomers should not be able to read former traffic
  • Traffic forward secrecy: former members should not be able to read present & future traffic
Classifications of Protocols:
Flat Schemes, Clustered Schemes, Tree-based Schemes, etc

Amount of work done by components depends critically on level of trust in MSSes.


Security protocols for 2G and 3G wireless communications
T. Newe & T. Coffey
Data Communications Security Group,
Department of Electronic & Computer Engineering,
University of Limerick, Ireland.
E-Mail: ( (

Generic set of security requirements for mobile device protocols:
1. Mutual Authentication of user and network
2. Exchange of certified public keys
3. Session key agreement
4. Joint control of session key
5. Mutual implicit key authentication
6. Mutual key confirmation
7. Mutual assurance of key freshness
8. Confidentiality
9. Initialisation of payment mechanism
10. Non-repudiation of origin

2G Mobile Protocols:
  • Beller-Chang-Yacobi and Carlsen's BCY
    • Combination of symmetric and asymmetric encryption
    • Suggested improvements to orig. BCY by Carlsen:
  • Beller-Yacobi and Boyd-Mathuria's BY
    • Low-cost, two-way public-key authentication and key agreement

3G Mobile Protocols:
  • ASPeCT (Variant B) Protocol
    • In UMTS environments
  • Boyd-Park and NC Boyd-Park Key Agreement Protocols
    • Corrects the mobile identification delay weakness in the ASPeCT protocol


The 3G protocols meet the 10 listed requirements given by the paper.
Then: only link security is feasible. Now: End-to-end security is primary concern.
Question: Will this work for non-UMTS services?


EDIT: I forgot to give credit where it is due.

First Progress Report

The group has already decided (with the advice of the thesis adviser) to prioritize the creation of encryption mechanisms (as compared to the authentication and replay subsystems). However, before we can begin on any coding (whether on Java, C, C++, or Visual C++), we need to be thoroughly familiar with the technologies and principles we will be working on. Thus, we are in the midst of reviewing related literature, and the following papers have already been read (brackets indicate the team member assigned to the paper):

  1. “Secure Multicast in Wireless Networks and Mobile Hosts”, Bruschi and Rosti [Lucero]
  2. “Security Protocols for 2G and 3G Wireless Communications”, Newe and Coffey [Lucero]
  3. “Secure Scalable Streaming Enabling Transcoding Without Decryption”, Wee and Apostolopoulos [Roque]
  4. “Securing Media for Adaptive Streaming”, Venkatramani et al [Roque]
  5. “The Secure Real-time Transport Protocol (SRTP) – RFC 3711”, Cisco Systems and Ericsson Research [Kimpo]
  6. “Network Security” (Chapter 8 of Computer Networks 4th Ed.), Tanenbaum [Kimpo]

We have also bookmarked essential pages on ciphers [Roque], IEEE MPEG papers [Lucero], and SpringerLink researches [Lucero]. However, we are having a problem accessing the full versions of some of the papers as we do not have the necessary accounts to open them.

Allow us to mention in passing that we have been able to set-up our PC at the thesis laboratory, and have installed the operating system.

In queue for our ongoing literature review are the following:

  1. “On the Use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution,” Cheung et al [Roque]
  2. “A Software-Optimized Encryption Algorithm”, Rogaway and Coppersmith [Roque]
  3. “Secure Scalable Video Streaming for Wireless Networks”, Wee and Apostolopoulos [Roque]
  4. “A Fast MPEG Video Encryption Algorithm”, Shi and Bhargava [Kimpo]
  5. “On the Performance of Group Key Agreement Protocols”, Amir et al [Kimpo]
  6. “A Survey of Key Management for Secure Group Communication”, Rafaeli and Hutchison [Kimpo]


Has read:
Secure Scalable Streaming Enabling Transcoding Without Decryption >> Wee, Apostolopoulos
Securing Media for Adaptive Streaming >> Venkatramani, Westerink, et al

To read:
On the Use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution >> Cheung, Ammar, Li
A Software-Optimized Encryption Algorithm >> Rogaway, Coppersmith
Secure Scalable Video Streaming for Wireless Networks >> Wee, Apostolopoulos

Has Bookmarked:
(Non-exhaustive Encryption) List of Stream Ciphers

Wednesday, July 13, 2005

Unreadable Bookmarks, and then some

I'll be reading Secure Multicast in Wireless Networks and Mobile Hosts (other link) tonight -- it seems promising. Hope I can post what I've absorbed from it soon.

MPEG (Moving Pictures Expert Group) is an industrial standard for video processing and is widely used in multimedia applications in the Internet. However, no security provision is specified in the standard. We conducted an experimental study of previously proposed selective encryption schemes for MPEG video security. This study showed that these methods are inadequate for sensitive applications. We discuss the tradeoffs between levels of security and computational and compression efficiency.

  • Secure Service and Network Framework for Mobile Ethernet
  • Secure cellular data services have become more popular in the Japanese market. These services are based on 2G/3G cellular networks and are expected to move into the next-generation wireless networks, called Beyond 3G. In the Beyond 3G, wireless communication available at a user's location is selected based on the type of the service. The user downloads an application from one wireless network and executes it on another. Beyond 3G expects core and wireless operators and allows to plug-in new wireless access. A security model that can accommodate these requirements needs to be sufficiently flexible for end users to utilize with ease. In this paper, we explain the Mobile Ethernet architecture for all IP networks in terms of the Beyond 3G. We discuss usage scenario/operator models and identify entities for the security model. We separate a mobile device into a personal identity card (PIC) containing cryptographic information and a wireless communications device that offers security and flexibility. We propose a self-delegation protocol for device authentication and use a delegated credential for unified network- and service-level authentication. We also propose proactive handover authentication using the security context between different types of wireless access, such as Third Generation Partnership Project (3GPP) and WLAN, so that the secure end-to-end communication channels established by service software on the TCP/IP are not terminated. Lastly, we raise security issues regarding the next-generation platform.
  • Provable Cryptographic Security and its Applications to Mobile Wireless Computing
  • Many attempts to secure mobile wireless systems have failed abysmally. Notable examples include 802.11 WEP, as well as major cellular phone standards such as TDMA, CDMA, and GSM. The attacks typically result from the correct use of a bad cryptographic primitive or the incorrect use of a good one.

    By designing provably secure algorithms and protocols, we not only minimize the time required to gain confidence in the security of a system, but we virtually eliminate the possibility of a cryptographic vulnerability. Unfortunately, the concept of "provable securit" is often misunderstood. In this survey paper, we state precisely what provable security is and is not, and describe the benefits of the approach.

    Craig Gentry

    Zulfikar Ramzan


ACM Digital Library:

Thursday, July 07, 2005

A Rather Incomplete 'Summary' of the Cisco-Ericsson SRTP Paper

Secure Real-time Transport Protocol
- high throughput, low packet expansion
- encryption (cryptographic transforms)
- authentication (key-based)
- a profile of RTP (extension of the RTp Audio/Video Profile)

RTP <----> SRTP <----------> SRTP <----> RTP

<----> denotes "intercept" (different from <---------->)

- packet is discarded
- log the event

REPLAY protection:
- packet is replayed when it is stored by an adversary, and then reinjected into the network
- implement a Replay List

Replay List:
- continuously updated with each authenticated packet
- implement using a bitmap
- if a packet is checked to be already in the replay list, discard the packet and log the event


*No meeting on Saturday (Wednesday na lang ulit).

*Task 1 -- Create lightweight versions of Encryption (highest priority), Authentication, and Replay Protection for the Java RTP (if possible, use existing security classes); Encryption can be shared key (symmetric), public key based (asymmetric), or hybrid (BEST CHOICE)

*Task 2 -- UIs for Admin (server side) and WAP client

Wednesday, July 06, 2005

summary [sss transcoding w/o decryption]

Secure Scalable Streaming (SSS)


- secure scalable packets using jointly designed scalable coding and progressive encryption techniques

- has unencrypted headers that can provide hints

- has low complexity and can support many simultaneous transcoding sessions

- Motion JPEG-200, 3D subband coding, MPEG-4 FGS

(1) scalability - to enable streaming to a multitude of clients with different device capabilities

(2) efficiency - to maximize the utility of available network and device resources

(3) security - to protect content from eavesdroppers

scalable coding

- encodes a video sequence into a scalable bitstream
- first segment of the scalable bitstream can be used to decode baseline-quality video
- progressively longer segments can be used to decode progressively improved video
- video quality ---> spatial resolution, bit plane resolution, frame rate

progressive encryption (encrypt and decrypt sequentially)

- bitstream could be divided into small blocks which are encrypted independently
- large degree of security ---> encrypting small blocks sequentially and feeding the encrypted data of earlier blocks into the encryption of later blocks
- first small block of ciphertext is decrypted into plaintext, second block of ciphertext is decrypted and the result is XORed ---> until the entire message is encrypted
- stream ciphers encrypte plaintext into ciphertext one bit a time


sss coding and transcoding

- scalable coding, packetization, progressive encryption combined into code video into secure scalable packets
- characteristics : (1) scalable - enable downstream transcoding with packet truncation (2) encrypted - end-to-end security (3) independently decodable - resilient to errors such as packet loss

coding ------
- if the coded data will not fit into a single facket, modifications will have to be made
- input video ---> regions ---> scalable video data + header data ---> encrypted with progressive encryption ---> scalable packets (unencrypted header data + progressive scalable video data)

transcoding ------
- read header data ---> discard/truncate packets ---> decrypt and decode received packets
- resolution and quality of the reconstructed video will depend on the transcoding operation

Tuesday, July 05, 2005

O2, 3GPP, etc.

O2 Xda microsite
Supports 3GPP, both in Album (playback) and Capture modes! Yay! ^_^

Specs, etc


From Phillip:

Nuvo: humanoid robot with video streaming
The 15-inch, 5.5 pound nuvo from ZMP, Inc. walks and responds to voice commands, as well as linking to your mobile phone both to receive commands and to send you images of your home taken with the camera inside its head.

Streaming, Streaming

Streaming Media over the Internet with the Real Time Streaming Protocol

RTP = Transport Protocol
RTSP = Streaming Protocol; more of controls such as playback

I haven't found anything tied to the keyword "Java". =(

From IEEE:

Yima: A Second-Generation Continuous Media Server
Continuous media data requires a streaming architecture that can manage real-time delivery constraints and address the large size of CM objects. Although commercial systems ordinarily use proprietary technology and algorithms, making it difficult to compare their products with research prototypes, the authors have designed and developed Yima, a second-generation CM server that demonstrates several advanced concepts.Although this system has not yet achieved the refinement of commercial solutions, it is operational and incorporates lessons learned from first-generation research prototypes, including complete distribution, efficient online scalability, and synchronization of several media streams within a single frame.

From SF:

Project: Medio4RTSP
We are to develop an RTSP/RTP based Video on Demand middleware (transparent proxy) to do service at high-evel.

Project: RTFSPP: Real-Time File Streaming & Proxy
An RTSP-based protocol to allow static files and live streams to be distributed from one computer-device, no matter how powerful, to theoretically an infinite number of recieving clients.

Monday, July 04, 2005

Related Links

HP Labs Research

On Streaming

Saturday, July 02, 2005

All Systems Go

Welcome to the our online scribblesheet for CS 198-199.