[vlc-devel] Support for ONVIF Profile G

[David R. Robison]

I understand. I will use a scalar value instead. I think, in part, 
live555 used a char* to help with the argument type conflicts on the 
operator override, but there is no overriding reason to keep that in VLC 
other than convenience. I will work with scalars. David

David R Robison
Open Roads Consulting, Inc.
103 Watson Road, Chesapeake, VA 23320
phone: (757) 546-3401
e-mail: david.robison at openroadsconsulting.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526

On 7/15/2014 4:23 AM, Rémi Denis-Courmont wrote:
>    Hello,
>
> Le 2014-07-14 21:39, David R. Robison a écrit :
>> Thanks for the pointers. The reason for strings is because they match
>> the arguments in the RTSPClient::sendPlayCommand command from the live
>> code.
>
> And how does that work if the underlying stream is _not_ from an RTSP 
> URL?
>
> The standard for time representation in VLC is scalar, not string.
>
>> The only other approach I thought of was to use more command line
>> arguments, but I was afraid of adding too many command line arguments
>> and it would serve only the RTSP interface with the live555 code. Is
>> there any other approach you can think of? From reading you post it
>> seems there will need to be some structure to send data from the core
>> to the different plugins, in this case the demux plugin. Has this been
>> done before? Is there such a structure?
>
> If the parameters are potentially useful from demux instantiation all 
> the way until destruction, you need to extend demux_t. If the 
> parameters are only useful at start-up, adding parameters to the 
> activation function prototype is cleaner.



This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed.
If you are not the intended recipient, please delete this email immediately.