[FFmpeg-devel] TrueHD track in EVO not playable/testable with ffplay
Thu Jul 9 04:12:38 CEST 2009
On Tue, Jul 7, 2009 at 8:26 PM, Robert
McNamara<robert.mcnamara at gmail.com> wrote:
> In attempting to track down an audio decode issue in my player
> application, I wanted to test first with ffplay. ?The files in
> question are all EVO container with TrueHD primary audio tracks.
> Unfortunately, any attempt to playback TrueHD in EVO results in:
> SDL_OpenAudio: Couldn't open audio device: Device or resource busy
> Note that this message is erroneous, as attempts to play back all the
> other tracks in the file work properly. ?One can also start playback
> on the file, then toggle audio tracks with "a", which works until
> landing on the TrueHD track. ?As such, I am unable to conclusively
> determine whether the audio issue is with my player (mythTV) or within
> libav*. ? This behavior is consistent in *all* my EVO files containing
> TrueHD audio, approximately 80 files from HD-DVD.
> I have opened a ticket for the issue:
> I have uploaded a sample to:
> I would be extremely appreciative for any help.
Bringing the discussion from the bug tracker to ffmpeg-devel.
On avcodec_open(), mlp runs the parser code to fill out the channels.
In that case it's filled with the total 6 channels (read from a major
sync frame). It's still not possible to find out if we can downmix
because the substream headers must be read to find out if the downmix
On the first frame being read, the substream headers are read and
avctx->channels is adjusted. It is set to the number of channels on
the substream that can give the smallest number of channels above or
equal to avctx->request_channels.
FFplay depends on the information given by avcodec_open(), so it only
knows the max channels, and not if it's possible to downmix.
Attached patch makes mlp skip the channel information from major sync
frames in the parser and discard them in decode_init (since the parser
is not filled with avctx->request_channels on the first run) if
avctx->request_channels is set, therefore forcing lavc to read more
frames to find out channel information, and reporting the proper
avctx->channels right after avcodec_open().
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1321 bytes
Desc: not available
More information about the ffmpeg-devel