Martin Storsj? wrote:> On Wed, 8 Apr 2009, michael brown wrote:
OK, I figured I was doing it wrong. What function(s) could I use to
blit onto the decoded YUV “frame” data with alpha blending support,
before calling sws_scale? Sorry if these are stupdid questions, I’m
still trying to wrap my head around all this stuff. Thanks.
Last time I checked, SDL doesn’t contain any routines for doing this.
So you’d have to do all the conversion yourself, first converting
your SDL surface into the YUV colorspace, and then manually blit it
into the YUV overlay. There are perhaps some external libraries that
would help you in doing this, though; don’t know any off-hand.
A little about what I’m trying to do:
I have a v4l program that captures 640x480 frames at 30fps from a security
camera. When the program detects motion, it compresses the frames into
individual JPEG files. This all works great. I’m trying to build a simple
media player type application to review and/or animate the images at up to
30 frames/second. This means I have to accomplish everything for each frame
in less than 33mS.
Hmm… Ok, I took out the YUV overlay, ffmpeg av_… and and calls and
replaced them with IMG_Load since I’m not really reading movie files, but
JPEG images. This works the way I expect, but IMG_Load is incredibly slow
for some reason.
On my machine, the command line ffmpeg program can process 180 frames per
second into an mp4, but IMG_Load takes 15-30mS to load one image to a
surface. All the other SDL calls I make to create the alpha blended text
layer take a total of 5mS on my machine. Any ideas why is IMG_Load so slow
or what I can do about it?
Martin Storsj? wrote:
OK, I figured I was doing it wrong. What function(s) could I use to
blit onto the decoded YUV “frame” data with alpha blending support,
before calling sws_scale? Sorry if these are stupdid questions, I’m
still trying to wrap my head around all this stuff. Thanks.
Last time I checked, SDL doesn’t contain any routines for doing this.
So you’d have to do all the conversion yourself, first converting
your SDL surface into the YUV colorspace, and then manually blit it
into the YUV overlay. There are perhaps some external libraries that
would help you in doing this, though; don’t know any off-hand.
A little about what I’m trying to do:
I have a v4l program that captures 640x480 frames at 30fps from a security
camera. When the program detects motion, it compresses the frames into
individual JPEG files. This all works great. I’m trying to build a simple
media player type application to review and/or animate the images at up to
30 frames/second. This means I have to accomplish everything for each
frame in less than 33mS.
Hmm… Ok, I took out the YUV overlay, ffmpeg av_… and and calls and
replaced them with IMG_Load since I’m not really reading movie files, but
JPEG images. This works the way I expect, but IMG_Load is incredibly slow
for some reason.
On my machine, the command line ffmpeg program can process 180 frames per
second into an mp4, but IMG_Load takes 15-30mS to load one image to a
surface. All the other SDL calls I make to create the alpha blended text
layer take a total of 5mS on my machine. Any ideas why is IMG_Load so slow
or what I can do about it?
Maybe this a related bug to the PNG loading bug, where the code opened and
closed the PNG library for every image loaded. For JPEG loading I would
imagine the speed loss being relatively higher than for PNG loading.
PS. You also may want to introduce some buffering and possibly your own image
loading using an existing surface ie preventing unnecessary memory allocations
and frees.On Thursday 09 April 2009 17:12:40 michael brown wrote:
On Wed, 8 Apr 2009, michael brown wrote:
On my machine, the command line ffmpeg program can process 180 frames per
second into an mp4, but IMG_Load takes 15-30mS to load one image to a
surface. All the other SDL calls I make to create the alpha blended text
layer take a total of 5mS on my machine. Any ideas why is IMG_Load so slow
or what I can do about it?
Maybe this a related bug to the PNG loading bug, where the code opened and
closed the PNG library for every image loaded. For JPEG loading I would
imagine the speed loss being relatively higher than for PNG loading.
It’s not exactly a bug, just a missing feature. Try adding my IMG_Init patch.
It affects PNGs, JPEGs and TIFFs, and ought to speed up the loading by
a bit. Just run
IMG_Init(IMG_INIT_JPG);
before you load up any JPEG files, and see if that doesn’t help things…>----- Original Message ----
From: Sami N??t?nen <sn.ml at keijukammari.fi>
Subject: Re: [SDL] IMG_Load performance was Problem combining sw_scale with blit operations on surface
This is a silly way to go about things. Don’t wait for motion and then
capture a JPEG, just capture to a good VBR video, and write out extra
data about when motion occurs. You can get higher image quality at
higher compression ratios than in your current scheme.
Don’t use SDL for this, use GStreamer!On Thu, Apr 9, 2009 at 10:12 AM, michael brown wrote:
A little about what I’m trying to do:
I have a v4l program that captures 640x480 frames at 30fps from a security
camera. ?When the program detects motion, it compresses the frames into
individual JPEG files. ?This all works great. ?I’m trying to build a simple
media player type application to review and/or animate the images at up to
30 frames/second. ?This means I have to accomplish everything for each frame
in less than 33mS.
–
http://codebad.com/