Currently, the file decoder is set to only read new frames and discard anything else, we would like to somehow enable an ability to rewind the video by loading frames in reverse order.

You will need to determine how to implement this with the frame decoder and then write these frames as needed into the buffer or renderer as you deem necessary.

Currently resizing the display halves the render window each time, this works but obviously isn't ideal.

The goal is to implement a naive resizing algorithm as described:
- Take in a number of "characters" to remove from the output (vStream.scale_x and vStream.scale_y)
- Using the char_X and char_Y values determine the equivalent number of rows/columns to remove from the image
- Remove these in equally spaced chunks

Ex: Given x = 2 and y = 1, remove xchar_X columns and ychar_Y rows equally spaced from the input frame data

There are some static memory leaks that occur when running the program, these are somewhat difficult to locate due to Valgrind not playing nicely with multi-threaded applications.

Simply reducing this would be nice, the current leaks don't affect functionality, but getting rid of them would be ideal.

Add some fun features, although unnecessary this will give people something fun to work on stress-free.

For example, implement a silent film style subtitle renderer, injecting text in frames following speech, or allowing audio rendered to be played back using the system bell.

Subtitles get the last character cut off when rendering. This can be "fixed" by appending spaces to the end of each line in the subtitle file, but should be fixed in code. Likely the space allocated for the strings is short one character.

I noticed many times when I am playing a video while its subtitle file has ended, I see a flickering white sub box containing the last subtitle.

Steps to reproduce:

• open a video with a subtitle file that ends sooner than the video.

Currently, only SRT subtitles are supported, we would like to expand this to more filetypes such as SSV and ASS. To do this you will need to check the file extension and then reimplement the subtitle loader system to load in the same style with these new formats.

This code can be found in loadSubs in the main.c file, by loading the data into the subtitle array in the format described within this function subtitle rendering should work.

When I try to open a video, I get a segmentation fault. I've tried to open two video files, where one uses the MPEG-4 (h.264) codec and the other uses the HEVC (h.265) codec.

Steps to reproduce:

• run ./telnetflix -f [your_fil_here]

Debug info displays normally on a 1080p display, but when downsizing the output for smaller windows it gets cut off at the top. This should be a relatively easy fix using the already found scaling offsets. All modifications need to be made in renderer.c

The compiler complains about a number of warnings that haven't really been addressed, if these could be fixed that would be nice.

This is a major enhancement that will require a lot of work.

Primarily the feature should spawn a new thread to track decoded audio data from the video stream and play it back, in sync with the source video file.

Following this, adding modes such as bit depth selection for audio rendering and the like can potentially be implemented.

Whenever I try to run the program (although I still havent managed to get it to actually play something) and exit by using ctrl -c, my terminal's cursor disappears. I can only revert it back to a normal state through the reset command.

Here's a command I use to open a sample video and subtitle combo:

./telnetflix -f ../sample_video/webcam.mp4 -s ../sample_video/sample.srt

Steps to reproduce:

• Run the program with the -f followed by the location of your video file.
• Exit through ctrl + C.

Edit: typo

Fast-forwarding currently operates by disengaging the frame limiter to allow the renderer to pull frames as they are decoded. This allows the video to run at a faster pace, however, it is quite slow once the renderer catches up to the buffer head.

Instead, the buffer should be caught up to and cleared as necessary, and then frames should be skipped in the loader to increase the rendering pace, going back to normal once the fast forward is terminated.

The subtitle loader is relatively naive. Ideally, the whole subtitle loader system should be reworked to be more modular. For now, it appears that subtitle files don't load unless they are formatted perfectly as far as padding.