Bug #519 was about making sure that trackevent handles ( used to resize a trackevent ) made the trackevent gain focus. Currently, clicking on a trackevent would give it focus, but clicking on the handles ( which are a child element of the trackevent ) would not.  After digging into the code a bit nothing jumped out a me that was glaringly wrong, so I figured it was an event bubbling issue.  I remember that the third arguement of addEventListener ( the one everyone forgets about ) had something to do with event bubbling so I went and looked it up on MDN.  The third arguement, also called userCapture, basically specifies if you want events to bubble as they normally do, from a child element up to it’s parent ( which means it would have a value of false, which I’m sure everyone is used to seeing ) or create what is called an event reflow ( I think ) and change the way an event gets triggered. By setting userCapture to true I noticed that events now fire from the parent element first and then to each of it’s children ( pending they have an event listener for the given event ).  This seemed to do the trick and the trackevent handles were now recognizing a click event and everything was being handled as it should.  The fix that I just explained worked because the event must have been getting captured and thrown away somewhere before it bubbled up to the parent element.  Doing what I did allows us to make sure that the event gives priority to it’s parent first ensuring that it get’s fired there and then fires the event on each of it’s children.  It was pretty cool playing around with how userCapture works and the difference it makes on events that get fired.  I don’t see setting userCapture to true to be something I will use very often, as an event that bubbles from a child up is typically what you want, but knowing how to change the flow and use it accordingly is definitely a powerful tool to remember we have in our arsenal as coders.

The other neat thing I learned this week was that I could use JSON.stringify to beautify JSON. Up until now I have only ever used JSON.stringify to do convert a JavaScript object into a string and never even bothered looking up what other arguements it took.  For bug #619 I wrote a recursive JSON beautifying function to do what I needed and put it up for review.  Bobby Ricther then asked me why I didn’t use something that was built in to do this already, like JSON.stringify.  I had no idea what he was talking about so I looked it up and was pretty amazed at what I found out.  I learned that JSON.stringify actually takes 3 arguements, the first being the source object, the second is a replacer function which lets you customize how you handle various data types, and the third being a spacer which lets you specify how the JSON is printed out. My fix went from a 25 line function to a 1  line fix once I found this out, which looked like the following:

var beautifiedObject = JSON.stringify( obj, null, 2 );

And that was it, I have beautified JavaScript in 24 less lines of code.  This is one of those things that you have to do the hard before you can learn the easy way and how awesome it is. Unless someone told me, I probably would have went on writing my own JSON beautifier functions until the end of time, so thanks for sharing that knowledge Bobby!

This week in general has been great for getting back into the swing of things again and refreshing myself with Popcorn Maker again, it’s crazy how fast the project is moving now a days. You don’t realize the crazy amount of bug mail you get until you take a week off and let it pile up.  Also with a project moving as fast as Popcorn Maker it’s also hard to stay up to date after taking that much time off, the code is changing so much everyday it’s crazy.  I’m looking forward to next week and getting ready to release 0.5 of Popcorn Maker!

Now I’m no teacher, not by a long shot. I tend to stumble over my words when trying to explain things, it ends up coming out as a jumbled mess that I have to piece together again after. Despite this I’ve been doing my best to explain concepts to Rob such as the difference between == and ===, how scoping works in JavaScript, objects, and closures. One thing that I’ve noticed doing this over the past few day’s is how hard it can be to concisely explain something and it has really got me thinking how under appreciated a good teacher can be. One of my bigger pitfalls when explaining concepts, as I explained before, is how I tend to stumble through an explanation. I jump back and forth between points making it difficult to understand what I’m trying to say. This is also evident in the way I give presentations. I tend to add lib a bit and whenever I do I tend to ramble on. I’m trying to make a conscious effort to slow down when explaining things and take a brief pause if needed to collect my thoughts. It’s difficult to do ( for me at least ) because I always attribute pauses of any sort to someone not knowing the content, when in reality I probably look worse trying to rush.

I think the funniest moment over the past few days has been when Rob wanted me to explain something from the book he was reading. There was an example about closures that had the following piece of code ( might not be exact but close enough ):

var i = 20;

console.log( i.toString( 16 ) );

At first Rob asked me what the arguments were that toString took. Without even thinking I’m pretty sure I blurted out “none” and didn’t think anything of it. “But it’s in the book, look”, I didn’t believe him at first, so I had to see for myself. I ended up looking at it dumbfounded for a while trying to figure out what was going on. My response was “Well, let’s see what it does” which I don’t know if I looked dumb for not knowing that toString took an aruguement or not, but regardless this was an opportunity for both of us to learn something together. I busted open my console and began playing with it and we soon realized that if a number was passed into toString it would convert the value to a base-X value. This meant passing in 16 for our value of 20 returned 14, and passing in 2 gave us 10100. It just goes to show that there is always an opportunity to learn something new and I think teaching is a perfect example of this.

Being forced to explain your ideas in more depth than normal can be really difficult and truly is an art. I did my best over the past week to help Rob and I hope some of what I was saying was useful. Teaching someone is really hard and we should appreciate the teachers that we’ve had that we’re good at explaining concepts and helping us ( everything always seems easy until you try and do it ). This was a great experience for me and I learned a lot about how do communicate more effectively and realized I’ve got some brushing up to do myself. Even tho I use most of these concepts daily, it was hard for me to explain things at times and teaching really forces you to know your content inside and out, as you will always get questions that you weren’t expecting. Being able to teach is an art that we all tend to take for granted and until you try and do it, never fully appreciate how hard, draining, and complicated it can be.

The Message: the (r)evolutionary power of climate change
“The Message is a multi-platform (book + documentary + web + events) project by Naomi Klein and Avi Lewis.

Turcot
“Turcot looks at Montreal’s largest highway Interchange, currently scheduled for a complete demolition and rebuild. The interactivity of the documentary project will allow the residents a direct voice, so that their concerns and opinions are heard by others. The voices will build on each other to develop alternative designs and solutions while there is still time to influence the actual Interchange construction.”

Following Wise Men (working title)
“The film will tell an evergreen story about a 50th anniversary reunion road trip with four friends who are astronomers; the interactive project will be an evergreen, searchable, expandable, community-sourced science web site charting astronomers and their discoveries in the context of their professors, mentors and students in an astronomer’s family tree. “

Looking at Los Sures “We will use an archival documentary (Los Sures by Diego Echeverria, 1984) about the South Williamsburg neighborhood as the inspiration as well as the primary online navigation for a set of new documentary projects that approach the same place and themes, now nearly thirty years later. New short interactive projects created by thirty different artists over three years will annotate and expand on the original film in ways previously unexplored.”

The Last Hijack
“For over 20 years Somalis have faced the horror of famine and war. The Last Hijack is a story about survival in this failed state. It is about the rise of piracy and how it affects the people around it.”

Immigrant Nation

Kate Hudson and I were paired up with Katie McKenna and began understanding what the project was about and what Katie wanted to accomplish.  The nice thing about this experience was the Brett and Ben had all of the teams create a concise idea before coming to Hot Hacks, so we had a good idea to begin with and rolled with it.  What Katie envisioned was a way to showcase the different perspectives of various speakers regarding our environment. To do this, we wanted to use a parallax effect and separate the project into different sections that the user could scroll through and experience each perspective independently with its own unique theme. Another issue that we had to address early on was the fact that Popcorn has a tendency to throw a lot of information at you very abruptly. To combat this we used various transitions and effects to blur content that wasn’t the primary focus at the moment and ease it in when it was relevant. In doing so we created an experience that allows the user to focus on what the speaker is saying but also annotate important information when it made sense.  Another unique aspect of our project was the fact that we utilized scrolling to drive the Popcorn experience throughout the demo. This meant that the user could freely explore the page with the opportunity to jump between perspectives seamlessly. This meant that the user could navigate as they saw fit and not feel like we were spoon feeding them a linear experience.

The experience in general was great. Katie, Kate, and I gelled quite well in my opinion and got on the same page pretty fast. Kate and really got into the groove of things on day two. We were able to both collaboratively work off of a single Github repo and merge with one another pretty painlessly. In typical hack-a-thon fashion, a lot of ideas were tried, didn’t necessarily work, and were thrown away, which was one of our groups strengths in my opinion. Since we weren’t afraid to try things we were able to create a tonne of small prototypes and were able to see what worked and what didn’t very fast. Some of the prototypes that we created and threw away were things like pulling in an RSS feed on relevant information and displaying it across the background of a page, a map of the world that lit up various regions as you scrolled through the page, and many more. It was awesome that Katie was on board with all of this as well, as I’m sure it had to seem quite hectic and scary at times!

All in all the weekend was great and the demo was a success. We created what we set out to do for the weekend and have a cool prototype for a web native version of The Message. I think events like this are an awesome idea as it bridges the gap between two very different professions. Just like Mozilla Journalism is bridging the gap between Journalists and Programmers, The Living Docs project and Popcorn is doing the same for Film Makers and Programmers and it’s great to be a part of.

• Bug 702161 – videocontrols.xml has anonymous function event listeners that are added but never removed
• Bug 680321 – Media preload state should reset in resource selection algorithm
• Bug 708814 – Should fade out videocontrols even if there’s no mouse movement
• Bug 686370 – Implement video playback statistics proposed in WHATWG
• Bug 722788 – JSON number parsing is slower than it needs to be
• Boot to Gecko working on my phone

Overall I’m happy with what I was able to accomplish so far and I’m still working towards finishing the video statistics ticket. Even tho my tickets haven’t been very high profile yet, it’s still a great feeling being able to get some code into Firefox, and really changes your perspective on how much hard work goes into making a browser.  I was working on tickets that involved things such as cleaning up event listeners, making sure controls for video elements got hidden when in fullscreen mode, and making sure the preload state reset properly, so I can only imagine how much work goes into other aspects such as security, the JavaScript engine, and so on. It really gave me a new respect for everyone doing this kind of work and I felt was a great experience.  It’s always funny when you hear someone say something along the lines of “Why doesn’t browser X just fix problem Y, it’s so easy” as once you get into the code it’s never easy and it’s never something that you can just write and then ship the next day, there is a ton of behind the scenes work that goes into making this a reality. Things like testing always go un-noticed by end users and is a really under appreciated portion of work that goes into development. I know from attempting to write my own tests on various projects that trying to prove that your fix is correct can sometimes be that hardest part of a patch. In addition to this I also continue to be amazed by the community and how helpful they can be.

Since I began working on open source projects over a year ago in OSD600 one of the biggest barriers to entry for me has been IRC. It always sounds simple to just go into IRC and ask for help but a lot of the time it can be a pretty nerve racking experience. It can be scary to just throw yourself into the middle of a chatroom full of sometimes hundreds of developers better than you and ask what is probably a trivial question. When I first began doing this I ended up being afraid almost every time, thinking I would be labeled as an idiot for asking such an easy question and from that point on that no one would take me seriously. In reality my experience has been quite the opposite, in that everyone is friendly and willing to help out a newcomer. I don’t know why this is, but I attribute it to the pay it forward mentality, someone helped you in the past so you are likely to do the same for a newcomer that comes to the channel looking for help.  I’ve actually taken this to heart and try to do it when I can, whether it be in Popcorn.js/Butter.js or Firefox bugs, I try to help people/newcomers whenever I can because I know I was once in the exact same position. I’m sure it’s just as hard to them to come into channel and ask a question as it was for me and I want to do whatever I can to make that experience more pleasant.

I have learned quite a bit this semester, from being more humble and stepping aside from my ego, to gaining confidence in both my coding and public speaking.  It’s taught me some interesting lessons when it comes to coding. Until this semester I have always tried to rush through things, brute forcing my way through code in fast trial and error type approach. I would figure out what the problem was and then begin frantically removing, altering, and adding code as I went along. Most of the time when I figured out what was wrong I was left with a warpath of broken and ugly code in my wake, something I’m sure my reviewers in Popcorn.js/Butter.js can attest to as I’m notrious for leaving things like console.log( “ASDASDASDASDASDFAS” ); in my code.  I learnt this lesson the hard way in one of the more recent bugs I was working on, 708814, which needed to be fixed up as it bit rotted for almost a month. I took a quick glance over my code and from what I could see it looked fine, I mean I also got an r+ on it, so it can’t be wrong, right? I went on what was a 20+ hour journey in the wrong direction, looking for a bug that didn’t exist.  It was a stressful experience to say the least, one where you just want to grab your computer, shake it violently, and yell “WHY AREN’T YOU WORKING”. I asked for help in channel and no one else was able to see a bug either. At this point I was spinning in circles in my chair and looking at the same 8 lines of code over and over again not understanding what could be wrong. Sort of jokingly I switched my listener from “mozfullscreenchange” to “mouseover” and changed the if condition to check if the video was fullscreen or not. This was basically the same approach as I was doing, just in a different fashion. To my surprise it worked, as it looked like a fullscreenchange event was being fired before a mouseover event, and this was why it wasn’t working. In the end it boiled down to me having 0 patience and rushing into the code. I didn’t even take a second look at my code and began smashing my face into other code and assumed to problem was there. If I took 10 minutes to go over my code and think about it again I probably wouldn’t have done this. The only real reason I figured this problem out was because I am stubborn and didn’t give up, but if I learned to be patient before hand I probably could have saved a day worth of work. In order to work on code as large as Firefox you are going to need to be able to persevere and be stubborn, the code is going to beat you down over and over again and you need to show it who’s boss. I’ve been pretty good at not giving up this semester, but I didn’t really learn how important it can be to take a step back and be patient with my approach until I saw how far off I went in the wrong direction with 708814 ( and it was really far ).

In general the semester was great, I got to write in a language that I am far from comfortable with, engage with an unfamiliar community, and land fixes in Firefox. I continually tried to challenge myself with the bugs I undertook and I learned a lot because of it. I’m working on getting the video statistics ticket up for review by thursday and then working on review failures from then on. I think being able to say “I wrote feature X for Firefox” is a pretty awesome and is definitely another notch on my programming belt, so that’s what I’m striving for.

I had a great semester with everyone from class and I can’t thank everyone enough for the great feedback during class presentations and the help on irc. It was also great to witness everyone else step it up a notch and see what they got done, it definitely motivated me throughout the course to keep going and not give up.  I wish everyone who graduated this semester ( I think everyone except me haha ) the best of luck with whatever you have planned for post graduation and hopefully we can all stay in touch via the seneca irc channel. To those who I’ll be working with over the summer at CDOT and Mozilla, I can’t wait to see what we make, it’s gonna be awesome!

One of the new issues that is popping up is that Util’s is not defined from the following block of code. I briefly asked Jaws about it but he didn’t seem to know why this was happening either, so I am still investigating as to why this is happening. I also tried using |this| instead of Utils as they seemed to be the same thing, but I think the context of |this| was being miscontrued as well seeing as it was coming from inside a setTimeout.  After compiling and testing this again it wasn’t complaining about Utils not existing coming from my listener, but rather from when it was called inside onMouseMove. I did the same thing I did as before and wrapped the function reference in an anonymous function and called |self._hideControlsFn( self )| ( obviously gross code, but for testing purposes it was fine ). Finally I was seeing some progress! At this point the controls were hiding after a mousemove over the video, but not if there wasn’t one. This was good because I was now back to a state where everything was working the way it should be before my patch got applied, so I knew I was headed in the right direction.

The only thing that I figured could be the cause here was if for some reason the scubber was being dragged, as that was the only check being done inside of _hideControlsFn, so I figured I would make sure that we were getting inside there, which it turns out wasn’t the issue. Back to the drawing board. I decided to look deeper into what was going on, as the issue obviously wasn’t present in _hideControlsFn, so I went looking in the startFade function itself. After reading through the startFade function a bit it was pretty obvious where I needed to monitor, which was this block of code.  I throw some console.logs in there to check out what the values were and if for some reason anything weird was going on and it turns out that still looked pretty normal. The only difference that I could spot was that whenever the controls succesfully hid it would enter the last block inside of the else. I did some more logging before that block executed and got some interesting values. It turns out that the controls were not the only one calling startFade, but also an element called clickToPlay ( maybe the start button? ) so I decided to allow clickToPlay or controls to be the element for the condition to pass, but didn’t seem to make a difference. Looked like there was no option, I had to go deeper.

After playing around with some stuff for about an hour and realized that I missed something super obvious from the get go, that the listener for fullscreen had a check in it for hover, which always came up false initially, which really wasn’t what we wanted. I made it so the listener was for mouseover and checked to see if the video was in fullscreen or not, and what do you know it worked!  After looking at my fix a bit more this made sense ( I think ). I’m happy that I finally figured this bug out, as it was a super subtle and tricky one to figure out, I got led off track quite a bit and went down a ton of deadends. As we speak I’m creating a new patch and making sure that it works fine, so fingers crossed!

Over the course of the semester I have been working on and off on bug 708814 and I even posted a patch a few weeks back. I got a “feedback looks good” from Jaws and thought I was essentially done, so I didn’t worry about it much.  I wanted to finally finish this ticket and get it landed so I could get it off my back.  I began by attempting to write some unit tests, but after about 2 days of driving myself nuts I realized that there really wasn’t a good way to test the feature that I added after Chris Pearce mentioned it on IRC. Awesome, I thought I was done at this point so I put the patch back up for a formal review and thought I had wiped my hands of this ticket, which sadly wasn’t the case.  Before I did this Chris asked me to re-base my code off of master as it had been sitting for a while and then put it up for review. I did this and threw it up, at which time Chris began playing with it.  It turns out that I few edge cases have turned up since I initially wrote the patch and the fix was no longer sound, which sucked pretty hard. I realized that through my neglect the code sat long enough that Mozilla Central had progressed far enough that my patch no longer fixed what it once did and that I needed to go back to the drawing board. It sucks because through my laziness I actually created more work for myself in the long run and should have just followed through with this patch from the get go, as this probably wouldn’t have happened. I am making this my first priority for my 1.0 release and want to get this done ASAP, even before I begin playing with the video statistics again.

The first ticket I was assigned to do this year was 686370, which was to finish implementing the video playback statistics.  I wrote about some of my earlier experiences with this and have been building on what I have been doing since. Mathew Schranz has also been helping me on this and has been writing about his experiences implementing the playback jitter portion of the stats.  There is still quite a bit left to do here and since this is the main feature I am planning on getting done for the end of the semester I am going to have my work cut out for me over the next few weeks.

The last but probably most interesting thing I have been working on is attempting to get Boot to Gecko working on my phone, the Samsung Galaxy SII. Currently my phone is running android and I thought it would be interesting to be able to play with the new mobile OS that Mozilla has been developing. Boot to Gecko ( or b2g for short ) is developing on top of core android libraries that control things such as the camera, wifi, and various other essential parts of the phone experience. On top of the Mozilla has made it so the web is the OS, meaning that everything is written in HTML, CSS, and JavaScript. This was really appealing to me as I work with the web on a daily basis, so being able to create apps without having to play with Java or objective C sounded pretty appealing. The only problem here was that the version of my phone wasn’t currently supported, so I knew I was in for a quite a bit of work. I wrote about some earlier experiences I had working with b2g, but it I never actually got it working which sort of sucks. The farthest I got into the build was getting to the point of flashing the kernel and having it fail at 98%, which really sucks. I did some more research and analyzed the logs a bit over the weekend and found that when I was creating the ROM it was actually failing in a few spots but I never noticed. I am going to research these issues in the future, but probably won’t be able to revisit my b2g work until after I have finished 708814 and 686370.

The next two weeks are going to be pretty busy and I am going to have to work like crazy in order to get these patches ready for the end of the semester, so it should be pretty interesting.

The problem that I initially ran into was build fails due to the fact that my specific model/version isn’t supported yet.  The solution here was to modify one of the build scripts to reflect my device, which wasn’t all that bad.  What I had to do was add in a case for my specific version and account for file names that may be different on my version compared to what is already used.  In a lot of the cases it just turned out to be modifying IF statements or appending an ‘M’ to some files ( as that is my specific version – the GT-I9100M, and the build – GINGERBREAD.UGKG2 ). After I had done this my make config-galaxy-s2 was passing now, which was awesome.

Now it was time to begin building gonk, which from what I understand is the backend of Boot to Gecko.  So I built that and it actually ended up going pretty smoothly.  I then simply ran |make| after that and this is when I began seeing some errors. On a side node it looks just like building Firefox from source, which is pretty cool. The errors were pretty cryptic and about stuff that I didn’t understand so I did what I normally do under these circumstances and went to ask someone smarter than me. I went into the IRC channel and started asking about the error and I immediatley got some responses. I was told to run |make sync| and to pastebin the output. What make sync does is update all of git submodules and makes sure everything is up to date with master.  I ran it and the output looked clean and fine to me, so I pastebined it to the channel. Someone quickly spotted where I went wrong. In my logs it said I that it was updating from my remote, so dseif/b2g ( which looked ok to me ) but apparently was wrong.  The problem here was that I forked and then cloned instead of just cloning.  The reason I shouldn’t have done this is it screws up the submodule updating apparently and I am not getting the most up to date files.  The errors I was seeing were old issues that had already been fixed and what I needed to do at this point was set my origin’s remote url as the url I forked from.  After I did this I re-ran make sync and I started getting updates! I went through the commands that I ran previously and they seemed to be passing now The make command took a while to finish but it did so without any errors.

Now it was time to begin flashing! To do so all I had to do was run |make flash|.  This ended up taking a while and once it was done it rebooted my phone. The moment of truth came and it didn’t boot at all, which scared me a bit I went back and reflashed my device by running the following:

adb reboot recovery

and then selected my backup that I made earlier and reflash my phone. Luckily the backup worked just fine and my phone was back in a working state

Tonight I plan on trying to figure out why my flash was failing and I will hopefully have a running boot to gecko phone by the end of the night

First thing’s first, it seems to be recommended that you do the build on Linux ( the latest version of Ubuntu seems to be what most guides are recommending ) so that’s what I did.  Since I was already running Windows on my desktop I used Ubuntu’s Window’s installer, which allows you to install Ubuntu right alongside an already existing Windows install ( no reformatting/partitioning needed! ).  Once I installed Ubuntu I installed the usual things that I would on a fresh install ( flash, vim, git, got all my music up and running, set up thunderbird, ect ) and begin following the guides that I found online.  One of the great things about the Mozilla community is how well they document things. I was able to follow the steps for the most part with no hiccups. I followed these guides and they seemed to do the trick, so I also recommend them! Just and FYI, I accept no responsibility if you brick your phone by following my steps

Setting up my enviroment so it was ready to install B2G was pretty simple.  It involved getting adb up and running ( which I had prior experience with from some Android development I’ve done ). You can do this by installing the Android SDK ( once installed you may need to run android-sdk-linux/tools/android and update the SDK ). Once that is done, you will need to add adb ( inside android-sdk-linux/platform-tools/ ) to your path ( done in your ~/.bashrc ).  You can test this easily by going to your terminal and typing adb, you should see something like the following:

Now I was ready to backup my phone, which required installind heimdall, which is a cross-platform tool used to flash firmware onto Samsung Galaxy S devices. After installing heimdall you are going to need make sure it has access to your phone ( which is done via udev ). I did this by editting /etc/udev/rules.d/android.rules ( if it doesn’t exist create it ) and adding the following line:

To get things started I was fortunate enough to have some class time allocated to go over how we would begin working on this bug.  Dave went over what would need to be done in order to get this implemented and how we would go from the decoder level all the way up to the DOM.  We began by taking a look at the already implemented portions of the spec and began tracing a route that they took from an idl file all the way down into the decoder. This was invaluable to me as I got input from the class on what they would do, thoughts from others who have worked with idl files before, as well as an understand of the scope of what I would be working on.  After we traced a path through the code it was time to begin coding.

I went home that night and basically didn’t know which statistics I wanted to do first, so I just chose the one at the top of the list, which was bytesReceived. bytesReceived is described as “The raw bytes received from the network for decode. Together with the downloadTime, this can be used to calculate the effective bandwidth. Includes container data.” which basically means that we need a way to measure all of the data that we are downloading for a given media element. I took a similar approach to what was done before in the  video idl file and applied it to the media element idl file.  I began forging my own path down to the decoder and began seeing some results. Once I got into the decoder I found a portion of the code that looked like what I needed to monitor and got access to the data I needed.  I battled with making this correct for the next few nights and it actually turned out that I wasn’t even in the right code, as I’m confident now the data that I need is hidden within the media cache somewhere. I took the weekend off to work on my car and think about this and it dawned on me that what I actually found and created was bytesDecoded.  I ended up renaming things accordingly and testing it again and it seemed like exactly what I needed.  1 down, 5 to go .

Next I decided to work on dropped frames, as I scrambled my brain a bit trying to comprehend some of the media cache code. droppedFrames is defined as “The number of frames of video that have been dropped due to performance reasons. This does not include (for example) frames dropped due to seeking.”. This means that we need a way to measure any frames that are not displayed, which will provide developers with a way to measure the speed of the decoding pipeline ( at least a portion of it, more accurate results would be achieved is used in conjunction with other media statistics ). Since this particular statistic was referencing frames I knew it would be directly related video only, and we could ignore the audio portion of the media element.  This enabled me to do some caro culting and copy what I could from earlier implementation of the video statistics.  Once I reached the decoder I did some searching and read through the code a bit and ended up finding the following snippet in the nsBuiltinStateMachine.cpp and added in a small piece of code that would keep track of all of the frames that were skipped and report them to a setter that I created in nsMediaDecoder for mozDroppedFrames. The setter would simply increment a value that I had stored in the nsMediaDecoder and I also had a getter that would be able to reach in and get the value of droppedFrames.  It looked like a pretty solid first attempt and I rolled with it and all seemed to be working well.  The problem that I am having is finding out if I did it right, because I seem to be getting the same results for both high-def videos and low-def videos ( 1080 vs 480 ).  This doesn’t seem like it should be the case and I should probably look into this further.

The next steps for the statistics are to get the remaining few implemented and get this up for review as soon as possible. I’m sure that I’ve done a few things the wrong way, or it isn’t optimized enough, so I’m looking forward to getting some feedback.  Until then, expect a few more blog posts about this and expect these stats to be landing in one of the upcoming Firefox Nightlies .

We began by dividing up the remaining features that were still needed which included the following:

• bytesReceived – the number of raw bytes received from the network for decode
• downloadTime – the time since first HTTP request is sent until now or the download stops/finishes/terminates (whichever is earlier)
• networkWaitTime – the total duration of time when a playback is stalled, waiting to receive more data from network
• videoBytesDecoded – the number of bytes of video data that have been decoded
• audioBytesDecoded – the number of bytes of audio data that have been decoded
• droppedFrames – the number of frames of video that have been dropped due to performance reasons
• playbackJitter – it is useful for applications to be able obtain an overall metric for perceived playback quality and smoothness

I decided that I would take bytesReceived, downloadTime, networkWaitTime, and dropped frames while Mathew would take on videoBytesDecoded, audioBytesDecoded, and playbackJitter.  I decided to simply start at the top of the list and work my way down, so bytesReceived was first. Since Humph went over this in class last week I had a good idea of where to start, so I picked up where we left off. Using MXR I looked up where the other parts of the playback statistics had been implemented and worked out from there.  My guess was that I wouldn’t need to do too much heavy lifting, as much of the work was probably done for me ( I mean, they must keep track of what they are downloading somehow ) so I began digging through various mediaElement, decoder, and mediaStream files. I eventually ended up pieces of code for each of the various video encoding formats and began sifting through what was there. Eventually I found a function that seemed like something I wanted:

void nsBuiltinDecoder::NotifyBytesConsumed(PRInt64 aBytes)

After looking at the function a bit closer I noticed that it called another function, AddBytes on the mPlaybackStatistics object, which seemed liked something that was related to what I was doing here ( not to mention it was referencing playback statistics! ). Looking closer at AddBytes I noticed it was adding the number of bytes passed into it to a local variable in the decoder called mAccumulatedBytes. I was pretty confident at this point that what we wanted for bytesDownloaded was simply all of the bytes that we have downloaded so far, which im pretty confident is mAccumulatedBytes.  Now I was ready to start coding!

I started by defining the attribute, mozBytesDownloaded, inside of the idl file located at dom/interfaces/html/nsIDOMHTMLMediaElement.idl inside mozilla-central. I made it a readonly attribute that was an unsigned long ( as i’m pretty sure that there will be no negative values here, so why not ).  Next I needed to find a way to reach into the decoder and access the value of mAccumulatedBytes, so I took a look at the route that was currently being taken by similar functions to get to the decoder.  I decided to look at how Chris Pearce originally did this for the already existing portions of the video playback statistics ( mozParsedFrames, mozDecodedFrames, mozPresentedFrames, mozPaintedFrames, mozPaintDelay ). After doing another search on MXR I found that this was being done inside nsHTMLVideoElement.cpp .  Seeing as the bytesDownloaded attribute applied to both audio AND video, I couldn’t do this in here but told me it needed to be done in the nsHTMLMediaElement.cpp file instead.

Inside the nsHTMLMediaElement file I saw similar getters and setters to those that were in the videoElement file, such as GetMozSampleRate, GetMozFrameBufferLength, and many more. I figured a good place for my new function, GetMozBytesDownloaded, would be at home with these guys. I did a bit of cargo culting and stole what logic I could from GetMozFrameBufferLength as it was also accessing the decoder so seemed ok to me.  What I needed to do from here was find my way into the decoder and it looked like GetMozFrameBufferLength was doing so also ( it was calling GetFrameBufferLength() ) so I decided to look where I could write my own function to access the data that I needed. The method was being defined in nsMediaDecoder.h so I figured it was a good place to put mine as well.  After doing a bit of poking around and checking out what else was in here I found the function that brought me down this path, NotifyBytesConsumed! I was feeling even more confident now in my function placement and created my own, getBytesDownloaded. I did some more cargo culting here and stole what I could from NotifyBytesConsumed.  I figured I didn’t need the check that NotifyBytesConsumed had for mIgnoreProgressData as it looked like it was pertaining to whether the video seeked or moved the play position; we only cared about how many bytes were downloaded. Instead of calling AddBytes on mPlaybackStatistics I figured I would yet again write my own function, getBytes. Just like I did previously, I looked up how AddBytes was implemented and followed suit where I could( which was done in MediaResource ).  All my function did was ensure that the video had started ( if it wasn’t started, return early ) and if it had started then return the number of bytes that we have downloaded. Alright great, now lets compile this and see what happens. Anddddd build failures

I managed to fix a few failures but I am currently stuck on one that looks like the following:

Undefined symbols for architecture x86_64:
“nsMediaDecoder::bytesDownloaded()”, referenced from:
nsHTMLMediaElement::GetMozBytesDownloaded(unsigned int*)in nsHTMLMediaElement.o
ld: symbol(s) not found for architecture x86_64

It’s gotten pretty late now, so I am going to tackle this in the morning and hopefully I figure it out then.