As promised here's a follow-up to the trial of HD HTTP adaptive streaming we ran during Wimbledon.

The trial produced a lot of useful feedback and data for us. So much, in fact, that it's taken us longer than expected to digest it all and make plans for our next trial; more about that later.

The HD adaptive bitrate trail on three screens.

Our objectives for the trial covered two broad areas: we wanted to see how the HTTP Adaptive bit rate player performed in real-world conditions and we also wanted to gain a better understanding of how our infrastructure - the systems behind the scenes that supply video to the player - would handle the traffic generated by ABR streaming.

Many of you took the time to give us feedback about how the player was working. As we expected there were a few issues: some of you were not getting full quality HD; occasionally a fragment of old video would show up in the stream; sometimes the bit rate switching was not as stable as we would have liked. We read each of the 212 comments and categorised the problems into eight distinct areas so we could start work on fixing them:

• iPlayer user interface
• Variations in video quality
• Delays / buffering
• Old video fragments
• Latency relative to live event
• Switching performance
• Jerky playback
• Other

In general though the adaptive bit rate streaming seems to have been a success. Here's what A Poskitt wrote in a comment on the blog post:

Andy, I am at the end of the line here in Wales with max. speed 0.5MB. However your streaming is like I have never seen it before, continuous and clear as a bell even on the maximum 4 that I receive. I have seen real TV on my computer for the first time!

The feedback you gave us has already been put to good use; it's told us things we couldn't have found out in the lab. We literally couldn't have done it without you.

It's also given the programmers who are working on this a great incentive to make it work even better; I think a remark I overheard sums that up: "Isn't it amazing that people are taking so much time to write detailed, accurate feedback - makes it all seem worthwhile". It does indeed. Thank you all for taking the time to share your thoughts and comments with us.

So, what next? One of the things that disappointed quite a few people was that we were only able to run the trial during office hours. That was disappointing for us too - we want to know more about how well HTTP adaptive bit rate streaming works on domestic broadband connections. When the trial is run during office hours, unsurprisingly, most of the traffic comes from office networks. So this weekend we're going to run a trial for the Hungarian Grand Prix. We'll cover the qualifying session from 12:10 to 14:20 on Saturday and the race from 12:05 to 15:25 on Sunday. See you there.

Andy Armstrong is the Technical Architect for Programmes and On Demand

• Try out the HD HTTP streaming coverage of the Hungarian Grand Prix on the BBC Sport web site.
• Read Andy Armstong's blog post about the Wimbledon trial.

Andy Armstrong's colleagues testing HTTP HD streaming video

I'm Andy Armstrong, technical architect for Programmes and On Demand here at the BBC. We investigate new technologies for online video and audio delivery looking for ways to enhance existing services, provide new services and streamline the way we handle media content on the internet.

Important sporting events like Wimbledon are great opportunities for us to test new technologies. This year we're testing a number of things including high definition HTTP adaptive bit rate video streaming.

Currently we use multiple approaches to bring video to your computers and other connected devices. The majority of you are using iPlayer in your web browser. That uses RTMP - a protocol developed by Macromedia (now Adobe) specifically for streaming audio and video over the web.

Unfortunately RTMP isn't available on all of the devices we support so we have to use other protocols too - principally HTTP and HTTPS progressive download - the same mechanism that is used for web pages and images.

We're always on the lookout for ways to support a wider range of computers and connected devices. If we can find a way to do that and at the same time serve more of them with a common protocol we will be able to provide a better service and make our infrastructure simpler and more efficient.

One technology that may make that possible is adaptive bit rate HTTP streaming. It works by splitting a video into short chunks (typically between 4 and 10 seconds long). Each chunk is available in a range of bit rates and hence qualities. For each chunk the player decides which bit rate to request based on its estimate of how much bandwidth your internet connection has.

We already use ABR streaming for some sports coverage with a limited range of available bit rates. For the Wimbledon test we will be using Adobe HTTP Dynamic Streaming for the first time and will be supporting bit rates of 416k, 624k, 944k, 1408k, 2112k and 3168k and a maximum resolution of 1280x720 (720p HD).

Until the player has had a chance to assess how much bandwidth it has available it will tend to choose lower bit rates. That means that the first few seconds of the video may be lower quality. Then, if you have enough bandwidth, the player will gradually select higher bit rates until it either detects that it is using as much bandwidth as it can safely sustain or it reaches the highest available quality. To get the highest bit rate the player needs to be displaying full screen video; the embedded version will limit the maximum bit rate to 1408k.

The player maintains a small buffer of downloaded chunks so that it can keep playing without interruption as the available bandwidth varies. At times it may detect that the overall available bandwidth has reduced and switch to a lower bit rate to compensate.

All this should happen smoothly and unobtrusively. Buffering times should be greatly reduced. The fact that the player adapts to the available bandwidth is particularly helpful for live events such as Wimbledon; it allows the player to display the highest possible quality video without lagging too far behind the live action as it struggles to buffer downloaded video.

However - as you might have guessed - if we had all this working properly now we'd be using it for the main web coverage of Wimbledon rather than testing it. This is an extremely promising technology but we don't feel that we know enough about it yet to do that. We know, for example, that the method the player uses to estimate the available bandwidth will need to be adjusted and we need to see how our servers handle this new kind of traffic.

So we certainly can't promise that it will be perfect. In fact we'd be rather surprised if it was. We have been testing it with a small group of BBC staff since February; now we've reached the point at which we need your help to find out how it works for a larger, more representative audience.

For the test we have placed a small icon (see above) in the upper left corner of the video that shows the current bit rate that you are viewing (1 to 5, HD). It will be interesting to hear from you how quickly the player settles to a sustainable quality - that can vary depending on the characteristics of your connection. If you haven't seen it already take a look at the test page.

We are extremely grateful for your help. We expect to run more tests of HTTP streaming over the coming months and it will be particularly valuable for us to have feedback and suggestions from those of you who have been in it from the start.

Andy Armstrong is the Technical Architect for Programmes and On Demand.