yesterday the guy I work with said : "see, there are horizontal bars
when it plays the video".
He was right: it's video tearing. I looked on the driver setup, there
are stuff like "Option tearfree", vblank syncing and stuff. It also
seems that it's ultimately the choice of the software to decide if it
adapts to vsync.
I did not try the fullscreen mode, because that's not exactly an option
at the moment (I need to hide the top of the window). Maybe with
shmout/shmin I can achieve something.
At the end of the day, I had nothing improved.
How does/can veejay deal with that ? Any clues welcome.
The setup:
- pc running archlinux
- video card is intel/nvidia hybrid, but I only use the Intel one. So
the Xorg driver is intel.
If the problem is gone in fullscreen, then shmin/out maybe a solution
Meanwhile, I reviewed SDL_VIDEO_GEOMETRY and _RESIZE,
there indeed is some confusement; GEOM is actually screen POSITION of the
video window, intended to be used with Twinview setups (single large
desktop)
I will implement a video clipping feature in the SDL video driver, but as
SDL can only display images this routine has to be done in software, once
that's done Fullscreen should be workable
On Tue, Oct 9, 2012 at 2:26 PM, Charles Goyard <c...@fsck.fr> wrote:
> Hi all,
> yesterday the guy I work with said : "see, there are horizontal bars
> when it plays the video".
> He was right: it's video tearing. I looked on the driver setup, there
> are stuff like "Option tearfree", vblank syncing and stuff. It also
> seems that it's ultimately the choice of the software to decide if it
> adapts to vsync.
> I did not try the fullscreen mode, because that's not exactly an option
> at the moment (I need to hide the top of the window). Maybe with
> shmout/shmin I can achieve something.
> At the end of the day, I had nothing improved.
> How does/can veejay deal with that ? Any clues welcome.
> The setup:
> - pc running archlinux
> - video card is intel/nvidia hybrid, but I only use the Intel one. So
> the Xorg driver is intel.
> Thanks,
> --
> Charles
> --
> You received this message because you are subscribed to the Google Groups
> "veejay-discussion" group.
> To post to this group, send email to veejay-discussion@googlegroups.com.
> To unsubscribe from this group, send email to
> veejay-discussion+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/veejay-discussion?hl=en.
Niels Elburg wrote:
> What does veejay say about the SDL configuration ? Perhaps it is
> running in software emulation mode instead of hardware accelerated ?
I don't know what to think:
I: Using output driver SDL
I: Setting up SDL with Hardware Acceleration
W: hw_surface = No
W: BLIT acceleration: No I: Initialized YUYV SDL video overlay (1024x880), using Hardware Acceleration
This is on my dev computer. I'll look on the production one tomorrow.
I get this whatever SDL tweaking I use. Same in full screen.
It's not that easy to see tearing when you look at it :) so I'll have to
do longer tests.
> I will implement a video clipping feature in the SDL video driver, but as
> SDL can only display images this routine has to be done in software, once
> that's done Fullscreen should be workable
Well, it seems opengl/mesa/dri are good at syncing to screen. Maybe
I can make a simple shm reader that puts the pixels on a 3D texture ?
Meanwhile, I committed a patch for VEEJAY_GET_IMAGE
If you export VEEJAY_ORIGINAL_FRAME=1,
the original video frame is kept in a temporary buffer,
which is returned from veejay_get_image_part,
It should be possible now to use the viewport.cfg for clipping
If you want to make a standalone gl display driver, that would be great!
You can look at lvd_shmin.c to see how you can read from veejay's shared
memory
> Did you find out more about the display problem ?
Not yet, I am focused on other (mechanical/electronics) problems with
the installation (opening December 6th).
> Meanwhile, I committed a patch for VEEJAY_GET_IMAGE
> If you export VEEJAY_ORIGINAL_FRAME=1,
> the original video frame is kept in a temporary buffer,
> which is returned from veejay_get_image_part,
> It should be possible now to use the viewport.cfg for clipping
Great, thanks a lot. I'll try that.
> If you want to make a standalone gl display driver, that would be great!
> You can look at lvd_shmin.c to see how you can read from veejay's shared
> memory
I'll see if this is needed or not, hopefully soon !
