Week 7

This past week was the busiest school week yet. Midterms really threw a wrench in my usual plans for managing the workload. I also happen to have assignments due on the first three days of the coming week, so I have spent all of the weekend at home doing work. That said, my schedule looks like it's clearing up a little after Wednesday, so I may actually get to spend next weekend doing something other than schoolwork!

What I Worked On

Earlier in the week I met with mtomwing over IRC and got some excellent feedback on the Configuration API draft that I started writing a couple of weeks ago. I reworked most of the Configuration endpoints based on his feedback. These can be seen here:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/

Later in the week, I spent some time debugging an issue with the refactored plugins code where different instances of a plugin were being saved under the same section in the plugin.conf file. I fixed that issue, made a few other suggested changes and improvements, and the plugins refactoring PR was merged into master! 

While testing the plugins code I also discovered a quirk with the plugin settings widgets: hitting 'close' on a settings window does not save the configuration, so for some of the plugins the default settings shown in their config widgets don't match the settings actually written to file until the user actively changes them. I opened an issue with a more detailed description:

https://github.com/Freeseer/freeseer/issues/636

What I Will be Working On

This week I want to prioritize work on the Configuration API, as I think there will probably be many details to work out once I start delving into implementation.

I would also like to have another look at https://github.com/Freeseer/freeseer/issues/636 to see if it's possible to improve the plugin widgets by adding config.save() callback methods to their close buttons.

Week 6

This felt like a very short week: probably because we had our last meeting on tuesday due to Thanksgiving weekend travel plans. It also happened to be a very busy week for me in terms of assignments, so I can't say I got as much done for Freeseer as I would have liked.

What I Worked On

Plugins

I made some changes to the plugin refactoring PR after receiving some feedback:

https://github.com/Freeseer/freeseer/issues/588

Configuration API Spec

I made a few changes to several endpoints in the spec. The biggest change being that I completely separated the endpoints for viewing/setting the configuration profile from the endpoints that cover the configuration itself.

The spec draft can be viewed here:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/

Flask and Configuration

I spent some time reading about flask (http://flask.pocoo.org/), and going over the existing recording.py and server.py code. I started experimenting on the configuration controller implementation, and opened a WIP pull request to keep track of these experiments: https://github.com/Freeseer/freeseer/pull/632

Issues

I encountered a unit test failure while testing some of my plugin configuration changes. Strangely enough, it was related to the server tests using the user's real configuration dir and not at all related to the plugins. I opened an issue for it: https://github.com/Freeseer/freeseer/issues/629

What I Will Be Working On

I will mostly be working on the configuration.py controller and some of the related functionality. 

An enhancement I would like to see for the Config classes is to have a method that returns the Config's options wrapped as key-value pairs in a dictionary. ChoiceOption classes could be represented as a list of available options plus its selected one. This will make the implementation of the configuration endpoints much cleaner and straight-forward. I may tackle this over the next week, since it makes sense to have this enhancement before going too deep into implementing the configuration back end.

Next week also happens to be particularly busy again due to midterms and a nasty assignment due date, so I may not get much time to work on Freeseer until later in the week: probably friday and saturday. However, I will check for and respond to any feedback I get on the config API spec.

Week 5

The past weekend was Thanksgiving, and involved a bit of travelling and family time. Most of the work I did on Freeseer was from earlier in the week, although I managed to sneak in a bit of homework between bouts of Turkey meals.

What I Worked On

Plugins

I spent the earlier part of the week working Plugin refactoring. The first task I spent time on was writing up a brief description of the unsupported plugin problem I had found while refactoring the firewire plugin last week, which can see read all about in this document: https://docs.google.com/document/d/16tRySYdZIaKww8L32wWFMSMX67ifXy77VjNh3zSBWd8/edit

Given feedback from one of Freeseer's mentors, I re-visited all of the plugins that were potentially affected by the above issue and simplied their Config classes to use StringOptions instead of ChoiceOptions. 

I also spent some time converting the last plugins that were still using the old Plugin Manager configurations to use Config classes instead: Pip, VideoPassthrough, Audiofeedback, Ogg Icecast, Ogg output, Videopreview, RTMP Streaming.

https://github.com/Freeseer/freeseer/pull/589

Configuration API Spec

I did some review of RESTful API design and started on a draft for the Freeseer Configuration API Spec, documented here: 

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/edit?usp=sharing

So far this spec includes endpoints for user profile, the general config page, the recording config page,  accessing plugin categories (audio, video, file, streaming) and specific plugins. I have not yet considered endpoints for the other two pages in the configuration tool.

Issues

I had an interesting issue with the Travis-CI unit tests earlier in the week. Basically, the multimedia unit tests were failing on Travis despite not failing when I ran them locally. To complicate matters, the failure on Travis was silent: There was no unit test output of any sort, and no messages specifying which particular test was failing. The test script just exited abruptly at the test_multimedia.py file.

The actual cause for the unit test failure was related to one of the plugins having a default value that was incompatible with the VM that Travis was running the tests on: The VideoPassthrough Plugin's default input was set to 'Desktop Source', which is unfortunately not supported on Travis. Changing this to 'Video Test Source' fixed the issue.

More importantly, we never did quite figure out why the unit tests were failing silently. If this happens to someone else in the future, one way of ensuring more output is to modify the ./run_tests script in the root folder of Freeseer by making this change as suggested by mtomwing:

-run_or_fail "src" "python setup.py test"

+run_or_fail "src" "py.test --verbose"

What I Will Be Working On

The coming week I plan on continuing work on both the plugin refactoring and the configuration API spec, and hope to get feedback on both. If the API spec looks reasonably good and I have extra time, then I will also start on writing the Configuration Controller class.

Week 4

What I Worked On

All of the work I did this week once again focused on refactoring existing plugin classes to work with the freeseer framework's Config class, and can be seen here (https://github.com/Freeseer/freeseer/pull/589). The overview of items I worked on is as follows:

• Finished with the audiomixer package by refactoring the MultiAudio plugin.
• Refactored all of the videoinput plugins: DesktopLinuxSrc, FirewireSrc, UsbSrc, and VideoTestSrc.
• Made the new ChoiceOptionFunction class a bit more robust in handling cases where the choice function returns no options.
• Spent quite a bit of time debugging an issue related to plugins not finding any compatible devices (described below) and the Config class' strong objections to such cases.

Issues 

In Freeseer's master branch, plugin configurations are persisted to file (plugin.conf) when the user makes any changes to the plugin's settings from inside the configuration windows, or when the user simply opens that plugin's configuration widget even if no changes are made. I wanted to fully duplicate this behavior in my branch with the new Config classes, but ran into an interesting issue while working on the firewire plugin. 

My laptop has no firewire, so naturally initializing the firewire plugin produces no selectable options for video. While the master branch handles this particular case by creating a default but fictional "/dev/fw1" entry to save in the plugin.conf file, the Config files I am working with in my branch are much stricter. Saving the plugin settings to file with a missing configuration option throws an OptionValueNotSetError. Saving to file with a fictional default value (like on master branch) throws an InvalidOptionValueError.

This same issue is causing some failures on the Travis CI tests, as some of the other plugins (PulseAudioSrc and UsbSrc) that are now using the Config files are also not detecting any compatible devices available on the Travis test VM. Since no compatible device is available, the Config file can't have a real value for that particular configuration option, and so throws the OptionValueNotSetError when the plugin's initialization code tries to read the device.

What I'll be Working On

I'll first revisit the issue I described above: I was considering extending the Options code to have an Options.NoneAvailable type as well as the existing Options.NotSpecified. This will let us explicitly record the fact that there are no compatible devices detected for a configuration. 

I'll need to review the plugins' init methods and make sure they can handle the cases where some needed option ends up being NoneAvailable. It's possible we should also alert the user when some chosen plugin finds no compatible devices, since the current code doesn't do that.

I still need to refactor the PIP (picture-in-picture), and the VideoPassthrough video plugins.

Finally, I need to start writing up a spec for the configuration system's REST api, although this task may get pushed back a week since I'm still dealing with the above plugin issues this week.

Week 3

Week 3 was a little short and less productive then I had hoped. After the 3 day code sprint last weekend, I had much work to catch up on for my other classes: readings, assignments, and problem sets that are somehow all due this upcoming week.

What I Worked On

I worked pretty much exclusively on the plugin system (#589 - refactor plugins).

JackAudio and PulseSrc Audio Plugins

The first task I visited this week was to finish converting the JackAudio and PulseSrc plugins to using their respective JackAudioConfig and PulseSrcConfig classes. This involved reworking the PulseSrc plugin's __get_sources() method so that it could be called by the ChoiceOption class used in the configuration.

I had to spend some time tracing a bug in the PulseSrc plugin initialization that was in the end caused by my change: I was not passing a valid and necessary default option for the plugin's 'source'. This just served as a reminder that our current unit tests are incomplete in their coverage, so some of the work i'm doing with the plugins requires manual testing.

ChoiceOptionFunction

I experimented with a ChoiceOptionFunction class to extend ChoiceOption: The purpose of this (as mtomwing commented on the above pull request) is so that the configuration files can be given a callable from which to generate available configuration choices at runtime, rather then receiving a static list of options which no longer change after the Freeseer starts. The use case would be for users who plugin some new peripherals (ie webcams, or usb microphones) while Freeseer is already running.

I'll have to do more work on this to make sure that all of the run-time methods that make use of ChoiceOptionFunction are overriden to use the callable, instead of ChoiceOption's static list.

Multiaudio Plugin

I started refactoring the multiaudio plugin to use its own Config file, but put it aside temporarily as I discovered the PulseSrc bug above. I have left that work set aside in my stash, and will continue on it this week.

Tig Stash is Awesome

I've gotten into the habit of using the tig command line tool (http://jonas.nitro.dk/tig/), but only recently had the occasion to discover tig's stash browsing feature with the 'tig stash show' command. Very handy way to find some bits of code that you put aside earlier.

What I Will Be Working On

1. Make sure that the plugins using the Config changes are still being persisted correctly to the user profile's plugin.confg. This will require a bit of additional refactoring.
2. ChoiceOptionFunction: Find all methods used by ChoiceOption plugins at runtime, and override in ChoiceOptionFunction as necessary.
3. Finish the Multiaudio plugin refactoring, then continue with remaining plugins.

Week 2

The Code Sprint

The Fall 2014 UCOSP code sprint was held this past weekend, hosted at the Mozilla offices in downtown Toronto. I attended the thursday evening social gathering as well as the three days for the actual sprint. It was an excellent chance to put faces to the IRC names of my Freeseer student team mates, as well as one of our mentors, Joseph.

What I Worked On

I spent much of the sprint reading the Freeseer codebase and drafting a proposal for the project that I plan to undertake this term. Freeseer currently has a basic HTTP API implementation that allows the user to remotely record and access recordings on a machine running Freeseer in server mode. As it stands, however, a user is unable to remotely access or modify any of Freeseer's configuration settings. My proposed project for term involves writing the REST API for this system.

The first concrete task I worked on once I had received some feedback about my project proposal was refactoring the existing plugin classes with the intent of making their configuration details easily accessible for the future remote config API. I opened a work-in-progress PR (#589) so as to get some quick feedback and to make sure I was working in the right direction.

I dealt with a few other miscellaneous issues over the weekend, including learning to properly rebase my pull request branch so that it could be merged into the upstream master. I also opened issues for a couple of Freeseer configuration problems I ran into while setting it up on my laptop:

1. #575 was an issue with the dev_requirements.txt file missing the Sphinx dependency.
2. #577 was a sound issue caused by missing the required gst plugin for Jackaudio.
3. #578 was a video recording issue that was fixed by installing ucview on my Fedora laptop.

What I Will Be Working On

Over the next couple of weeks I will be working on refactoring the existing plugins to use PluginConfig classes, as needed. Additionally, I will be reviewing RESTful API design so that I can write the spec for the remote configuration API. 

Week 1

Me, UCOSP, and Freeseer

My name is Francisco Canas. I am a 4th year undergrad student at the University of Toronto's Computer Science department. This fall, I am participating in the Undergraduate Capstone Open Source Project (http://ucosp.ca/) as part of my 4th year curriculum. I will maintain this blog on a weekly basis in order to share my overall impressions of the UCOSP project, and also as a status report for my team mates and mentors.

The UCOSP project that I am participating is Freeseer , an open-source, cross-platform video streaming and webcasting program. You can read all about Freeseer here: http://freeseer.readthedocs.org/en/latest/about/index.html

Preparation

In preparation for the first official week of working on UCOSP, I first spent some time ensuring that my dev environment (ie. my laptop) was capable of running Freeseer and set up with all of my usual dev tools. My goal was to have Freeseer working, and to be able to run, test, and debug the project from my IDE by the time the first week started.

The first challenge encountered was a failing test suite, and I was able to fix these failing tests by installing a couple of dependencies that were missing from my Fedora system: gstreamer-python, sphinx, and sphinx-python. 

Running Freeseer successfully also required a little bit of troubleshooting. Although the program started up fine, I was unable to successfully record any video or audio, and was seeing stack traces in the terminal when attempting to record. Once again, this issues were caused due to missing dependencies. I use Jackaudio on my laptop, and so had to install gstreamer's Jack plugin, which came in the form of the package gstreamer-plugins-good-extras. This fixed the audio recording issue, but my webcam only became accessible to Freeseer once I installed and configured ucview as detailed in these instructions: https://ask.fedoraproject.org/en/question/7456/my-webcam-does-not-work/

Week 1

What I Worked On

Most of the time I spent on Freeseer this week involved reading code and trying to understand the project's overall architecture. I also worked on some more immediate improvements to unit tests (see https://github.com/Freeseer/freeseer/pull/565).

What I Will be Working On

After a good discussion on the IRC channel about some potential additions to Freeseer's remote recording capabilities, I am considering working on a remote configuration API. Having such an API would allow users to remotely configure Freeseer, thereby opening the potential for using it as an entirely headless recording device. Before the configuration API can be started on, however, it may be very necessary to clean up the code for Freeseer's plugins. This is the area that i'll be focusing on over the next week (at least).