Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

* This is the deadline for all submissions except where an approved extension is in place. For benchtests taking place in practical sessions, the given date is the Monday of the week in which the benchtests will take place.

Late submissions received within 5 working days of the deadline will be capped at 40%.

Late submissions received later than 5 days after the deadline will receive a mark of 0. It is your responsibility to check that your submission has uploaded successfully and obtain a submission receipt.

Your work must be done by yourself (or your group, if there is an assigned groupwork component) and comply with the university rules about plagiarism and collusion. Students suspected of plagiarism, either of published or unpublished sources, including the work of other students, or of collusion will be dealt with according to University guidelines (https://www.dur.ac.uk/learningandteaching.handbook/6/2/4/).

libFilmMaster2000: Computationally and Memory Efficient quick filtering of videos

1. Background

Videos are an essential part of modern culture. However, handling them requires computational compromise. The concept of “do that in post” is common vernacular on movie sets; therefore, reliable, highly efficient video editing is critical to the process. Video frames are the fundamental unit captured by a camera and encoder into a video file. A video frame is composed of between one and three channels, typically with one channel resulting in a grayscale movie, alternatively, three channels representing red, green and blue. While a wider range of channels is possible, these are not commonplace on commodity hardware.

In this assignment, we will develop a library for editors to allow them to do basic video effects to make their movies more dramatic. You will implement a reading function based on a binary encoded file, which operations will then be performed on frames, for example, swapping channels and channel clipping, amongst others, which will then be written out into the same file format. The challenge is to implement this by balancing computational performance and memory to streamline editors’ activities.

2. Problem Definition

For this assignment, you will implement a library (libFilmMaster2000.a) and a command line testing executable (runme) to validate the functions within your library. The core of the implementation should be within the library, and basic command line parsing should be handled within the executable.

In the library, you should include a basic decoder (read) and encoder (write). The expected format is an uncompressed binary file in the following format:

For example, for the indexing, Ch0 refers to the first (zeroth) channel, H0 refers to the first row, and W0 refers to the first column.

To clarify, frame pixels are read in the following order:

• `reverse` Reverse the entire video

The frames should be saved in reverse starting from the last frame in the video to the first frame in the video.

• `swap_channel` Swap channel in video frames

Taking as input the parameters of the two channels to swap, `[Channel ，Number],[Channel Number]` in unsigned char, for each frame in the video, the two channels should be swapped around.

• `clip_channel` Clips the range of each pixel in each frame

Taking as input channel number `[channel number]` and the range to clip `[minimum, maximum]` in unsigned char, the value of each pixel in all frames should be limited to be within this range where values outside of the range are set to the respective minimum or maximum value.

• `scale_channel` Scales each pixel in each frame

Taking as input channel number `[channel number]` and the scale factor `[scale factor]` in float which should be multiplied to each pixel in each frame.

3. Hints

• Please read the submission instructions carefully. Since this is a programming assignment, deviations from the instructions might lead to you losing marks as a result of simple submission mistakes that can lead to your submission not running.
• Your implementation should be as efficient in its performance as possible, both in terms of memory and run-time.• It is important that your solution can generalise to an arbitrary number of frames and frame dimensions. However, limits of the types might act as upper bounds.
• Creating the right data structures to hold your video components and functions that perform the required operations on your video can make your implementation easier.
• Implement error handling and bounds checking to ensure that your program handles invalid input, and does not go into an infinite loop or other such issues. Not only will this make your implementation easier to test for yourself, but it is also part of the marking scheme and can affect your marks.
• Optimise your code for performance or memory (using [-S/-M]) with no flag indicating a balanced or vanilla solution. This might include algorithmic optimisations and careful memory allocation. Make sure your optimisation methods are explained in your report. Advanced optimisation methods will receive extra credit. Allocate and deallocate memory efficiently to avoid memory leaks.
• The vanilla implementation should be quite easy to implement you are therefore encouraged (and marks awarded) to go beyond the basic implementation, thinking about how to implement novel functions or optimising your code in a novel way.
• A simple testing file is provided to test your solution.
• The Iterative Sketched Design Document should use hand-drawn sketches and show a refinement from the initial stage to the final stage. A single solution sketch will receive minimal marks. You will not be marked down for ideas that you try that you are unable to implement (however, should be plausible) or provide worse results in terms of performance or memory. Such results should be reflected in the report through quantitative analysis.
• Testing on Mira can be slightly different to the barebones testing environment. There are some compilation flags set by default. Make sure you are aware of the flags being set and include them in your Makefile. You might find that testing on the autograder results in different outcomes (or build fails) if you do not consider this.
• Make sure you submit your files well before the deadline to make sure that system or network issues do not affect your submission. Every year, we receive dozens of emails right after the submission deadline from students with their submissions marked as “late” due to a variety of reasons. Do not leave your submission to the final minutes and leave yourself plenty of time to deal with any issues that might affect your submission. Note that lecturers do not have the power to grant extensions and late submissions are handled by the office centrally.

4. Code and Submission Specifications

- `./runme [input] [output] [-S/-M] reverse`

- `./runme [input] [output] [-S/-M] swap_channel 1,2`

- `./runme [input] [output] [-S/-M] clip_channel 1 [10,200]`

- `./runme [input] [output] [-S/-M] scale_channel 1 1.5`

Where [input]and [output]are variable length file paths and [-S/-M] are performance mode options to prioritise Speed (S) or Memory (M) where optimisations are to be determined and implemented by you.

5. Submission

6. Marks

• Correctness of solution 10%
• You may receive partial marks for certain parts of the Solution, but note that certain wrong solutions might lead to the loss of not only the entirety of this portion of the marks but other parts as well.
• Makefile 5%
• Your Makefile should have `all`, `test` and `clean` options and will be marked based on correctness, functionality and generalisability.
• Performance of your program in terms of run-time (speed) 5%
• Performance of your program in terms of memory requirements 5%
• Effectiveness of [-S/-M] for respective run-time / memory usage 5%
• Quality of the implementation
• Clear, readable, well-documented (with sufficient comments) 10% 
• and well-presented program source code
• Error handling 5%
• Extensibility 5%
• Report:
• Iterative Sketched Design Document 10%
• Discussion/detail of solution design and choices made 10%
• Quantitative evidence and analysis of performance 10%
• Additional credit for one or more of, but not limited to, the following:
• design and use of an alternative or novel frame editing functionality and described in the report
• use of advanced optimisation methods to improve performance or memory use and described in the report
• superior performance in terms of speed and memory use
• (for any of the above, up to a maximum, dependent on quality) 20%

Total 100%

Plagiarism: You must not plagiarise your work. Attempts to hide plagiarism by simply changing comments/variable names will be detected. You should have been made aware of the Durham University policy on plagiarism.

You should not make your submission publicly available or share it with others as that will be considered plagiarism.

Submissions should be made through the Gradescope system. Delayed submissions are handled centrally and are not under the control of the lecturers.