Bug 36536 - multipart/x-mixed-replace does not show final frame in MJPEG over HTTP
Summary: multipart/x-mixed-replace does not show final frame in MJPEG over HTTP
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows Vista
: P1 Minor
Assignee: Nobody
URL: http://indiespot.net/files/mjpeg.html
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-24 08:54 PDT by Riven
Modified: 2022-08-16 13:02 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Riven 2010-03-24 08:54:41 PDT
the last frame of the MJPEG movie contains the text "END OF MESSAGE", which is not shown in WebKit
Comment 1 Christopher Stanton 2011-04-20 18:10:56 PDT
I have a custom MJPEG server which multiplexes various MJPEG camera streams to users. The when the stream terminates (upstream from the server/in the server), either due to a stream failure, the stream being disconnected, etc the last frame is used as a status frame to provide the user info and so they don't think the stream is hung.

For some reason WebKit (in Chrome) does not display the frame even though the stream is terminated by a valid terminating break.

Content-Type: multipart/mixed; boundary="MYBOUNDARY"
Boundaries between parts are "--MYBOUNDARY"
The end of the stream is signified by "--MYBOUNDARY--".

http://en.wikipedia.org/wiki/MIME

http://code.google.com/p/chromium/issues/detail?id=78622
Comment 2 Antti Koivisto 2014-12-06 02:33:11 PST
Run into this while making test for bug 139313. 

The problem is that we rely on CachedImage::responseReceived to reset the image for each frame and then a synthetic call (from SubresourceLoader) to CachedImage::finishLoading to update the data. This fails for the last frame since there is no responseReceived call when the load is really finishing and the existing image decoder will be in closed state.