[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
there:

    *((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?

--ryan.






More information about the smpeg mailing list