[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