You are welcome, and a small tip, in case youre not aware already - avoid any YUV codecs on encoding original video, use RGB pixel format with some fast codec. This will preserve quality and avoid redundant YUV to RGB conversions at runtime. I cannot advise at the moment what exactly codec would be best, but I am currently working on related things so probably can advise something later on.
On 16 February 2015 at 17:36, Brian Madden <br...@missionpinball.com> wrote: > In my case I also need to be able to overlay content from other Pygame > surfaces on the video. Our specific use is a background video loop for a > scoring screen in a pinball machine. (I mean a real pinball machine—the > 300-pound things you find in bars. If you haven't followed pinball in the > past few years, they now have LCD monitors in the back of them instead of > those orange dot matrix screens.) > > So we have other content (score, stats, etc.) which goes on top of the > video. In our app, all those elements all have their own surfaces and then > everything is blitted together in to the final surface which we blit to the > screen. So we need a solution that will let us get a pygame surface from > the video which we can layer in with all the rest of our surfaces. > > I'll look into OpenCV as well. Even if we have to call some kind of OpenCV > method to get the pixels to a byte string and then use pygame's > Image.from_string(), that might work. (Though I tried that with pyglet and > the performance was not good, though in Pyglet's case we had to do several > steps in python to get the pixels in the format we needed to convert them > to a pygame surface.) > > Anyway, I'll play with this some more and report back. (Though I have a > few other higher priority things to get to first so it might be a few > weeks.) At the end of the day I'm really looking for the most performant > way to get a pygame surface from a video frame. > > (BTW we were able to successfully encode source videos to MPEG-1 to get > them to play via pygame. Performance on our current system was not great, > but it's a start.) > > Also, luckily, since our app is running on a computer inside a pinball > machine, we do have control over what's installed on that computer. So a > dependence on ffmpeg being installed a certain way or OpenCV or anything > else like that is ok for us. > > Thanks again! > Brian > > On Mon, Feb 16, 2015 at 8:05 AM, Mikhail V <mikhail...@gmail.com> wrote: > >> I have read now your question one more time, so you just want to play a >> video, wright? Then it is worth probably to use a lib which supports video >> decoding, like "openCV" for example. I am not very familiar with its >> decoding capabilities, but it seems it is using ffmpeg's dlls to decode >> video files. This must be significantly faster than piping, but still you >> are dependant on ffmpeg libs and openCV so no guarantee that the end user >> have those properly installed. >> >> On Saturday, February 14, 2015 at 10:10:36 PM UTC+1, Mikhail V wrote: >>> >>> Hi, >>> this is the first result in google for 'ffmpeg python piping' search: >>> http://zulko.github.io/blog/2013/09/27/read-and-write- >>> video-frames-in-python-using-ffmpeg/ >>> >>> it is a good step by step tutorial, it helped me to make my player, >>> however I made it for playing image sequences, not videos, but the approach >>> is exactly the same. >>> There is one caveat however for linux, popen did not function well with >>> ffmpeg (it makes the console non-responsive when an error occurs), so I >>> need to kill the ffmpeg process manually from the script after a portion of >>> frames is loaded. >>> >>> Mikhail >>> >>> On 14 February 2015 at 01:55, Brian Madden <br...@missionpinball.com> >>> wrote: >>> >>>> Hi Ted, >>>> >>>> Thanks for these ideas! I'll try those settings for ffmpeg, but yeah, I >>>> already learned that the movie module isn't in Pygame for Mac. >>>> >>>> I'd love an example of the pipe to ffmpeg, either here or off list via >>>> my email br...@missionpinball.com. I assume that you get the pixels >>>> for a frame from ffmpeg and then blit them to a pygame surface manually? >>>> >>>> Thanks! >>>> Brian >>>> >>>> On Fri, Feb 13, 2015 at 4:27 PM, Ted Hunt <ted.h...@clear.net.nz> >>>> wrote: >>>> >>>>> Hi Brian, >>>>> >>>>> I had a similar problem to you (wrote an app thinking I'd be able to >>>>> play video, only to later find problems). I did manage to get the movie >>>>> module in pygame to play HD video. Here's the ffmpeg command I used to >>>>> encode the video :- >>>>> >>>>> ffmpeg -r 24 -f image2 -i SD%%04d.png -r 24 -g 18 -s 1920x1080 -vcodec >>>>> mpeg1video -b:v 6000k -minrate 6000K -maxrate 6000k -bufsize 3276800 >>>>> -intra >>>>> SD.mpg >>>>> >>>>> I think the trick is using a fixed bit rate. If while encoding ffmpeg >>>>> reports a buffer underflow, then you'll need to increase the bit rate >>>>> (always keep -b:v, -minrate and -maxrate the same). >>>>> >>>>> Another problem which you may or may not discover is that not all >>>>> pygame versions include the movie module. And it's possible that the movie >>>>> module will be dropped in future versions. Because of this I decided not >>>>> to >>>>> use the movie module and instead I open a pipe to ffmpeg to decode my >>>>> videos. The disadvantage with this is that ffmpeg has to be available to >>>>> your app. The advantage is that you can use any encoding method ffmpeg >>>>> supports. If you need an example of opening a pipe to ffmpeg, just let me >>>>> know. >>>>> >>>>> Cheers, >>>>> >>>>> Ted. >>>>> >>>>> >>>>> >>>>> On 14/02/2015 6:41 a.m., Brian Madden wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> I have a Python app that's pretty much ready to go. Problem is that >>>>> we need to be able to play videos. To be honest I never really looked too >>>>> deep into Pygame's video support. I knew from the docs that it had to be >>>>> MPEG-1 and that if you wanted audio then it had to have exclusive control >>>>> of Pygame.media, so I kind of thought, "Ok, that's fine, I'll deal with >>>>> all >>>>> that later." >>>>> >>>>> So now it's "later" and I'm dealing with it. :) >>>>> >>>>> Problem is that we cannot get videos converted to MPEG-1 in a way >>>>> that works reliably. We've gone through all the posts on this list and >>>>> read >>>>> a lot. Sometimes the videos play, sometimes not, sometimes we get SDL >>>>> errors, sometimes we get garbage on the screen.. It's really kind of a >>>>> mess. >>>>> >>>>> So I've started looking into options for non-MPEG1 videos and I >>>>> wonder if anyone has successfully done anything? >>>>> >>>>> I found a blog post where a guy wrote a simple app that uses Pyglet >>>>> to play the video and then for each frame it converts the Pyglet video >>>>> frame to a Pyglet texture (kind of like Pyglet's version of a Surface), >>>>> converts the pixels to a ctype, converts the ctype to the format Pygame >>>>> can >>>>> use, converts it to an image, then blits it to the Pygame window surface. >>>>> That technically works but it's far too slow.. for hi-def videos we're >>>>> only >>>>> getting about 10fps. >>>>> >>>>> So I wonder if there are any other alternatives? Like can we install >>>>> SDL2 and use PySDL2 to play the video and somehow convert that to a Pygame >>>>> surface? (I have no idea if surfaces between SDL1.2 and SDL2 are >>>>> compatible, or if so if it would be possible to get them into Pygame.) >>>>> >>>>> Or are there any other crazy ideas? >>>>> >>>>> To be honest if we can't figure this out then I think we're going to >>>>> have to go with something other than Pygame, which would be a lot of work, >>>>> but I don't know of any other alternatives? Unfortunately I don't know C >>>>> or >>>>> C++ so I'm afraid I'm not much help in terms of contributing to Pygame. >>>>> >>>>> Has anyone successfully taken a Python project based on Pygame and >>>>> converted it to PySDL2? From what I've read it seems like there are many >>>>> similarities since they're both SDL, but I don't know how much "other" >>>>> work >>>>> Pygame is doing, and whether if I recreated any of that in Python it will >>>>> be fast enough? >>>>> >>>>> Anyway, sorry I'm a bit all over the place. I wonder if anyone has >>>>> any thoughts to share? >>>>> >>>>> Thanks, >>>>> Brian >>>>> >>>>> -- >>>>> *Brian Madden* >>>>> Mission Pinball (blog <http://missionpinball.com> | twitter >>>>> <https://twitter.com/missionpinball> | MPF software framework >>>>> <http://missionpinball.com/framework> | sample games >>>>> <https://missionpinball.com/blog/category/big-shot-em-conversion/>) >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> <http://www.avast.com/> >>>>> >>>>> This email is free from viruses and malware because avast! Antivirus >>>>> <http://www.avast.com/> protection is active. >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Brian Madden* >>>> Mission Pinball (blog <http://missionpinball.com> | twitter >>>> <https://twitter.com/missionpinball> | MPF software framework >>>> <http://missionpinball.com/framework> | sample games >>>> <https://missionpinball.com/blog/category/big-shot-em-conversion/>) >>>> >>> >>> > > > -- > *Brian Madden* > Mission Pinball (blog <http://missionpinball.com> | twitter > <https://twitter.com/missionpinball> | MPF software framework > <http://missionpinball.com/framework> | sample games > <https://missionpinball.com/blog/category/big-shot-em-conversion/>) >
