SGI: Video

mplayer glitch

In general, Mplayer on Irix works great. But there's a few videos that do this ....

It's almost right ... sound is perfect. Where should I start looking to see why some video has this not-quite-synched-up stripe pattern ?
In my experience -vo gl2 is a workaround for this problem.
:Tezro: :Fuel: :Octane2: :Octane: :Onyx2: :O2+: :O2: :Indy: :Indigo: :Cube:
diegel wrote: In my experience -vo gl2 is a workaround for this problem.


Oooh. Nice, thanks ... fixed about half of my problem videos ...

What is the reasoning behind the various output options ? I've been using vo=sgi:textures:softcs and that's worked well on most videos. Is OpenGL always better if you have that option ? Since SGI does OpenGL in hardware, would you think it should normally be a better choice for us ?


Edit: Okay le, did a little testing. Thanks for the pointer to gl2, I had lazily assumed that once you found settings that worked, they would work across the board. So, for posterity ...


With the nekochan version of Mplayer, there are several output options. You can set defaults in $home/.mplayer/config. I usually watch a video by just dragging the file icon over the mplayer icon. This is a case where the workplace shell would be great - make three or four copies of the mplayer object and change the parameters of each one. Viola (don't call me Shirley), you can easily run different videos with different settings. MaxxDesktop with Porter's SOM would be the best desktop ever for Loonix. Oh well.

Anyhow, I ran the same video through the five or six useful ones : < mplayer -vo help > (turning a video into tiffs was not what I want to do at the moment, but might be worth looking into for screenshots - like when Michael Douglas lost the purse going over the falls, but there it was in the next scene and you want to pick up the frame that you know shows it flying through the air).

vo = sgi is opengl, seems the sharpest and least dropped frames
vo=gl is opengl, I can't see much difference but may as well go with the sgi-optimized version
vo=gl2 is not as sharp but as diegel points out, other output options might solve problems with display of some videos
vo=sdl is not as good, in fact I saw a lot of dropped frames on several videos. But again, it may work in certain instances. Plus it's good for testing neko_sdl :)
vo=aa is kind of interesting but not very useful, except for a special effect sometimes. Try it, it's kind of a trip :D

The lesson, thanks to Mr Diegel, is to not get lazy and assume that your output options are the best for every video. If there are display problems, one of the other choices may solve the problem for that video .
*looool* is this rick james?? :lol:
no plan
yetanother**ixuser wrote: *looool* is this rick james?? :lol:

Arthur Lee ... different personality, different music, similar taste in clothes :P
What is the version of the MPlayer? :)
:1600SW: :320: :Octane: :Indigo2: :Indigo2IMP: :O200: -CrayLink- :O200:
Sold: :Indy: :O2: :O2+: :Fuel:
To speak on some of these settings...
-vo sgi tells it to use our (made here at nekochan largely) SGI output plugin...
:textures is telling it to use texturing (instead of blitting to the buffer), and :softcs tells it to use software (hand-optimized assembly) colorspace conversion.

Looking at the output video, it's an alignment issue.
I'm guessing it's an odd-width video (or non-multiple-of-4 or similar) and it's just a bug in the output plugin.