LABSN / expyfun

Experimental paradigm functions.
BSD 3-Clause "New" or "Revised" License
13 stars 21 forks source link

BUG: Fix video on Windows for Pyglet > 1.3 #439

Closed larsoner closed 2 years ago

larsoner commented 2 years ago

We had two problems, I think:

  1. We need to call pyglet.clock.tick(poll=True) to get the video to advance, and
  2. The alpha for the video is messed up on Windows

(2) has been opened upstream as a Pyglet bug (https://github.com/pyglet/pyglet/issues/531), but the workaround here should be fine.

@JustinTFleming can you test it with latest pyglet (1.5.21) and pyglet-ffmpeg?

FWIW @drammock for me when I play the video it plays way too fast on Linux -- it should take ~6 sec but it takes ~1. But this seems to be the case with newer Pyglet even before these PRs. Do you want to take a look? IIRC you worked on the timing stuff originally...?

JustinTFleming commented 2 years ago

Just got a chance to test. The video does play, but it's clearly sped up for me too on Windows (playback time around 1s).

For kicks I also tried it on another mp4 file and the same thing happens, with a bunch of dropped frames. Audio cuts out at this shortened video end time as well.

larsoner commented 2 years ago

Okay we should probably fix the timing before bothering to merge this... maybe you should stick with 1.3 + AVBin until this part is solved, since I think the timing might work there...?

larsoner commented 2 years ago

Okay this plus https://github.com/pyglet/pyglet/pull/533 fixes playback speed for me. Feel free to try it @JustinTFleming , hopefully the pyglet devs agree with my fix (or point out a better one!).

larsoner commented 2 years ago

FWIW the "alpha on Windows" bug is fixed by https://github.com/pyglet/pyglet/pull/534, but this PR shouldn't hurt anything in the meantime.

@JustinTFleming if you update to latest pyglet-1.5-maintenance and (now that I'm merging this) and latest expyfun, video should work again for you on windows. It should also be smoother on Linux and macOS / ffmpeg backend due to pyglet/pyglet#533 !

JustinTFleming commented 2 years ago

Yes, videos are now the correct duration on Windows as well, and example-video.mp4 playback is much smoother!

With that working, I tried changing the video file in simple_video.py. Unfortunately, the video remains choppy / stop-and-start on test videos with the following characteristics (both 1920x1080 resolution):

larsoner commented 2 years ago

@JustinTFleming can you look into which video backend is being used / configuring Pyglet, and make sure it's ffmpeg? The Pyglet devs told me that it's preferred over the WMF one (which also had the alpha issue BTW) because the WMF is unaccelerated.

JustinTFleming commented 2 years ago

Bit of guesswork here, not being very familiar with pyglet, but in pyglet\media\codecs\__init__.py, there's the following code to prepare the codecs. There's a comment that they should be listed in order, but on my machine wmf will be added ahead of ffmpeg (see below) -- possibly meaning it will be preferred? Also, have_ffmpeg() returns True, so pyglet is able to at least find that library. ` def add_default_media_codecs():

Add all bundled codecs. These should be listed in order of

# preference.  This is called automatically by pyglet.media.

try:
    from . import wave
    add_decoders(wave)
    add_encoders(wave)
except ImportError:
    pass

if pyglet.compat_platform.startswith('linux'):
    try:
        from . import gstreamer
        add_decoders(gstreamer)
    except ImportError:
        pass

try:
    if pyglet.compat_platform in ('win32', 'cygwin'):
        from pyglet.libs.win32.constants import WINDOWS_VISTA_OR_GREATER
        if WINDOWS_VISTA_OR_GREATER:  # Supports Vista and above.
            from . import wmf
            add_decoders(wmf)
except ImportError:
    pass

try:
    if have_ffmpeg():
        from . import ffmpeg
        add_decoders(ffmpeg)
except ImportError:
    pass

try:
    from . import pyogg
    add_decoders(pyogg)
except ImportError:
    pass`

I can try moving the ffmpeg block ahead of wmf and see if that changes anything (for better or worse).

JustinTFleming commented 2 years ago

Ooh, moving up the ffmpeg block makes a huge difference in playback quality -- drastically better. I think you were right @larsoner that it was defaulting to WMF!

I currently have no audio, but I'm testing at home without my usual RME setup, so I'll try this in the lab before getting alarmed about that.

larsoner commented 2 years ago

Okay I opened https://github.com/pyglet/pyglet/pull/535, let's see what they say