Date: Thu, 20 Dec 2007 23:39:19 +0100 From: "Danny Pansters" <danny@ricin.com> To: usleepless@gmail.com Cc: freebsd-multimedia@freebsd.org Subject: Re: PVR-150 on 6-STABLE: success and mini HOWTO Message-ID: <200712202339.19763.danny@ricin.com> In-Reply-To: <c39ec84c0712201415w5a8dcf35h508dfb32692e1ca6@mail.gmail.com> References: <200712191659.28032.danny@ricin.com> <200712202244.12942.danny@ricin.com> <c39ec84c0712201415w5a8dcf35h508dfb32692e1ca6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 20 December 2007 23:15:21 you wrote: > Hi Danny, Mat, <snip> > > 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 iic). 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 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. Thanks, Dan > regards, > > usleep
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712202339.19763.danny>