Closed Bug 832446 Opened 10 years ago Closed 10 years ago

jpeg stream very low framerate


(Core :: Graphics: ImageLib, defect)

19 Branch
Windows 7
Not set



Tracking Status
firefox18 --- unaffected
firefox19 + verified
firefox20 + fixed


(Reporter: timojarvenpaa, Assigned: joe)


(Keywords: regression)


(1 file, 1 obsolete file)

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?
Hardware: x86_64 → x86
Hardware: x86 → x86_64
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:

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"
In case you used mozregression you can just post the output of it.

I bet that this is a regression from one of Joe's checkins
Component: Untriaged → ImageLib
Keywords: regression
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
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.
Attached patch updatedSplinter Review
Attachment #704560 - Attachment is obsolete: true
Attachment #704628 - Flags: review+
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Please nominate for uplift to Aurora/Beta this week.
Comment on attachment 704628 [details] [diff] [review]

[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
Attachment #704628 - Flags: approval-mozilla-beta?
Attachment #704628 - Flags: approval-mozilla-aurora?
Attachment #704628 - Flags: approval-mozilla-beta?
Attachment #704628 - Flags: approval-mozilla-beta+
Attachment #704628 - Flags: approval-mozilla-aurora?
Attachment #704628 - Flags: approval-mozilla-aurora+
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

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.