freultwah
commented
11 years ago Just a quick illustration.
libav 0.8.4:
[snip] Duration: 00:04:31.58, start: 0.000000, bitrate: 128 kb/s Stream #0.0: Audio: mp3, 44100 Hz, stereo, s16, 128 kb/s At least one output file must be specified [/snip]
ffmpeg 1.1 (behaviour identical to the latest libav release):
[snip] Duration: 00:04:31.59, start: 0.000000, bitrate: 128 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s Stream #0:1: Video: mjpeg, yuvj420p, 170x170 [SAR 157:157 DAR 1:1], 90k tbr, 90k tbn, 90k tbc Metadata: title : front comment : Cover (front) At least one output file must be specified [/snip]
As you can see, newer software reports a video stream #0:1.
At one point I struggled with forked-daapd not compiling with a libav Plain 9 beta and finally managed to cook up a patch that checked the library's API version and used relevant API calls depending on the version. The stuff even ran, but I ran into a problem that I could not solve, since I do not really know how to write code and have just been hacking around to make stuff work.
The problem: newer libav and ffmpeg support cover art in MP3 files. That brings about an interesting issue: many otherwise fine MP3 files heretofore detected as such are now seen as an unknown movie by forked-daapd. Why? Because libav/ffmpeg reports an extra stream all of a sudden and that stream is usually identified as MJPEG. Thus, forked-daapd sees it as a movie.
Is anybody up to the task of fixing it? I have sent my half-baked patch to Mr Blache, but development seems to have stalled and he never wrote back, so I do not know what happened to it. If anybody's interested in digging in filescanner.c or possibly elsewhere, I'll post my semi-patch here.