[mythtv] hdtv reorg, crc checking

Daniel Thor Kristjansson danielk at cat.nyu.edu
Tue Feb 3 21:16:51 EST 2004


]Still haven't had time to look at your patch in depth yet (just from paging
]through it, though, it looks like you're going to break compilation for most
]people -- VIDIOCGSIGNAL isn't standard v4l, and I really wish you wouldn't
]combine your patch with the switch to another tuner card patch), but..

VIDIOCGSIGNAL isn't called unless you have a HDTV card, which right now
I'm assuming is only the pcHDTV card. In the latest patch (#4) I update
the videodev[2]_myth.h to add the signal there instead of depending on the
headers being patched in the kernel. Still, I think this may break
for anyone with a different custom patch to bttv. I'm trying to clean
this up. I'll also remove the switch tuner patch next round. I don't
think this is ready for CVS, but is ready for anyone with a pcHDTV card and I
would also like anyone with a DVB tuner or a low end PVR-250 machine
with XvMC to try it for the decoding parts. I'll break this up into 2-3
logical patches when I think it's getting there. And also #ifdef any
possibly dangerous patches to videodev[2]_myth.h

I'm releasing these to the list mostly because HDTV only works on the
one strong signal in my area without the patches. I'm in New York where
most of the transmitters are at low power and will be until 2007 or
2008, the one channel at full power (WNBC) always transmits 1920x1024
which means I have to use XvMC.

]> It helps a little with the OSD slowdown by calling Flush on the OSD
]> fill, and delaying Sync on a frame until you really need it. But I think
]> this actually requires a fix to NuppelVideoPlayer::VTAVSync & co, too
]> add more frames between the call to PrepareFrame and Show, since
]> PrepareFrame can take a while with OSD compositing.
]>
]> The problem here is that if we need to drop frames we really don't want
]> to waste calls to PrepareFrame on Frames we never use. Has anyone
]> thought of this with PVR decoding? It seems like this would be a problem
]> with slow CPUs on regular 640x480, not just on full size HDTV on a fast
]> CPU. From my googling it looks like the mplayer people do something like
]> this to make OSD work with XvMC.
]
]VTAVSync() is experimental, and I doubt people want to use it most of the
]time..  All the sync methods, however, don't call PrepareFrame unless it's
]going to also call Show on that frame.

Yep, but if calling PrepareFrame is going to take 40 msec you will want
to call it earlier, and then may never call Show on it because it later
turns out you need to skip that frame to stay in sync. Unfortunately the
XvMC's sync is being called on practically every frame whether
PrepareFrame is called or not, this seems to be to keep the hardware
decoder happy, but this could probably be avoided on I frames and
reduced for other frames (non-bidirectional frames only need one side...)
I think that will be what I look at first.

All this patch does however is call Flush on the OSD image composite
where Sync was called before, and then call Sync before the composite is
actually used. Whether this helps depends on which XvMC implementation
you are using.

Maybe the NuppelVideoPlayer needs to know about the difference between
I, P & B frames when skipping ahead, then you could try to skip to the
next I frame, avoiding the chain of dependencies to other frames?

Another option is to just not composite OSD in and instead pop up a
frameless window, Xv can chromakey out black pixels in another window
and this could be used to get something that look decent and works. I
don't really like this option, but it is probably the easiest.

-- Daniel


More information about the mythtv-dev mailing list