PVR-150 on 6-STABLE: success and mini HOWTO
danny at ricin.com
Thu Dec 20 15:01:46 PST 2007
On Thursday 20 December 2007 23:39:19 Danny Pansters wrote:
> On Thursday 20 December 2007 23:15:21 you wrote:
> > Hi Danny, Mat,
> > as the author of the pvrxxx version of the pvr250 driver, i have been
> > reading along.
> > Danny, thanks for your mini howto, and it is nice to read it was
> > pretty straightforward for you.
> > i noticed a couple of things:
> > 1. some version of mythtv fails to probe the inputs. this needs to be
> > investigated: there is a problem with the v4l(2)-header-files, or the
> > v4l(2) api actually changed ( i seem to recall something about his ).
> > i would like to know the exact version of mythtv which fails to probe
> > the inputs.
> Needless to say that I avoid Myth :)
> > 2. the driver is not designed for multiple reading. however, it must
> > be able to be opened more than once because the tuner is not a
> > separate device. this makes tuning while watching possible.
> The tuner works over the iic bus, it is a different device than the a/v
> decoder and the mpeg encoder, drivers merely hide such things. The saa
> driver has explicit devices for video (saa), audio (sau) and tuning (raw
> I'm somewhat interested in the possibility to capture straight off the
> decoder (av decoder, not to be confused with mpeg decoder which is to be
> done in software), bypassing the mpeg chip altogether. It ought to be
> almost the same as bktr capture, but I'm not sure how to handle the audio.
> And there are probably many unpleasant surprises as to which BT848_* and
> METEOR_* ioctls would work as expected if at all. I suspect most of them
> are not supported at all, but I haven't read the code in detail yet. That
> said, software decoding of the PES mpeg as is the default works pretty
> well, and I may not be able to outdo it.
> But I think (also from how hauppauge advertises it), that "concurrent
> access" to the a/v stream simply means that you record to a file and while
> doing that you can open that file for reading (playing). Well, duh.
> > 3. switching back from svhs is not possible?
> Nope, once composite, always composite. I have PAL, and although the tuner
> had nothing interesting under the sticker, I suspect it needs some reinit.
> It does do the sound of the channel, so I think its failed PLL lock or
> something in that region.
> > 4. supporting tvtime and other linux tv-viewers is on my wishlist too:
> > a v4l(2) compatible reading api needs to be implemented.
> 4vl sucks, 4vl sucks2 IMHO. Tying together individual drivers is much
> better handled in userspace and in a (simple) higher level api of sorts
> (say, in python). Of course I'm biased :)
> > 5. i experimented with the "3:2 pulldown" flag of the encoder. i think
> > the current driver mistakenly enables 3:2 pulldown. fixing this will
> > improve fast moving scenes ( sports ) and sliding texts.
> Hmm, I dunno. If it means anything, the artifacts are exactly the same in
> bktr (brooktree chips are the forefathers of connexant chips). I noticed
> that hauppauge has a setting for capturing all fields or odd-only *in their
> tv application*. You only do that if it's a fundamental problem with the
Let me add to that: capturing only odd or even fields (and thus not
interlacing them) is actually sub optimal, because you loose UV data that
way. The way mplayer handles this with halfpack leaves the UV interlaced, but
not the Y IIUC. That eliminates only movement artifacts but not color
> capture chipset. I suspect it's because of a crappy scaler actually.
> saa-based boards do NOT have this problem, bt/connexant based boards do.
> At least the "brooktree stipple" at the top of the video frames is gone in
> cxm :)
> > if anyone has any other wishes or problems please let us know in this
> > thread.
> > regards,
> > usleep
> freebsd-multimedia at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-multimedia-unsubscribe at freebsd.org"
More information about the freebsd-multimedia