[Live-devel] Re: Problem about on-demand unicast live streaming

[worm520]

> At 04:47 AM 7/1/05, you wrote:
> >The FAQ mentions that one can pipe stdin of the test***Streamer with
> >the stdout of a encoder to do live streaming. I tried and it works
> >fine.  Next, I'd like to apply it to the testOnDemandRTSPServer (I
> >modify the inputFileName as "stdin") but get into troubles:
> 
> You should also change the variable "reuseFirstSource" (near the top of
> "testOnDemandRTSPServer.cpp") to "True".  This tells the server not to try
> to create a new copy of the input source (in this case, 'stdin') for each
> new client, but instead to reuse the existing source.
> 
> >If the stdin is from a local file ( via I/O redirection ), the player
> >(such as VLC ) just receives some last several frames of the file from
> >the testOnDemandServer.
> 
> The change noted above will probably fix this.

Yes, I have tried it but this seems helps little even if there's only
one player instance.
 
> >When I try to pipe it with an encoder, nothing
> >is played. I did some source tracing and sees that some unknown
> >FramedSource not the ByteStreamFileSource associated with stdin calls
> >doGetNextFrame()  and reads bytes repeatedly.
> 
> If you're still having problems with this, then try the following:
> 1/ Create a data file with output from your encoder.
> 2/ Rename this file as "test.<whatever>" (e.g., "test.m4v" for MPEG-4
> Elementary Stream video).
> 3/ Run the (original, unmodified) "testOnDemandRTSPServer", and see if you
> can play a stream from your file.  If you can't, then your file is probably
> in the wrong format, and you'll need to check the settings on your encoder.

Actually, it works well if I save the output of the encoder as
test.m4v and run the testOnDemandRTSPServer. However, I cannot figure
out why the behavior is abnormal if the output file serves as the
stdin of the program, not to mention to pipe it with the encoder.

I did the source tracing by adding some output at certain points and
compare the messages in normal and abnormal cases. I guess the
FramedSource::afterGetting() is the scheduled task in
doGetNextFrame(). In this case, it should be
MultiFramedRTPSink::afterGettingFrame (the super class of
MPEG4ESVideoRTPSink). The scheduled task is executed in normal case
but not in the abnormal case after some framedsource reads the frame.
Maybe I get some misunderstanding of the source. If so, I shall feel
so sorry for that. Again, thanks for spending your time solving my
problem.

worm