[mythtv-users] [ivtv-users] /dev/video48 vs /dev/video16

Luke McKee hojuruku at gmail.com
Thu Feb 1 22:53:42 UTC 2007

Sandler: Yep /dev/video16 works great. I posted to this list about using
mencoder to re-encode the audio only in realtime so I can watch DVDs using
1-5% cpu. Actually it's video18 on my system becuase I've got a bttv and a
DVB card.

Scott: I turn of VBI and VBI passthrough for good luck. Mythtv keeps turning
it on to get subtitles from the VBI private stream mixed in with the video.
I read there are lots of bugs with VBI in post 0.9.1 versions due to a
firmware issue that mixes where the VBI packets end up, and that ivtv
developers made a workaround... correct me if I'm wrong.

I heard some other people talk about high CPU usage as well running gentoo
and non SMP kernels. 2.6.19-r4 (I need that or above for a promise IDE
patch). It's not mythtv that does it its the IVTV xserver that races and
uses all the available CPU. I'm running the debian repository binary of the
xserver everyone uses with Xorg 7.1  for amd64. I found the source code
patches for this against the stable version of the xserver driver, but the
SVN patches don't even work when I load the right release from when the
patch was posted.

I think I'm going to try and get SVN xserver going, because now (after 15
days) they might of put the XV patches in).

Simple follow-up question - reworded. Does mythtv support both using XV and
MPEG2 out, i.e. switching to MPEG (/dev/video16) when the stream supports it
- IE MPEG2 PS with the right resolution and transcoded audio to MP2? On my
system this doesn't happen with re-encoded DVB streams. I've got a NTSC card
in a PAL country (don't ask I moved :P) so I'll test tonight with captured
video from the SVideo port. I know it's a myth question but what determines
is /dev/video16 kicks in, I have a hunch it doesn't even check the stream -
it just does a query to see if the recording was recorded through the IVTV
first..... hence why it always uses XV for playback of my DVB streams. Again
tonight I'll check the source and post back to you.

I've heard lots of rumors that they are going to pull video output from a
future release, and that /dev/video16 output only works if you run Xserver
on a different card than the PVR-350 output. In any case with all the
confusion I'm going to put a blog entry about how to do low CPU DVB
recording and playback with a PVR-350. I may also give up on the Xserver (at
least for a time) and experiment with using QT-Embedded instead of the
Xserver. Any recommendations?



On 02/02/07, Scott Reynolds <srey0123+ivtv at gmail.com> wrote:
> On Feb 1, 2007, at 7:05 AM, Sander Sweers wrote:
> > I
> > have also read that the framebuffer support in mythtv is not working
> > well and will be ripped out in the next version (correct me if I'm
> > wrong here).
> This is apparently false. See:
> http://www.mythpvr.com/mythtv/pvr-350-mythtv-support.html#comment-1
> What is currently not working on my systems:
> - There is an issue with Qt performance on KnoppMyth R5E50. It's
> horribly slow. You can watch dialog boxes paint on an 800 MHz Pentium
> III system.
> - Also, there's a problem that I'm running into with sending VBI to
> the 350's TV Out. For lack of better terms, it's garbled. One could
> work around the issue by simply using Live TV once after rebooting,
> but no longer. My search through the changes between 0.19 and 0.20
> isn't turning up anything, either. To be honest, I am starting to
> wonder if there was a change to ivtv between 0.4.x and 0.8.x that
> might account for the difference in behavior. I have verified that
> VBI data is being captured correctly: you can decode it with the
> native MythTV player, and the "vbi" utility in the ivtv/tests
> directory is able to extract it from the stream. It's only playback
> through the MPEG decoder that's an issue.
> All of this to say: yes, the PVR-350 still seems to work, modulo a
> couple of relatively minor problems. These do not appear to be
> related directly MythTV.
> --scott
> _______________________________________________
> ivtv-users mailing list
> ivtv-users at ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070202/754486f2/attachment.htm 

More information about the mythtv-users mailing list