XOverlay lost after setting playbin state to Null

[Ralph]

dhoyt wrote
> 
> Try the following pipelines: 
> 
> gst-launch playbin2 uri=http://ralphos.com/video/test1.avi
> video-sink=dshowvideosink
> 
> gst-launch playbin2 uri=http://ralphos.com/video/test1.avi
> video-sink=d3dvideosink
> 
> gst-launch playbin2 uri=http://ralphos.com/video/test1.avi
> video-sink="d3dvideosink force-aspect-ratio=true"
> 
> Both those seem to be exactly alike. I see no black bars added to the
> video. Now the video *itself* has black bars on the side and bottom -- but
> that's got nothing to do with the video sink. Both behave exactly the
> same. d3dvideosink does have a force-aspect-ratio property you can use,
> but by default it should stretch to the window it's in (in each one of
> those example pipelines, try resizing the window during playback).
> 


The dshowvideosink pipeline produces 5:4 video, and when I set
force-aspect-ratio to true, the window can be resized and the aspect ratio
of the video doesn't change.
Both d3dvideosink pipelines produce 4:3 video, the second one forces the
wrong aspect ratio when I resize the window.  There is definitely something
wrong with d3dvideosink on my machine.  If I could only zip or rar my
machine and send it to you... ;-)




dhoyt wrote
> 
>  You might want to examine your application's code and see if it's not
> doing something to cause the problem you're seeing.
> 


I turned off absolutely everything that might have any influence.  Still no
change...




dhoyt wrote
> 
> Sounds like an issue either with the direct 3d driver for your card or
> your application. How are you doing "full screen"? I don't recommend using
> a direct x style full screen -- instead create a normal window that fills
> the screen and use xoverlay to place the video in the appropriate window.
> My app takes over every monitor attached to a system -- so that's
> typically 2, 3, or 4 at a time w/ 4-5 videos running on each screen and
> never had a problem. It's likely your app that's the issue. I can't rule
> out a bug, but I can point to very similar scenarios where it's known to
> be working...so it's more unlikely it's on the d3dvideosink end. However,
> since it's working with other video sinks, it's definitely suspect. But,
> directdrawsink uses an older technology and direct show, if my memory
> serves me right, will fall back to direct draw if necessary.
> 


I'm doing it as you say - I create a borderless window and make it full
screen.  I've just discovered that if I display the window in Normal state
and resize it to fill the entire screen, then there is no problem.  It is
setting the window state to FullScreen that causes problems.  Fortunately
there is a workaround, but it is interesting why FullScreen state has any
influence on displaying video, xoverlay gets the same handle to the same
window.




dhoyt wrote
> 
> What OS are you running this on? If it's Win XP, try re-running your app
> w/ the same setup but in Win 7 and see how well it does. It's my
> experience that manufacturer direct 3d drivers seem to be better w/ Win 7.
> 


I'm testing d3dvideosink with same results on two different machines:

1. Highly customised Dell PC
System: Windows7 Ultimate 64-bit SP1.
Graphics: ATI Radeon HD 5670.

2. Avent 4211-B netbook
System: Windows 7 Professional 32-bit
Graphics: Mobile Intel 945 Express


--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/XOverlay-lost-after-setting-playbin-state-to-NULL-or-READY-tp4115442p4159853.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.