13060 2011-06-25 16:38:46 +0000 Need to define how JPEG-push images are handled 2011-09-30 17:35:32 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED FIXED P4 enhancement --- 1 david.humphrey ian ayg bobby bzbarsky ian mike philipj public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 50314 0 1005 david.humphrey 2011-06-25 16:38:46 +0000 Created attachment 1005 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. 50321 1 bzbarsky 2011-06-26 15:04:17 +0000 > 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. 52806 2 mike 2011-08-04 05:04:20 +0000 mass-move component to LC1 54673 3 ian 2011-08-11 06:14:33 +0000 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? 57488 4 ian 2011-09-28 23:18:51 +0000 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. 57494 5 contributor 2011-09-29 00:24:17 +0000 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 1005 2011-06-25 16:38:46 +0000 2011-06-25 16:38:46 +0000 DrawImage test case with MJPG (traffic web cam) index.html text/html 607 david.humphrey PGh0bWw+CjxoZWFkPgogIDx0aXRsZT5NSlBHIERyYXdJbWFnZSBUZXN0IENhc2U8L3RpdGxlPgo8 L2hlYWQ+Cjxib2R5Pgo8ZGl2PgogIDxoMj5NSlBHIE9yaWdpbmFsPC9oMj4KICA8aW1nIGlkPSJt anBnIiBzcmM9Imh0dHA6Ly9jYW0udGhlc3lsdmFoZXJhbGQuY29tL21qcGcvdmlkZW8ubWpwZyIg Lz4KPC9kaXY+CjxkaXY+CiAgPGgyPkNhbnZhcyBDb3B5PC9oMj4KICA8Y2FudmFzIGlkPSJjYW52 YXMiIHdpZHRoPSI2NDAiIGhlaWdodD0iNDgwIiBzdHlsZT0iYm9yZGVyOjFweCBzb2xpZCBibGFj ayI+PC9jYW52YXM+CjwvZGl2Pgo8c2NyaXB0PgpmdW5jdGlvbiBsb2FkZWQoKSB7CiAgdmFyIGN0 eCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdjYW52YXMnKS5nZXRDb250ZXh0KCcyZCcpLAog ICAgICBtanBnID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ21qcGcnKTsKCiAgc2V0SW50ZXJ2 YWwoZnVuY3Rpb24oKSB7CiAgICBjdHguZHJhd0ltYWdlKG1qcGcsIDAsIDApOwogIH0sIDMwMDAp Owp9CgphZGRFdmVudExpc3RlbmVyKCdET01Db250ZW50TG9hZGVkJywgbG9hZGVkLCBmYWxzZSk7 Cjwvc2NyaXB0Pgo8L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+Cg==