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

Reply via email to