Date: Sun, 25 May 1997 12:33:00 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: multimedia@freebsd.org Subject: about vic Message-ID: <199705251933.MAA01246@rah.star-gate.com>
next in thread | raw e-mail | index | archive | help
------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1241.864588780.1@rah.star-gate.com> Background: Brad Karp <karp@eecs.harvard.edu> is complaining about the artifacts that vic is generating using vic's nornmal resolution. This simple issue hits two important areas the driver and why does H.261 require 352x288 which is probably 1/2 of PAL resolution. To say the least I don't see why we have to be restricted to resolutions which are evenly divisible of PAL resolution: 177x144, 352x288. On the driver say we may be able to improve the NTSC artifacts by way of storing frames in a round robin fashion which means that every time that vic wants a frame it will get a valid frame and not a frame which is currently being updated, or starting to capture the next frame. Cheers, Amancio ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Replied: Sun, 25 May 1997 11:40:54 -0700 Replied: Van Jacobson <van@ee.lbl.gov> Return-Path: van@ee.lbl.gov Received: from rx7.ee.lbl.gov (rx7.ee.lbl.gov [131.243.1.54]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id LAA00699 for <hasty@rah.star-gate.com>; Sun, 25 May 1997 11:06:07 -0700 (PDT) Received: by rx7.ee.lbl.gov (8.8.2/1.43r) id LAA29062; Sun, 25 May 1997 11:06:26 -0700 (PDT) Message-Id: <199705251806.LAA29062@rx7.ee.lbl.gov> To: Amancio Hasty <hasty@rah.star-gate.com> cc: rem-conf@es.net Subject: Re: h.261 : 320x240 vs 352x288 In-reply-to: Your message of Sat, 24 May 97 22:40:50 PDT. Date: Sun, 25 May 97 11:06:26 PDT From: Van Jacobson <van@ee.lbl.gov> Amancio, the vic h261 encoder code, like the precept h261 encoder, will embed a 320x240 ntsc image in a 352x288 cif rectangle so decoders see no change. Almost all the vic grabbers work this way. The major exception was the meteor grabber but I've rewritten part of it for the upcoming vic 2.8.1 release to grab 320x240 fields rather than scaling 640x480 frames. This gets rid of the interlace artifacts & also some geometric distortion introduced by the scaling. I also changed it to grab YUV_PACKED rather than YUV_422. The combination of this change & the single field grab now means the stock meteor works reliably even with the broken Natoma PCI chips on Intel's Pentium-Pro motherboards. The grabber was also changed to remove two extra memory-memory copies of each frame so it sped up more than a factor of two (our 200mhz ppro systems will now grab & h261 cif encode 30fps of high motion video while simultaneously decoding & rendering 2 30fps cif streams at 640x480 -- we don't have any other box that can come close to this). I've put the current working version of the modified meteor driver at ftp://ftp.ee.lbl.gov/grabber-meteor.cc if you want to play with it. It should work with vic-2.8 & I'd welcome any bug reports or changes that could make it in before the 2.8.1 release. Thanks. - Van ------- =_aaaaaaaaaa0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705251933.MAA01246>