[ANN] vlc 0.2.81

[PhiloVivero]

Christophe Massiot wrote:

> > What does it mean if SDL works, but xvideo doesn't work?
>
> SDL doesn't need YUV overlay to operate, it can also do software rendering.
> Xvideo can't. Check your console and see if vlc talks about some
> "YUV optimization". Upgrade to the latest XFree86 and see if your video
> board is supported.

Odd. Yesterday SDL worked and xvideo didn't. Today, xvideo works. But then,
yesterday it was segfaulting and acting wierd for a while. I gave up on it. I'll
keep an eye out for wierd behaviour and see if I can characterise it better. Bottom
line, now xvideo & sdl both work on my system (?!?)

> > 0. After RAM gets filled up, the video gets choppy, sometimes pausing up to
> > three seconds while the filesystem thrashes. So far as I can tell, this is
> > only because the filesystem buffer is full, not any bug in VLC.
>
> Did you try turning on DMA ?

[root at sakura ~] # hdparm /dev/dvd

/dev/dvd:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 HDIO_GET_NOWERR failed: Invalid argument
 readonly     =  1 (on)
 readahead    =  8 (on)
 HDIO_GETGEO failed: Invalid argument

It looks like I'm getting some errors with hdparm, but the using_dma is on. Now
that I have xvideo working, I'll see if that makes a difference. I suspect it
won't, since I think the performance problem is RAM (being used up -- my total RAM
is 396MB which is quite more than I need), not output method.

Does turning DMA on somehow bypass the buffer cache? I was not aware that this was
a byproduct of using DMA.

It acts like thus:

Linux is a multitasking operating system with buffer cache. As VLC reads the DVD,
Linux caches the information. As time passes, the cache becomes full, and Linux
begins swapping out old processes (gstripchart backs up my hypothesis).

Then for whatever reason, a network packet, a timed event, some process that was
swapped out needs to come back off disk to run. Normally the 2 or 3 MB would be in
RAM, but because it was earlier swapped out, it is read off disk. The resultant
thrashing causes VLC to lose CPU time (disk interrupts winning out) which causes
long multi-second delays in decoding.

I suspect that bypassing the buffer cache will fix this problem. Samuel Hocevar
mentioned that perhaps the libdvdcss libraries are having trouble doing key
negotiation when /dev/dvd is mapped to a raw device.

Anyone know of some other way of bypassing the buffer cache? (I believe the answer
is 'no' because I'm fairly certain raw devices are the *ONLY* Linux mechanism for
doing this)

--
PhiloVivero