path: root/etc
diff options
authorwm4 <wm4@nowhere>2012-08-07 19:02:34 +0200
committerwm4 <wm4@nowhere>2012-08-07 19:02:34 +0200
commit762ef8d53238160d5fc8873c249d11d38399bf94 (patch)
tree7046f57ea33385e177e759d8370014d22bb59862 /etc
parent796599bcc21e0447eedb9770561ea8da08fe8595 (diff)
codecs.cfg: do not prefer spdifmpa over mpg123 decoder
The generic hardware pass-through decoder ad_spdif (imported from mplayer-svn) was mistakenly prefered over the default decoder mpg123. This is the same as mplayer-svn commit 34192. The spidfmpa entry was marked as "untested", which for inconceivable reasons is preferred over entries marked "working". (The probe order is untested, working, buggy. Possibly to "force" untested codecs to be tested?) I didn't know this behavior, and skipped the corresponding mplayer-svn commit 34192, as it looked like it would move up the entry in autoprobe order (not the reverse), which might have been slightly dangerous, or at least not something we would have to bother with. The only change in behavior the incorrect entry caused was that playing a shoutcast mp3 stream displayed "inf" as time on the mplayer status line, instead the time since joining the stream. (The same can be seen when starting mplayer-svn with -ac spdifmpa,mpg123 .) I'm not sure why this happens; I can only guess that when spdifmpa throws away header data when it fails initializing, or messes up something else.
Diffstat (limited to 'etc')
1 files changed, 1 insertions, 1 deletions
diff --git a/etc/codecs.conf b/etc/codecs.conf
index 586b0d31b4..f31a8b69db 100644
--- a/etc/codecs.conf
+++ b/etc/codecs.conf
@@ -4757,7 +4757,7 @@ audiocodec spdifdts
audiocodec spdifmpa
info "libavformat/spdifenc MPEG AUDIO BC pass-through decoder"
- status untested
+ status working
comment "for MPEG AUDIO BC hardware decoders"
format 0x50 ; layer-1 && layer-2
format 0x55 ; layer-3