Hi Ross, Thanks for taking the time to consider my requests.
I understand your wish to support IETF standards primarily and I take the hint about not 'for free' (that may be an option). Yes, ONVIF have added some extensions to achieve their goals. My understanding is that these extensions are allowed by the SDP and RTP standards. In case you are interested, I believe the ONVIF objective is to represent a set of non-contiguous media clips as a single container (a bit like a VOB but without the continuity of chapters). Imagine two video clips with duration T1 to T2 and T3 to T4 then the SDP would return a duration of T4-T1. During replay, the RTP timestamp header extension is used to indicate to the client the discontinuity at the T2 to T3 boundary. I don't think it's intended for human viewing in a player but for transfer of recordings from a camera to an archiver. I think this uses a valid timestamp header extension of the RTP spec but "bends" the SDP specification as it is not envisaged but not forbidden. However it is an unusual use case so is probably not of interest to the majority of LIVE555 stakeholders. In response to your specific points: 1. I think the ability of being able to add session level attributes of the form "a=x-" might well be useful to some people. As described above, it was not my objective but I can achieve that in other ways e.g subclassing the DESCRIBE handler which is already virtual although it is a bit more clunky. Thanks for considering it. 2. Here I was trying to work around the assumption that the session duration is the maximum of the subsessions. Yes indeed I was trying to return a duration for the entire collection i.e. T4-T1 in my example. I don't think this violates SDP but I can understand if you think it does and don't want to allow subclassing. 3. This was to handle a quirk of the ONVIF spec that wants each track enumerated with a special attribute e.g. video tracks get a=x-onvif-track:VIDEO001, 002, ... and audio tracks get a=x-onvif-track:AUDIO001, 002, ... and so forth. To me it seems a complete waste of effort since an SDP parser can easily work this out from the media level blocks following the session level lines. But I didn't write the spec, just the poor guy trying to comply with it. :( I know the subsessions are already virtual but by appending it in the ServerMediaSession I didn't have to add it for each type of video and audio subsession class in use. 4. This was always a completely different problem domain to 1, 2 & 3. Thanks for adding that, I think it will be useful to everyone. As you suggest, I can make changes under the LGPL but just thought I would check first whether you wanted to adopt any of them. Again thanks for taking the time to consider my request. Kind Regards, Mike Brimer Oncam Grandeye From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: 20 February 2014 17:39 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Changes to make it easier to subclass ServerMediaSession and set packet buffer size Michael, To begin with, it's important to note that 'ONVIF' is an industry consortium (and one that Live Networks, Inc. does not belong to) - not a standards organization. The relevant standards organization here (the one that we belong to, and whose specifications we try to adhere to) is the IETF. For the most part, 'ONVIF standards' are really just IETF standards that they have referenced 'as is'; in this case, we will try to support them ourselves. In some cases, however, 'ONVIF' may have made their own changes to SDP (or other IETF standards), without describing them in an IETF RFC or Internet-Draft; in that case, I feel no compulsion to support them in the "LIVE555 Streaming Media" software (and certainly not 'for free'). But having said that, let's look at each of the specific changes that you requested: 1. ServerMediaSession::generateSDPDescription() becomes a virtual method. Allows subclass to generate the SDP description in an independent manner e.g. database lookup. The reason I can't do this is that the existing "generateSDPDescription()" code is important. It explicitly generates 'session-level' SDP lines, followed by 'media-level' SDP lines for each "ServerMediaSubsession" - by calling "sdpLines()" (which, BTW, *is* a virtual function) on each subsession. If I were to make it possible for subclasses to completely replace this code, then there's no guarantee that the resulting SDP would be (1) standards compliant, and (2) in a form that would allow a client to properly operate on the session/subsessions. However, what I *might* do - sometime in the future - is provide a mechanism to allow developers to add their own 'session-level' attributes (i.e., beginning with "a=x-") to a SDP description. Perhaps that would give you what you want here?? 2. ServerMediaSession::duration() becomes a virtual method. Allows subclass to generate the duration in an independent manner e.g. database lookup. Note that "ServerMedia*Sub*session::duration()" is already a virtual function, so your "ServerMediaSubsession" subclasses can redefine "duration()" to return whatever you want. But the existing "ServerMediaSession::duration()" code is important (although admittedly a bit 'hacky'), and the code in several places makes assumptions about how "ServerMediaSession::duration()" works (basically, by returning the maximum of all the subsession "duration()"s, along with an indication of whether or not the subsession "duration()"s differ). So it can't be changed arbitrarily. Note that the child "ServerMediaSubsession"s are assumed to be 'concurrent' tracks within the parent "ServerMediaSession", so that the "duration()" of the parent is simply the maximum of the "duration()" of the children. I hope you're not proposing that media-level SDP lines (i.e., generated from "ServerMediaSubsession"s) within a SDP description mean something different that this. That's certainly not something that I could support, because that would be a non-standard interpretation of SDP (unless the SDP description also includes some IETF-defined 'grouping' mechanism that indicates otherwise). 3. Add a virtual method called ServerMediaSession::mediaSdpLines() and modify the implementation of ServerMediaSession::generateSDPDescription() to call mediaSdpLines() instead of calling subsession->sdpLines() directly. This seems unnecessary, because "ServerMediaSubsession::sdpLines()" is already a virtual function. 4. Modify MatroskaFile::createSourceForStreaming() implementation to check for larger values of OutPacketBuffer::maxSize before setting 300000 value. Allows server instantiation to set a larger value without it being ignored. With a full field-of-view I'm seeing a few warning messages being emitted during replay and therefore a larger value than 300000 is recommended. Yes, this is a good point. What I'll do (in the next release of the software) is define a new function "OutPacketBuffer::increaseMaxSizeTo(unsigned)" that doesn't change "OutPacketBuffer::maxSize" if it's already less than the specified value - and then change "MatroskaFile::createSourceForStreaming()" to call this new function instead. Needless to say, you are, of course, welcome to make whatever changes you want to your own copy of the code, provided that - in doing so - you comply with the LGPL; see http://www.live555.com/liveMedia/faq.html#copyright-and-license Ross Finlayson Live Networks, Inc. http://www.live555.com/ Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam. This message has been scanned for malware by Websense. www.websense.com
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
