[FFmpeg-devel] TrueHD track in EVO not playable/testable with ffplay
Thu Jul 9 08:01:57 CEST 2009
On 07/08/2009 07:47 PM, Michael Niedermayer wrote:
> On Wed, Jul 08, 2009 at 11:12:38PM -0300, Ramiro Polla wrote:
>> 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
>> is possible.
>> 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().
>> Please comment.
> my tired mind says we need a
> coded_channels representing the number of channels stored in the stream
> and a seperate field that represents the decoder output channels
I suggest to keep ->channels as the coded channels and to use another
field like output_channels.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel