The VideoLAN Forums

Hello!

I'm hoping to reduce (or better yet, eliminate) the black screen that appears when switching in between files. To be clear, I'm not seeking true gapless playback, just playback with less of a visible gap in between files (it ruins the pepper's ghost illusion that we've created).

Previous forum posts have suggested --sout-keep. However, this option appears to be for streaming only (and seems to have no effect). Playback of DVDs in VLC does seem to work "gaplessly" when switching between chapters, which seems to indicate that this playback is possible in theory.

Context: I'm using vlc.py to control an instance of VLC and switch between local video files. For my convenience, I manually feed the files to VLC (rather than using a playlist). Would using a playlist help? Or perhaps recoding the videos in a different format (currently h264/mp4)?

Thanks for any help or direction you can provide,
Patton

Turns out, the underlying error was improper use of vlc.py.

I had disabled X11 (--no-xlib) as recommended in the vlc.py error message. However, this in turn disables VDPAU. Thus, VLC was unable to take advantage of GPU decoding.

For any other vlc.py users, calling XInitThreads() before you begin to use vlc.py resolves the issue, like so: With full GPU decoding enabled through VDPAU, the transition between videos is almost immediate and seemless!

Patton

I'd occasionally see the BLACK screen with my custom video player..
I had to add a begin== point so the play back would be running... Before the Slow motion kicked in..
and the longer the video the more seconds needed.

Maybe include a short segment of the same video right before??

photo d:\test folder\Tobacco Leaf Flyer close pause begin==60000 start==63600 wait=.8 speed=125 len=262260 demo85_pict7.mpg bytes=103827456
xxx.d:\test folder\Tobacco Leaf Flyer close again begin==59000 start==63600 wait=.6 speed=125 len=262260 demo85_pict7.mpg

photo d:\test folder\Tobacco Leaf Flyer close continue pause begin==62780 start==63680 wait=.39 speed=200 freeze=.2 len=262260 demo85_pict7.mpg bytes=103827456
xxx.d:\test folder\Tobacco Leaf Flyer close again begin==59000 start==63600 wait=.6 speed=125 len=262260 demo85_pict7.mpg

photo d:\test folder\Tobacco Leaf Flyer close continue pause begin==62790 start==63690 wait=.39 speed=200 freeze=.2 len=262260 demo85_pict7.mpg bytes=103827456
xxx.d:\test folder\Tobacco Leaf Flyer close again begin==59000 start==63600 wait=.6 speed=125 len=262260 demo85_pict7.mpg

Hi,

Seemless playback will correctly work for 4.0 release. Before this, only hacks will work, and probably not for all cases.

Thanks for the info unidan! Is there a release schedule for version 4 (I did some searching, but couldn't find it if it exists).

Unfortunately, GPU decoding caused VLC to freeze with painful regularity (perhaps an unrelated issue), so I've switched back to CPU decoding for now.

Thanks again for your help,
Patton

Thanks for the info unidan! Is there a release schedule for version 4 (I did some searching, but couldn't find it if it exists).

Not yet, hopefully soon.

Unfortunately, GPU decoding caused VLC to freeze with painful regularity (perhaps an unrelated issue), so I've switched back to CPU decoding for now.

Do you have more info on this ?

Unfortunately, GPU decoding caused VLC to freeze with painful regularity (perhaps an unrelated issue), so I've switched back to CPU decoding for now.

Do you have more info on this ?

Unfortunately, I'm not sure how to debug this variety of crash. VLC remains open, but the video is paused/unresponsive. Is there a debug output I can post?

Patton

Hi, you can try using logs or messages to get an output

Thanks unidan!

Sorry for the delay - it took me a while to reliably reproduce the error. The common factor is the long delay before the crash. This delay, plus a couple lines about waiting for memory to free near the end of the log, leads me to believe the cause is a memory leak in VDPAU that causes GPU memory to fill up.

The tail end of the log is here: https://pastebin.com/dDmuyQVE (the full log is 8.6 MB, too long for a free pastebin account.)

Patton

Just realized I forgot to post other system details.

VLC Version: 3.0.3 Vetinari (revision 3.0.3-1-0-gc2bb759264)
System: Ubuntu 18.04.1 64 bit w/AMD Ryzen 3 2200g and GeForce GTX1050 Ti

Let me know if there's any other useful information I can gather,
Patton

VLC 3.0.3 is no longer supported.

Ah, I'll try to reproduce the issue with the latest version. Thanks for the tip.

Patton

Hi all,

Sorry it took me a while to return to this issue. I was able to reproduce the error with VLC version 3.0.8 Vetinari (revision 3.0.8-0-gf350b6b5a7). Is this a version that is still supported? Regardless, let me know if you have other thoughts on how to debug the issue.

We have tested it on several different computers, and the VLC instance on only one computer seems to crash (with any regularity). There are two unique factors about this computer:
- VLC is loading a non-standard video size (1366 × 758), a typo from 1366 × 768. In my next round of testing, I will resize these videos to see if this resolves the problem.
- There are two instances of VLC running at the same time.

Thanks again for your help,
Patton

P.S. I finally noticed the typo in the title of this thread and am somewhat embarrassed. Thanks for helping even though I can't spell.

I was able to rerender the videos and perform the test again. There seems to be no change, so the video resolution is not the cause of the crash

It's possible that the two VLC instances are interfering in some when then using VDPAU. It's also possible that something about Xlib is causing the crash.

I'm currently loading Xlib in the python program using Is this the correct way to do it?

Thanks again,
Patton