Thu, 24/06/2010 - 17:24
The level B extended model containing the proposed pair of publications for capturing CCTV information are available from http://www.datex2.eu/content/cctv-publications-extension.
The two publications reflect the separate static and dynamic nature of the information relating to CCTV cameras.
To make confidentiality efficient, I think we have to do 5 different URL.
example
I have 5 differents list of parteners for the 5 diffents levels of confidentiality.
I have 5 differents links to download videos.
I have a camera witch is generaly not confidential, so I publish the video to everybody with the same link, the "URL no restriction"
If a car accident happends in front the camera I break the link "no restricion" and give only to my parteners always allowed to see the video a "URL internalUse"
When the car accident is finished, I can publish the video with the initial "URL no restriction"
If you agree with that we have to precise that in the description of the attribute URL.
what do you think about that ?
Regarding confidentiality levels associated with each URL I think this can be directly associated with the ServiceLevel. If we add a serviceLevelDescription attribute into the CctvStillImageService class and the CctvVideoService class you can describe the confidentialty level you want to associate with each level. Of course different authorities will have different policies for this and so I don't think we can use an enumeration list here.
Why cctvPrivilegeOfCurrentControllingClient is an integer ?
There must be a signification to thoses numberses, so I think it's better to use an Enumeration like CctvControllingPrivilegeEnum.
I think we need an Enum with the different type of cctvVideoFormat as for StillImageFormatEnum : flv, mpeg4, mpeg2, mjpeg
We also need heigt, weidth.
A video can also be an extract with a time of begining and a lenght
What is OrientationImageUrl ?
cctvPrivilegeOfCurrentControllingClient is a non negative integer, where "1" is the highest privilege. I agree it would be better to use an enumeration but getting harmonisation of enumeration values for all different implementations across Europe will be very difficult. All that is really needed is an ordered list of privileges so I think integer values are ok.
An Enum for the different types of cctv video encoding would be good. Can we come up with a definite list as there are quite a number of possible formats out there? Is this list complete:flv, f4v, mpeg4, mpeg2, mjpeg. I think in practice most CCTVs will provide either mpeg2 or mpeg4 formats.
Ok I can add pixel height and width for cctv video
I don't think providing a video extract is what is produced by a camera. That is something which is done downstream. This publication is only defining the raw video that can be acquired from a camera so I don't think it is necessary to provide start and end times or video length parameters.
An orientation image URL is a reference to a fixed image which shows you what the image should look like when pointing in a defined direction. So if the real image shows the same road aspects and orientation you know that the camera is pointiung in that direction. This is useful to help clients know which way along the carriageway the camera is pointing by comparing the live image with this fixed orientation image.
Of course if you have just an order to describe privileges computers will be able to discuss :
-what is the priviege ?
-2
-ok 2.
But that is not enought for interoperability. Because if for the first computer "2" is ablility to move the camera but not to change its configuration, and for the second computer "2" is ablility to change camera's configuration but not moving it.......
So it's better to have an enumeration, give what you need, for exemple
the enumeration can be :
"moving"
"change configuration"
"see"
"all rights"
and the attribute
cctvPrivilegeOfCurrentControllingClient : controlingCameraPrivilegeEnum [0..*]
So you can describe any distribution of rights and other contries will complete the list if they need
The format we use are flv, mpeg4, mpeg2, mjpeg, H264 BP, H264BP+ and H264MP. You can had f4v but we are not using it yet.
In France we publish video extracts 30sec every 3 minutes, so we need to have the time of the vidéo and its lenght (no use for the time of the end of the vidéo, just begin and lenght)
It sounds like you publish video clips/extracts taken from a cctv camera's video stream. I think this requires its own publication as it requires each video clip to be separately identified and, as you have noted, to have its own start time stamp and length of play specified. That is something different from the 'raison d'être' of these publications. I guess such a publication could be formatted as a library of video clips which are available for downloading. Correct me if I am wrong, but if this is your requirement I think it needs a bit more discussion.
I am sure we can easily come up with a new publication to cover that requirement and it can probably reuse a lot of the entities defined in the current proposed CCTV publications.
ok, no matter if we don't have those two attributes.
(For information it is not realy a library of video clips.)
Thinking a bit more about this I think we could add a "videoServiceType" attribute into the CctvVideoService class of the CctvSiteTablePublication. This attribute could take values of "continuousVideoStream" or "videoClips" to describe the type of video service available from the CCTV camera.
If a "videoClips" type of service was specified we could add another aggregated class to allow you to specify that the video clips are of a defined length and are available at defined intervals. So in your case you could say in the static publication that video clips of length 30 seconds are available in blocks every 3 minutes from a particular camera.
The dynamic publication could then give the current status of this type of service from that camera as done for the other services.
perfect !
is it
a technical use of broadcast from on @ip to several @ip (in this case the very name of this technical use of adressing is multicast)
or
a fonctional use of the video : is it possible to show video to people on TV ? (in this case this is duplication)
In this context the "broadcastable" boolean determines whether the images/video are allowed to be provided to the general public by whatever means. I think the definition is clear on this. So in your terms it is the functional use of the images/video that is being defined here.
so isn't duplicate with ConfidentialityValueEnum ?
The "broadcastable" attribute does not overlap the confidentiality attribute in the HeaderInformation class. The confidentiality attribute in the HeaderInformation class applies to the information contained in the DATEX II publication only. That is how the HeaderInformation class is defined and how it is used in all the other publications. The "broadcastable" attributes in the CctvStatusPublication are applicable to the images and video streams. So we need both.
What VideoServiceLevel, cctvVideoZoomBlankingLevel and orientation ?
Is cctvVideoZoomBlankingLevel a level like
1 : global view
2 : view the event
3 : view a vehicle
?
In this case why not having a cctvVideoZoomBlankingLevelName as Multilingual String ?
The cctvVideoServiceLevel is an integer identifier assigned to that specific level of service provided by the camera. It's an arbitary identifier assigned by the video service provider and is used here in this class to identify a name for that service and the other various attributes for that service. Some cameras may only offer one level of service, but more sophisticated installations may allow a camera to offer a range of service levels each with their own characteristics/image resolution/quality and which can each have their own availability status (as defined in the CctvStatusPublication.
Similarly the cctvStillImageServiceLevel is an identifier for the still image service from a camera.
The ccvVideoBlankingLevel is a zoom factor at which the camera blanks automatically, i.e. if an operator/client tries to zoom in past this level the camera blanks. This is used in the Highways Agency system to inhibit personal details (e.g. number plates, recognisable faces, or disturbing accident images) being available to inappropriate clients or from being broadcast to the general public via the media.
ok, of course
why not having the information about Zoom of PTZ ?
Hello,
cctvCameraOrientationCompass (Enum)
This Enum is not as pricise as a definition with P.T.Z.
What is it for ? In your mind, is it possible to give this information insted of a ptz information ?
Hello,
I am wonderring about the attribute
cctvCameraOrientationBearing (angleInDegrees)
what is bearing ? is it the same as panning or tilting ?
thank's
Erwan,
The intension of this pair of CCTV publications is not to provide or replace the normal control type interfaces of CCTV systems. Hence the information provided is not at the detailed PTZ level. The information is only intended to provide potential clients with enough information to make a choice as to which cameras might be useful to access at any point in time and what types of images/video streams are available.
For example a service provider is not really interested in the detailed PTZ of the camera, but might need to know the general direction in which the camera is pointing and what image resolutions are available to make an informed choice of which cameras to access.
However it would be easy to add optional PTZ attributes to the CctvCameraStatus class if thought useful.
So if PTZ informations are not usefull, why having cctvEndStopMaxPTZValue attributes without cctvPTZValue attribute ?
If DatexII dealwith PTZ informations I think we have to do it with PTZValues.
I agree, there is a bit of inconsistency here. I am happy to add current PZT values into the CctvCameraStatus class although I am a bit hestitant since it is was never my intention that this publication is in anyway part of the control loop which is controlling a camera.
These publications were only intended to provide information to third parties to allow them to decide which camera's images they may wish to access or which cameras they may wish to take control of.