[MPlayer-dev-eng] Re: Another ATSC "a52: CRC check failed" problem
Trent Piepho
xyzzy at speakeasy.org
Tue Feb 21 03:19:26 CET 2006
On Mon, 20 Feb 2006, Nico Sabbi wrote:
> Trent Piepho wrote:
> >http://www.speakeasy.org/~xyzzy/download/C81.ts.bz2
> >
> >This is a ~3 second capture of QAM channel 81, which carries both KCPQ-DT
> >(tsprog 1, vid 33, aid 34, AC3 2.0) and KTWB-DT (tsprog 2, vid 36, aid 37, AC3
> >5.1)
> >
>
> this one is the only one with a PAT/PMT pair. When pids are clearly
> typified
> there's no problem whatsoever: all the payload is fed to the decoder and no
> crc error is present.
There is just one CRC error in that ts capture, but it is an AC3 frame which
is short 184 bytes. Obviously one TS packet was dropped and it probably has
nothing to do with mplayer, or at least is a totaly different problem.
If I pipe the output of getatsc to mplayer, so that it gets the full QAM
channel including PAT/PMT, it does work. Mplayer's cpu usage is much higher
than if I just tune a single virtual channel.
> Long time ago, when I first realized that auto-detection can fail, I
> forced the
Here is a question, can auto-detection be made to work (better)? I would try,
but where can I get better documentation on the PES format? All I find is
info on the first 6 bytes of the PES header.
> dvb:// code to always include pid 0 (PAT) to the TS and added to the xml
> doc:
Is there anyway to automatically add the PMT, after parsing the PAT? If I use
the extended channels.conf format and add the PMT, it appears to work. I still
get a52 errors, but not nearly so many.
I need to have a -cache value of at least a few MB, or mplayer will often
randomly not work with dvb:// syntax (no video or no audio). This is to be
expected? I'm guessing mplayer looks in the cache to find the PAT/PMT, and a
too small cache will not have a them in it? Doc. A/53D Annex C tells me that
the maximum time between PMT sections is 400 ms, and for the PAT it's 140 ms.
At least I think that's what it saying. So we need at least 400 ms to find
them both. If we don't know the PMT pid, and need to find the PAT first, then
find the _next_ PMT, we'd need 540 ms. At 40 Mbit/sec, that's 1954-2636
KiloBytes. So, does mplayer need this much in the cache before it starts
playing?
More information about the MPlayer-dev-eng
mailing list