VLC refresh bug comment

[Christophe Massiot]

Hi dude,

At 21:57 -0700 6/06/2002, Jeff Lebowski wrote :

>     I wanted to follow-up on my post, which seems to have been 
>misinterpreted.  The video-refresh bug is NOT QuickTime 6's fault. 
> This has been an error present ever since I've started using VLC on 
>Mac OS X, which I believe was version 0.2.9 or 0.3.0.  This occurs 
>on my own computer, which has had QuickTime 6 Developer and now 
>QuickTime 6 Public Preview installed, and on my girlfriend's 
>computer with QuickTime 5.0.4 installed.  This also has occurred in 
>Mac OS X 10.1.3-10.1.5, and my computer has a 32MB GeForce 2MX-400 
>while my girlfriend's has a 16MB Rage 128 Pro.  The most likely 
>explanation of this issue is a bug in VLC's method of rendering 
>video when running in millions of colors, as no other Mac OS X 
>program exhibits this behavior.

Maybe we're not talking of the same bug. I know of at least two 
reported "black screen" bugs which have been fixed between 0.2.92 and 
0.4.0.

The reason I don't believe this last one is VLC's fault is that it is 
millions of colors-specific. VLC does *NOT* do the rendering by 
itself, it's QuickTime's job, and it is done in hardware. As a 
consequence there is no notion of millions of colors in VLC, since we 
only work on YUV coordinates. The only part which deals with RGB 
colors is after the rendering, that is in QuickTime.

When you say "no other Mac OS X program exhibits this behavior", you 
shouldn't tell things you don't know.

http://www.mireth.com/pub/mxme.html

"Although I havem't tried it out yet I've received reports that our 
codec also displays black under QT6. It was working fine under 5 on 
OSX. The codec asks for a yuv 422 pixelmap for decompression. I'm 
assuming it's a bug in QT6 at this point." --Avid Technology

>     For further proof of this, I've run Quartz Debug, one of Apple's 
>freely available dev tools, while playing a movie in VLC while in 
>millions of colors.  After setting QB to "Flash Screen Updates", it 
>is quite clear that the VLC video window is not updating at all via 
>Quartz.  The only time it will update is

What a coincidence, we don't use Quartz. Quartz would be painfully 
slow for what we do, and we use hardware acceleration provided by 
QuickTime. That means that in the normal course of operations, the OS 
doesn't even know a picture is displayed, it is directly written in 
VRAM.

>when a dynamic Quartz element, most clearly and easily demonstrated 
>by a dropshadow, is dragged over the video window, forcing Quartz to 
>render the image of all elements below the dropshadow.  However, 
>leaving a window with dropshadow in place, motionless, over the 
>video window will not result in an refresh of either the video 
>window or the dropshadow.  Picking the "Autoflush drawing" option in 
>QB, with "flash" turned off, will allow the video to display in 
>millions of colors.   It also runs at a noticeably slower framerate 
>than normal (perhaps 15-20 frames per second).  Switching to 
>thousands of colors and running

Sure, when you force the OS to do software rendering instead of 
hardware rendering, it works. Of course it is much slower, that's why 
we don't want to use software rendering. Oh, and your experiment only 
shows there is a problem with hardware rendering, which is done by 
QuickTime.

Of course the problem may be in the way VLC sends parameters to 
QuickTime. I have spent many hours on this, trying everything I 
could, and with the documentation I have (which is very sparse, thank 
you Apple) I don't see what we could be doing wrong.

For the time being, I don't see what I can do to solve this bug, and 
I won't keep fighting the wind any longer. Since QuickTime is not 
open source, and its documentation is even worse than what the worse 
open source project provides, I can't prove you it is a bug in 
QuickTime. I have sent a mail to the quicktime-api mailing-list, I 
hope Apple will confirm what I say, or tell me what's wrong with VLC.

If people want to look at the code to find a hypothetic bug in VLC, 
that's fine with me. In fact I'd be very glad if the bug could be in 
VLC, because that means we could fix it. However, with information I 
have at hand, I'm almost convinced the issue is in QT6.

I may sound a little upset in this mail (nothing personal, be 
reassured). The reason I'm currently pissed off is that OS X users, 
when facing a bug involving beta, not-for-production Apple software, 
and an open-source application whose bugs everyone can look for, 
automatically think that Apple is right and that we, poor hackers, 
are wrong. Don't people read the readme file ? QuickTime 6 Preview 
*contains bugs* and *is not for production purposes*, even Apple says 
it, why do people keep complaining to us, and not to Apple ?

BTW, I hope you don't mind if I Cc: to the mailing-list, as I think a 
lot of information in this mail may be interesting for other OS X 
users.

>     On an unrelated note, I have been able to open SVCDs directly 
>via the "Open Disc" command fairly reliably since some of the later 
>0.3.1 builds.  Why does the Read Me still state you must copy over 
>the MPEG-2 files and view them from your HD?  Admittedly, sometimes 
>the disc won't play on the first iteration of the "Open Disc" 
>command, and other times it may not start exactly from the start of 
>the disc (perhaps jumping 5-30 seconds into the movie), but very 
>rarely does it not work after 3 or 4 tries.  The lack of consistency 
>may be related the bug report I had posted a month or so ago, with 
>the three or four different errors early VLC 0.3.1 builds were 
>giving me.

We haven't announced SVCD support yet, because we haven't tested it 
(we only have one SVCD, and this one showed significant problems). 
I'm glad to hear it works for you.

-- 
Christophe Massiot.

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>