Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 5 commits into from Jan 12, 2022
Merged

Conversation

larsoner
Copy link
Member

@larsoner larsoner commented Jan 7, 2022

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 (pyglet/pyglet#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
Copy link

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
Copy link
Member Author

larsoner commented Jan 9, 2022

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
Copy link
Member Author

Okay this plus pyglet/pyglet#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
Copy link
Member Author

FWIW the "alpha on Windows" bug is fixed by pyglet/pyglet#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 !

@larsoner larsoner merged commit e229746 into LABSN:main Jan 12, 2022
@larsoner larsoner deleted the video branch January 12, 2022 20:18
@JustinTFleming
Copy link

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):

  • Video 1: 6-second mp4, 30 Hz fps, has audio, 3.5MB. Audio is also very choppy.
  • Video 2: 30-second mp4, 30fps, no audio, 17.0MB.
    I tried compressing those videos to m4v's to reduce file sizes, which got them down to 372KB and 3.74MB, respectively, but it didn't change video quality much in either case.

@larsoner
Copy link
Member Author

@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
Copy link

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
Copy link

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
Copy link
Member Author

Okay I opened pyglet/pyglet#535, let's see what they say

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants