We default to certain codecs while testing support-seeking-unbuffered-position (e.g., mp3 on chrome). This causes Chrome to fail this test.
However, I have tested it out and it actually performs properly using ogg or aac so I see the need to introduce separate tests for this.
One "interesting" thing that I see here... I have replace the long.mp3 (mono, 11Khz, 32bit samples) for another mp3 (stereo, 44kHz, 32bit samples) and it seems to have a different behavior...
For the long.mp3 there is a unique request with range 0- which never gets cancelled....
For the new.mp3 (only done locally) I see more requests done on the browser but it still tries to download the whole file... trying to figure out why.
We default to certain codecs while testing support-seeking-unbuffered-position (e.g., mp3 on chrome). This causes Chrome to fail this test. However, I have tested it out and it actually performs properly using ogg or aac so I see the need to introduce separate tests for this.
One "interesting" thing that I see here... I have replace the long.mp3 (mono, 11Khz, 32bit samples) for another mp3 (stereo, 44kHz, 32bit samples) and it seems to have a different behavior... For the long.mp3 there is a unique request with range 0- which never gets cancelled.... For the new.mp3 (only done locally) I see more requests done on the browser but it still tries to download the whole file... trying to figure out why.
I will continue investigating what can be done on chrome and update http://code.google.com/p/chromium/issues/detail?id=100303