QuickTime backend of QtMultimedia reports QMediaPlayer::StalledMedia way too early.

When testing QtWebKit and the media element I found a bug on the QuickTime backend. Same as usual, you run QtTestBrowser (from trunk) you go to tiny.cc/wkmedia, you pick the iPod Touch video and you start the playback. The video seems to disappear for a while and then come back.

I nailed down the issue in the QuickTime backend of Qt Multimedia. What happen is that the backend returns the state QMediaPlayer::StalledMedia way too early, or I would say it sends it when it's not appropriate.

According to http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/QTKitApplicationProgrammingGuide/AnatomyoftheQTKFramework/AnatomyoftheQTKFramework.html#//apple_ref/doc/uid/TP40008156-CH109-SW17

when we get kMovieLoadStateLoading there is no clear distinction of loading like the first load and loading to get more data because the playback can't continue.

The code in QtMM assumed that whenever it's not stopped and we reach kMovieLoadStateLoading, it is stalled. Unfortunately this is not true. Because if we sent the stalled state to the users it means the media has been loaded and therefore we can get the meta-data for example. In that particular use case it's wrong, it's the first load so the backend lie by saying a state way more ahead of what it actually have. That explain why when WebKit get that signal it tries to query the meta-data and can't get them because there are not yet available (and we fallback to 0,0 size)

The proposed patch ensure that in order to send the QMediaPlayer::StalledMedia we reached previously at least the QMediaPlayer::LoadedState.