User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130116072953 Steps to reproduce: I'm using Firefox to view CCTV-pictures from Zoneminder. It streams camera pictures in jpeg. Jpeg is in 720x576 resolution, stream is 25 jpg/second and also a mosaic view with 4 views each showing a jpeg stream with 25fps. Actual results: With Firefox 19 beta 1 and beta 2 framerate has dropped to an unusable rate, few refreshes/second, jumping and in the mosaic view one window refreshes and others freeze. Expected results: jpeg streams are perfect with Firefox 18. So what was changed in the 19 that caused this?
Is there a public URL for testing available ? Would you search a regression range for us in case that the URL is non-public ? We have an automated tool for doing a regression range search: http://mozilla.github.com/mozregression/ example: mozregression --good=2012-06-01 --args="http://URL-to-stream"
The url is not public and I haven't found any public Zoneminder demo sites. But I did regression tests and build 2012-10-17 is the last one that works, all builds after that have this problem. So what was changed after that date?
Can you please post the changeset of from the last working and the first failing build ? You can get the changeset id from about:buildconfig Example: "Built from http://hg.mozilla.org/mozilla-central/rev/0a6e5a67c4e8" In case you used mozregression you can just post the output of it.
Here's that info. GOOD: Built from http://hg.mozilla.org/mozilla-central/rev/dac5700acf8b BAD: Built from http://hg.mozilla.org/mozilla-central/rev/cb573b9307e5
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5 I bet that this is a regression from one of Joe's checkins
Component: Untriaged → ImageLib
Product: Firefox → Core
Are the streaming images displayed at smaller sizes than their native 720x576?
Presuming the answer to my question is "yes", this patch should fix the problem. In the long term we do want to have some heuristic about time as to whether we use the high quality scaler, but in the mean time this is a very safe patch that we can apply to all branches to make things less bad for multipart images.
Assignee: nobody → joe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #704560 - Flags: review?(jmuizelaar)
Comment on attachment 704560 [details] [diff] [review] disable high quality downscaler on multipart images Review of attachment 704560 [details] [diff] [review]: ----------------------------------------------------------------- Add a comment why.
Attachment #704560 - Flags: review?(jmuizelaar) → review+
Yes, they are shown in 720x518 and 647x486.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Please nominate for uplift to Aurora/Beta this week.
Comment on attachment 704628 [details] [diff] [review] updated [Approval Request Comment] Bug caused by (feature/regressing bug #): high quality downscaler User impact if declined: JPEG webcams that are displayed scaled will be displayed slowly Testing completed (on m-c, etc.): On m-c Risk to taking this patch (and alternatives if risky): Very low risk. Worst case we don't use the high-quality scaler when we normally would have. String or UUID changes made by this patch: none
timojarvenpaa, can you confirm the fix for 19.0 beta 3?
It's not fixed in 19b3 but nightly 2013-01-24 works fine, nightly 2013-01-23 still has the problem. So was 19b3 build just before the fix was available?
(In reply to Timo Jarvenpaa from comment #18) > It's not fixed in 19b3 but nightly 2013-01-24 works fine, nightly 2013-01-23 > still has the problem. So was 19b3 build just before the fix was available? That's correct - please verify in b4 at https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/19.0b4-candidates/build1/ Thanks!
Yes, 19 b4 works fine. Thanks for fixing this!
You need to log in before you can comment on or make changes to this bug.