This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1005 [details] DrawImage test case with MJPG (traffic web cam) Currently, the canvas2d drawImage() spec says: "When the drawImage() method is passed an animated image as its image argument, the user agent must use the poster frame of the animation, or, if there is no poster frame, the first frame of the animation." It then goes on to discuss the special case of HTMLVideoElements: "When the image argument is an HTMLVideoElement, then the frame at the current playback position must be used as the source image, and the source image's dimensions must be the intrinsic width and intrinsic height of the media resource (i.e. after any aspect-ratio correction has been applied)." I'd like to suggest that MJPG files are often used in place of video, especially with security cameras and other web camera feeds. Some browser vendors already take the same position, for example Chrome and Safari, which will use the current image (frame) of the MJPG when it is passed to drawImage(). Firefox currently tries to do what the spec says, and load the first frame. I've filed a bug with Mozilla, as well: https://bugzilla.mozilla.org/show_bug.cgi?id=667206 I believe that WebKit's behaviour is useful and least surprising here, even though not spec compliant. I'd like to suggest that this behaviour be considered as the correct one for the spec going forward, and that spec be changed. I've included a simple test case. Thanks for considering this.
> Firefox currently tries to do what the spec says, and load the first frame. Actually, it doesn't. The problem there is that in Gecko an MJPEG image is never actually done loading for purposes of our internal test. I'll follow up in the Gecko bug.
mass-move component to LC1
A resource delivered as a mutipart/replace package containing a series of JPEG payloads is no a single image; it's a whole series of images. As currently specced, a <canvas> element's drawImage() method would do nothing if invoked with an <img> using an infinite multipart/replace resource, because such an image is never fully decodable. In fact, how to handle multipart/replace isn't really defined by the spec at all even for regular <img> purposes. I guess what I should do is update the tasks queued by the "update the image data" algorithm so that if the resource is actually a multipart/replace resource, each subresource updates the image data and the image is marked as fully decodable as soon as the first one is found. Then it should all just work. Does that seem ok?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r6596. Check-in comment: Specify multipart/x-mixed-replace http://html5.org/tools/web-apps-tracker?from=6595&to=6596