Difference between revisions of "Private:almohammadi"
From NMSL
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Summary of accomplishments by Bassam Almohammadi. | Summary of accomplishments by Bassam Almohammadi. | ||
| + | == August 9, 2010 == | ||
| + | * completed the new implementation that will substitute the old Sniffer. | ||
| + | * I will start unit testing to validate all the API's and double check the timestamps sync appropriately. | ||
| + | |||
| + | == August 2, 2010 == | ||
| + | * implemented a unicast connection that connects with the streaming server for every streaming program. | ||
| + | * for every streaming program I create a new thread that establishes a connection with the server and get the SDP info. | ||
| + | * now working on parsing the SDP info in order to extract the media type and record a new timestamp for both video and audio according to local time. | ||
| + | |||
| + | == July 19, 2010 == | ||
| + | * implemented all the test cases and added them to the src/test folder in the repository. | ||
| + | * documented all the test cases in the test section of the design document. | ||
| + | * performed a thorough testing for all the APIs in my module and made all the necessary fixes. The module has passed all the tests. | ||
| + | * the stream reader is now fully functional according to the design. Need to be integrated with the scheduler if we want to test bursts generation. | ||
| + | |||
| + | == July 12, 2010 == | ||
| + | * Updated the design document for the stream reader, and included new APIs required for the scheduler. | ||
| + | * Completed the integration of the stream reader based on the new design: | ||
| + | ** in MTV: added a new thread for the Sniffer. | ||
| + | ** in Configuration Manager: added a new case for "Stream" Programs. | ||
| + | ** in Programs: added a new constructor to handle the creation of the UDPReader for the stream. | ||
| + | ** completed the Sniffer implementation. | ||
| + | ** completed the UDPReader implementation of the new APIs. | ||
| + | ** added new fields to the Ip_pkt class to use it for buffering packets in the UDPReader. | ||
| + | ** Used mutex to control the shared buffers between the Sniffer thread and the Timeslicer thread. | ||
| + | ISSUES: | ||
| + | * still not clear about handling audio/video stream. My current implementation considers them equal and sort them in a single buffer based on their timestamp. I assume the rest is for the scheduler to handle. | ||
| + | * I assume all the packets that should be handled by the Stream Reader contain RTP payload. Thus I relay on the timestamp in the RTP header to sort packets. If we shall handle any other type of packets then I think we should filter them differently from RTP packets? consequently, I shall add a local mechanism to record the timestamp for these packets. | ||
| + | * according to the design, the implementation should work fine with multicast. However, I'm not sure how the scenario will be different with handling unicast streams? do we need to support this? | ||
| + | * I couldn't find a perfect way to check whether UDP data contains RTP payload or not for live streaming. I am checking for the constant version field ==2 for now. I looked for better alternatives and apparently there is no better way than sending a DESCRIBE command and get the SDP. I think this is not a big issue because we are listening on a specific port and address which will hold only the stream data (true?). | ||
| + | |||
| + | TODO: | ||
| + | * integration testing [and debugging]. | ||
| + | * update test cases documentation. | ||
| + | |||
| + | == July 5, 2010 == | ||
| + | * Added Sniffer class to the design and the code. Its function is to listen for incoming live stream on a separate thread and filter packets into UDPReaders packet buffers. | ||
| + | * created a thread for the sniffer at the initialization of the Mtv class. | ||
| + | * created a new constructor in the Program class for live programs. Live programs, and the program type in general, shall be identified by a new 'string' field in the configuration file. | ||
| + | * created two instances of UDPReader for every live program, one for audio and one for video. Both instances share the same IP but different ports. | ||
| + | ** the challenge here is in returning the ready Burst instance. Currently the timeslicer::schedule() makes only one push_request per program for one Burst instance. I propose declaring the program type in the public field of 'Program' class. At the timeslicer::schedule(), if we want to schedule a burst for a program we shall schedule two bursts for live programs! | ||
| + | * Generally almost done with the integration. The only thing left is to load packets from the UDP buffer to the burst. I'm trying to figure out the function of get_candidate(current, deltaT) to write a parallel one for the UDPReader. | ||
| + | * after the integration is done with the burst class code, I can perform integration testing. | ||
| + | |||
| + | == June 28, 2010 == | ||
| + | * Discussed the design with Som and made some modifications. | ||
| + | * Updated the design document accordingly. | ||
| + | * Started integration with the current code. | ||
| + | * TODO: | ||
| + | ** Finish integration. | ||
| + | ** Perform integration testing. | ||
| + | |||
| + | == June 15, 2010 == | ||
| + | * read the DVB-H implementation guidlines, and looked into FATCAPS source and documentation to get an idea how they implemented the dataAggregator. | ||
| + | * updated the class diagram for StreamReader and UDPReader. Still have to confirm this with Som in order to update the design document. | ||
| + | * working on integrating my class with the Burst class. | ||
| + | |||
| + | == June 8, 2010 == | ||
| + | * faced a challenge in receiving packets with IP headers included. As far as I know there are two ways of doing this: | ||
| + | ** using libpcap library. | ||
| + | ** using RAW SOCKETs. | ||
| + | |||
| + | * I have implemented a StreamReader from scratch using raw sockets without depending on libpcap library. | ||
| + | * The basic function of my current StreamReader class: it listens for any incoming UDP packets on the local interface from a particular IP address and port number. The IP and Port are given as an input for the class. The output of this read function is returned in a buffer that contains packets received from the predetermined address and port. | ||
| + | * I tested my program by streaming video from VLC destained to my client's IP address. I was able to capture the stream packets and save them in the buffer. | ||
| + | * Every instance of my class shall handle different requests for different streams. I will handle multiple requests by multithreading. It is still not clear to me though when to terminate each thread? and whether it should continue listening for incoming stream from source until terminated by a user request. | ||
| + | * I still have to test my class by receiving from multicast stream to see if I have to handle this differently. | ||
| + | TODO: | ||
| + | * integration: add my reader class to the repository and integrate it with the burst class. | ||
| + | * write about DarwinSS installation and configuration in the wiki. | ||
| + | * update the design for the StreamReader class. | ||
| + | |||
| + | == 31 May 2010 == | ||
| + | * Tried implementing streaming clients using different libraries mentioned below. | ||
| + | * The most advance and used library is LIVE555, and I was able to write a program that receives a unicast stream from the server and saves the payload in a buffer. My only concern about this library is complexity of debugging for any future reason. | ||
| + | * The RTSP session was created easily but faced some problems with firewall blocking UDP packets flow. I think this issue can be ignored for now. I tested the program successfully on a local machine and between two remote machines. | ||
| + | * In case of RTP only, I implemented a client that uses ccRTP GNU library to download RTP packets from the server. ccRTP is a solid implementation and very easy to use. However, it depends on many other GNU libraries and therefore it requires long installation procedures in case those libraries were absent or obsolete. On the other hand, it provides reliability and high performance. | ||
| + | * Looked up how to perform multiple streaming instances of the RTPreader through multithreading. | ||
| + | * Now I am revising our initial MTV code in order to understand how to handle the arguments and deal with the buffer. | ||
| + | * after a quick review, I think we don't have to implement RTSP over RTP at this level, based on the current implementation of MTV, which takes the whole IP packet including UDP and RTP headers. However, there is a comment left in the Burst class saying that eventually we shall store only the media data in the buffer (i.e. RTP payload) as I understand. | ||
| + | |||
| + | * TODO: Test multiple streams and multithreading. Test the compliance of the buffer to BurstReader class processing requirement. | ||
== 24 May 2010 == | == 24 May 2010 == | ||
Latest revision as of 15:24, 10 August 2010
Summary of accomplishments by Bassam Almohammadi.
August 9, 2010
- completed the new implementation that will substitute the old Sniffer.
- I will start unit testing to validate all the API's and double check the timestamps sync appropriately.
August 2, 2010
- implemented a unicast connection that connects with the streaming server for every streaming program.
- for every streaming program I create a new thread that establishes a connection with the server and get the SDP info.
- now working on parsing the SDP info in order to extract the media type and record a new timestamp for both video and audio according to local time.
July 19, 2010
- implemented all the test cases and added them to the src/test folder in the repository.
- documented all the test cases in the test section of the design document.
- performed a thorough testing for all the APIs in my module and made all the necessary fixes. The module has passed all the tests.
- the stream reader is now fully functional according to the design. Need to be integrated with the scheduler if we want to test bursts generation.
July 12, 2010
- Updated the design document for the stream reader, and included new APIs required for the scheduler.
- Completed the integration of the stream reader based on the new design:
- in MTV: added a new thread for the Sniffer.
- in Configuration Manager: added a new case for "Stream" Programs.
- in Programs: added a new constructor to handle the creation of the UDPReader for the stream.
- completed the Sniffer implementation.
- completed the UDPReader implementation of the new APIs.
- added new fields to the Ip_pkt class to use it for buffering packets in the UDPReader.
- Used mutex to control the shared buffers between the Sniffer thread and the Timeslicer thread.
ISSUES:
- still not clear about handling audio/video stream. My current implementation considers them equal and sort them in a single buffer based on their timestamp. I assume the rest is for the scheduler to handle.
- I assume all the packets that should be handled by the Stream Reader contain RTP payload. Thus I relay on the timestamp in the RTP header to sort packets. If we shall handle any other type of packets then I think we should filter them differently from RTP packets? consequently, I shall add a local mechanism to record the timestamp for these packets.
- according to the design, the implementation should work fine with multicast. However, I'm not sure how the scenario will be different with handling unicast streams? do we need to support this?
- I couldn't find a perfect way to check whether UDP data contains RTP payload or not for live streaming. I am checking for the constant version field ==2 for now. I looked for better alternatives and apparently there is no better way than sending a DESCRIBE command and get the SDP. I think this is not a big issue because we are listening on a specific port and address which will hold only the stream data (true?).
TODO:
- integration testing [and debugging].
- update test cases documentation.
July 5, 2010
- Added Sniffer class to the design and the code. Its function is to listen for incoming live stream on a separate thread and filter packets into UDPReaders packet buffers.
- created a thread for the sniffer at the initialization of the Mtv class.
- created a new constructor in the Program class for live programs. Live programs, and the program type in general, shall be identified by a new 'string' field in the configuration file.
- created two instances of UDPReader for every live program, one for audio and one for video. Both instances share the same IP but different ports.
- the challenge here is in returning the ready Burst instance. Currently the timeslicer::schedule() makes only one push_request per program for one Burst instance. I propose declaring the program type in the public field of 'Program' class. At the timeslicer::schedule(), if we want to schedule a burst for a program we shall schedule two bursts for live programs!
- Generally almost done with the integration. The only thing left is to load packets from the UDP buffer to the burst. I'm trying to figure out the function of get_candidate(current, deltaT) to write a parallel one for the UDPReader.
- after the integration is done with the burst class code, I can perform integration testing.
June 28, 2010
- Discussed the design with Som and made some modifications.
- Updated the design document accordingly.
- Started integration with the current code.
- TODO:
- Finish integration.
- Perform integration testing.
June 15, 2010
- read the DVB-H implementation guidlines, and looked into FATCAPS source and documentation to get an idea how they implemented the dataAggregator.
- updated the class diagram for StreamReader and UDPReader. Still have to confirm this with Som in order to update the design document.
- working on integrating my class with the Burst class.
June 8, 2010
- faced a challenge in receiving packets with IP headers included. As far as I know there are two ways of doing this:
- using libpcap library.
- using RAW SOCKETs.
- I have implemented a StreamReader from scratch using raw sockets without depending on libpcap library.
- The basic function of my current StreamReader class: it listens for any incoming UDP packets on the local interface from a particular IP address and port number. The IP and Port are given as an input for the class. The output of this read function is returned in a buffer that contains packets received from the predetermined address and port.
- I tested my program by streaming video from VLC destained to my client's IP address. I was able to capture the stream packets and save them in the buffer.
- Every instance of my class shall handle different requests for different streams. I will handle multiple requests by multithreading. It is still not clear to me though when to terminate each thread? and whether it should continue listening for incoming stream from source until terminated by a user request.
- I still have to test my class by receiving from multicast stream to see if I have to handle this differently.
TODO:
- integration: add my reader class to the repository and integrate it with the burst class.
- write about DarwinSS installation and configuration in the wiki.
- update the design for the StreamReader class.
31 May 2010
- Tried implementing streaming clients using different libraries mentioned below.
- The most advance and used library is LIVE555, and I was able to write a program that receives a unicast stream from the server and saves the payload in a buffer. My only concern about this library is complexity of debugging for any future reason.
- The RTSP session was created easily but faced some problems with firewall blocking UDP packets flow. I think this issue can be ignored for now. I tested the program successfully on a local machine and between two remote machines.
- In case of RTP only, I implemented a client that uses ccRTP GNU library to download RTP packets from the server. ccRTP is a solid implementation and very easy to use. However, it depends on many other GNU libraries and therefore it requires long installation procedures in case those libraries were absent or obsolete. On the other hand, it provides reliability and high performance.
- Looked up how to perform multiple streaming instances of the RTPreader through multithreading.
- Now I am revising our initial MTV code in order to understand how to handle the arguments and deal with the buffer.
- after a quick review, I think we don't have to implement RTSP over RTP at this level, based on the current implementation of MTV, which takes the whole IP packet including UDP and RTP headers. However, there is a comment left in the Burst class saying that eventually we shall store only the media data in the buffer (i.e. RTP payload) as I understand.
- TODO: Test multiple streams and multithreading. Test the compliance of the buffer to BurstReader class processing requirement.
24 May 2010
- Found many libraries for RTP (RFC 3550) / RTSP (RFC 2326):
in addition to some other libraries, but those were the most commonly used in other projects. After exploring each library's code and documentation, I found that JRTPLIB is the best candidate due to its good documentation and simplicity of reuse.
- Finished the draft implementation of a client program based on JRTPLIB documentation, still facing some problems in building the code in order to test it.
17 May 2010
- Practicing C++ native on Eclipse CDT for Ubuntu.
- Reading about QuickTime Streaming Server and Darwin Streaming Server. [6] [7] [8]
- Reading about RTP and RTSP protocols. [9] [10]
- Install and configure Darwin Streaming Server and explore the source code.
- Test streaming successfully with some clients (QuickTime and VLC).
- Looking at some open source streaming clients and trying to understand how they function. [11]
