I know we're either locked, or nearly locked, so even if it's an easy fix, this bug will probably need to wait until after release.
The following is with the Feb 2 snapshot on i386. The packages are reasonably up to date. $ pkg_info | perl -ne 'm/(ffmpeg|mplayer|faa)/ && print' faac-1.26 MPEG-2 and MPEG-4 AAC encoder faad-2.6.1 MPEG-2 and MPEG-4 AAC decoder ffmpeg-20080620p12 audio/video converter and streamer with bktr(4) support mplayer-20090708p4 movie player supporting MPEG, DivX, AVI, ASF, MOV & more If you try to create an AVC (AAC) file with ffmpeg, the resulting file works fine with mplayer, but causes errors with ffplay. $ ffmpeg -i song46.mp3 -acodec libfaac song46.aac $ ffplay song46.aac [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change In the above, the resulting file plays fine with mplayer using the same libfaad/libfaac. The problem is not in the transcoding. For example, if you grab any video from YouTube (since Feb 2009) in either FLV or MP4 format (has AVC/AAC audio), you'll still have problems if you try to a raw "copy" of the audio track (without transcoding). $ ffmpeg -i video.mp4 -acodec copy audio.aac $ ffplay audio.aac [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change [libfaad @ 0x289d5500]faac: frame decoding failed: Unexpected channel configuration change In this case again, the resulting file plays fine with mplayer using the same libfaad/libfaac. The strange part of these first two cases where the output file was created by ffmpeg, it doesn't make much sense how mplayer can play the file and ffplay cannot when both are using the same decoding library? My initial "hunch" says the above error has something to do with the handling of VBR (Variable Bit Rate) encoding, but this doesn't make a whole lot of sense. Even if files are created with `-ab` or `-ar` or even the undocumented `-aq` options, the resulting AAC file will play fine in mplayer, and fail to play in ffplay. I have no clue how to debug this (hints welcome). Additionally, I've noticed there is a *possibly* related bug in the `-dumpaudio` feature of mplayer, but in this case, the resulting file cannot be played by either mplayer or ffplay. The interesting part about the bug with `mplayer -dumpaudio` is that it reports "core dumped ;)" but still produces the output file (and no mplayer.core). -jcr
