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

[Michael Niedermayer]

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

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- 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/da4d0eea/attachment.pgp>