First, my apologies for the long delay in responding to this question. (I have been traveling recently, including a couple of weeks “en vacances” in your wonderful (though unusually hot :-) country.)
> On Jul 12, 2018, at 9:32 AM, GENESTIER Denis > <denis.genest...@thalesgroup.com> wrote: > > Hi Ross, > > We do have to deal with special camera that display only raw video, i.e. > uncompressed format (RFC 4175). > We are aware that is an heresy to stream video in that way Not at all. This RTP payload format would not have been standardized if it wasn’t thought to have been appropriate. It’s perfectly appropriate to stream raw video over networks (e.g., corporate intranets) that can handle streams with this high bitrate (and with low packet loss). > In a first draft for supporting this, I am intending to create a subclass of > MultiFramedRTPSource (like RawVideoRTPSource.cpp) that would be created in > MediaSession.cpp. > That should allow a RTSP client to get that kind of stream. > > If I send you a patch, would you integrate it in your code? Yes, very likely. Do you also plan to implement this for transmitters - i.e., a subclass of “MultiFramedRTPSink”? After re-reading RFC 4175, I think that it should be possible to implement most of this payload format fairly easily, by reimplementing the “processSpecialHeader()” virtual function in your “MultiFramedRTPSource” subclass. The big problem, however, is going to be the ‘extended sequence number’ field. I see no way to implement the handling of ‘extended sequence numbers’ without making major changes to the code. The best solution for now would probably be to ignore this field - which will mean that receivers will unnecessarily drop some packets if they get excessively delayed. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
