From owner-freebsd-multimedia Thu Apr 25 07:10:28 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA11677 for multimedia-outgoing; Thu, 25 Apr 1996 07:10:28 -0700 (PDT) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA11672 for ; Thu, 25 Apr 1996 07:10:25 -0700 (PDT) Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id JAA19519; Thu, 25 Apr 1996 09:10:15 -0500 Date: Thu, 25 Apr 1996 09:10:15 -0500 From: Jim Lowe Message-Id: <199604251410.JAA19519@miller.cs.uwm.edu> To: hasty@rah.star-gate.com, tinguely@plains.nodak.edu Subject: Re: 30fps with vic? Cc: multimedia@freebsd.org Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: "Amancio Hasty Jr." > > My next question is: has anyone done a profile analysis on vic / h.261 to > see if vic's performance can be improved? > To answer to your question, no I have not done profiling of vic, but I have thought of ways to speed it and other algorithms like it up by making the device drivers we support for video capture a little smarter. One way vic/h.261 and other algorithms like it could be improved would be to eliminate the copying of data. I have thought of adding a ``vic'' capture mode to the meteor device driver to speed things up. Basically vic uses a buffer that looks like: xxxxxxxxxx .......... .......... .......... .......... .......... .......... xxxxxxxxxx The ``.''s are the actual video data and the ``x''s are scratch buffers for the encoding algorithm (h.261 or whatever). Vic's internal buffer is rows * cols + 2 * cols (see grabber.cc for details). If one used synchronous capture mode and could specify where the video capture driver was suppose to put the data, then one could create a buffer for vic, let the driver do the work (via dma) and avoid the copy from the mmaped area to a vic work area. This would save a fair amount of coping time and speed up the encoding rate. The time you would save is the time it takes to copy a 358x244x2x30fps from one memory location to another. Since the memory bandwidth of a Triton MB is about 40Meg/Sec (mem to mem), this copy alone would take up about 1/8 of total memory bandwidth. If you were going to create a user memory encoding capture mode, then you would want something that does 4:1:1 or 4:2:2 and dma's the data directly from the card into user space. A capture mode like this would come in handy for mpeg and jpeg encoders as well as a TV player :-). There is a bug with the Philips SAA7116 chip that would not allow range checking to work if you wanted to dma directly into user space. Also, the user memory would have to be locked into an actual physical location all the time. I am not certain if there is a FreeBSD kernel VM function that will allow one to do this. In any case, the source code is available :-). -Jim