Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jul 2003 23:50:09 -0700
From:      John-Mark Gurney <gurney_j@efn.org>
To:        "Steve O'Hara-Smith" <steve@sohara.org>
Cc:        multimedia@freebsd.org
Subject:   Re: BSD video capture emulation question
Message-ID:  <20030711065009.GG35337@funkthat.com>
In-Reply-To: <20030711070916.5320dd5c.steve@sohara.org>
References:  <7192223.1057850975979.JavaMail.nobody@kermit.psp.pas.earthlink.net> <20030710191329.GB44762@funkthat.com> <20030710222923.0ece3692.steve@sohara.org> <20030710204047.GC35337@funkthat.com> <20030711070916.5320dd5c.steve@sohara.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Steve O'Hara-Smith wrote this message on Fri, Jul 11, 2003 at 07:09 +0200:
> On Thu, 10 Jul 2003 13:40:47 -0700
> John-Mark Gurney <gurney_j@efn.org> wrote:
> 
> JMG> Yes, I followed the bktr interface, but the bktr interface needs to
> JMG> disappear ASAP!  The bktr interface is very bad as we make FreeBSD
> JMG> multiplatform.  It lets the user supply the physical address when
> JMG> doing video overlay to the video card.  This should be handled by the
> JMG> driver, not the userland app.
> 
> 	Hmm, that implies that the driver must know how to find the
> overlay area that the userland app wants it to use - irrespective of the
> video out driver in use.

Actually, this is very easy.  I was first using svgalib to write my
overlay program which gave me a userland buffer but NOT a physical
address.. it was easy to pass this buffer to the driver and have it
do the right thing.

This is more complex on sparc64 machines that don't do a direct
physical to PCI mapping but have an IOMMU, since you need to know
more about the machine.

> 	Conclusion the overlay areas have to be entities of some kind in
> the in the multimedia infrastructure. 

To a certain extent yes...  but there is work underway to properly
handle device to device dma..

> JMG> > 	AFAICS what's needed is someone with some insight into what makes
> JMG> > a good video API if FreeBSD is ever going to get one. The innards
> JMG> > of things like ffmpeg and transcode are probably worth looking at
> JMG> > as models.
> JMG> 
> JMG> Hmmm.  I'll have to look at that.
> JMG> 
> JMG> But there is more than just codec handling.  One of the features that
> 
> 	Oh sure - but seamless plumbing of codecs, sources and sinks is
> a very desirable feature IMHO. This is the bit that these apps seem to
> manage.

Then let them manage that.. :)

> JMG> the Zoran card supports is the ability to have two sources (since as
> JMG> external video and MJPEG playback) one in a window of the other.  But
> JMG> you need to only have one video clock running the output.  This
> JMG> should be handled by the video api so the drivers just write the raw
> JMG> interface and the api does the manipulation of the driver.
> 
> 	Yep seamless plumbing - so somehow the PIP has to present as a video
> sink and DTRT when you plumb the other video source into it - even if that
> turns out to be the output of mplayer playing a VCD and not the expected
> other bit from the card. If it can't do it the plumbing must fail.

Ummm..  you are talking about something completely different.  I'm
talking about the hardware aspect of it, not the software aspect..

> 	ISTM the plumbing actions either require a smart plumber or a
> dialogue between the interfaces being plumbed. The latter seems to fit
> the UNIX device model better.
> 
> 	Are thinking in similar terms ?

Nope, you are thinking of pure software, and I have been talking about
pure hardware wrt to the windowing scheme mentioned above.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030711065009.GG35337>