Date: Wed, 20 Aug 1997 00:24:27 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG Subject: Re: [bt848] comments and diffs Message-ID: <199708200724.AAA02369@rah.star-gate.com> In-Reply-To: Your message of "Wed, 20 Aug 1997 05:40:19 %2B0200." <199708200340.FAA12548@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Guys, 1.* when capturing full frames, should we get the odd field > first, followed by the even one (I do believe this is the way to > do, reading some CCIR documents the odd field is always mentioned > as the first one in a frame), the even field first, or whatever > we find first (the latter is _very_ tricky to program since the > dma program waits for a specific field); When capturing full frames the ODD field is first. >2.* when capturing single fields, do we return only one field per > frame (i.e. have a max of 25/30 fields per second) or, if the > user asks for more, we return both even and odd fields ? The > latter is also tricky since we need a different DMA program than > the one which only returns all even (or all odd) fields; it is > also a problem for applications because the fields have a slight > vertical offset, and any application trying to do compression on > subsequent frames will be negatively affected by this offset. Of > course one could say that if the user asks for something the > hardware can deliver, why not support it... Typically , if the user wants single fields they want ODD or EVEN and not both . They may be some exotic application which can benefit from a mixture of odd / even ,.e.g., 30 ODD fields and 10 EVEN fields but I doubt it. Sure if anyone wants to implement no problem with me provided that it does not break the rest of the functionality in the driver. >* I have not rewritten the program which does clipping, hence it does > not work for me. There are several reasons for that, the main ones > being that a) I have no use for them, and b) I am not too satisfied with > the way clip regions are passed to the kernel. But since Amancio has > some working code and I don't even have a detailed proposal, I'll > shut up on this issue... The clipping code was designed for simplicity sake from the users's perspective . That aside no one has a expressed a dire need for clipping . To my knowledege the only application which I know of today which can benefit from clipping is fxtv . Randall said that he was going to use clipping : "when the leaves turn this year" so we shall see. My point is this it takes a considerable amount of effort to support something like clipping and we can support multiple schemes however there should be at least a genuine justification or desire to use such functionality. In this respect perhaps we should poll the BSDI and Linux community since the driver now works on their platform -- who knows may be we can even port a cool video app from their camp (BSDI / Linux). Let me say this another way, it is important to keep the same video interface in Linux, BSDI and FreeBSD for the purpose of hopefully making video apps portable. One way of accomplishing this is by getting them involve in the development of the driver. It also increases our support coverage so if anyone feels like dropping out or is tied up hopefully one the video experts can take over. >using the driver for other applications ?). But I am strongly >convinced that we should aim at making the driver behave consistently >with some specification which a) can be applied to other video >drivers as well, and b) can be used by application writers as a >reference for what the driver should do, as opposed to writing the What we should have is a C/C++ interface to which developers can code to and isolate them from the ioctl interface. Most OSes have such video API. If we decide to go this route it will be nice to be compliant to a well known interface : SGI, HP , or SUN . >* there is some code depending on BROOKTREE_IRQ being defined. > Someone some time ago told me that similar code (in the meteor > driver) might not even work. I suggest it to remove it from both > drivers. This code works and I recently used it -- that is assigning an IRQ to the driver . Try it out. --- Now has anyone managed to try out Luigi's diffs? Last but not least probably what the driver *really* needs is a good user manual . Any volunteers? Tnks, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708200724.AAA02369>