> in MultiFramedRTPSource::doGetNextFrame1, why 'if
> (fCurrentPacketCompletesFrame && fFrameSize > 0)' need 'fFrameSize > 0',
> fCurrentPacketCompletesFrame is true, the frame is completes,then can break
> the while, is not it?
I’m not going to answer your question. Here’s why:
I’ve fou
--- Begin Message ---
in MultiFramedRTPSource::doGetNextFrame1, why 'if
(fCurrentPacketCompletesFrame && fFrameSize > 0)' need 'fFrameSize > 0',
fCurrentPacketCompletesFrame is true, the frame is completes,then can break
the while, is not it?
wangdanhui...@aliyun.com
--- End Message ---
> Ok then how to fix/debug further this message and SIGSEGV ? Seems like
> nobody is using the source twice but the bug is still present.
Something is definitely reading from the source more than once (at the same
time). I *thought* that it was the call to “startPlaying()” at line 948 of
“playC
> > Though passing the data through stdin is ugly solution
> I don?t think it?s ugly at all. In fact, it?s quite clean, because it uses
> familiar Unix I/O stdio and pipes, rather than requiring extra programming.
Returning to the stdout->stdin approach: the same SPS/PPS problem is
present here
> stream? If that?s the case, then you?ll have to implement the
> ?getAuxSDPLine()? virtual function in your ?H264LiveServerMediaSession?
> class. For guidance on how to do this, see how we implement the
> ?H264VideoFileServerMediaSubsession? class.
Ok, this approach seems to work - though it p
> > While the H264LiveServerMediaSession constructor is called once - the
> > createNewRTPSink/createNewStreamSource are called twice (?!) upon RTSP
> > connection. May be this is the real reason of
> > "FramedSource[0x1bf42e0]::getNextFrame():
> > attempting to read more" message ?
>
> No, I don
