From owner-freebsd-multimedia Mon Sep 22 00:46:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA23001 for multimedia-outgoing; Mon, 22 Sep 1997 00:46:11 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22988 for ; Mon, 22 Sep 1997 00:46:07 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id AAA01031 for ; Mon, 22 Sep 1997 00:46:05 -0700 (PDT) Message-Id: <199709220746.AAA01031@rah.star-gate.com> To: multimedia@freebsd.org Subject: [video] My Current Plan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Sep 1997 00:46:04 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In no particular order of implementation , this is what I have been thinking of doing for the next 6 months. 1. Provide X server side video extensions I downloaded the old X11R5 video extensions: http://ftp.uci.agh.edu.pl/pub/X11R5/contrib/extensions/mvex http://ftp.uci.agh.edu.pl/pub/X11R5/contrib/extensions/xv Will be evaluating the extensions based on ease of implementation & extensibility. For starters, I would like to provide yuv to rgb color expansion from a video source or from an application side. For the case that an application provides a yuv stream (like vic is capable of ) , the yuv to rgb & scaling hardware support will be best done thru the XIE extensions. The X Video extensions will not be affected since they will have direct access to the hardware. Targetted applications are fxtv and vic. If anyone has any info into an existing xvideo project please let me know. 2. Proceed forward to provide a hardware mpeg decoder/encoder solution Details a bit fuzzy however I am gathering the docs and have an Omnimedia mpeg encoder/decoder board. Should be interesting to serve up mpeg audio and video streams . The mpeg audio component should be very interesting because we will be able to serve quality audio streams at around 80kbs . At any rate, thats my warm fuzzy feeling 8) 3. Provide the functionality of fastvid that is disable caching of the video frame buffer -- experimental tests over here show that at least under dos and with a matrox millenium the data trasfer to the frame buffer can jump from 20MB/s to 80MB/s. A simple hardwire hack over has show positive results for MTV and I will imagine that vic will also benefit a lot. If I managed to provide the above functionality in a reasonable time we will have a decent low level video solution. What is lacking is an application frame work -- that one is a bit tougher to accomplish perhaps we can ride this one with recent advancements in object technlogy in java -- for example java beans. Enjoy, Amancio