Skip to content
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: bad RST marker due to pre-reset marker byte alignment #28717

astromechza opened this issue Nov 10, 2018 · 6 comments · May be fixed by astromechza/go#1

image/jpeg: bad RST marker due to pre-reset marker byte alignment #28717

astromechza opened this issue Nov 10, 2018 · 6 comments · May be fixed by astromechza/go#1


Copy link

@astromechza astromechza commented Nov 10, 2018

What did you do?

While writing a small app to decode and process the JPEG frames from webcams running in Motion-JPEG mode, I found that images from a Logitech C270 webcam failed to decode when using the jpeg.Decode function. Images from other /dev/video devices worked just fine. I confirmed that the same images decoded fine using other programs like vlc.

I isolated a frame that caused the decoder to fail and stepped through the decoding with a debugger and compared it to the part of the jpeg spec in F1.2.3 from,-200,43.

Turns out the jpeg decoder doesn't handle 0xFF 0x00 bytes that precede the expected 0xFF 0xD* bytes that form the reset markers. The stuffed bytes are used for byte alignment.

Here's an example frame from the stream:


And here's a link with a reproducer:

I've experimented with a fix in the handling of the rst marker in the image/jpeg/scan.go file and I'm fairly confident that this should fix the issue (it certainly seemed to fix it in my usecase):

diff image/jpeg/scan.go /snap/go/current/src/image/jpeg/scan.go 
<                               // detect the presence of a stuffed 0xff00 pair caused by byte alignment
<                               if d.tmp[0] == 0xff && d.tmp[1] == 0x00 {
<                                       if err := d.readFull(d.tmp[:2]); err != nil {
<                                               return err
<                                       }
<                               }

What did you expect to see?

Expected the frame to decode successfully as it is in other software like VLC and web browsers.

What did you see instead?

panic: invalid JPEG format: bad RST marker

Does this issue reproduce with the latest release (go1.11.2)?


System details

go version go1.11 linux/amd64
GOROOT/bin/go version: go version go1.11 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -sr: Linux 4.15.0-36-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic
/lib/x86_64-linux-gnu/ GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.
gdb --version: GNU gdb (Ubuntu 8.1-0ubuntu3)
@astromechza astromechza changed the title image/jpeg: fails on stuffed bytes due to pre-reset marker byte alignment image/jpeg: bad RST marker due to pre-reset marker byte alignment Nov 10, 2018
Copy link

@ianlancetaylor ianlancetaylor commented Nov 10, 2018


@ianlancetaylor ianlancetaylor added this to the Go1.13 milestone Nov 10, 2018
astromechza added a commit to astromechza/go that referenced this issue Nov 10, 2018
JPEG standard allows for stuffed bytes just before the reset markers in order to align bytes (refer to B 1, D 1.6, and F 1.2.3 of JPEG spec). Some JPEG encoders seem to use these even when byte alignment is not strictly necessary. This fix checks for and skips over the escaped stuffed byte.

Fixes golang#28717
Copy link

@astromechza astromechza commented Nov 10, 2018

I've setup a branch with the proposed fix on my fork of golang/go. I may be completely wrong about this bug (there's a chance the webcam has a bad jpeg encoder) or there may be a better way to fix the issue 😄


@andybons andybons removed this from the Go1.13 milestone Jul 8, 2019
@andybons andybons added this to the Go1.14 milestone Jul 8, 2019
Copy link

@borud borud commented Aug 12, 2019

Any chance this will be fixed in 1.12?


Copy link

@nigeltao nigeltao commented Aug 14, 2019

The patch in the OP looks plausible (although I'd like the comment to mention F1.2.3 in the spec), but we are deep in the release cycle ( for Go 1.13. As it is not a regression, it will probably land in 1.14 at the earliest.

Sorry for the late reply. I can't remember why I didn't see the "CC @nigeltao" note earlier.


@rsc rsc removed this from the Go1.14 milestone Oct 9, 2019
@rsc rsc added this to the Backlog milestone Oct 9, 2019
Copy link

@gunnsth gunnsth commented Apr 8, 2020

Is this anticipated in 1.15?


Copy link

@gopherbot gopherbot commented Apr 28, 2020

Change mentions this issue: image/jpeg: accept "\xff\x00" before a RST marker


@gopherbot gopherbot closed this in 7250dd2 Apr 29, 2020
xujianhai666 added a commit to xujianhai666/go-1 that referenced this issue May 21, 2020
Fixes golang#28717

Change-Id: I0a1e4ef1583fff89b6f46ef647fb6e4499bdf999
Run-TryBot: Nigel Tao <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Rob Pike <>
@golang golang locked and limited conversation to collaborators Apr 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

8 participants