On Fri, 19 Oct 2001, Billy Biggs wrote:
> [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> > What I don't understand is why there is such an issue about root
> > permissions. v4l devices, for example, have been user-accessible for a
> > while. [...]
>
> Please consider the root issue a separate matter: I don't want it to
> hinder my suggestions for improving video output quality.
>
> That said, let me explain my reasoning:
>
> Consider a video player attempting to play a TV feed at 59.94fps. A
> frame must be blit every 16ms. With current scheduling under linux,
> nanosleep has an accuracy of 1/HZ, which for most systems is 10ms.
> Film-source material at 24fps (41.6ms/blit) suffers similarily. The
> +/-5ms error here is visible, especially on big cinematic pans.
> Clearly, smooth video output is only possible with better accuracy.
>
> My current plan of attack is simple:
>
> * Use /dev/rtc to cause an interupt at 1024hz (need root for >64hz).
> * Set your render thread SCHED_FIFO so that when the timer interrupt
> occurs, you will preempt everything (requires root).
>
> I get +/-1ms accuracy for my frame blits. This brute force method
> works fine, but I still suffer slightly from not being synced to the
> refresh rate. If HZ was set to something reasonable (like, say, 1024),
> then being SCHED_FIFO would only be required when you want to guarentee
> that you're never very far off, which you probably only need when you're
> going to sit down with your family for a sunday night movie.
>
> If we had the vsync as an interrupt (/dev/vsync or something), then
> quality would increase with less system load! Very nice! But
> SCHED_FIFO would still be needed to guarentee accurate blits.
The other approach is to have a device which you mmap and write your
frames into. Then you issue an ioctl and the driver DMAs the buffers at
the next available opportunity.
>
> Not all video and multimedia applications require root access.
> Single-frame video grabbers, teletext decoders, and some specific
> hardware-assisted players are examples. But you do need something
> special for realtime audio effects processors, MIDI synthesizers, and
> high quality (even TV quality!) video players.
Not necessarily, though you may want something like this for real-time
effects,encoders and decoders. This still does not imply you can't provide
a clean interface to userspace.
>
> Check out deinterlace.sf.net (aka dscaler.sf.net). It's an example of
> a (Windows-based) video deinterlacer, something I've kinda got working
> under linux. For realtime deinterlacing, you have about 16ms _total_ to
> grab a field from the capture card, process it, and send it to the
> display. This demands alot from the CPU, and will definitely require
> root access to ensure accurate timing. We can't buffer more than maybe
> 2 fields, since unlike using a software DVD player we have no control of
> the audio (which goes direct from your DVD player into your AC3 decoder
> etc). Ouch!!
How big are the cpu requirements ? This is something that is quite useful,
because, at the moment, v4l does not allow to convey such information as
field parity..
>
>
> Branden Robinson mentioned the following:
>
> > FWIW, I've heard that the pre-emptible kernel patches to Linux improve
> > latency a great deal.
>
> If you're talking about the low-latency kernel patches, these only
> guarentee performance benefits to SCHED_FIFO processes running as root,
> AFAIK.
>
> > What I'm telling you is that DVD playback software that has to be
> > setuid root, or run only by the root user, is a very unpalatable
> > prospect to most general-purpose distributions. I think that is the
> > audience that most interests the current developers of XvMC, but I
> > urge them to correct me if I'm wrong.
>
> Hey, I'm just saying that for 'high quality' output, that is, at
> television framerates or theatre-smooth video, you need root. You can
> play things just fine as a user but your quality will be nowhere near
> what you can achieve.
>
>
> Back to [EMAIL PROTECTED]:
>
> > Bill - if you are willing to settle for your application to
> > work with one video card (i.e. ATI) you could get such functionality
> > much sooner. Just e-mail me what you want (in terms of sync), and I'll
> > try to include this in our "extended" v4l module (http://gatos.sf.net)
>
> Vladimir, the idea of a /dev/vsync device is looking very promising.
> Maybe we should look at standardizing something in this line, but
> ideally I want my software to work with all video cards eventually (so
> long as they don't suck and can provide me with the vsync status or an
> interrupt).
>
> Thoughts?
Not /dev/vsync. just a device to write frame data into and issue ioctl for
dma'ed transfer to video memory.
One thing - did you try your dvd player with recent ATI drivers ? ATI
can doublebuffer frames switching them automatically on vsync. If you
still see the issue you are worried about something is wrong with our
drivers - I'd appreciate a lot if you could write a test up to debug the
issue. (or a test mpeg stream)
Vladimir Dergachev
>
> --
> Billy Biggs [EMAIL PROTECTED]
> http://www.billybiggs.com/ [EMAIL PROTECTED]
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
