On 2010/10/31 17:22, Anton Khirnov <an...@khirnov.net> wrote: > Rationale: recent libavformat versions now assume there can be an ID3 > header in _anything_ and try to skip it before real probing, instead of > assuming anything with and ID3 header is an mp3. This leads to problems > with identifying mp3 files with ID3v2 headers bigger than our current > buffer size.
That change gives me a some headache. First of all, allocating 1 MB is easy for your multi-gigabyte desktop machine, but may be a lot of stress for an embedded box. If the allocation fails, MPD will crash. This kind of probing can take a long time if the file is a stream or if the file is on a remote server. What if this is a garbage file? FFMPEG doesn't give any feedback if it expects a better result when more data is received. Bad API. MPD will only give up after it has waited for 1 MB of data. That can take longer than users are willing to wait. Is that what the "recent" libavformat documentation suggests? Do we need this only for mp3 files? Does anybody really use libavformat (and not libmad / libmpg123) for decoding mp3 files? If libavformat sucks at detecting mp3 files, can we roll our own? Max ------------------------------------------------------------------------------ Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
