[mythtv-users] Why do those mpeg files not play? (capture with a ceton infiniTV 4)

[Ronald Frazier]

I know a little bit of very basic info about MPEG packets, PAT/PMT
packets, PIDs, etc, but I don't know a whole lot about what to expect
in a valid mpeg stream, but I'm starting to learn a bit more about it.
I found a nice program called the MPEG-2 TS packet analyser 2.3.0.0,
and it's pretty handy.

I'm looking at some of the files generated by the ceton, and comparing
them to files generated by the hd homerun (using hdhomerun_config to
tune and save the file). I'm noticing a few differences, which I think
may be key:

PID 0 packets (PAT) - these packets contain info about all of the
programs (ie: virtual sub-channels or multiplexes) that are contained
in the tuned QAM channel. If the cable company has 10 programs packed
into, there will be 10 entries in this packet, listing the PID number
of each program. The HDHR seems to rewrite these packets to filter it
down to just 1 entry (the program you tuned) regardless of how many
programs the cable company broadcasts. The Ceton, on the other hand,
passes you the raw packets with all of the programs listed.

Tuned program packets - not sure what the terminology for this is, but
if you tuned program 29 and it was PID 4352, then the file would
contain packets for PID 4352, 4353, and 4354. I'm not positive, but I
think 4352 is a stream info/control sort of packet, while 4353 is the
video data and 4354 is the audio data. That's just a guess.
Regardless, both the HDHR and Ceton seem to generate these packets in
roughly the same proprotion...a tiny quantity of 4352, a large
quantity of 4353, and a medium quantity of 4354.

Other packets - the only other packets the HDHR outputs seem to be
NULL packets (which contain a tiny header and then no data). The
Ceton, on the other hand, seems to generate a handful of extra packets
for a number of different PIDs. It looks like for each other program
that you didn't tune (the other entries in the PAT), it still includes
the packets for the primary PID number (the one I think is the stream
info/control packets) and just filters out the adjacent packets that I
believe carry the audio/video data. The result is that, while the HDHR
generated files only contain packets for 5 PIDs total (0, the 3 tuned
PIDs, and the null packets), the Ceton files contain packets for about
15 different PIDs.

That software I mentioned above also has an option to remux the file,
stripping out packets for whichever PIDs you don't want. I used that
to strip out the extra packets on all 3 files. The resulting files now
actually worked in VLC, Window Media Player, and myth trunk. They also
play in myth 0.22, but one of them has a 5-10 second delay before
beginning. That's the one file that has several program entries in the
PAT listed before the desired program.  I'm thinking maybe having
those extra programs listed in the PAT packets is confusing it (like
maybe it's not sure which program to use, so it scans the file for the
first program, doesn't find it, scans it for the next PID, etc, until
it finds one of the programs in the file). I'm betting if I could
rewrite those packets to remove the extra programs, it would be fine.

So my questions are, for someone more familiar with the MPEG spec (or
if anyone know which of the myth developers would be the best one to
ask):
1) Does my explanation sound about right (maybe not perfect, but at
least have I got the general idea), and
2) Is what the ceton is doing...is that considered to be valid data,
or should it be filtering those extra packets? If anyone is lucky
enough to have worked with or have sample files from a pre-release
HDHR Prime, does it do the same sort of thing, or does it filter more
strictly like the regular HDHR does? I'm wondering if this is a bug
Ceton should be fixing, or if software is just supposed to know how to
deal with it (and most of them just don't do a good job with
tolerating it)?

-- 
Ron Frazier