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

[Michael Niedermayer]

On Wed, Jul 08, 2009 at 11:01:57PM -0700, Baptiste Coudurier wrote:
> 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.

I wouldnt mind, if we wouldnt have
coded_width & coded_height in there

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090709/c7f64151/attachment.pgp>