[MPlayer-dev-eng] DTS hardware decoding

[Steven Brookes]

Hi,

I recently passed on some patches for mplayer and the DXR3 driver via David 
Holm to get hardware AC3 decoding (-ac hwac3) working.  I've now turned my 
hand to doing the same thing for DTS audio streams.  Most of what I've done 
is based on the xine DTS passtrhough support code.  I now have a patched 
version of mplayer which implements -ac hwdts.

Now to the problem, the VOB I have has both an AC3 and DTS soundtracks on it 
(aid 128 and 137 respectively).  I can play the whole AC3 soundtrack with no 
problems, and when I use -audiodump -aid 128 I get the correct amount of data 
to make the AC3 stream, given it is 384kbit/s.  I can also see the AC3 
packets at the correct spacing through the dump file.

When I use -audiodump -aid 129, I do not get suffiicient data output.  The 
DTS soundtrack is 1509Kbit/s and I'm only getting exactly half of the amount 
of data I would expect.  The audio dump file does contain valid DTS samples 
though with the correct headers etc.

When I play the VOB using -hwdts then I get DTS sync on my receiver, but the 
samples are played at double speed.  Also the A/V sync is lost as the audio 
tarck is passing twice as fast as the video track.

Now, to me, this points to a problem in demux_mpg.c, which seeme to be losing 
half of the data from the audio stream for aid 129.  I've turned on all the 
debugging I can, but I don't know enough about the demuxing to make much 
progress.  Can anybody help here.

One further tidbit, in demux_mpg.c around line 160, there is a comment which 
states "READ Packet: Skip additional audio header data:"  The first byte of 
the hreader is apparently the number of data frames on the block - which in 
the case of the VOB I'm looking at is 2.  This factor is used when 
calculating the size of the DTS frame.  I'm not sure if this makes any 
difference to the demuxing progress though.

Hope somebody knows the demuxer inside out - DTS passtrhough would be a nice 
for 0.60!

Steven Brookes