[MPlayer-dev-eng] Ac3 streams detected as LPCM or SPU in TS

[lordvader at swiftdsl.com.au]

On Sat, 5 Jun 2004 09:15 pm, James Courtier-Dutton wrote:
<snip>

> This is a well known problem, and xine has the same problem.
> 1) The DVB card cannot output the PAT or PMT
> One has to use the DVB API to gather that information.
> As a result the file saved from that DVB card will not have a PAT or
> PMT. Really the program saving the file should add PAT and PMT for every
> 10s of the stream before it saves it, but I don't think any linux
> programs do this currently.

Something I would like to know, is the lack of PMT/PAT a hardware issue
(unfixable), or a driver issue (fixable)?

> 2) We are left with TS streams without any PAT or PMT.
> 3) The AC3 is placed in private_stream_1
> 4) The AC3 in private_stream_1 is not in sync with the PES pack.
> i.e. The beginning of an AC3 pack does not necessarily apprear at the
> start of a PES pack.
>
> Solution:
> When one starts playing the stream with a private_stream_1, that
> particular PID should be marked as unidentified.
> TS pack should be buffered up until 2*AC3 packet length.
> Once buffered, content detection should be done on the buffered packet.
> This content detection should probably search the buffer for the AC3
> header (0x0b, 0x77) and then maybe do a AC3 CRC check on the next 1536
> bytes. Once identified, all future TS packs can be sent to the AC3 decoder.

I'll like to have a play around with this approach. I'm not totally
familair with the way mplayer (or xine) work, but what is sent to the
audio fifo? Is it the complete packet (ie, the 1536 bytes buffered from
the dvb packets), or is the 184 bytes received from the dvb input?

>
> Problems with this method: -
> What if the user changed channels while recording. The content of the
> PID might change from AC3 to subtitles!
>
> Cheers
> James

Also, I'm not sure if its relevant now, but the file channel9hdtv_ac3.ts
is successfully uploaded in the incoming ftp directory.