Poor video/audio quality even on powerful PC, probably due to our buffering logic I see this on certain videos, let me write what I see. VIDEO 1 (part A) 1. goto http://tinyvid.tv/show/2wn7rkzapa2ci 2. do right-click > view video 3. press pause 4. wait till video buffering process stop - even though video is only 31.4MB, it stop buffering around 7 minutes on the scroll bar 5. click play button on video - Actual: video plays with disturbance in audio, and with skipping - Expected : video play properly (part B) 6. click pause 7. move the scrollbar towards end of buffered video, but still inside buffered range (move it by clicking, rather than dragging) 8. wait for video to buffer completely 9. move scroll bar to START 10. Click Play - Actual: Video plays without any problem on a powerful PC VIDEO 2 (part A) 1. goto http://tinyvid.tv/show/asjek24g00ww 2. wait for video buffering process stop 3. click play 4. wait till 25 to 30 minutes playback - Actual: some where after 25 minutes video/audio quality goes bad - Expected : video play properly (part B) 5. click pause 6. make video buffer for complete length as explained in VIDEO 2 part B 7. bring the scrollbar to same place where there was problem 8. click play - Actual: Video plays without any problem on a powerful PC

Happens on Linux (with no sound hardware) too, but not when playing the file from local disk or a local webserver. It looks like the frames are being delivered earlier than usual, but I'm not sure how that could cause this. The file layout looks sensible, e.g. the audio and video is muxed sensibly.

I also see problem in the interview at http://www.double.co.nz/video_test/test1.html ie, around after 40 minutes of playback. To see this you have to play it from web

(In reply to comment #0) > VIDEO 1 > (part A) > 1. goto http://tinyvid.tv/show/2wn7rkzapa2ci Wow! That is brutal. Playback does not max out my CPU yet it's worse than some video that max out my CPU. It's like the choppy audio performance is so bad that it's dragging down the whole video.

now, what happens in the Part B? Whether it gets better?

(In reply to comment #4) > now, what happens in the Part B? Whether it gets better? Yes it does. That's really messed up. There definitely does seem to be some major flaws in buffering, whether how it's fed, how it's read, or both.

This is happening in lot more PCs So asking blocking1.9.1.1 RedHat bug https://bugzilla.redhat.com/show_bug.cgi?id=509229

Actually I can reproduce it pretty reliably even with locally stored http://mcepl.fedorapeople.org/tmp/emilia-big-big-world.ogv from YouTube (converted to OGG via Firefogg) on my dual core 2.4GHz, 4GB RAM computer. Needless to say totem on the same computer plays the same file without a hitch. The worst part is the beginning as if something was still getting together ... after five or so seconds it plays pretty well. Emphasizing the "stored locally" part ... it has apparently nothing to do with network delays. (Sorry, RIAA, but it really is on YouTube, and it is for a good cause).

And yes of course, this is platform independent ... I have here Fedora 11/x86_64 with Firefox 3.5 from Fedora packages.

Actually similarly bad playback is even with audio-only file http://mcepl.fedorapeople.org/tmp/emilia-big-big-world.oga ... playback has just sensible stuttering in the beginning.

I see a better performance when the controls are hidden. So are we updating the scroll bar for buffer and current time even if there is no visible change? ie, we received a new block but it was only few k bytes and there is no pixel size difference in buffer scroll bar length. Or when time progressed but the time change is only less than a second. I heard in bug 462667 comment 27 the buffer size is 50MB. So can we re-start buffering only when the buffer size reduce below 40MB. This may provide better experience (at least some time in playback), if I can assume there is enough bandwidth and also quality of playback reduces when the data is downloading.

cpearce: Are you still investigating this? It's not blocking for 1.9.1.1, but is likely wanted later.

Slashdot just had an article on HTML 5: ( http://tech.slashdot.org/story/09/08/05/2348219/HTML-5-Canvas-Experiment-Hints-At-Things-To-Come ) that points to a HTML 5 demonstration: ( http://9elements.com/io/projects/html5/canvas/ ) This demonstration has an HTML 5 audio tag sound and I quickly noticed I had the same choppiness ( start/stop start/stop ) as I reported in bug https://bugzilla.redhat.com/show_bug.cgi?id=509229 So I made a local test of the HTML 5 audio tag to see if I experience my choppiness bug locally. I do. It is reproducible about 80% of the time ( on page reload ). The sound choppiness coming from the network: ( http://9elements.com/io/projects/html5/canvas/ ) is always reproducible for me. So it's not just the HTML 5 video tag that is choppy it's the audio tag too. I've attached a video of my screen running the local sound test with the choppy ( start/stop ) sound. Hope this helps resolve this bug.

I'd be interested in knowing if the patches in bug 506061 fix the issue.

did patches in bug 506061 got applied to nightly trunk? I dont see any r+ for patch. Do you have a windows build that I can download. Anyway I have tested it, let me write what observed. VIDEO url 1 on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090807 Minefield/3.6a1pre Vista (fast pc, 2GB memory) and WinXP (slow pc, 335MB) buffered differently. For Vista the buffer limit is approximately 5 minutes On WinXP it buffered approx. 7 minutes Quality: Definitely on WinXP the quality improved compared to previous time I test it. On Vista I feel there is an improvement, but not sure how much. VIDEO 2 video 2 played smoothly on Vista and stopped at 27:16 on WinXP PC it started smoothly but at 15 minute or so it start dragging finally stopped at 27:16 So clearly bug 506061 fix not there in nightly. and without that fixed and due to generally other video code improvements we wont be able to test this again. PS: other than that, THANKS to all, generally we have improved the quality of videos in Firefox. We still need to work a lot to match flash video quality.

(In reply to comment #14) > did patches in bug 506061 got applied to nightly trunk? > I dont see any r+ for patch. No they have not landed. Most of the patches in that bug relate to problems with the Linux audio backend. The generic platformpatches are to do with a/v sync.

any update? the playback is still abysmal on windows 7. its not hardware related, since similar linux and mac play video just fine. its not video bitrate related, since the choppiness exists fpr videos of 400kbps, or 1200kbps. please fix this, how can we preach ogg/theora while give vast majority users an awful experiences when they try to check it out? H.264 already has more advantages in misinformation war, this will be another false impression giving to end users.

We fixed bug 506061 a few months ago now, are people still seeing problems with trunk builds?

yes, problem is still there. its disturbingly bad on my win7 computer. (In reply to comment #17) > We fixed bug 506061 a few months ago now, are people still seeing problems with > trunk builds?

(In reply to comment #17) > are people still seeing problems with trunk builds? The URL's in comment #0 is not available so I cant test it same way as before. If I remember correct, one of the video was the interview video at http://double.co.nz/video_test/test1.html I have local copy of that video, so I published it on a intranet web server and tested it. I dont see same problem as what I saw earlier in the latest MineField nightly build. That does not automatically imply this is a PASS. As:- 1. As I am testing it on intranet server I dont have a network download time delay. Previously also if it is a network file:// protocol file we where not seeing that error. 2. The intranet server I re-tested dont have any load like http://tinyvid.tv/ have I am happy to mark it as a PASS by bug 506061 Still there may be other issues, for which we should open another bug.

I am marking this fixed by bug 506061 If anybody see this failing per steps in Comment 0 please reopen. If it is fail by some other reason please create a new bug.