Video display, frame rate 640x480 @ 30fps achievable?

[Guenter]

Hi,

I need to develop an application that displays video 640x480 16-bit per
pixel with 30 fps.

I would prefer to do that with Python (wxPython) but don't have any
experience whether it is possible to achieve that frame rate and still
have some resources for other processing left? My development PC would
be a Celeron 1 GHz. The final system could be a faster system.

I would appreciate if anybody could share some experience in that
field.

Thanks for any help.

Guenter

 

[Peter Hansen]

I need to develop an application that displays video 640x480 16-bit per
pixel with 30 fps.

I would prefer to do that with Python (wxPython) but don't have any
experience whether it is possible to achieve that frame rate and still
have some resources for other processing left? My development PC would
be a Celeron 1 GHz. The final system could be a faster system.

At the very least, you should be looking at Pygame instead, as wxPython
is not really intended for that kind of thing. Whether or not you can
manage the desired frame rate depends entirely on what you will be
displaying... a single pixel moving around, full-screen video, or
something in between? ;-)

See for example
http://mail.python.org/pipermail/python-list/2002-May/106546.html for
one first-hand report on frame rates possible with Pygame (whether it's
accurate or not I don't know).

-Peter

 

[Fredrik Lundh]

At the very least, you should be looking at Pygame instead, as wxPython
is not really intended for that kind of thing. Whether or not you can
manage the desired frame rate depends entirely on what you will be
displaying... a single pixel moving around, full-screen video, or
something in between? ;-)

no contemporary hardware should have any problem reaching that
framerate at that resolution, even if you stick to standard "blit" inter-
faces.

getting the data into the "blittable" object fast enough may be more
of a problem, though. I don't know how good wxPython is in that
respect; Tkinter's PhotoImage is probably not fast enough for video,
but a more lightweight object like PIL's ImageWin.Dib works just
fine (I just wrote a test script that reached ~200 FPS at 1400x900,
but my machine is indeed a bit faster than a 1 GHz Celeron).

</F>

 

[Diez B. Roggisch]

Hi,

I need to develop an application that displays video 640x480 16-bit per
pixel with 30 fps.

I would prefer to do that with Python (wxPython) but don't have any
experience whether it is possible to achieve that frame rate and still
have some resources for other processing left? My development PC would
be a Celeron 1 GHz. The final system could be a faster system.

I would appreciate if anybody could share some experience in that
field.

No first hand experience - but I guess pymedia is what you need. how to
combine that with wx? No idea.

Diez

 

[Michael Sparks]

I need to develop an application that displays video 640x480 16-bit per
pixel with 30 fps .... it is possible to achieve that frame rate and still
have some resources for other processing left?

Yes.

Co-incidentally we've been looking at video playback this week as well.
We've been using Pygame with an Overlay surface, and it works fairly well.
Initially we're testing with simple IYUV raw video data, and it's a good
idea to use a modern video card supported by your OS, but other than that
we've not had problems. If you're interested in code, let us know

If you end up using the framebuffer device in linux under xorg's X11 (not
exactly an ideal setup for video playback anyway!) there is a little oddity
that we found, due to SDL underneath, but we've been able to work
around that. The system I'm working on normally has that issue, and as
a result isn't accelerated and is a 1.6Ghz machine, but can do standard
defintion video (720x576) playback happily at >30fps. Normally though
most people can offload this to their graphics card so there shouldn't
be issues on your 1Ghz machine.

Clearly if you're interested in driving that you need to decode some data
source to IYUV, but that's a different issue.

People have embedded pygame in wxPython before (I don't know how
though, I've only seen screenshots of the integration) so although you said
wxPython and might've discounted pygame based on that, it might still be
suitable for you.

Regards,


Michael.

 

[Guenter]

getting the data into the "blittable" object fast enough may be more
of a problem, though. I don't know how good wxPython is in that
respect; Tkinter's PhotoImage is probably not fast enough for video,
but a more lightweight object like PIL's ImageWin.Dib works just
fine (I just wrote a test script that reached ~200 FPS at 1400x900,
but my machine is indeed a bit faster than a 1 GHz Celeron).

</F>

I would be interested in how many frames this reaches on my computer.
Did you create like two arbitrary images under PLI and then display
them one after another? Then stop the time and count how many times you
were able to switch between the two?

One feature I need to figure out when using PLI is that I need to move
a cursor over the image, controlled by a joystick. But I could add that
with the drawing feature when creating the image.

Now is there a feature that would allow me to map data from a memory
into an image? I saw there is a function called Image.frombuffer(). If
I understand that right the buffer is a python data type. If I get that
data type to represent a specific memory where I can dma the data to I
should be able to display them pretty fast?


Guenter

 

[Peter Hansen]

I would be interested in how many frames this reaches on my computer.
Did you create like two arbitrary images under PLI and then display
them one after another? Then stop the time and count how many times you
were able to switch between the two?

One feature I need to figure out when using PLI is that I need to move
a cursor over the image, controlled by a joystick. But I could add that
with the drawing feature when creating the image.

Maybe it would be a good idea to tell us something about the nature of
the image you'll be displaying (though the fact that it needs a
cross-hair or something is useful information, for a start). For
example, is it a photographic image? A map? A drawing? Is it
generated dynamically, or is it static? Do you pan over it, or zoom it,
or what?

-Peter

 

[Guenter]

Maybe it would be a good idea to tell us something about the nature of
the image you'll be displaying (though the fact that it needs a
cross-hair or something is useful information, for a start). For
example, is it a photographic image? A map? A drawing? Is it
generated dynamically, or is it static? Do you pan over it, or zoom it,
or what?

-Peter

It is a video image coming from a camera over a frame grabber board.
The video from the frame grabber is passed to another board that
performs some processing and when it comes back from that board it
needs to be displayed. The joystick allows to specify some regions of
interest in the image, but any zooming is done by the chip on that
second board. So the application needs only to take the image it gets
from that second board, displays it, handle the joystick input and does
some book keeping of where it is with the joystick position and zoom
factor.

It also needs to initiate the frame grabber and the second processing
board, but that should be simple by having some python extensions to
the respective software api provided with the boards. As the data
transfers between the boards are DMA based it should not put any
constrain on the application.

Guenter

 

[Guenter]

Yes.

Co-incidentally we've been looking at video playback this week as well.
We've been using Pygame with an Overlay surface, and it works fairly well.

I guess Pygame was more suitable overall for your application? I would
just be interested whether you have considered using PyMedia? I knew
about Pygame, but haven't done anything with it yet. So far when I
needed a GUI based application I have used wxPython, but I am not stuck
to that.

Initially we're testing with simple IYUV raw video data, and it's a good
idea to use a modern video card supported by your OS, but other than that
we've not had problems. If you're interested in code, let us know

Thanks for the offer. If it is getting serious and I need some jump
start I might come back to you about the code.

[...]


Guenter

 

[Peter Hansen]

It is a video image coming from a camera over a frame grabber board.
The video from the frame grabber is passed to another board that
performs some processing and when it comes back from that board it
needs to be displayed. The joystick allows to specify some regions of
interest in the image, but any zooming is done by the chip on that
second board. So the application needs only to take the image it gets
from that second board, displays it, handle the joystick input and does
some book keeping of where it is with the joystick position and zoom
factor.

Cool! It sounds to me as though Pygame (perhaps embedded in a wxPython
app) would be most appropriate. I know it has direct support for
joysticks, which I doubt the standard GUI frameworks generally have.
(Hmm... no, I'm wrong. At least wxPython does have Joystick support.
Check it out in the demo.)

-Peter

 

[Michael Sparks]

I guess Pygame was more suitable overall for your application?

It's not really that, it's just that it was the easiest most obvious
(and we've found portable) approach to getting the video onscreen.
You create an overlay object and simply throw decoded YUV data at
in and don't worry too much.

We can generally mix and match UI's happily at the moment with our
work, so we can have tkinter and pygame side by side for example.

I would just be interested whether you have considered using
PyMedia?

We did look at it, but found sufficient numbers of problems to decide
that it might be worth coming back to at a later point in time. Also
we kept hitting issues on 64-bit machines which didn't really help. API
changes also invalidated some of the examples causing confusion (I
wasn't the person directly working on it).

That said I've heard enough people say enough good things about it to
suggest that don't take our experience as the best example - I suspect
it's far from the best example. (I wish we had more time to try and
help fix it!)

(We've decided to wrap dirac instead for now)

Thanks for the offer. If it is getting serious and I need some jump
start I might come back to you about the code.

No problem.


Michael
--
(e-mail address removed), http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.