Oh, you’re the tons-of-JPEGs guy…
use GStreamer ;)On Fri, Apr 10, 2009 at 3:38 PM, michael brown wrote:
I thought it’d be smart to do my frame flipping during the callback to try
for a nice even frame presentation. ?In the callback I push an event to
trigger the main thread to start decompressing another JPG image (if
present). ?When the image is finally decompressed (about 11mS later now 
I draw it on the surface and set a flag indicating that the frame is ready
for display. ?The callback checks the flag and does an SDL_Flip on the
screen if the flag is set. ?I’ll find a better timer, but keep the design.
–
http://codebad.com/
Donny Viszneki wrote:
I thought it’d be smart to do my frame flipping during the callback
to try for a nice even frame presentation. In the callback I push an
event to trigger the main thread to start decompressing another JPG
image (if present). When the image is finally decompressed (about
11mS later now I draw it on the surface and set a flag
indicating that the frame is ready for display. The callback checks
the flag and does an SDL_Flip on the screen if the flag is set. I’ll
find a better timer, but keep the design.
Oh, you’re the tons-of-JPEGs guy…
Yep, pthreads seems to have solved my problem, though the precision (my
fault) still leaves lots to be desired. OTOH, to the human eye it works
beautifully. I’ve never used pthreads before, much easier to get working
than I expected.
use GStreamer 
Looks like too much delay for what I’m doing right now, but I think I can
incorporate it in other ways. Thanks again for pointing it out.> On Fri, Apr 10, 2009 at 3:38 PM, michael brown <@michael_brown> wrote:
Hmm?On Fri, Apr 10, 2009 at 5:55 PM, michael brown wrote:
use GStreamer
Looks like too much delay for what I’m doing right now, but I think I can
incorporate it in other ways. ?Thanks again for pointing it out.
–
http://codebad.com/
Donny Viszneki wrote:> On Fri, Apr 10, 2009 at 5:55 PM, michael brown <@michael_brown> wrote:
use GStreamer
Looks like too much delay for what I’m doing right now, but I think
I can incorporate it in other ways. Thanks again for pointing it out.
Hmm?
The delay? Right now I can get “live” data to my vnc desktop window with
less than 500mS delay. Almost any streaming system that also captures to
disk is going to introduce 5 to 10 times that much delay for buffering and
other overhead. Granted it would be much more efficient in terms of network
bandwidth than what I’m doing now. I can use that for some other things I
want to play with.
Some more background if you’re interested. My capture process is watching
the street in front of my house. It constantly looks for vehicle sized
objects passing by and estimates their speed. I have a traffic problem in
the neighborhood and I’m correcting it.
Here is a sample of the images I capture:
All that markup is done at capture time. How do you like my home brew
motion tracking?
Here’s an older flash video of some of the early stuff:
OTOn Fri, Apr 10, 2009 at 6:21 PM, michael brown wrote:
Donny Viszneki wrote:
On Fri, Apr 10, 2009 at 5:55 PM, michael brown wrote:
use GStreamer
Looks like too much delay for what I’m doing right now, but I think
I can incorporate it in other ways. Thanks again for pointing it out.
Hmm?
The delay? ?Right now I can get “live” data to my vnc desktop window with
less than 500mS delay. ?Almost any streaming system that also captures to
disk is going to introduce 5 to 10 times that much delay for buffering and
other overhead.
It sounds like you didn’t even look at GStreamer…
–
http://codebad.com/
Donny Viszneki wrote:
OT
Donny Viszneki wrote:
use GStreamer
Looks like too much delay for what I’m doing right now, but I think
I can incorporate it in other ways. Thanks again for pointing it
out.
Hmm?
The delay? Right now I can get “live” data to my vnc desktop window
with less than 500mS delay. Almost any streaming system that also
captures to disk is going to introduce 5 to 10 times that much delay
for buffering and other overhead.
It sounds like you didn’t even look at GStreamer…
You are correct, I haven’t had time to really look at it yet. I only
glanced thru the documentation quickly. I do intend to spend some time
playing with it. When I’m viewing in “real time”, I want my viewer to play
at normal speed as frames are being captured, yet stop when frames aren’t
being captured. I also want to be able to skip back and step thru the
frames of someone that just drove by. It’s also nice to be able to hit a
key and have the original JPEG instantly copied to another directory of
heinous violaters. Perhaps I can easily accomplish this with
GStreamer, but I’ll have to spend some time digging thru it. I wanted some
instant gratification and pthreads is doing it for me right now. :-)> On Fri, Apr 10, 2009 at 6:21 PM, michael brown <@michael_brown> wrote:
On Fri, Apr 10, 2009 at 5:55 PM, michael brown <@michael_brown> wrote:
I want my viewer to play
at normal speed as frames are being captured, yet stop when frames aren’t
being captured.
How do you tell if a video that isn’t changing has “stopped?” If
you’re using a reasonable VBR codec, then even the network
transmissions will drop off to basically nothing. If you use a filter
that can determine whether the scene is moving or not and reduce it to
literally no motion, which as I understand things is what you’re doing
now, then it’ll work great!
?I also want to be able to skip back and step thru the
frames of someone that just drove by. ?It’s also nice to be able to hit a
key and have the original JPEG instantly copied to another directory of
heinous violaters.
Ah, hmm… I suppose one way to do this would be for the client app to
have a live mode and a non-live mode. Seeking from live mode would
automatically transition to non-live mode. You wouldn’t even need to
use GStreamer for non-live mode on the server, as you could just share
the archive across the networking using Samba, Apache, or FTP.
Perhaps I can easily accomplish this with
GStreamer, but I’ll have to spend some time digging thru it. ?I wanted some
instant gratification and pthreads is doing it for me right now. ?
Ah, I can understand that ;)On Fri, Apr 10, 2009 at 7:49 PM, michael brown wrote:
–
http://codebad.com/
That is absolute craziness.
SDL timers are not good for much because their resolution is too low.
You clearly need very precise timing (which is typical of games) and
you should not be using an SDL timer for this.
I went to look in there, and wow, they’re even weirder than I
remembered (including an invalid use of “volatile” to provide
thread-safety, but which really doesn’t! oops), including subtracting
the “timeslice” from the interval (uh?) and rather arbitrarily
snapping the resolution of the timer to 10 msec.
Personally, I use a priority queue of expiration times (SDL_GetTicks()
- timeout, when setting the timer), and use the one off the top minus
SDL_GetTicks() as my select() timeout (minimum of zero, of course!)),
then after the select(), I pop the expired timers off the top of the
queue. Pretty simple, and gets me as low as the platform can support
(although I suspect select()'s timeout might not be the best on some
exotic platforms). In practice, the resolution is close to 10 msec,
yes, but it’s actually a hair under most of the time (every bit
helps), and if someone improves Linux to make it less 1 msec or better
resolution, it’ll magically become better, as opposed to artificially
making it awful…On Fri, Apr 10, 2009 at 3:12 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
–
http://pphaneuf.livejournal.com/
Which begs the question: why do SDL timers suck so badly?
No one has written a better SDL timer yet, that’s the only real reason.
Note how what I described in my previous message works very well when
you replace my mentions of select() with SDL_WaitEventTimeout().
I should dust off my other patch that removes the SDL_Delay(10) in
there (I have it working correctly for X11 and using the fallback path
that still does SDL_Delay(10) on Mac OS X, but doesn’t compile on
every other platforms, I just need to dive in and fix it)…On Fri, Apr 10, 2009 at 3:27 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
–
http://pphaneuf.livejournal.com/
Note how what I described in my previous message works very well when
you replace my mentions of select() with SDL_WaitEventTimeout().
OK, this is driving me up the wall. What’s this select() thing that all the
Linux people keep talking about? In my line of work, “select” is followed
by a bunch of column names and a FROM clause. :P>----- Original Message ----
From: Pierre Phaneuf
Subject: Re: [SDL] Repeating timers
select() is a POSIX/GNU API for waiting!
http://linux.die.net/man/2/select
It is also a Windows API, but Windows’ select() interface is more limited.On Mon, Apr 13, 2009 at 9:02 PM, Mason Wheeler wrote:
OK, this is driving me up the wall. What’s this select() thing that all the
Linux people keep talking about? ?In my line of work, “select” is followed
by a bunch of column names and a FROM clause. 
–
http://codebad.com/
OK, this is driving me up the wall. What’s this select() thing that all the
Linux people keep talking about? ?In my line of work, “select” is followed
by a bunch of column names and a FROM clause.
It’s like Donny said. It’s the moral equivalent of GetMessage, but
with a medium resolution timeout (zero is really non-blocking, not
giving the timeslice away or anything, more than that is basically the
resolution of the OS timeslice, which can vary from machine to
machine, but is usually much better than the craptastic WM_TIMER).
You can help with the resolution a fair bit if you artificially reduce
the timeout a little bit, and spin for that last bit, which basically
makes it as good as SDL_GetTicks can be.On Mon, Apr 13, 2009 at 9:02 PM, Mason Wheeler wrote:
–
http://pphaneuf.livejournal.com/