[Live-devel] stripping jpeg headers

Jeremy Bernstein jeremy at bootsquad.com
Wed Feb 2 02:24:43 PST 2005


Thanks a lot, Ross -

It's working (the JPEG streams)! Happy day.

Now for my next questions... (and thanks for your patience and 
generosity once again) ... 

Number 1 has to do with MPEG-4. So, I'm multicasting video-only 
streams, using the code in "testMPEG4VideoStreamer" as a model. I'm not 
serving a file, but rather live video. And I'm happy to report that 
it's mostly working, as of just a few moments ago. I figured out my 
VOSH problems that I was running up against a few months ago, and 
super-great. OK, the problem... 

Everything starts out great, but after a variable amount of time (in 
VLC and in QT Player) the stream just freezes and can't be restarted 
without closing and reopening the client (and sometimes not even then). 

I'm seeing some messages in the output from openRTSP which might be 
related, from MultiFramedRTPSource::doGetNextFrame1(), about needing to 
drop some data, due to the client's buffer size. I noticed in my 
doGetNextFrame(), that the fMaxSize progressively gets smaller and 
smaller until this point is reached, and then goes back to its 
"maximum" maximum. Anyway, I wonder if this has anything to do with 
it...?

Question number 2 has to do with breaking down the process. Some months 
ago, you pointed me to "testWAVAudioStreamer" as an example of closing 
and deleting the appropriate objects. I'm not convinced that the entire 
process is being killed (for technical reasons, I can't call exit and 
be done with it - my streamer is just one component in a larger system, 
which I can't kill). Clients don't seem to notice that the server has 
closed (whereas, if I kill my host software, the client software 
notices at once that the server is gone). In the case of MPEG-4 
streaming (as opposed to H.263 or JPEG), I get a crash when I try to 
close certain objects (it varies, though, which is troubling - usually 
the Sink, but sometimes the RTSPServer). My close-it-all down sequence 
looks like this:

Medium::close(sessionState.video.rtcpInstance);
Medium::close(sessionState.video.sink);
delete sessionState.video.rtpGroupsock;
Medium::close(sessionState.video.source);
delete sessionState.video.rtcpGroupSock;
Medium::close(sessionState.video.rtspServer);
// any crashes happen above
delete sessionState.sched; // just to be sure
sessionState.env->reclaim();

In the case of MPEG, I created and Medium::close()d an 
MPEG4VideoStreamFramer as well, previous to this mess. Thanks for any 
insight.

And thanks for reading to the end. Cheers -
jb

Mon, 31 Jan 2005 11:07:55 -0800, finlayson at live.com (Ross Finlayson):
> Jeremy,
> 
> The JPEG header begins with


More information about the live-devel mailing list