CCTV Fight Detection

CCTV BASED FIGHT CLASSIFICATION
Final Year Project
2019-2023
A project submitted in partial fulfillment of the degree of
BS in Computer Science
Submitted to
Mr. Hafiz Saud Arshad
Department of Computer Science
Faculty of Computing & Artificial Intelligence (FCAI)
Air University, Islamabad

Project Report: CCTV based fight Classification
Type (Nature of project) [] Development [ ] R&D
[] WebApp [ ] Mobile App

Area of specialization
[ ] AI based [ ] Embedded System
FYP ID IT-SP-21-18
Project Group Members
Sr.# Reg. # Student Name Email ID *Signature
Samreen
(i) 181337 181337@students.au.edu.pk
Tabbasam
Muhammad
(ii) 181339 181339@students.au.edu.pk
Ahsan Farooq
(iii)
*The candidates confirm that the work submitted is their own and appropriate credit has been
given where reference has been made to work of others
Department of Computer Science, Air University, Islamabad, Pakistan 2

Plagiarism Certificate
This is to certify that, I ________ S/D of ____________________, group leader of FYP under
registration no ______________________________at Computer Sciences Department, Air University. I
declare that my FYP report is checked by my supervisor.
Date: ______________ Name of Group Leader: _____________________ Signature: ________
Name of Supervisor: Mr. Hafiz Saud Arshad Co-Supervisor: (Not Allocated)

Designation: Lecturer Designation: (N/A)
Signature: ________________ Signature: _________________
HoD: Dr. Awais Ahmad

Signature: _______________

CCTV based fight classification
Change Record
Author(s) Version Date Notes Supervisor’s Signature

APPROVAL
PROJECT SUPERVISOR
Name: Hafiz Saud Arshad
Date:_______________________________ Signature:_________________________
PROJECT MANAGER
Date:_______________________________ Signature:__________________________
CHAIR DEPARTMENT
Date:_______________________________ Signature:__________________________

Dedication
This work is dedicated to our parents who have failed to give us financial and
moral support. We dedicate this project to our supervisor who have worked hard
to help us complete this project. We will always appreciate all they done for
helping us develop our technical skills

Acknowledgements
I am really thankful to my supervisor/university/friend who has . . . . . . . . . .

Executive Summary
[An executive summary summarizes a longer report or proposal or a group of related reports in
such a way that readers can rapidly become acquainted with a large body of material without
having to read it all. This section summarizes the overall document, and should include the
important highlights from the document. It should be concise. It is NOT an introduction, index or
table of contents, it is a summary. The Executive Summary should not make any reference to
other parts of the document. You have to write one page to let reader understand an overview of
the project.]

Table of Contents
Plagiarism Certificate.....................................................................................................................iii
Dedication.......................................................................................................................................vi
Acknowledgements.......................................................................................................................vii
Executive Summary [16pt, Times new roman, bold]...................................................................viii
Table of Contents............................................................................................................................ix
List of Figures................................................................................................................................xii
List of Tables................................................................................................................................xiii
List of Abbreviations....................................................................................................................xiv
Chapter 1..........................................................................................................................................1
Introduction & Background.............................................................................................................1
1.1. Background [16pt, Bold, Times new Roman]..................................................................2
1.2. Motivations and Challenges..............................................................................................2
1.3. Goals and Objectives........................................................................................................2
1.4. Literature Review/Existing Solutions...............................................................................2
1.5. Gap Analysis.....................................................................................................................2
1.6. Proposed Solution.............................................................................................................2
1.7. Project Plan.......................................................................................................................2
1.7.1. Work Breakdown Structure...........................................................................................3
1.7.2. Roles & Responsibility Matrix......................................................................................3
1.7.3. Gantt Chart....................................................................................................................3
1.8. Report Outline...................................................................................................................3
Chapter 2..........................................................................................................................................4
Software Requirement Specifications..............................................................................................4
2.1. Introduction.......................................................................................................................5
2.1.1. Purpose [14pt, Times new Roman, Bold].....................................................................5
2.1.2. Document Conventions.................................................................................................5
2.1.3. Intended Audience and Reading Suggestions...............................................................5
2.1.4. Product Scope................................................................................................................5
2.2. Overall Description...........................................................................................................6
2.2.1. Product Perspective.......................................................................................................6
2.2.2. User Classes and Characteristics...................................................................................6
2.2.3. Operating Environment.................................................................................................6
2.2.4. Design and Implementation Constraints.......................................................................6
2.2.5. Assumptions and Dependencies....................................................................................7
2.3. External Interface Requirements.......................................................................................7
2.3.1. User Interfaces...............................................................................................................7
2.3.2. Hardware Interfaces......................................................................................................7
2.3.3. Software Interfaces........................................................................................................7
2.3.4. Communications Interfaces...........................................................................................8
2.4. System Features................................................................................................................8
2.4.1. System Feature 1...........................................................................................................8
2.4.1.1. Description and Priority.............................................................................................8
2.4.1.2. Stimulus/Response Sequences...................................................................................8
2.4.1.3. Functional Requirements...........................................................................................8

2.4.2. System Feature 2...........................................................................................................9

2.4.2.1. Description and Priority.............................................................................................9
2.4.2.2. Stimulus/Response Sequences...................................................................................9
2.4.2.3. Functional Requirements...........................................................................................9
2.4.3. System Feature 3 (and so on)......................................................................................10
2.5. Nonfunctional Requirements..........................................................................................10
2.5.1. Performance Requirements.........................................................................................10
2.5.2. Safety Requirements....................................................................................................10
2.5.3. Security Requirements................................................................................................10
2.5.4. Usability Requirements...............................................................................................10
2.5.5. Reliability Requirements.............................................................................................10
2.5.6. Maintainability/Supportability Requirements.............................................................11
2.5.7. Portability Requirements.............................................................................................11
2.5.8. Efficiency Requirements.............................................................................................11
2.6. Domain Requirements.....................................................................................................11
Chapter 3........................................................................................................................................12
Use Case Analysis.........................................................................................................................12
3.1. Use Case Model..............................................................................................................13
3.2. Use Cases Description....................................................................................................14
Chapter 4........................................................................................................................................15
System Design...............................................................................................................................15
4.1. Architecture Diagram......................................................................................................16
4.2. Domain Model................................................................................................................17
4.3. Entity Relationship Diagram with data dictionary..........................................................18
4.4. Class Diagram.................................................................................................................18
4.5. Sequence / Collaboration Diagram.................................................................................19
4.6. Activity Diagram.............................................................................................................20
4.7. State Transition Diagram................................................................................................20
4.8. Component Diagram.......................................................................................................21
4.9. Deployment Diagram......................................................................................................21
4.10. Data Flow diagram [only if structured approach is used - Level 0 and 1]..................22
Chapter 5........................................................................................................................................23
Implementation..............................................................................................................................23
5.1. Important Flow Control/Pseudo codes............................................................................24
5.2. Components, Libraries, Web Services and stubs............................................................24
5.3. Deployment Environment...............................................................................................24
5.4. Tools and Techniques.....................................................................................................25
5.5. Best Practices / Coding Standards..................................................................................25
5.6. Version Control...............................................................................................................25
Chapter 6........................................................................................................................................26
Business Plan.................................................................................................................................26
6.1 Business Description.......................................................................................................27
6.2 Market Analysis & Strategy............................................................................................27
6.3 Competitive Analysis......................................................................................................27
6.4 Products/Services Description........................................................................................27
6.5 SWOT Analysis..............................................................................................................27

Chapter 7........................................................................................................................................28
Testing & Evaluation.....................................................................................................................28
7.1 Use Case Testing.............................................................................................................29
7.2 Equivalence partitioning.................................................................................................30
7.3 Boundary value analysis.................................................................................................30
7.4 Data flow testing.............................................................................................................30
7.5 Unit testing......................................................................................................................30
7.6 Integration testing...........................................................................................................30
7.7 Performance testing.........................................................................................................31
7.8 Stress Testing..................................................................................................................31
Chapter 8........................................................................................................................................32
Conclusion & Future Enhancements.............................................................................................32
8.1 Achievements and Improvements...................................................................................33
8.2 Critical Review...............................................................................................................33
8.3 Lessons Learnt................................................................................................................33
8.4 Future Enhancements/Recommendations.......................................................................33
Appendices....................................................................................................................................34
Appendix A: Information / Promotional Material.........................................................................35

List of Figures
1.1 Caption of first figure of first chapter 6

1.2 Caption of second figure of first chapter 7
2.1 Caption of first figure of second chapter 14
2.2 Caption of second figure of second chapter 22
2.3 Caption of third figure of second chapter 26
5.1 Caption of first figure of fifth chapter 49
5.2 Caption of second figure of fifth chapter 49

List of Tables
1.1 label of first table of first chapter 6
1.2 label of second table of first chapter 7
2.1 label of first table of second chapter 14
2.2 label of second table of second chapter 22
2.3 label of third table of second chapter 26
5.1 label of first table of fifth chapter 49
5.2 label of second table of fifth chapter 49

List of Abbreviations
1.1 UML Unified Model Notation
1.2 SRE Software Requirement Engineering
2.1 SDR Software Defined Radios

Chapter 1
Introduction & Background

Chapter 1: Introduction
Violence detection has become the active and progressive research topic in the field of computer
vision and Al. Automatic violence detection can be useful in many areas for the security purpose.
Violence detection consist of different domain like activity detection, fight detection, action
recognition, we mainly focus on fight detection for this purpose two approaches are used 1)
Feature Extraction and 2) Classification. This chapter contains the means and methods that are
used to achieve the goals and objective of our product.
1.1. Background
Today the society highly depends on CCTV for the security purpose, but the CCTV footage is
not very effective because they are only used after hours or evens days of the occurrence of some
incidents. The systems that are commonly used are semi-automated and human supervision is
needed to monitor the video from the CCTVs which cannot be very reliable in most cases
because human is prone to error and one cannot precisely monitor some fight activity because of
the number of videos from different CTTVS. There are many researches to transform the semi-
automated systems to fully automated using the different techniques of Artificial Intelligence and
deep learning.
1.2. Motivations and Challenges

In the existing system, activities are monitored manually from the screens of the surveillance
camera. To recognize activities like fights or other security-related issues continuous monitoring
is required which is not possible for us human beings. Manual monitoring in case of fight
detection cannot be very effective and useful because of work boredom, lack of concentration of
the person, and quick action cannot be taken if these activities are not timely detected. Fully
automated systems can quickly and easily detect fight activities using computer vision and
machine learning and can be proved more effective and efficient than semi-automated existing
systems. The fight can be raised from different events like hated discussion, hate speech or
anger, etc. However Human activity recognition can be a challenging task due to the
inconsistency of light, and bad quality of CCTV footage during real-time classification.

1.3. Goals and Objectives

Image Processing and machine learning techniques have proved to be very useful in extracting
the information from the CCTV videos in much efficient and faster way then any human
observer. Our goal is to propose an approach that can detect fight from the real life CCTV videos
of fight because most of the existing work is done on the videos from public datasets that are
manifested as fight
The Objectives of our project are
 To automate and facilitate the processing of visual information in terms of security
monitoring and detection of fighting scenes.
 To develop a desktop-based application that can be used to feed in an input sequence and
get explicit predictions
1.4. Literature Review/Existing Solutions

[Paragraph Text 12 pt, Times New Roman, 1.5 Line Spacing, Justified]
1.5. Gap Analysis

Many researchers have used frame-based feature extraction techniques and then used the
discriminative model for classification purposes. There is very little work in which the
spatiotemporal features are extracted from CCTV videos. Moreover, many types of research
don’t contain any strong evaluation mechanisms like K-fold that ensure that the model is
evaluated correctly nor there is any evidence of the performance of the model in the real world
scenario. For this reason, it is necessary to make a new dataset that contains videos of real fights
from the CCTV to ensure the performance of the model and to come up with ha strong
evaluation strategy.
1.6. Proposed Solution


1.7. Project Plan

1.7.1. Work Breakdown Structure
1.7.2. Roles & Responsibility Matrix

1.7.3. Gantt Chart

1.8. Report Outline

Problem statement:
 Human operators are overwhelmed with the number of camera feeds and manual
response times are slow, resulting in a strong demand for automated alert systems.
 Similarly, there is increasing demand for automated rating and tagging systems that can
process the great quantities of video uploaded to websites.
 To solve this problem a fight scene detection application can be built to detect fight
scenes so that further actions can be taken for the violent video.
General description:
In a semi-automated system, Fight events are monitored manually through the monitor screen of
a surveillance camera. This is not beneficial because continuous monitoring is required, but
watching screens continuously to recognize fight event is difficult. There is no scope for
carelessness while monitoring such activities because these can occur at any time. There is a
need to transform such semi-automated systems into fully automated intelligent systems that can
detect and recognize violent activities without human supervision. Fully automated systems can
detect human activity through computer vision and machine learning and are more effective and

efficient in detecting object movements and recognizing human activity as compared to semi-
automated systems. Human activity recognition is a difficult task because of many factors such
as real-time classification, low video quality of surveillance cameras, and inconsistent light
intensity during monitoring
Results:
Only the documentation and the front end will be produced for the time being, as that is how the
flow of work will be taken and how our application will appear
Conclusions:
We as a two team members learned a lot from this project as in developing this project many
libraries are being used which helped us in developing the web application and which will also
help us to use these libraries in different project at market place level and we will also be able to
learn to integrate the AL/ML algorithms with the web application

Chapter 2
Software Requirement
Specifications

Chapter 2: Software Requirement Specifications

2.1. Introduction
2.1.1. Purpose
The purpose of the SRS document is to clearly describe the requirements and specification of our
product. Our product is the automatic fight detector that is a desktop application which will take
the video from the CCTV, predict the events and classify them as fight or no fight. This
application can be very useful in the security domain and public areas where there are videos
from many CCTVs that are difficult for humans to monitor. It can be helpful in predicting the
fight activities in schools, prisons, playground streets etc. and timely actions can be taken if such
activities are detected.
2.1.2. Document Conventions

The SRS document uses few different font sizes for clear distinction. For example, 14pt for the
heading and 12pt for the paragraph text. The main headings are numbered with whole numbers
like 1. Purpose 2. Overall description. The subheadings are numbered with decimals like 2.1.1
purpose, 2.1.2 document conventions etc. All the requirements mentioned in the document have
their own priority.
2.1.3. Intended Audience and Reading Suggestions

This article is for the authors, users and developers of this product. The document above already
discusses the paper's purpose, scope, motivation, aims, and objectives. The following is the rest
of this SRS:
• Product perspective
• User interfaces
• Functional requirements
• Non-functional requirements
• System features etc.
This article will give a clear vision and work flow of our project. A reader should start reading
from Introduction, as it will give the reader a clear perception of what our project is. Then the

Goals and objectives and Project plan, to get the idea of how our project work. To know the
detailed working and flow of the project, the reader should check the diagrams as it will hive the
visual image of the system. To know that how a user will interact with the system, and what will
be the usage scenarios w.r.t the product.
2.1.4. Product Scope

The possible application areas for our product can include different public and private sectors:
 Law enforcements
 Public safety ensuring
 Crowd monitoring
 Surveillance cameras install in schools, prisons, offices, restaurants etc.
The main focus of this technology is to help the law enforcement department in preventing the
breakthrough of fight through automatic fight detection and security alerts.
2.2. Overall Description

2.2.1. Product Perspective
This product is intended to be a replacement for current platforms. Many fight detection projects
are already capable of detecting fighting events in the videos that are collected from movies
scenes or are performed by some actors. The project we're working on is a fight detection
platform with a few differences, such as the dataset is collected from the real surveillance videos
in which the real fights scenes are shown, so it can give the good accuracy if it was to be
extended as the real time fight detection desktop app.
2.2.2. User Classes and Characteristics

All those who are related to security cameras surveillance (e.g. police, security guards etc.) will
be our supreme users. Frequency of use of our platform would be high because our application
would be used by the people who are related to surveillance domain and today security cameras
are almost used everywhere.

2.2.3. Operating Environment

We have developed a desktop application using pyQt, our application will run in the operating
environment of windows 10 most probably. For now only the prototype of the project has been
developed that runs on the localhost.
2.2.4. Design and Implementation Constraints

 The surveillance camera should be connected in order to get video feed for the
predictions.
 The fight detection system is running 24 hours a day
 The users can download the app from any browsers that has the internet connection
2.2.5. Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend to
reuse from another project, unless they are already documented elsewhere (for example, in the
vision and scope document or the project plan).>
2.3. External Interface Requirements
2.3.1. User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on.
Define the software components for which a user interface is needed. Details of the user interface
design should be documented in a separate user interface specification.>

2.3.2. Hardware Interfaces

The hardware required is the surveillance camera that is used for the video feeds. Other than that
only the recommended configuration (Basic requirements of the computer systems) no other
specific hardware is required to run the application.
2.3.3. Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>
2.3.4. Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>
2.4. System Features

<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>

2.4.1. System Feature 1

<Don’t really say “System Feature 1.” State the feature name in just a few words.>
2.4.1.1. Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as benefit,
penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>
2.4.1.2. Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.>
2.4.1.3. Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should
respond to anticipated error conditions or invalid inputs. Requirements should be concise,
complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate
when necessary information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a meaningful

tag of some kind.>
REQ-SF1-1: <Write your requirement here>

REQ-SF1-2:
REQ-SF1-3:
2.4.2. System Feature 2

<Don’t really say “System Feature 1.” State the feature name in just a few words.>
2.4.2.1. Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as benefit,
penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

2.4.2.2. Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.>
2.4.2.3. Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should
respond to anticipated error conditions or invalid inputs. Requirements should be concise,
complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate
when necessary information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a meaningful

tag of some kind.>
REQ-SF2-1:
REQ-SF2-2:
REQ-SF2-3:
2.4.3. System Feature 3 (and so on)
2.5. Nonfunctional Requirements

2.5.1. Performance Requirements
The system should be able to accommodate the different video feeds from multiple cameras
2.5.2. Usability Requirements

 The application will be fully functional mainly on the windows operating system.
 The interface is easy to learn and navigate.
 Goal is easy to accomplish quickly with few errors

2.5.3. Maintainability/Supportability Requirements

 Client will handle all non-technical support issues.
 Company will handle all technical issues related to the application functionality.
 Time-to-time updates of the system will be provided

Chapter 3
Use Case Analysis

Chapter 3: Use Case Analysis

This Chapter consist of the use cases analysis for our product that we have designed by gathering
and analyzing the requirement for the system.
3.1. Use Case Model
Figure 1: Use Case for CCTV video classification

3.2. Use Cases Description
3.2.1. Record Video

Title Record Video
Requirement User’s Camera should be connected
Rational Upload/record a video
Restriction or Risk Camera not connected/Video not uploaded
Dependency Pc, Internet connection
Priority timing
Table 1: Record Video Function
Use case 1
Record Video
Actor
 Regular User/Camera
Preconditions
 Camera should be connected
Basic flow
 User will upload the video from the system or will record the video from the camera
Alternate flows
 User don’t want to view result
Post Condition
 Video is uploaded
Table 2: Record Video Function: Use Case 1
3.2.2. Predict Video
Title Predict Video
Requirement Video must be uploaded
Rational Upload/record a video
Restriction or Risk Camera not connected/Video not uploaded
Dependency Pc, Internet connection
Priority accuracy
Table 3: Record Video Function
Use case 1
Predict Video
Actor
 Regular User/Camera
Preconditions

 Camera must be connected/ The video must be uploaded before detection

Basic flow
 User will upload the video from the system the prediction will be made by the pre-trained
model as fight/nofight
Alternate flows
 User don’t want to view result
Post Condition
 The alert will be generated on user’s UI if the fight is detected
Table 4: Predict Video Function: Use Case 1

Chapter 4
System Design

Chapter 4: System Design

When users start up the application, the CNN model will first be loaded into memory. Then users
will be allowed to choose their video/file of their choice or open the camera. After selecting their
desired video, users can start the prediction process by clicking on the start button. The
Prediction Pipeline of a Model starts with Pre-processing of Data Sample followed by feature
extraction. After that features from the videos are fed to model. The Model predicts the Video as
‘Fight’ or ‘No Fight’ and generates the alert when the fight is detected. The prediction is
displayed on the UI of the user.
4.1. Architecture Diagram
INTERFACE
Figure 2: Architecture Diagram

4.2. Sequence / Collaboration Diagram
3: Sequence Diagram
4.3. Activity Diagram
Figure 4: Activity Diagram

4.4. State Transition Diagram
Figure 5: State transition diagram

4.5. Flow diagram

Chapter 5
Implementation

Chapter 5: Implementation
We have evaluated our fight detection technology on a 300-video fight dataset. After
preprocessing and features extractions. We split the data into training and testing subsets on the
basis of which the model is trained to give the predictions of fight/nofight events
5.1. Important Flow Control/Pseudo codes

5.2. Components, Libraries, Web Services and stubs

The software & libraries for the fight classification project are:
 Python (3.7.4)
 Pandas
 Numpy (version 1.16.5)
 openCV (version 3.4.2)
 Keras (version 2.3.1)
 Tensorflow (as keras uses tensorflow in backend and for image preprocessing)
5.3. Deployment Environment

PYCHARM.
5.4. Tools and Techniques

 Train and validate models and develop a machine learning pipeline on IDE (google
colab) using Python.
 Build a basic front-end with an input form for local machine or webcam
 Build a back-end of the web application using a CNN.
 Deploy the app on Windows using MSIX. Once deployed, it will become publicly
available and can be used on the system of users.

Chapter 6
Business Plan

Chapter 6: Business Plan

An efficient surveillance system is a large-scale computer vision, data analysis, and decision
making challenge. Hence the ‘smart’ approach to extracting information from the surveillance
footages employs the synergy of several innovative technologies that power the next key
components of the Smart Surveillance Systems.
6.1 Business Description

Fight detection will be especially useful for real life applications regarding video surveillance.
Video surveillance equipment and systems can be set up virtually everywhere however, beyond
their ability to record and stream recordings, their capabilities are quite limited. Our product will
solve the problem of continuous monitoring of videos from CCTV and human work by
automatically predicting the fight scenes from CCTV and alerting the authorities about fight. Our
Product will encompass the worth perception that the customers are expecting as there can be
any chance of fight breaking out near shops , neighborhoods , inside buildings and on roads.
6.2 Market Analysis & Strategy

Fight Detection app provides a useful growth strategy that any application based businesses can
consider. It offers market penetration and diversification. Our aim is to seek attention of the
market by attracting first time users of a product, encouraging existing customers to increase
purchase and winning customers from competitors. By doing this we can increase our products
market value. We would implement Competitive pricing strategy to win customers from
competitors by introducing slight price difference. We will use strategy of communicating with
consumers reminding new, ex-users or non-users that why our product is a “must have.”
6.3 Products/Services Description

With the aim of expanding the range of our fight detection Surveillance Systems solutions that
already cover a fight detection technology that can be easily integrated with any security system.
Its primary function is to ensure public safety through visual crowd surveillance, so any violent
activity generates automatic security and police alert. The fight detection module can be

incorporated into the surveillance systems installed in airports, schools, parking lots, prisons,
shopping malls, and other indoor and outdoor public access areas. Through the application of
image processing and machine learning techniques, Smart Surveillance Systems are able to
extract and interpret the information from the CCTV footages faster and much more efficiently
than any human observer. Moreover, all of the components work together in a flexible
environment so they can be customized to serve a specific purpose that can also change over
time.
6.4 SWOT Analysis


Chapter 7
Testing & Evaluation

Chapter 7: Testing and Evaluation

In the testing and evaluation phase we have compared the components of our system against the
requirements and specifications. There were only two use cases for our system against which the
test cases are created. The results are evaluated to assess the design progress and performance.
Through the testing phase the quality of the product is assured and in evaluation phase
judgements are made based on the criteria and evidence
7
7.1 Use Case Testing (Test Cases)
Test Case – 1
Test Case ID TC_001 Test Case Test that the desktop app is
Description connected to some video source
Created By Samreen Reviewed By Saud Version 1.0
QA Tester’s Log Review comments from saud incorporate

in version 1.1
Tester's Name Samreen Date Tested 29-Mar- Test Case Pass

2022 (Pass/Fail/No
t Executed)
S# Prerequisites: S# Test Data

1 Access to Chrome Browser 1 Camera is connected
2 Access to Internet 2 App can capture the
Video stream from
camera
3 Access to video source
Test On click of the start button the web app should be

Scenario connected and running
Step # Step Details Expected Results Actual Results Pass / Fail / Not
executed /
Suspended
1 Navigate to Site should open As Expected Pass
https://example.com

2 Start the Video Webcam should As Expected Pass

Stream be connected
3 Click Start The video should As Expected Pass
be running in the
canvas
Test Case – 2
Test Case ID TC_002 Test Case Test that the Model correctly
Description predicts the video from webcam
Created By Samreen Reviewed By Saud Version 1.0
QA Tester’s Log Review comments from saud incorporate

in version 1.1
Tester's Name Samreen Date Tested 29-Mar-2022 Test Case Pass

(Pass/Fail/
Not
Executed)
S# Prerequisites: S# Test Data

1 Camera is connected 1 Prediction Model is loaded
2 Video Stream from camera is 2 Predictions are displayed
running in the label

Test On click of the predict button the web app should be to

Scenario provide the prediction of fight on the video stream from
the webcam
Step # Step Details Expected Actual Results Pass / Fail / Not

Results executed /
Suspended
1 Click Predict Button Prediction results As Expected Pass
are displayed in
the label
7.2 Equivalence partitioning

<Perform equivalence partitioning testing for all possible use cases and functions which takes
some parameters and use values in any kind of operation>

Serail NO Description Input Expected Note
1 Start Valid Camera is Video is ----

TEST CASE 1 connected and recorded
running
2 Start Invalid Camera not Camera not Please connect
TEST CASE 1 connected selected , Error to a camera
message will be
displayed
3 Predict Valid Video From the Predicted label -----
TEST CASE 2 camera is passed will be displayed
to prediction on the screen
model
4 Predict Invalid The video is not Error message Start the video
TEST CASE 2 captured from will be displayed
the camera
7.3 Boundary value analysis

<Perform Boundary value testing for all possible use cases and functions which takes some
parameters and use values in any kind of operation>
7.4 Data flow testing

Perform data flow testing according to the sequence and dataflow diagram in above design
section.

7.5 Unit testing

<Individual testing of all components and functionalities/features of your application/web
site/product. For example, if your application has location tracking and location sending two
different features so you should do individual testing for both of them the you have to show
results/final outcome also mention the testing process along with pass and fail result of test.>
7.6 Integration testing

<Perform integration testing of all combined features and components of your product. For
example if your product have a backend database connected with mobile application web portal
then you should check the API level data transfer and between all of them. You also mentioned
methods you used for integration testing.>
7.7 Performance testing

7.8 Regression Testing

Regression testing is a software testing practice that ensures an application still functions as
expected after any code changes, updates, or improvements.

7.9 Stress Testing

Stress Testing determines the stability and reliability of the system. In other words stress testing
defines the limits at which our system breaks.

Chapter 8
Conclusion & Future
Enhancements

Chapter 8: Conclusion & Future Enhancements
8
8.1 Achievements and Improvements
Initially we used the video sequence as input and generated frames. Some frames were selected
from each video clip using image subtraction and averaging techniques and Histogram of
Oriented Gradient (HOG) is applied to extract lower level features. The extracted features from
the videos were given to the trained model which predicts the fight or no fight events. The model
was trained using Logistic Regression, Random Forest and Decision Tress Classifier are used for
the classification purpose. As the videos were of different resolutions, we have resized them to
be 28 x 28 pixels for our CNN architecture. We down sampled the frame to make the training
faster. Thirty frames have been extracted per second from the videos. The CNN model prevents
overfitting by applying regularization techniques like kernel regularizers and dropout of 0.5. The
cost function of this model is binary cross entropy and the optimizer is ‘adam’
Moreover, we have extracted features from our videos using VGG16 and ResNet50. VGG16 is a
simple deep convolutional neural network architecture. It has a deep stacked layered CNN
followed by two fully connected layers which have 4096 neurons on each of them. The output
layer has a softmax classifier. ResNet50 is a deeper model than VGG19 but it proposes very
interesting architecture consisting residual modules. Interestingly, despite of being deeper than
the VGG models, the model size of ResNet50 is much smaller than them because it uses global
average pooling rather than fully connected layers. We have used Keras deep learning library
with TensorFlow backend to implement our desired models and pyQt for the frontend
development.
8.2 Lessons Learnt

This project taught us how to understand the problem situation, the use cases and how to solve
the certain problems that can happen in real life. Besides these we also learned a lot of new skills
rather than just development.

Teamwork
I learned teamwork in order to motivate my fellow members to achieve the right and effective.
Python language and different libraries used in ML

We have learned about how the different libraries and models used in machine learning works
and how are they useful.
Understanding the User Requirements
While working on the project I learned what things we have to consider before developing the
new feature. What kind of benefit this will provide to the user. Understanding the user
requirement make the development of the feature and module very easy
Importance of Prospect of Performance
The one of the most important thing I learned in this project was keeping in mind the aspect of
performance in the mind. The things sometimes become very complex but it is a great learning
opportunity as it will allow us to thing outside of the box and try to solve the problem from a
different angle
8.3 Future Enhancements/Recommendations

Surveillance is a basic requirement for the safety and security of the people and their properties.
With advancements in technology, threats are also bound to increase. Intelligent analysis and
contextual decision making can be highly beneficial in identifying threatening events
beforehand.
Potential topic of interest include but not limited to:
 Techniques to improve the SVAS method to deal with moving cameras and multi-camera
data set.
 Selective ID protection for intelligent video surveillance systems.
 Gaussian Mixture Model (GMM) for background modelling in intelligent video
surveillance systems. etc.

Appendices

Appendix A: Information / Promotional Material

[Between 4 to 8 lines describe what this appendix all about is]
A.1. Broacher (if any)
A.2. Flyer (if any)
A.3. Standee (if any)
A.4. Banner (if any)

Reference and Bibliography

Note: Use Mendeley or Endnote
[1] M. Sher, M. Rehman, “Title of the Paper” Conference name/Journal Name, Edition,
Volume, Issue, ISBN/ISSN, PP, Publisher/City-Country, Year.
[2] ……


CCTV Fight Detection

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CCTV Fight Detection

Uploaded by

Copyright:

Available Formats

CCTV BASED FIGHT CLASSIFICATION

Final Year Project

A project submitted in partial fulfillment of the degree of

Department of Computer Science

Faculty of Computing & Artificial Intelligence (FCAI)

Air University, Islamabad

Type (Nature of project) [] Development [ ] R&D

[] WebApp [ ] Mobile App

Project Group Members

Sr.# Reg. # Student Name Email ID *Signature

Department of Computer Science, Air University, Islamabad, Pakistan 2

Date: ______________ Name of Group Leader: _____________________ Signature: ________

Name of Supervisor: Mr. Hafiz Saud Arshad Co-Supervisor: (Not Allocated)

Signature: ________________ Signature: _________________

HoD: Dr. Awais Ahmad

Department of Computer Science, Air University, Islamabad, Pakistan 3

CCTV based fight classification

Department of Computer Science, Air University, Islamabad, Pakistan 4

Name: Hafiz Saud Arshad

Department of Computer Science, Air University, Islamabad, Pakistan 5

Department of Computer Science, Air University, Islamabad, Pakistan 6

I am really thankful to my supervisor/university/friend who has . . . . . . . . . .

Department of Computer Science, Air University, Islamabad, Pakistan 7

Department of Computer Science, Air University, Islamabad, Pakistan 8

Department of Computer Science, Air University, Islamabad, Pakistan 9

2.4.2. System Feature 2...........................................................................................................9

Department of Computer Science, Air University, Islamabad, Pakistan 10

Department of Computer Science, Air University, Islamabad, Pakistan 11

1.1 Caption of first figure of first chapter 6

Department of Computer Science, Air University, Islamabad, Pakistan 12

Department of Computer Science, Air University, Islamabad, Pakistan 13

Department of Computer Science, Air University, Islamabad, Pakistan 14

Department of Computer Science, Air University, Islamabad, Pakistan 15

1.2. Motivations and Challenges

Department of Computer Science, Air University, Islamabad, Pakistan 16

1.3. Goals and Objectives

1.4. Literature Review/Existing Solutions

1.5. Gap Analysis

1.6. Proposed Solution

Department of Computer Science, Air University, Islamabad, Pakistan 17

1.7. Project Plan

1.7.2. Roles & Responsibility Matrix

1.7.3. Gantt Chart

1.8. Report Outline

Department of Computer Science, Air University, Islamabad, Pakistan 18

Department of Computer Science, Air University, Islamabad, Pakistan 19

Department of Computer Science, Air University, Islamabad, Pakistan 20

Chapter 2: Software Requirement Specifications

2.1.2. Document Conventions

2.1.3. Intended Audience and Reading Suggestions

Department of Computer Science, Air University, Islamabad, Pakistan 21

2.1.4. Product Scope

2.2. Overall Description

2.2.2. User Classes and Characteristics

Department of Computer Science, Air University, Islamabad, Pakistan 22

2.2.3. Operating Environment

2.2.4. Design and Implementation Constraints

2.2.5. Assumptions and Dependencies

2.3. External Interface Requirements

2.3.1. User Interfaces

Department of Computer Science, Air University, Islamabad, Pakistan 23

2.3.2. Hardware Interfaces

Date: __ Name of Group Leader: _ Signature:

Signature: Signature: _