As I detailed in my last post, I've been hacking on Firefox bug 517363. This bug aims to fix <video> poster frame image stretching that occurs if you have a video that's a different aspect ratio as the poster itself. After a lot of trial and error, I came up with this patch, which seemed to do the job. cpearce took a look at the patch, and pushed it up to try. This revealed that my patch was breaking reftests related to poster frames.
An investigation into this revealed that my code was not drawing the poster if a video element did not have a set size (Either through height/width or CSS). Roc pointed me to an object in the method called aMetrics, which contains the calculated height/width of the video's drawing area. This is what I needed. I reworked my solution to use aMetrics. Testing against this new code I noticed a completely different issue with poster frames.
Lets say you have a video that's 500x500, and a poster image that's 250x250. When Firefox loads, it will create the video at an initial size of 250x250. I thought that this looked weird and mentioned it in the poster frame scaling bug. Roc linked me to the spec for intrinsic video sizes which states:
"The intrinsic width of a video element's playback area is the intrinsic width of the video resource, if that is available; otherwise it is the intrinsic width of the poster frame, if that is available; otherwise it is 300 CSS pixels.
The intrinsic height of a video element's playback area is the intrinsic height of the video resource, if that is available; otherwise it is the intrinsic height of the poster frame, if that is available; otherwise it is 150 CSS pixels."
Using the spec as a guide it's clear that things aren't working correctly when calculating intrinsic video size. I filed bug 726904 on this issue, assigned it to myself and began working on a fix. Luckily all the code I need exists already in nsVideoFrame::GetVideoIntrinsicSize, it just needs to be rearranged to do things in a proper order. Once I had a fix, I started playing around with some different use cases. I noticed a couple things while doing so. If your video sets the preload attribute to "none", there will not be any information about the video when it gets it's intrinsic size, and will go with the poster frame. This makes perfect sense. If there is no preload attribute or it's set to "auto" then the video will report the size of the video, which seems to load its metadata in time. After getting some feedback on my first patch, I've juggled things around a little more and now I'm preparing a new patch for some feedback.
I'm thinking about applying for Level one commit access so that I can run tests on my code, as it's hard to tell if my fixes are breaking other tests. This is especially true when it comes to the poster frame bugs, because they change the current behaviour of the video element that other tests might rely on. now I just need somebody to vouch for me.