[mythtv-users] Ceton InfiniTV 4 and patches to support it

[Ronald Frazier]

On Sat, Jul 23, 2011 at 9:48 AM, John Haller <john.h.haller at gmail.com> wrote:
> I tried out Ron's patches, and it works fairly well, except for one problem,
> which is probably not associated with his patches.
>
> The picture will tear, jump, or pixelate, which is generally associated with
> the X process using close to 100% of one core, and the following message
> repeated in the myth front end log:
> 2011-07-22 15:59:11.236 [mpeg2video @
> 0x7fdf1e7d57a0]mpeg_decode_postinit() failure
>
> Single stepping the video one frame at a time has the same problem.
>
> I recorded the same show off the antenna at the same time, it's close to the
> same size (5.50 GB - cable vs 5.52 GB - antenna)
>
> The kernel log was also full of messages like:
> notify_cc_check:41 WARNING: (0) NOTIFY board 0 tuner 0 pid 0x1d77
> out_of_sync 2000
> This message comes out of the Ceton driver when packets don't start
> with the start
> of packet indicator 0x47, and is happening quite a bit. I rebooted,
> the out-of-sync
> messages stopped, but still get the pixelation.
>
> So, I'm not sure if my problem is with the card dropping packets, causing the
> decode to choke on the missing packets, or something else. With the antenna,
> the CPU for X associated core runs at 100% for about 10-15 seconds, then
> is less than 5%. For the Ceton recording, it's similar, but about 38 seconds in,
> I start seeing chunks of the picture in places it doesn't belong, and the
> CPU spikes to 100% again. I suspect the picture is not synchronized,
> and whatever causes the X associated CPU to spike at the beginning of
> the playback is kicking in again.
>
> The only other thing which might be a problem is that the tuners run
> close to the
> 65C max (62.8). The signal level is -10.5 dBmv, signal to noise of 36.0 dB. But,
> I put a fan on it, got it down to 38C, and still lots of dropped packets. But,
> clear QAM off the other splitter tap works fine going directly into the TV.
>
> After the reboot, now I get these messages in mythfrontend log (just a
> sample, there
> are more of these message):
> 2011-07-22 18:39:17.461 Player(0): Video timing method: USleep with busy wait
> 2011-07-22 18:39:17.461 TV: Changing from None to WatchingRecording
> 2011-07-22 18:39:17.496 VideoOutput: Created YV12 OSD.
> 2011-07-22 18:40:22.197 AFD Error: Unknown decoding error
> 2011-07-22 18:40:22.247 AFD Error: Unknown decoding error
> 2011-07-22 18:42:37.933 Player(0): Waited 100ms for video buffers
> UUUUUUUUUUULLLLLLLLLLLLLLLLLfff
> 2011-07-22 18:42:37.941 Player(0): Waited 100ms for video buffers
> UUUUUUUUUUULLLLLLLLLLLLLLLLLfff
> 2011-07-22 18:44:32.052 Player(0): Timed out waiting for frames, and
>                        there are not enough free frames. Discarding
> buffered frames.
> FYI, the front/backend is a Core i7 860 @2.8 Ghz.


In theory , any playback problems should not have anything to do with
my patch, since it only handles recording. It doesn't even handle
anything like parsing out the mpeg ts packets to find the content of
interest...that's all handled by the existing myth mpeg libraries. The
only way I could do anything about it was if it was either a buffer
overrun case (like reading too small of a block of data at a time and
myth falls behind and the card fills up it's internal buffer and
starts discarding data I didn't get in time) or if there was some
other sort of bug in my patch,  or in the myth mpeg code (unlikely,
but in my case I actually did run into case where it wasn't properly
handling the mpeg-ts stream that comes from my cable company).

The best way to figure this out would ideally be to eliminate my code
from the equation, and just dump the data straight from /dev/ceton/*
into a .mpg file and see if that plays in myth. Unfortunately, there's
a small kink in the ceton's output which prevent that from working
reliably. As I discovered, when you tune a particular channel, the
Ceton filters out all the other channels video/audio packets from the
stream, but it leaves in all the PMT entries from the channels you
aren't watching. This seems to confuse almost everything except for
mplayer. So the way to resolve that is to remux the resulting file to
strip out those extra PMT entries. The only way I found to do this was
a Windows program called MPEG-2 Transport Stream packet analyser:
http://www.pjdaniel.org.uk/mpeg/

I can tell you how I did this, but I should say that it's going to
depend on how your cable company arranges the data in the mpeg-ts
stream, so what worked for me may not be as simple for you.

1) Lost the mpg file into the program.
2) In the Filter section at the top left, check the PID box and set
the text box value to 0.
3) Click the goto next packet button on the toolbar.
4) In the text area on the right, it's going to list all of the
channels that are available on the tuned multiplex, and the PID
associated with that program. Make not of the PID for the channel you
tuned.
5) Click on the Show PID List button. This will scan the whole file
and show you which PIDs it finds in the stream and how many packets it
finds for each one. What I found was that there were packets for PID 0
(the PAT), packets for each PID that were found in the PAT (these all
correspond to the PMTs for each channel on the multiplex),
occasionally some null packets (PID 8191), and then 2 or 3 other PIDs.
Those 2 or 3 other PIDS were the most common packets (percentage
wise), and they were all numbered sequentially after the PID that I
noted in step 4. You'll want to make note of these PIDs also
6) Now you want to remux the stream. Chose File -> Trim/Remux stream,
and in the popup dialog, chose to include only PID 0 and the PIDs you
noted in steps 4 and 5.

If everything works like it did for me, the resulting file should be
perfectly playable in myth video or any media player software. If you
have the same problems here, then my code is out of the equation. If
this works fine, then we know your ceton is outputting good, usable
data, and we just need to figure out if the problem is my code doing
something bad, or if you system is just too overloaded to handle
playback and recording of the data simultaneously (possible, since you
mentioned your CPU occasionally goitg to 100%).


Just for reference, my signal -5.4 dBmV, my SNR is 36.6 dB, and the
temp is about 50-51 degrees (though my computer is in a cool basement)

-- 
Ron Frazier