[Live-devel] H264 streaming problem

[gather bzbz]

The SPS and PPS showed up on the network once, per wireshark, so they did get sent out once at the beginning of the multicasting. So the questions, does that mean all the clients join later will not see SPS or/and PPS at all? How should that work? What do I need to do? Through SDP? Thanks!

--- On Wed, 2/25/09, gather bzbz <gbzbz at yahoo.com> wrote:

> From: gather bzbz <gbzbz at yahoo.com>
> Subject: Re: [Live-devel] H264 streaming problem
> To: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Date: Wednesday, February 25, 2009, 10:25 PM
> Right after I capture the buffer from the hardware and right
> before I pass the buffer for processing (memmove(fTo)), I
> write the buffer to a file, that file contains the correct
> the SPS and PPS. VLC/Mplayer can playback that file without
> problem. But the file saved by openRTSP does not have SPS
> and PPS. So who dropped them?
> 
> 
> --- On Wed, 2/25/09, gather bzbz <gbzbz at yahoo.com>
> wrote:
> 
> > From: gather bzbz <gbzbz at yahoo.com>
> > Subject: Re: [Live-devel] H264 streaming problem
> > To: live-devel at ns.live555.com
> > Date: Wednesday, February 25, 2009, 2:27 PM
> > <QUOTE>
> > The problem is that special headers called SPS and PPS
> > (sequence
> > parameter set and picture parameter set) are not
> included
> > in the file. 
> > Those headers may be carried in-band (which is
> probably not
> > your case)
> > or in the SDP.
> > My guess is that your source sent them in the SDP and
> not
> > in-band (in
> > the RTP stream), and that's why they are not found
> in
> > the file.
> > <QUOTE>
> > 
> > Now I am trying to understand the live555 codes,
> > 
> > 1. the SPS and PPS NALs are treated the same way as
> the
> > DATA NALs, right?
> > I mean, looking at the void
> > H264FUAFragmenter::doGetNextFrame() in
> H264VideoRTPSink.cpp,
> > do we need to actually parse the fInputBuffer for SPS
> and
> > PPS? I assume that SPS and PPS NALs are small enough
> to be
> > deliver "as is". 
> > 
> > 2. My understanding is that, most sources will give
> single
> > NAL per frame, so it is normally the case that
> > currentNALUnitEndsAccessUnit() returns TRUE. The FUA
> mode
> > means, even in single NAL/frame case, the NAL may be
> too big
> > for the MTU to carry, but we usually do not need to do
> > anything special because the void
> > H264FUAFragmenter::doGetNextFrame() in
> H264VideoRTPSink.cpp
> > has done all the job.
> > 
> > Thanks
> > 
> > 
> >       
> > _______________________________________________
> > live-devel mailing list
> > live-devel at lists.live555.com
> > http://lists.live555.com/mailman/listinfo/live-devel
> 
> 
>       
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel