Date: Sun, 24 Apr 2005 00:19:18 -0700 From: Julian Elischer <julian@elischer.org> To: Jacob Meuser <jakemsr@jakemsr.com> Cc: freebsd-multimedia@freebsd.org Subject: Re: patch for bktr(4): don't reset tuner on open/close Message-ID: <426B4876.6020307@elischer.org> In-Reply-To: <20050424052941.GA3339@puff.jakemsr.gom> References: <20050423225506.GA25461@puff.jakemsr.gom> <426B23BA.6060206@elischer.org> <20050424052941.GA3339@puff.jakemsr.gom>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacob Meuser wrote: > On Sat, Apr 23, 2005 at 09:42:34PM -0700, Julian Elischer wrote: > >>Jacob Meuser wrote: >> >>>the following is a patch that is in OpenBSD's bktr. >>> >>>the idea is to not reset the tuner device on open(2) and close(2). >>> >>>effects: >>> - don't need to hold /dev/tuner open to get audio. >>> - selected channelset won't get clobbered on open/close. IMO, the >>> current behaviour here is idiotic. the channelset has nothing to >>> do with the hardware. it is internally used by the driver. also, >>> this is IMO a much cleaner fix to the problems with V4L programs >>> not tuning properly because they never set the channelset. now >>> the correct channelset can be set at bootup with something like >>> bsdbktrtvtune or whatever, instead of rebuilding the kernel with >>> the default channelset hardcoded into the driver. >>> >>>BTW, I haven't tested this on FreeBSD at all. it might need some >>>tweaking. the diff is also set up so that BKTR_NO_OPEN_RESET must >>>be defined to enable it. ultimately, I think this should be the >>>default behaviour. >>> >> >> >>can you comment on what you mean by "V4L programs"? >>(since we don't have V4L on freeBSD (as such)) > > > mplayer, xawtv, etc. I guess what I meant was programs that were > originally for V4L and then ported (with some pieces missing). > > the bktr interface is not very intuitive, and it's pretty easy, IMO, > to understand why some projects that were ported from V4L to bktr > don't do things quite right. > > probably the most common issue is with tuning via TVTUNER_SETFREQ. > on the surface this looks like VIDIOCSFREQ or VIDIOC_S_FREQUENCY. > however, bktr uses it's internal channelset to calculate carrier > offset, etc. this does not happen in the linux bttv driver. > as a result, programs like mplayer and xawtv never set the > channelset. for mplayer, allowing a user to choose the channelset > (because remember, as it is now, the channelset gets reset to the > default everytime the tuner is opened) would require another option. > xawtv has a menu box for selecting the channelset. however, the > action of changing the channelset doesn't do anything but update > the list pointer. the less intrusive fix would be to add > TVTUNER_SETTYPE before each TVTUNER_SETFREQ. otherwise a new > action would have to be added to xawtv (which I have patches for. > but of course, they are for xawtv-3.x, which is now obsolete ...). > > also, there is (was) no documentation for bktr ioctls. some was > recently added to the OpenBSD bktr manpage. your meteor(4) explains > some of the METEOR_ ioctls, but it seems there are differences and > some of the stuff it talks about was apparently never implemented > in bktr(4)? > ok. I was just checking that there wasn't more V4L work going on that I wasn't aware of.. So far I know of the following: We have a largely working port of the V4L2 basic interface by Christian Gusenbauer and the V4L and V4L2 authors have indicated to me that we are welcome to copy the interface spec (read include files) so I think we'll end up with a V4L interface ourselves.. I've looked at the code and it looks like a good starting point. I'm in the process of ponderring whether we can take that interface and provide a real framework for video that uses that interface as one of the ways in/out of it. (see later) Luis López Solé, and Tomomi Suzuki are apparently active in this field and Stacey Son has been mentionned similarly. Hopefully we can make something that makes teh V4L interface look a bit half hearted, while maintaining compatibility with it. If we are good enough at doing that we may even be able to give it back the Linux guys as a thankyou for the headstart. My basic thoughts keep coming back to the fact that there is no starndard abstraction for a full Multimedia stream. A full stream has multiple channels, some of which may contain video and some of which may contain audio. These in turn may have subchannels and alternative format channels, while all the time maintaining time synchronisation between these various parts. For example there could be a stream with 2 video channels and 5 track audio. The video could in turn be available in mpeg4 and raw at the same time, and the audio might be available in raw and mp3. In addition there could be a synchronous data stream (e.g. a digital whiteboard session) that is also to be synchronised with this (like the old multicast 'wb' program), so that you could play back a recording of a meeting or use it to send/record a videoconference, including the whiteboard doodles, at the correct pace. In addition there needs to be a way to specify readers and writers to these streams where a writer might be writing asynchronously (e.g. reading as fast as it can from a recording file) but the reader is working synchronously (sending the video and audio out to be viewed), or it could be the other way around, where a synchronous source (a camera/microphone) is sending to a reader that is async in nature (being recorded to disk). In fact some cases the more difficult situation is the case of 2 synchronous entities working together.. And what do we do if there needs to be a format conversion between them? and what about if the source is a webcam doing 15 fps and teh sync is a TV broadcast reading at 25 or 30 fps? In my opinion the framework needs to take all this into account and I believe it is possible. Puting a V4L frontend/backend on it is just the easy part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?426B4876.6020307>