[Live-devel] Confused about how to generate fmtp line for H.264 source for SDP
Matt Schuckmannn
matt at schuckmannacres.com
Wed Aug 3 10:04:53 PDT 2011
On Wednesday, August 03, 2011 6:14:13 AM, Ross Finlayson wrote:
> On Aug 2, 2011, at 6:45 PM, Matt Schuckmannn wrote:
>
>> I'm working on up grading our use of Live555 RTSP server code to the
>> latest version of the library, our old version was at least a couple
>> of years old.
>
> Good heavens; there have been *many* improvements and bug fixes since then!
Yes well, when we first adopted live555 we need RTPS over TCP to work
with sending commands like SET_PARAMETER during the stream, so we did
our own fix for that which made it difficult to keep up with your
changes, and until recently we didn't have time to convert over to your
new code.
> Yes. Now, the SPS and PPS NAL units are assumed to be in the input NAL
> unit stream (and are extracted from there).
Is that a safe assumption, isn't optional to include the SPS and PPS
NAL units in the stream? or at the very least make the very infrequent?
>
> That means that if we're streaming a H.264 stream 'on demand'
(e.g.,
> from a unicast RTSP server), we have to do a little trick (hack) to get
> this information for use in the stream's SDP description, before we
> start delivering to the first client. Basically, we have to 'stream' the
> input source to a dummy sink, until we see the data that we need.
>
> The place to do this is in your subclass of "ServerMediaSubsession" for
> H.264 video. Specifically, you reimplement the "getAuxSDPLine()" virtual
> function.
>
Hmm, I'll look into it, but my encoder gives me the sps and pps when I
initialize it, it seems like it would be easier to just hand the sps
and pps to the rtp sink and just re-implement auxSDPLine in my class,
pretty much like I used to do. Is there a reason your recommending this
approach
> For a model of how to do this, see our implementation of
> "H264VideoFileServerMediaSubsession". You will presumably do something
> similar, except with your own subclass. (Of course, as always, you will
> also implement t
he "createNewStreamSource()" and "createNewRTPSink()"
> virtual functions.)
Thanks,
Matt S.
More information about the live-devel
mailing list