Hi, Max, thank you for reply. Of course this method (using pipe) is not perfect and I know it. But the purpose is NOT to replace native decoders, it is to be able to support minor or maniac or personal decoder EASILY, and I think it maybe expand mpd's capability.
(for example, I want to support japanese old computer music format and some game console music format which is not supported by libgme. but I don't feel like writing and maintaining some such a maniac plugin codes and porting several (unverified and unmaintained) libraries into mpd. in this case this patch is useful for me.) But OK, I understood your mpd policy, and I agree with it ! 2014-03-01 2:45 GMT+09:00 Max Kellermann <[email protected]>: > On 2014/02/28 17:22, mtm kmkz <[email protected]> wrote: > > If possible, I want to make an effort to merge it into master branch. > > What do you think? > > No. I'm completely unimpressed by this idea. > > This will never work as well as "native" decoders. There will always > be difficult problems. > > For example: > > - your code is unable to seek > - it cannot detect the audio format, this must be hard-coded in the > configuration file > - the child process will ignore signals > - which your code works around by sending SIGKILL (which cannot be > ignored) - ouch!! > - it supports only very few tags > - huge overhead for reading tags (launch one child process for every > tag) > - no support for streams, remote files and archive files > > Compared to that, problems with buggy libraries are insignificant. > The biggest problem with library bugs is always that people don't > install bug fix releases. (The same is true with MPD bugs.) > > > - mpd can support new format without changing mpd repository > > I don't want that. It means that people write decoders with non-free > code. > > > - mpd process is separated from some serious problems like as crash > > and/or memory leak caused by external decoder process > > Bugs in libraries are bad, and we had a good load of crash reports due > to FFMPEG bugs, and sometimes I wished there were better separation > from MPD, but this is not the solution. If you had an idea how to > implement the separation in an elegant way, without feature loss and > without measurable performance loss, then we can talk about this. But > this patch is just a kludge that omits a large part of MPD's decoder > API. It doesn't even come close to solving any problem. > > Max >
_______________________________________________ mpd-devel mailing list [email protected] http://mailman.blarg.de/listinfo/mpd-devel
