|
List Info
Thread: Re: Re: corrupt colour output with Xvideo
|
|
| Re: Re: corrupt colour output with
Xvideo |
 
United Kingdom |
2007-03-07 07:21:30 |
>> The only difference I see below is that you are
offsetting the
>> video when in full screen (drw_y=85). See if you
can make sure
>> that the scaled size is *always*:
>>
>> width: a multiple of 4
>> height: a multiple of 2.
ok, a little clarification:
#-----------------------------------------------------------
------------
-------
# A small clip (small screensize (400x224) - smaller than my
display
which is set to 720x576))
#
rtsp://rmv8.bbc.net.uk/news/olmedia/n5ctrl/summaries/weather
/
hc_weather_uk_bb.rm
uses Xv with:
via_video.c : viaPutImage : called
via_video.c : FourCC=0x32315659 width=400
height=224 sync=1
via_video.c : src_x=0 src_y=0 src_w=400 src_h=224
colorkey=0x1010
via_video.c : drw_x=0 drw_y=0 drw_w=400
drw_h=224
pressing fs+ give me the picture at fullscreen
(colours are now
corrected, and Xv is still being used):
via_video.c : viaPutImage : called
via_video.c : FourCC=0x32315659 width=400
height=224 sync=1
via_video.c : src_x=0 src_y=0 src_w=400 src_h=224
colorkey=0x1010
via_video.c : drw_x=0 drw_y=86 drw_w=720
drw_h=403
pressing fs- give me the picture at it's native size
(colours are
messed up again, and Xv is still being used).
#-----------------------------------------------------------
------------
-------
# A much larger clip (large screensize (1280x720) - larger
than my
display which is set to 720x576)
# rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
Madagascar.rm?screensize=full
uses Xv with:
via_video.c : viaPutImage : called
via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
via_video.c : src_x=0 src_y=0 src_w=1280 src_h=720
colorkey=0x1010
via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
pressing fs+ give me the picture at fullscreen
(colours
are now corrected, and Xv is still being used):
via_video.c : viaPutImage : called
via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
via_video.c : src_x=0 src_y=0 src_w=1280 src_h=720
colorkey=0x1010
via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
pressing fs- give me the picture at it's native size
(colours are messed up again, and Xv is still being
used).
#-----------------------------------------------------------
------------
-------
# A much larger clip (large screensize (1280x720) - larger
than my
display which is set to 720x576)
# rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
Madagascar.rm?screensize=full
# with wallpapermode=1 preference set
does not play through Xv and I see no output at all
pressing fs+ give me the picture at fullscreen with
correct
colout output (Xv is still not used)
pressing fs- give me the picture at it's native size
with
correct colout output (Xv is still not used)
What can we deduce from this?
1) Shrinking a large clip to fit the screen will correct the
Xv
colour problem.
2) Scaling a clip up to fill the screen has no effect on the
Xv
colour problem
3) Clips over a certain size will not play through Xv (I'm
not sure
what the cut off point is, but a 1280x720 clip reverts to
some other
output method even though xvinfo reports "maximum
XvImage size: 1920
x 1200").
5) Shrinking a large clip will not get you Xv support back
if it has
already been denied due to the clip being too large.
4) When wallpapermode=1 is set for a large clip, there is no
output
(except a black screen)
4a) Pressing fs+ will get you the video output, scaled to
fill the
screen (no Xv)
4b) Pressing fs- (after fs+) will get you the video
output at it's
native size (no Xv)
On 7 Mar 2007, at 12:04, Tom Kirkpatrick wrote:
> After many hours of searching last night, I thought I
had come
> across the solution, but alas, it turns out I was
wrong. I had read
> a few reports of similar behavior from mplayer, which
had been
> fixed by ensuring that the XV attribute
XV_AUTOPAINT_COLORKEY was
> set correctly. Unfortunately, it was only after writing
a patch and
> finding out that it didn't fix my problem that I found
further,
> more detailed reports describing the mplayer problem
(and fix) futher.
>
> The actual issue with mplayer, was that it was assuming
that
> XV_AUTOPAINT_COLORKEY was set to 1, and so if it
wasn't, for one
> reason or another (some graphics devices have this set
to 0 by
> default, or another program may have altered the value)
then no
> video would be rendered to the overlay except for a
black window
> (or a window the colour of XV_COLORKEY).
>
> I then stumbled across this bug report in the Helix bug
tracker,
> which describes the exact same thing:
>
> https://bugs.helixcommunity.org/show_bug.cgi?id=3
465&link=0
>
> Attached is the patch I wrote which addresses that bug,
although my
> patch does not go the whole hog and save the original
value of
> XV_AUTOPAINT_COLORKEY and restore it when helix exits.
>
> So. I'm still left with a broken Xv. I have tried
setting the
> following preferences, with no effect (except for
yuy2first=1
> causing a segfault - but I was unable to attache gdb on
the target
> machine):
>
> I420First=1
> YV12First=1
> YUY2First=1
> UYVYFirst=1
> YVU9First=1
>
>> The only difference I see below is that you are
offsetting the
>> video when in full screen (drw_y=85). See if you
can make sure
>> that the scaled size is *always*:
>>
>> width: a multiple of 4
>> height: a multiple of 2.
> My screen size is set to 720x576, which does already
agree with
> those multiple factors, and I can't see how that would
be any
> different when scaling a clip up, to when shrinking.
All I can
> think on that front is that when fullscreen mode is
being entered
> on those larger clips (where a scale down is
happening), for one
> reason or another, xv is not being used at all for the
output.
>
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>
> I'm not sure I understand these values correctly.
drw_y=85 looks to
> be a y offset. Where does this value come from? Why is
it being
> offset at all? and where does drw_h=405 come from?
>
> Any other suggestions are welcome! This one is really
starting to
> do my head in now, Performance is just not acceptable
without Xv
> acceleration.
>
> I also noticed that if if I start mplayer first, and
then run Helix
> whilst mplayer is still running, then Helix gets the
colours right.
> I put this down to the fact that when mplayer has a a
grip on the
> Xv port, Helix defaults to another output method. Is
this a correct
> assumption?
>
>
>
> diff -Naur splay/video/sitelib/basesurf.cpp
work/i586-sts-linux/
>
stshelix-libs-2.0.3+svn20070305-r0/splay/video/sitelib/bases
urf.cpp
> --- splay/video/sitelib/basesurf.cpp 2007-01-27
> 00:42:57.000000000 +0000
> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
> video/sitelib/basesurf.cpp 2007-03-07
11:36:39.000000000 +0000
>  -3943,6 +3943,7
> _SetColorKey(m_convertedOverlayColor,
m_convertedOverlayColor);
> + _SetAutopaintColorkey(1);
> INT32 flags = HX_OVER_KEYDEST;
> if ( (destRect.right - destRect.left) < 0 ||
(destRect.bottom
> - destRect.top) < 0 )
> diff -Naur
splay/video/sitelib/platform/unix/unixsurf.cpp work/i586-
>
sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay/video/sit
elib/
> platform/unix/unixsurf.cpp
> --- splay/video/sitelib/platform/unix/unixsurf.cpp
2006-11-07
> 23:02:05.000000000 +0000
> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
> video/sitelib/platform/unix/unixsurf.cpp
2007-03-07
> 11:36:39.000000000 +0000
> -81,6 +81,7
> , m_bStretchToFill(FALSE)
> , m_pXvImage(NULL)
> , m_atomColorKey(None)
> + , m_atomAutopaintColorkey(None)
> , m_atomClipKey(None)
> #if defined(HELIX_FEATURE_HARDWARE_COLOR_CONTROLS)
> , m_atomBrightness(None)
> -643,6 +644,18
> m_atomColorKey =
XInternAtom(m_display,
> "XV_COLORKEY", True);
> XUnlockDisplay(m_display);
> }
> +
> + XLockDisplay(m_display);
> + m_atomAutopaintColorkey =
XInternAtom(m_display,
> "XV_AUTOPAINT_COLORKEY", True);
> + XUnlockDisplay(m_display);
> + if( m_atomAutopaintColorkey == None )
> + {
> + //There isn't a naming convention
for any of
> these atoms. we
> + //have to disover at run time what
they are.
> + XLockDisplay(m_display);
> + m_atomAutopaintColorkey =
XInternAtom
> (m_display, "XV_AUTOPAINT_COLOURKEY", True);
> + XUnlockDisplay(m_display);
> + }
> XLockDisplay(m_display);
> m_atomClipKey =
XInternAtom(m_display,
> "XV_PAINT_CLIPLIST", True);
> XUnlockDisplay(m_display);
> -825,6 +838,25
> #endif
> }
> +void CUnixSurf::_SetAutopaintColorkey(int Autopaint)
> +{
> +#if defined(_LINUX) && defined(_OVERLAY)
> +
> + static HXBOOL bDoneItAlready = FALSE;
> +
> + if( m_atomAutopaintColorkey != None &&
!bDoneItAlready)
> + {
> + //The user did not set an autopaint color key
preference...
> + XLockDisplay(m_display);
> + XvSetPortAttribute( m_display, m_nPortID,
> m_atomAutopaintColorkey, Autopaint );
> + XUnlockDisplay(m_display);
> + bDoneItAlready = TRUE;
> + }
> +#endif
> +}
> +
> +
> +
> static HXBOOL CheckIt(Display* dis, XEvent* event,
XPointer arg)
> {
> HXBOOL ret = (event->type==(int)arg);
> diff -Naur splay/video/sitelib/pub/basesurf.h
work/i586-sts-linux/
>
stshelix-libs-2.0.3+svn20070305-r0/splay/video/sitelib/pub/b
asesurf.h
> --- splay/video/sitelib/pub/basesurf.h 2007-01-24
> 19:20:39.000000000 +0000
> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
> video/sitelib/pub/basesurf.h 2007-03-07
11:36:39.000000000 +0000
> -580,6 +580,14
> */
> virtual void _SetColorKey(INT32
nColorSpaceLowValue, INT32
> nColorSpaceHighValue) = 0;
> + /
>
************************************************************
**********
> **
> + * Method:
> + * _SetAutopaintColorkey
> + * Purpose:
> + * Set the overlay's autopaint color key
switch.
> + * This may not be applicable on some
platforms.
> + */
> + virtual void _SetAutopaintColorkey(int Autopaint)
= 0;
> /
>
************************************************************
**********
> **
> * Method:
> diff -Naur
splay/video/sitelib/pub/platform/unix/unixsurf.h work/
>
i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay/vide
o/
> sitelib/pub/platform/unix/unixsurf.h
> --- splay/video/sitelib/pub/platform/unix/unixsurf.h
2007-02-26
> 10:22:20.000000000 +0000
> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
> video/sitelib/pub/platform/unix/unixsurf.h
2007-03-07
> 11:36:39.000000000 +0000
> -122,6 +122,7
> virtual INT32 _InsureColorMatch(INT32
InColor);
> virtual void _SetColorKey(INT32
nColorSpaceLowValue,
> INT32
nColorSpaceHighValue);
> + virtual void _SetAutopaintColorkey(int
Autopaint);
> virtual void _UpdateOverlay(HXxRect* src,
HXxRect* dest,
> INT32 inFlags);
> virtual HXBOOL _IsSurfaceVisible();
> virtual void _ReleaseSurface();
> -161,6 +162,7
> INT32 m_nPortID;
> XvImage** m_pXvImage;
> Atom m_atomColorKey;
> + Atom m_atomAutopaintColorkey;
> Atom m_atomClipKey;
>
>
> On 6 Mar 2007, at 18:58, Greg Wright wrote:
>
>> Tom Kirkpatrick wrote:
>>> Interestingly, I have managed to find two clips
which is able to
>>> be played without corrupt colours:
>>>
rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
>>> SkeletonKey_HD.rm?screensize=full
rtsp://212.70.64.60/
>>>
realdemo/Internet_HD/media/video/HD/Madagascar.rm?screensize
=full
>>> When the clip first starts to play, the colours
are all garbled.
>>> But if I then enter fullscreen mode (fs+) then
when the clip
>>> shrinks to fit in the screen (that clip is
1280x720, where as my
>>> screen res is set to 720x576) the colour output
is corrected.
>>> Leaving fullscreen mode (fs-) screws the
colours up once again.
>>> It seems to only be clips which are downsized
when entering
>>> fullscreen mode that get their colours
corrected by the use of
>>> fullscreen mode. Smaller clips which get
stretched to fill the
>>> screen do not get fixed by entering fullscreen
mode.
>>
>> Perhaps your XVideo driver doesn't like to use
overlays when the
>> video is shrinking. That use to be a problem with
many old video
>> drivers. However, since you say that smaller clips
that are stretched
>> still look bad, I am not sure that is it.
>>
>> The only difference I see below is that you are
offsetting the
>> video when in full screen (drw_y=85). See if you
can make sure
>> that the scaled size is *always*:
>>
>> width: a multiple of 4
>> height: a multiple of 2.
>>
>> YUV formats are sensitive to that.
>>
>> --greg.
>>
>>
>>> Below is the output from Xv debug before and
after entering
>>> fullscreen mode with one of the above clips.
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>> fs+
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>>> via_video.c : viaPutImage : called
>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>
> ---
> Tom Kirkpatrick
> Platforms Director
> Settop Solutions
>
> tomsettopsolutions.com
>
>
>
---
Tom Kirkpatrick
Platforms Director
Settop Solutions
tomsettopsolutions.com
_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|
|
| Re: Re: corrupt colour output with
Xvideo |
United Kingdom |
2007-03-07 13:01:20 |
well.. After two days of furious hunting, I finally have it
Basically, it's part of
HELIX_FEATURE_HARDWARE_COLOR_CONTROLS thats
screwing up my graphics device output. Where it attempts to
set the
XV_SATURATION attribute (which it tries to do pretty much
every
single blt - is this really necessary?), it uses a
subroutine called
_scaleIt, which ensures that the saturation value is within
the valid
range (which it finds out by probing the device). This
routine was
missing return statement and that was causing the
XV_SATURATION
attribute to be set to an invalid value - screwing up the
colours:
diff -Naur splay/video/sitelib/platform/unix/unixsurf.cpp
splay-
patched/video/sitelib/platform/unix/unixsurf.cpp
--- splay/video/sitelib/platform/unix/unixsurf.cpp
2007-03-07
18:20:43.000000000 +0000
+++ splay-patched/video/sitelib/platform/unix/unixsurf.cpp
2007-03-07 18:12:47.000000000 +0000
-871,6
+839,7
nRetVal = at.nMinValue;
if( nRetVal > at.nMaxValue )
nRetVal = at.nMaxValue;
+ return nRetVal;
}
HXBOOL CUnixSurf::HasHWColorConrols()
All that work for 1 missing line of code... unbelievable!!
Can someone apply this to the trunk please?
many thanks
Tom
On 7 Mar 2007, at 13:21, Tom Kirkpatrick wrote:
>>> The only difference I see below is that you are
offsetting the
>>> video when in full screen (drw_y=85). See if
you can make sure
>>> that the scaled size is *always*:
>>>
>>> width: a multiple of 4
>>> height: a multiple of 2.
>
> ok, a little clarification:
>
>
#-----------------------------------------------------------
----------
> ---------
> # A small clip (small screensize (400x224) - smaller
than my
> display which is set to 720x576))
> #
rtsp://rmv8.bbc.net.uk/news/olmedia/n5ctrl/summaries/weather
/
> hc_weather_uk_bb.rm
>
> uses Xv with:
> via_video.c : viaPutImage : called
> via_video.c : FourCC=0x32315659 width=400
height=224 sync=1
> via_video.c : src_x=0 src_y=0 src_w=400
src_h=224
> colorkey=0x1010
> via_video.c : drw_x=0 drw_y=0 drw_w=400
drw_h=224
>
> pressing fs+ give me the picture at fullscreen
(colours are now
> corrected, and Xv is still being used):
> via_video.c : viaPutImage : called
> via_video.c : FourCC=0x32315659 width=400
height=224 sync=1
> via_video.c : src_x=0 src_y=0 src_w=400
src_h=224
> colorkey=0x1010
> via_video.c : drw_x=0 drw_y=86 drw_w=720
drw_h=403
>
> pressing fs- give me the picture at it's native
size (colours are
> messed up again, and Xv is still being used).
>
>
>
#-----------------------------------------------------------
----------
> ---------
> # A much larger clip (large screensize (1280x720) -
larger than my
> display which is set to 720x576)
> #
rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
> Madagascar.rm?screensize=full
>
> uses Xv with:
> via_video.c : viaPutImage : called
> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720
> colorkey=0x1010
> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>
> pressing fs+ give me the picture at fullscreen
(colours
> are now corrected, and Xv is still being used):
> via_video.c : viaPutImage : called
> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720
> colorkey=0x1010
> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>
> pressing fs- give me the picture at it's native
size
> (colours are messed up again, and Xv is still
being used).
>
>
>
#-----------------------------------------------------------
----------
> ---------
> # A much larger clip (large screensize (1280x720) -
larger than my
> display which is set to 720x576)
> #
rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
> Madagascar.rm?screensize=full
> # with wallpapermode=1 preference set
>
> does not play through Xv and I see no output at
all
> pressing fs+ give me the picture at fullscreen with
correct
> colout output (Xv is still not used)
> pressing fs- give me the picture at it's native
size with
> correct colout output (Xv is still not used)
>
>
> What can we deduce from this?
>
> 1) Shrinking a large clip to fit the screen will
correct the Xv
> colour problem.
>
> 2) Scaling a clip up to fill the screen has no effect
on the Xv
> colour problem
>
> 3) Clips over a certain size will not play through Xv
(I'm not sure
> what the cut off point is, but a 1280x720 clip reverts
to some
> other output method even though xvinfo reports
"maximum XvImage
> size: 1920 x 1200").
>
> 5) Shrinking a large clip will not get you Xv support
back if it
> has already been denied due to the clip being too
large.
>
> 4) When wallpapermode=1 is set for a large clip, there
is no output
> (except a black screen)
> 4a) Pressing fs+ will get you the video output,
scaled to fill
> the screen (no Xv)
> 4b) Pressing fs- (after fs+) will get you the video
output at
> it's native size (no Xv)
>
>
> On 7 Mar 2007, at 12:04, Tom Kirkpatrick wrote:
>
>> After many hours of searching last night, I thought
I had come
>> across the solution, but alas, it turns out I was
wrong. I had
>> read a few reports of similar behavior from
mplayer, which had
>> been fixed by ensuring that the XV attribute
XV_AUTOPAINT_COLORKEY
>> was set correctly. Unfortunately, it was only after
writing a
>> patch and finding out that it didn't fix my problem
that I found
>> further, more detailed reports describing the
mplayer problem (and
>> fix) futher.
>>
>> The actual issue with mplayer, was that it was
assuming that
>> XV_AUTOPAINT_COLORKEY was set to 1, and so if it
wasn't, for one
>> reason or another (some graphics devices have this
set to 0 by
>> default, or another program may have altered the
value) then no
>> video would be rendered to the overlay except for a
black window
>> (or a window the colour of XV_COLORKEY).
>>
>> I then stumbled across this bug report in the Helix
bug tracker,
>> which describes the exact same thing:
>>
>> https://bugs.helixcommunity.org/show_bug.cgi?id=3
465&link=0
>>
>> Attached is the patch I wrote which addresses that
bug, although
>> my patch does not go the whole hog and save the
original value of
>> XV_AUTOPAINT_COLORKEY and restore it when helix
exits.
>>
>> So. I'm still left with a broken Xv. I have tried
setting the
>> following preferences, with no effect (except for
yuy2first=1
>> causing a segfault - but I was unable to attache
gdb on the target
>> machine):
>>
>> I420First=1
>> YV12First=1
>> YUY2First=1
>> UYVYFirst=1
>> YVU9First=1
>>
>>> The only difference I see below is that you are
offsetting the
>>> video when in full screen (drw_y=85). See if
you can make sure
>>> that the scaled size is *always*:
>>>
>>> width: a multiple of 4
>>> height: a multiple of 2.
>> My screen size is set to 720x576, which does
already agree with
>> those multiple factors, and I can't see how that
would be any
>> different when scaling a clip up, to when
shrinking. All I can
>> think on that front is that when fullscreen mode is
being entered
>> on those larger clips (where a scale down is
happening), for one
>> reason or another, xv is not being used at all for
the output.
>>
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>>
>> I'm not sure I understand these values correctly.
drw_y=85 looks
>> to be a y offset. Where does this value come from?
Why is it being
>> offset at all? and where does drw_h=405 come from?
>>
>> Any other suggestions are welcome! This one is
really starting to
>> do my head in now, Performance is just not
acceptable without Xv
>> acceleration.
>>
>> I also noticed that if if I start mplayer first,
and then run
>> Helix whilst mplayer is still running, then Helix
gets the colours
>> right. I put this down to the fact that when
mplayer has a a grip
>> on the Xv port, Helix defaults to another output
method. Is this a
>> correct assumption?
>>
>>
>>
>> diff -Naur splay/video/sitelib/basesurf.cpp
work/i586-sts-linux/
>>
stshelix-libs-2.0.3+svn20070305-r0/splay/video/sitelib/bases
urf.cpp
>> --- splay/video/sitelib/basesurf.cpp 2007-01-27
>> 00:42:57.000000000 +0000
>> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
>> video/sitelib/basesurf.cpp 2007-03-07
11:36:39.000000000 +0000
>> -3943,6 +3943,7
>> _SetColorKey(m_convertedOverlayColor,
m_convertedOverlayColor);
>> + _SetAutopaintColorkey(1);
>> INT32 flags = HX_OVER_KEYDEST;
>> if ( (destRect.right - destRect.left) < 0
|| (destRect.bottom
>> - destRect.top) < 0 )
>> diff -Naur
splay/video/sitelib/platform/unix/unixsurf.cpp work/
>>
i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay/vide
o/
>> sitelib/platform/unix/unixsurf.cpp
>> --- splay/video/sitelib/platform/unix/unixsurf.cpp
2006-11-07
>> 23:02:05.000000000 +0000
>> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
>> video/sitelib/platform/unix/unixsurf.cpp
2007-03-07
>> 11:36:39.000000000 +0000
>> -81,6 +81,7
>> , m_bStretchToFill(FALSE)
>> , m_pXvImage(NULL)
>> , m_atomColorKey(None)
>> + , m_atomAutopaintColorkey(None)
>> , m_atomClipKey(None)
>> #if defined(HELIX_FEATURE_HARDWARE_COLOR_CONTROLS)
>> , m_atomBrightness(None)
>> -643,6 +644,18
>> m_atomColorKey =
XInternAtom(m_display,
>> "XV_COLORKEY", True);
>> XUnlockDisplay(m_display);
>> }
>> +
>> + XLockDisplay(m_display);
>> + m_atomAutopaintColorkey =
XInternAtom(m_display,
>> "XV_AUTOPAINT_COLORKEY", True);
>> + XUnlockDisplay(m_display);
>> + if( m_atomAutopaintColorkey ==
None )
>> + {
>> + //There isn't a naming
convention for any of
>> these atoms. we
>> + //have to disover at run time
what they are.
>> + XLockDisplay(m_display);
>> + m_atomAutopaintColorkey =
XInternAtom
>> (m_display, "XV_AUTOPAINT_COLOURKEY",
True);
>> + XUnlockDisplay(m_display);
>> + }
>> XLockDisplay(m_display);
>> m_atomClipKey =
XInternAtom(m_display,
>> "XV_PAINT_CLIPLIST", True);
>> XUnlockDisplay(m_display);
>> -825,6 +838,25
>> #endif
>> }
>> +void CUnixSurf::_SetAutopaintColorkey(int
Autopaint)
>> +{
>> +#if defined(_LINUX) && defined(_OVERLAY)
>> +
>> + static HXBOOL bDoneItAlready = FALSE;
>> +
>> + if( m_atomAutopaintColorkey != None &&
!bDoneItAlready)
>> + {
>> + //The user did not set an autopaint color
key preference...
>> + XLockDisplay(m_display);
>> + XvSetPortAttribute( m_display, m_nPortID,
>> m_atomAutopaintColorkey, Autopaint );
>> + XUnlockDisplay(m_display);
>> + bDoneItAlready = TRUE;
>> + }
>> +#endif
>> +}
>> +
>> +
>> +
>> static HXBOOL CheckIt(Display* dis, XEvent* event,
XPointer arg)
>> {
>> HXBOOL ret = (event->type==(int)arg);
>> diff -Naur splay/video/sitelib/pub/basesurf.h
work/i586-sts-linux/
>>
stshelix-libs-2.0.3+svn20070305-r0/splay/video/sitelib/pub/b
asesurf.h
>> --- splay/video/sitelib/pub/basesurf.h 2007-01-24
>> 19:20:39.000000000 +0000
>> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
>> video/sitelib/pub/basesurf.h 2007-03-07
11:36:39.000000000 +0000
>> -580,6 +580,14
>> */
>> virtual void _SetColorKey(INT32
nColorSpaceLowValue, INT32
>> nColorSpaceHighValue) = 0;
>> + /
>>
************************************************************
*********
>> ***
>> + * Method:
>> + * _SetAutopaintColorkey
>> + * Purpose:
>> + * Set the overlay's autopaint color key
switch.
>> + * This may not be applicable on some
platforms.
>> + */
>> + virtual void _SetAutopaintColorkey(int
Autopaint) = 0;
>> /
>>
************************************************************
*********
>> ***
>> * Method:
>> diff -Naur
splay/video/sitelib/pub/platform/unix/unixsurf.h work/
>>
i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay/vide
o/
>> sitelib/pub/platform/unix/unixsurf.h
>> ---
splay/video/sitelib/pub/platform/unix/unixsurf.h
2007-02-26
>> 10:22:20.000000000 +0000
>> +++
work/i586-sts-linux/stshelix-libs-2.0.3+svn20070305-r0/splay
/
>> video/sitelib/pub/platform/unix/unixsurf.h
2007-03-07
>> 11:36:39.000000000 +0000
>> -122,6 +122,7
>> virtual INT32 _InsureColorMatch(INT32
InColor);
>> virtual void _SetColorKey(INT32
nColorSpaceLowValue,
>> INT32
nColorSpaceHighValue);
>> + virtual void _SetAutopaintColorkey(int
Autopaint);
>> virtual void _UpdateOverlay(HXxRect* src,
HXxRect* dest,
>> INT32 inFlags);
>> virtual HXBOOL _IsSurfaceVisible();
>> virtual void _ReleaseSurface();
>> -161,6 +162,7
>> INT32 m_nPortID;
>> XvImage** m_pXvImage;
>> Atom m_atomColorKey;
>> + Atom m_atomAutopaintColorkey;
>> Atom m_atomClipKey;
>>
>>
>> On 6 Mar 2007, at 18:58, Greg Wright wrote:
>>
>>> Tom Kirkpatrick wrote:
>>>> Interestingly, I have managed to find two
clips which is able to
>>>> be played without corrupt colours:
>>>>
rtsp://212.70.64.60/realdemo/Internet_HD/media/video/HD/
>>>> SkeletonKey_HD.rm?screensize=full
rtsp://212.70.64.60/
>>>>
realdemo/Internet_HD/media/video/HD/Madagascar.rm?
>>>> screensize=full When the clip first starts
to play, the colours
>>>> are all garbled. But if I then enter
fullscreen mode (fs+) then
>>>> when the clip shrinks to fit in the screen
(that clip is
>>>> 1280x720, where as my screen res is set to
720x576) the colour
>>>> output is corrected. Leaving fullscreen
mode (fs-) screws the
>>>> colours up once again. It seems to only be
clips which are
>>>> downsized when entering fullscreen mode
that get their colours
>>>> corrected by the use of fullscreen mode.
Smaller clips which get
>>>> stretched to fill the screen do not get
fixed by entering
>>>> fullscreen mode.
>>>
>>> Perhaps your XVideo driver doesn't like to use
overlays when the
>>> video is shrinking. That use to be a problem
with many old video
>>> drivers. However, since you say that smaller
clips that are
>>> stretched
>>> still look bad, I am not sure that is it.
>>>
>>> The only difference I see below is that you are
offsetting the
>>> video when in full screen (drw_y=85). See if
you can make sure
>>> that the scaled size is *always*:
>>>
>>> width: a multiple of 4
>>> height: a multiple of 2.
>>>
>>> YUV formats are sensitive to that.
>>>
>>> --greg.
>>>
>>>
>>>> Below is the output from Xv debug before
and after entering
>>>> fullscreen mode with one of the above
clips.
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=0 drw_w=1280
drw_h=720
>>>> fs+
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
>>>> via_video.c : viaPutImage : called
>>>> via_video.c : FourCC=0x32315659 width=1280
height=720 sync=1
>>>> via_video.c : src_x=0 src_y=0 src_w=1280
src_h=720 colorkey=0x1010
>>>> via_video.c : drw_x=0 drw_y=85 drw_w=720
drw_h=405
_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|
|
[1-2]
|
|