[FFmpeg-devel] TrueHD track in EVO not playable/testable with ffplay

Baptiste Coudurier baptiste.coudurier
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:
>> Hi,
>>
>> 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:
>>>
>>> https://roundup.ffmpeg.org/roundup/ffmpeg/issue1258
>>>
>>> I have uploaded a sample to:
>>>
>>> /MPlayer/incoming/EVO-TrueHD-playfail/truehdfail.evo
>>>
>>> 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 mailing list