Bug 459150 – dev-python/audioread should depend on virtual/ffmpeg

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Mark 2013-02-25 13:21:01 UTC]

Attempting to change my system over to libav.  dev-python/audioread does not accept the virtual ffmpeg, thus I cannot change the system to the recommended configuration.

[Comment 1 Jeroen Roovers (RETIRED) 2013-02-26 18:08:50 UTC]

But does it work?

[Comment 2 Stanislav Ochotnicky (RETIRED) 2013-02-26 20:49:17 UTC]

(In reply to comment #1)
> But does it work?

To be honest I haven't tried so I'll have a look

[Comment 3 Stanislav Ochotnicky (RETIRED) 2013-02-26 21:02:42 UTC]

As it happens audioread ffmpeg backend just runs ffmpeg binary:
self.proc = subprocess.Popen(
                ['ffmpeg', '-i', filename, '-f', 's16le', '-'],
                stdout=subprocess.PIPE, stderr=subprocess.PIPE
            )

So libav should be a drop-in replacement. *However* audioread will use following priority for decoding:
 
 1. Use build-in python support for WAV files
 2. Try to use Mac CoreAudio (irrelevant for us)
 3. Try  dev-python/gst-python
 4. Try dev-python/pymad
 5. Fallback to ffmpeg binary (most probably either one of implementations willl suffice)

Mark: Ideally you should be using gstreamer infrastructure. It will be less error-prone IMO. I'll be switching to virtual package soonish, but if I were you I'd consider switching the backend anyway :-)

[Comment 4 Stanislav Ochotnicky (RETIRED) 2013-02-26 21:57:36 UTC]

Actually looking at replacing dependency with virtual it seems like it would not be ideal due to this message from libav:

 ffmpeg had been replaced by the feature incompatible avconv thus
 the legacy ffmpeg is provided for compatibility with older scripts
 but will be removed in the next version

It would mean switching to virtual and soon after libav is updated we'd have to go back to original ffmpeg. Not to mention that audioread is actually parsing stdout of ffmpeg so simple replacement with avconv would be easy to break. Since there are workarounds (different backends) for this case I am closing this as WONTFIX.

[Comment 5 Mark 2013-02-27 23:04:01 UTC]

Thanks all.  I will go to the gstreamer solution as that makes good sense.