Streaming Support And MediaKit Development - Weekly Report #3
Hello, here a short report about how things are coming along.
Work continue on the curl streaming code
I’ve continued working on the network glue by adding a very basic locking using the RWLocker in Haiku’s shared kit. This class allow multiple concurrent readers and an exclusive writer at one time.
Added a live555 recipe to haikuports and Fixed live555 source to compile with gcc2
The live555 library recipe has been necessary for the next step which relates integrating it in the Haiku build system. Once this initial work has been completed I can begin to migrate the curl code to this library. To make this happen there was need of some fixes to make it compile under gcc2. Being added just a day ago, I expect the final recipe to be more sophisticated too.
Included parts of past weeks work into official tree
I’ve used some time to make the point and slim down my local branch.
This has been necessary to make way for the next step into the development and among the other things I wanted to submit for review my code. While I requested it, the tracking to make my work reviewed in the mailing list has not been set up, at this point I felt it was needed. I excluded from the changes the streamer plugin code as it was not worth of, I prefer to include the final version when it will be ready (and working). MediaPlayer changes are also out right now. To keep the stability, the intent of this merge is to begin testing for regressions rather than testing the actual features.
Plans for future caching implementation in the plugin manager
The general idea is to move out the complexity from plugins. My plan is to move away code from the curl streamer. Depending on what the upper level code want to do there might be different levels of caching needed. I’m studying how to develop the PluginManager further to supply different levels of caching and MediaIO to specify if the stream is seekable backward and/or forward.
The work on MediaPlayer has stalled a bit right now, the main problem being that the code is recreating the BMediaFile every time it needs access to. In the backend it results in the plugin trying to download the data twice and as you might imagine this cause various problems. There’s probably a reason for having the code behave this way, so I decided to look a bit more in deep before to make this change in the MediaPlayer engine. In the meantime I’ve setup a little test program so that we can have a replicable test in our source tree.
See you next week!
Barrett's blog
- Tales of a Video Editor #2
- Tales of a Video Editor
- Streaming Support And MediaKit Development - Report #7
- Streaming Support And MediaKit Development - Report #6
- Streaming Support And MediaKit Development - Report #5
- Streaming Support And MediaKit Development - Weekly (?) Report #4
- Streaming Support And MediaKit Development - Weekly Report #3
- Streaming Support And MediaKit Development - Weekly Report #2
- Streaming Support And MediaKit Development - Weekly Report #1
- Media Kit: New And Old Pieces