-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
image/jpeg: Unable to decode concatenated JPEGs (MIME-less "MJPEG") #22170
Comments
https://play.golang.org/p/5j6qu6ofuW The decoder eats your entire stream 4096 bytes at a time, along with all images in between. You will have to use a bytes.Reader instead of a bytes.Buffer and seek to the starting position of the stream to get this to work how you expect. That out of the way, I can confirm that image/png works in the scenario above without reading past the next image. |
Thanks for pointing this out. To be clear, I'm expecting the behaviour of |
Yes, that is what I was trying to point out as well. Reading my last comment again I see how ambiguous the statement was. To paraphrase, the image/jpeg is the only package I have used that over-reads the stream, and I also find this behavior a bit unusual. |
Upon further inspection of the png, gif, and jpeg packages, I don't think this issue can be easily resolved at the package level. The data structures are simple for byte formats where a bitstream doesn't cross byte-boundaries (e.g., PNG), and it turns out that streamable PNGs are part of the png standard itself: https://tools.ietf.org/html/rfc2083#section-2 The jpeg package has a custom reader for decoding the variable length bitstream, it fills the buffer 4k bytes at a time. There is generally no way to stuff those unprocessed bytes back into the underling reader after the decode is done, short of reading the bitstream and detecting the A container format solves this problem, but MJPEG has no formal standardization that I know of, and a bit of research also shows that other decoders have had this problem too: https://github.com/search?q=mjpeg&type=Issues&utf8=%E2%9C%93 /cc @nigeltao |
Yeah, that diagnosis sounds correct, and not easily solvable. Sorry. |
https://github.com/mattn/go-mjpeg I don't see the problem yet. |
Just at a cursory glance, it seems like In this issue, there is no header at all, it's a concatenation of multiple jpeg images. |
MJPEG typically means the MIME version. I've retitled this bug for clarity. |
Any news on this? |
@JOHN-DEV You need to seek to the beginning of the next image yourself. Here's an example for a specific type of MJPEG |
What did you do?
Wrapping
ffmpeg -i <url> -c:v mjpeg -f image2pipe -
in aexec.Cmd
and continuously decoding the command output in a loop withjpeg.Decode
fails while doing the same thing withffmpeg -i <url> -c:v png -f image2pipe -
andpng.Decode
works.The following example illustrates the error by creating an MJPEG stream using a sample image: https://play.golang.org/p/lppyHZftWA
The same program but using a PNG stream and
png.Decode
shows successful decoding and a clean exit: https://play.golang.org/p/c54-hc6JRKThe following is a test that is expected to pass:
Grabbing a number of frames from a video and inspecting the output we can verify that there's no unexpected bytes after the EOI marker (
ff d9
) and before the next SOI marker (ff d8
) and that we get the expected number of frames:What did you expect to see?
The MJPEG stream is a concatenation of JPEG images and the decoder should be able to successfully decode multiple images in sequence without forcing caller to keep track of and seek to next frame.
The program https://play.golang.org/p/lppyHZftWA is expected to not give any output but decode all stream frames correctly and exit cleanly when hitting
io.EOF
What did you see instead?
The program prints an error message as it hits
io.ErrUnexpectedEOF
Does this issue reproduce with the latest release (go1.9.1)?
Yes
System details
The text was updated successfully, but these errors were encountered: