Monday, March 23, 2009
Daily RDAHMM portlet modified corresponding to the video service
We have modified the daily RDAHMM portlet so that it now links to a video file made by the daily RDAHMM video service, which will always be in mp4 format.
Monday, March 16, 2009
Daily RDAHMM Video Web Service Completed
And here's the design document:
To make daily RDAHMM movies with h264 video format, which is the most portable format across Linux, Windows and Mac platforms, we decide to create a DailyRDAHMMVideoService web service sitting on a machine where everything is OK for making h264 videos, and answering the requests from DailyRDAHMMService, and returning links to videos newly created.
Pre-requisite:
mencoder installed with support for x264 options
mp4BOX installed
So far the only machine that satisfies these requirements is Xiaoming's machine with IP address 156.56.104.161.
Requirements for DailyRDAHMMVideoService web service:
We call DailyRDAHMMVideoService the "video service" for short. This service is supposed to support the creation of daily RDAHMM movies for different data sources (SOPAC, JPL, etc.), and different pre-process treatment methods to input data (with vs. without missing data treatment). Given a data source, a treatment method, a URL to the analysis result XML file of that data souce, and a pair of start and end date, the video service will create a movie for the period between the start and end date, according to the result XML file specified in that URL, and return a URL to the created video. More specificly, the video service provides a web service method "String makeVideo(String dataSource, String preProcTreat, String resultURL, String startDate, String endDate)", which makes the requested video, and returns the URL string of the video.
Design Issues:
1. Directory seperation. Since we want to support different data sets and input treatment methods, the analysis results and corresponding map pictures for these different parameters will be different, so we need to separate the directories for different parameter combinations. Let denote the top directory for storing the pictures and temporary video files, we use [picDir]/[dataSouce]/[preProcTreat] for different parameters.
2. Quick response. To respond quickly to the client, we apply asynchronous process to its request. First, the video service will check if the parameters are valid, e.g., whether the given data source and treatment methods are supported. If not, a URL pointing to another method of the video service, "String getErrorMsg(int msgNum)" will be returned to the client, so that when the client opens that URL, a proper error message will be returned. If the parameters are valid, a URL will be constructed immediately according to these parameters and returned to the client, before the video is actually created. That is, we assume that there will be no errors in the process of creating the video. After enough debugging, we think this will not cause very serious problems: anyway, putting an invalid URL on the portal in rare cases will not be the end of the world.
3. Requests buffering. In order to answer multiple requests asynchronously in a short time, we buffer these results in a list, and use a separate thread to process them. This separate thread is sleeping when there is no request to process, and will be waken up for new requests.
4. Avoiding redundant work. To avoid creating video frames for any period for multiple times, we save the start date (which will always be 1994-01-01) and end date of the last video created. Upon every new request, the video service will check its start and end date. If these dates falls in between the start and end date of the last video, we just return the URL for the last video. A new video will be created only if the end date is later than the end date of the last video, since all starting dates are supposed to be no earlier than 1994-01-01. Besides, if the month number of the given end date minus 2 is later than the month number of the historical video, the historical video is updated and extended to the month according to the given month number minus 2. For example, if the end date of the historical video is 2008-07-31, and the end date of the requested video is 2008-11-22, then the historical video will be updated to 2008-09-30 first, and then the new video is created based on the new historical video.
To make daily RDAHMM movies with h264 video format, which is the most portable format across Linux, Windows and Mac platforms, we decide to create a DailyRDAHMMVideoService web service sitting on a machine where everything is OK for making h264 videos, and answering the requests from DailyRDAHMMService, and returning links to videos newly created.
Pre-requisite:
mencoder installed with support for x264 options
mp4BOX installed
So far the only machine that satisfies these requirements is Xiaoming's machine with IP address 156.56.104.161.
Requirements for DailyRDAHMMVideoService web service:
We call DailyRDAHMMVideoService the "video service" for short. This service is supposed to support the creation of daily RDAHMM movies for different data sources (SOPAC, JPL, etc.), and different pre-process treatment methods to input data (with vs. without missing data treatment). Given a data source, a treatment method, a URL to the analysis result XML file of that data souce, and a pair of start and end date, the video service will create a movie for the period between the start and end date, according to the result XML file specified in that URL, and return a URL to the created video. More specificly, the video service provides a web service method "String makeVideo(String dataSource, String preProcTreat, String resultURL, String startDate, String endDate)", which makes the requested video, and returns the URL string of the video.
Design Issues:
1. Directory seperation. Since we want to support different data sets and input treatment methods, the analysis results and corresponding map pictures for these different parameters will be different, so we need to separate the directories for different parameter combinations. Let denote the top directory for storing the pictures and temporary video files, we use [picDir]/[dataSouce]/[preProcTreat] for different parameters.
2. Quick response. To respond quickly to the client, we apply asynchronous process to its request. First, the video service will check if the parameters are valid, e.g., whether the given data source and treatment methods are supported. If not, a URL pointing to another method of the video service, "String getErrorMsg(int msgNum)" will be returned to the client, so that when the client opens that URL, a proper error message will be returned. If the parameters are valid, a URL will be constructed immediately according to these parameters and returned to the client, before the video is actually created. That is, we assume that there will be no errors in the process of creating the video. After enough debugging, we think this will not cause very serious problems: anyway, putting an invalid URL on the portal in rare cases will not be the end of the world.
3. Requests buffering. In order to answer multiple requests asynchronously in a short time, we buffer these results in a list, and use a separate thread to process them. This separate thread is sleeping when there is no request to process, and will be waken up for new requests.
4. Avoiding redundant work. To avoid creating video frames for any period for multiple times, we save the start date (which will always be 1994-01-01) and end date of the last video created. Upon every new request, the video service will check its start and end date. If these dates falls in between the start and end date of the last video, we just return the URL for the last video. A new video will be created only if the end date is later than the end date of the last video, since all starting dates are supposed to be no earlier than 1994-01-01. Besides, if the month number of the given end date minus 2 is later than the month number of the historical video, the historical video is updated and extended to the month according to the given month number minus 2. For example, if the end date of the historical video is 2008-07-31, and the end date of the requested video is 2008-11-22, then the historical video will be updated to 2008-09-30 first, and then the new video is created based on the new historical video.
Subscribe to:
Posts (Atom)