[smpeg] SMPEG threading, SMPEG constructors
Ryan C. Gordon
icculus at clutteredmind.org
Wed Jan 8 23:59:15 EST 2003
> > None of the SMPEG functions block...you should regain control immediately.
> Hmmm! Then something could be seriously wrong with my SMPEG installation.
> I don't remember getting any error messages when installing though. I am
> using SMPEG on a RedHat 7.3 machine.
Sorry: they don't block, assuming that i/o is available. My assumption is
that reading from a pipe will block. Most people are reading from static
files...this might need an API change, honestly.
> but they have no effect. No output is printed to the screen.
Are you sure that you've got the right library linked in? Put this in
*((char *) 0x0000) = 0;
If the program doesn't crash at that point, you definitely don't have the
right library linked in.
> Of course, I recompiled the library with "make all", and
> reinstalled it with "make install", both operations as root, and I have
> recompiled my programme with the altered libraries.
If you installed from RPM, it's likely that the default source install
went to /usr/local/lib, which is likely checked after /usr/lib, where the
RPMs would go, and thus would link to the wrong library at runtime.
> Is the SMPEG_new_descr(...); the right choice? Any alternatives?
Wrap your network in an SDL_RWops that doesn't block when there isn't
data...hmm...I wonder if smpeg treats a zero-byte read as EOF...
> Am I on the right track by using a pipe? My plan is to have the SMPEG
> player "read" from the pipe, while my programme continuosly writes data
> to it.
You should also try using fctrl() to set your pipe to non-blocking mode
and see what happens. Disabling SIGPIPE is a good idea, too. I don't know
if a pipe is necessarily the best plan, but these things might help.
> Can anyone please help me out?
More information about the smpeg