vlc - "jerky" playback

[Guest]

I'm interested in finding a resolution in a visual artifact playback problem we've been seeing with VLC.

For example, observe this stream:

ftp://ftp.tek.com/tv/test/streams/Eleme ... ns_060.m2v

Note the picture on the wall when the camera starts to pan to the right. The jerkiness can be observed as the picture moves to the left of the screen.

I don't see any interesting debug messages (i.e. late pictures, etc.) when the -v3 log option is used. I tried:

- upgrading to vlc-0.7.0-test1

- upgrading libmpeg2 to version 0.4.0

and see no change.

I see this problem quite often while playing back mpeg2 program streams.

Using a modified version of mpeg2dec, however, one with changes introduced to limit the playback frame rate, these artifacts cannot be observed. This leads me to believe it is a clock/timing problem.

Any ideas? It's a bit annoying and we'd like to address it.

Thanks!

Regards,

Howard G Page

[Howard]

BTW, this is using Xvideo, RH9, NVidia GForce2 chipset and drivers from Nvidia.

More data:

I hacked video_output.c to play frames at a constant frame rate 41.666ms and the jerkyness is less but still visible.

I hacked up textxv.c, creating a standalone program display a set of frames consisting of a blue bar moving across the screen at 24 fps (with or with out a 2:3 pulldown simulation).

The jerkiness is still visible. Anyone out there an Xv expert?

Anyone care to take a look? I'll be more than happy to send you the standalone program if you wish.

Thanks.

Regards,

Howard

[Gibalou]

Afaik this comes from a desing problem in the Xv extension itself.
Problem is, when you use Xv/XvShmPutImage() to overlay your picture on the screen, you don't exactly know when Xv will actually display it for the simple reason that the Xv picture buffers do reside in system memory and they first need to be copied to the graphics card memory as an overlay backbuffer and then must flipped as the front buffer when the next monitor refresh VSYNC arrives.

The X11 server being a process like another one on your machine, it is susceptible to the scheduler behaviour and thus all these operations might not happen on time.

I remember seeing discussions about this on the xfree86 mailing lists, maybe you should have a look.