search

jasonmc / forked-daapd

A re-write of the firefly media server (mt-daapd). It's released under GPLv2+. Please note that this git repository is a mirror of the official one at git://git.debian.org/~jblache/forked-daapd.git
http://blog.technologeek.org/2009/06/12/217
GNU General Public License v2.0
328 stars 45 forks source link

Some artwork is sent transposed #53

Open stormcock opened 13 years ago

stormcock commented 13 years ago

As the title says - some jpgs are sent transposed (upside down & reversed) when returned by extra_data/artwork. No discernable pattern yet as to characteristics / what conditions - but specifiying a different mh & mw value can result in the proper orientation. Will investigate further.

peterjc commented 13 years ago

Try and test big/small images, since large ones will be resized before being sent to the client.

I would guess the JPEG rotation flags are not being used (either in forked-daapd if it is large images that mess up, or in the client if it is small images which mess up).

stormcock commented 13 years ago

OK, done some testing. Certain jpg images are susceptible to being 'flipped' i.e. mirrored and rotated 180 degress. Not all images are susceptible. Those that are, are 'flipped' only when they are resized to a smaller size. So a susceptible image with original size 300x300 will be OK when requested at this size or larger, but 'flipped' if requested at, say, 200x200. Of the 600+ images I have, around a quarter are susceptible to being 'flipped'. I'm not able to determine what characteristics of an image (jpg) make it susceptible to flipping: I have no expertise in jpg/images, but I can supply examples of susceptible and non-susceptible images if this helps.

It does't appear to be a client issue, as the 'flipping' is reproducible in Internet Explorer 9 and Firefox 3.63 (both Windows) as well as my client (which happens to be a plugin for Winamp that I originally used with mt-daapd, and am now adapting to work with forked-daapd severs also).

This is in forked-daapd-0.15 on Fedora14 and I have ffmpeg-0.6-4.

peterjc commented 13 years ago

I suggest you email Julien with the offer of sample images to reproduce the problem.

stormcock commented 13 years ago

Corresponded with Julien and he believes this is a bug in ffmpeg, in the way it deals with baseline JPEG images - all problem JPEGs are baseline rather than progressive. A workaround being to transform any baseline JPEGS to progressive format.