[FFmpeg-trac] #6945(undetermined:closed): ffmpeg fails at jpeg EXIF orientation (test included)

FFmpeg trac at avcodec.org
Fri Jan 5 05:52:26 EET 2018

#6945: ffmpeg fails at jpeg EXIF orientation (test included)
             Reporter:  JohnnyX      |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:               |               Resolution:  duplicate
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0

Comment (by JohnnyX):

 Replying to [comment:4 cehoyos]:
 > I thought you mentioned this is a duplicate of ticket #4149, is it not?

 Hehe, no. Please re-open this ticket.

 I apologize if I wasn't clear. I was only referring to those old tickets
 since they contained discussions about "ffmpeg's stance" on auto-rotation
 of input material.

 Number 4149 is someone who asked about "passthrough" writing (output) of
 video rotation data into ffmpeg's generated mjpeg snapshots from videos.
 It's a very muddy ticket actually. You might even want to close that one
 or ask for more info in it, to see what they really need (and it's 3 years
 old, so it seems dead). I only linked to it because it contained some
 related statements.

 This ticket on the other hand is about something that's close to
 "critical" level: ffmpeg's reading of (input) jpeg files is totally
 incorrect because it unfortunately doesn't insert vflip/hflip/rotate video
 transformation filters to the output graph as-required by the the jpeg
 format's EXIF `orientation` value. This means that ffmpeg is unable to
 understand large amounts of modern jpegs taken from digital cameras, which
 very frequently use EXIF orientation to assign the final display-
 orientation. You can try out ffmpeg with the test files in my original
 message above. The result is very sad. :-\ ffmpeg will decode those jpegs
 as their raw pixels without any of their assigned transformations, which
 means that ffmpeg's output will just be randomly rotated and flipped
 (mirrored) rather than their intended orientation.

 It seems like the appropriate fix would be to combine the techniques from
 the two linked commits; the one that handles video autorotate and the one
 that handles jpeg EXIF reading.

Ticket URL: <https://trac.ffmpeg.org/ticket/6945#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list