Hi Alex, On 12 Mar 2009, at 01:55, Alex Holkner wrote:
> > On Thu, Mar 12, 2009 at 9:30 AM, Padraig Kitterick > <[email protected]> wrote: >> >> Hi, >> >> I've been having quite a lot of problems getting Pyglet+AVBin to play >> back a bunch of video files correctly (Win XP32, Python 2.5, Pyglet >> 1.1.2) using the simple video.py example and I would really >> appreciate >> some input from pyglet experts. Here are a few Qs: >> >> 1) Inspecting the source for pyglet.media.Player I came across >> Player._update_schedule and the following lines: >> >> interval = 1000. >> if self._sources[0].video_format: >> interval = min(interval, 1/24.) >> [snip] >> clock.schedule_interval_soft(self.dispatch_events, interval) >> >> which in my case, using the simple video.py example, always results >> in >> the player updating itself at 24fps maximum. Am I correct in thinking >> that the player is hard limited to 24 fps?! > > That's right. The current trunk version of avbin (not yet released) > exposes the reported frame rate of the video, so future versions of > pyglet will be able to use this to set a more appropriate interval. Fantastic to hear that this is coming. I read somewhere that 1.2 will have multi-threaded decoding of AV streams. Is that correct? > >> >> 2) I seem to have consistent problems with >> pyglet.media.avbin.AVbinSource objects reporting the wrong video >> stream duration, commonly 70% of what it should be. The videos are >> MPEG 2 720x576 25fps files exported from Premier Pro using one of the >> default export profiles without anything else being done to them. Any >> ideas as to why avbin is misreporting the duration? If I step through >> the video frames in the stream, there are the correct number of them, >> so it can read the file alright, and if I get the timestamps for each >> frame they are correct. However, avbin misreports the total duration >> only which causes the player class to stop playing the videos too >> early. Any ideas? >> > > pyglet passes on the duration reported by avbin, which is reported by > FFmpeg. Check with the ffplay program (distributed with ffmpeg) that > the duration is the same. I've seen similar issues with ffmpeg > before; the problem is either in the file reporting an incorrect > duration (due to a bug in the encoder, for example), or a bug in > ffmpeg. > > Alex. Okay, thanks for this. I'll check what ffplay is reporting. For now I've hacked in a patch which finds the value of the last timestamp and uses that for the length, which always works, but does involve reading a limited number of frames. Thanks! Padraig > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
