I've tried downloading the full BBB movie in mp4/avi format, but unfortunately both mirrors seem unresponsive at the moment. I'll give it another try in the morning and see how it performs.
About the micro-stuttering, sorry I wasn't clearer before. I've tried with both PulseAudio and OpenAL, and the result is the same. I then tried remuxing the video without the audio stream, and the playback was smooth. (So It does not appear to happen with the SilentAudio player). The stuttering is very very minor, but it's noticable. Seeking around in the video doesn't appear to have any affect on the behavior. It's an interesting idea to add an option to the seek method. We probably want to lean towards keeping it simple, but lets see what kind of other feedback we get first and then consider if its worth it. I agree on the usage of Threads. The idea of using Processes is very appealing to me. I've done a lot of work on the procedural audio module this year, and I've also thought about using processes there as well. In my experience with the multiprocessing module, the IPC overhead is really not bad at all for this kind of job. There is some overhead, but it's sub-milisecond in my experience. Obviously this adds up fast if you try to do a million function calls, but we're only talking about arrays of video packets for full frames of video. Also, since we know in advance how big the video frames are, we could possibly use a multiprocessing.Array for potentially faster access to the data. This would be a fun one to experiment with in the future! I'm certainly up for a Skype call if we can make it work. Weekends are best for me. -Ben On Tuesday, April 11, 2017 at 5:58:05 PM UTC+9, Daniel Gillet wrote: > > Hi, > > Well this is very good news! > I'm glad you find the seeking delay small enough. Truth is, there is still > room for improvement. But my aim was to first make it work. > I have downloaded the whole BBB movie in avi format (in full HD) from > here: https://peach.blender.org/download/ This is where I find the > biggest delay when I seek. > > >> One thing I have noticed, is that the video playback seems very slightly >> stuttery with the 1080p trailers only. I also tested a 1080p trailer (the >> *.mov one) with the audio track removed, and that one seemed to play >> completely smoothly. Do you see this at all on Windows? I wonder if there >> is some slight rounding errors somewhere that are not apparent in the >> SilentAudio player. >> > > I don't experience this on Windows. I believe it's not really a Windows - > Linux problem, but more the audio driver which is different. So in order to > trouble shoot this a bit more, could you let me know if you experience the > same problem on OpenAL and PulseAudio? Try first to watch the video without > touching anything, then try the same with some seeking and report if it's > the same or it's getting worse. I've just found a small bug in OpenAL and > pushed the fix on my repo. But this should not affect how the video plays > when you don't touch it at all, only if you stop or seek. > > > Also, just wanted to say that you've done a fantastic job on this. >> > > Thanks a lot! I appreciate. I must say I'm also proud of the work that has > been accomplished. The code is far from perfect. As I stated several time, > it would be better (understant more efficient) to re-write it completely > because it's doing things in very complicated ways for no good reasons. The > worse problem in my opinion is the use of Threads for decoding audio and > video which is totally unnecessary because of the GIL (global interpreter > lock). It's actually even decreasing performances! > > If I find the motivation to carry on after this phase is done, I will > maybe try to rewrite the player to use pyglet event loop rather than > threads. This should improve things a little. For a real performance boost, > I could change the Threads into Processes which would then indeed use the > other cores to decode the video and audio. But we will loose time passing > data around the processes. I have no idea if this would in the end improve > performances so much. > > By the way, regarding the seeking, maybe I could try to add a keyword > argument to the player seek method to let the user choose if he wants a > precise seeking behaviour or if he prefers the regular seeking which is > less precise but quicker. > > I think I read you're living somewhere in Japan. So we have quite a big > time difference as I'm in Europe. But maybe we could try to arrange a Skype > meeting and see if we can find what the problem is with the stutter on > Linux. > > Dan > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
