Closed larsoner closed 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.
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...?
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!).
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 !
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):
@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.
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():
# 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).
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.
Okay I opened https://github.com/pyglet/pyglet/pull/535, let's see what they say
We had two problems, I think:
pyglet.clock.tick(poll=True)
to get the video to advance, and(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...?