I was wondering if I could get your assessment of the feasibility of the below Python application idea I had? If feasible, are there any significant areas you can see that I might need to clarify, elaborate on, or potentially rethink altogether? The idea is to get an MVP version of the application created that can then be enhanced later.

# Video Converter Overview

## **Purpose:**
A Python application for personal use that allows a user to to select either a single video file or a folder of video files and transcode them with configurable settings.

## **User Workflow**
1. The user launches the application. The initial state is a blank canvas.

2. To add a video file to transcode, the user can add a single video file using the “Add Video” option. To add a folder of video files the user would use the “Add Folder” option. When adding a folder, the application will scan for all valid video files in the folder the user selects ignoring subfolders. When scanning, the application will read metadata for each video file (based on file extension - .ts, .wmv, .mp4, .m4v) using ffprobe and create a widget for each valid file added - valid files will be determined by file extension, and files with a valid extension but where ffprobe failed to retrieve metadata should be treated as a failed import. In the case of a folder being selected, files should be scanned and added sequentially in alphabetical order. Adding a folder of videos should present a modal dialog with a progress bar (the progress bar should show file-level progress during the scan) to the user as files are being scanned & added and disable other UI actions to avoid the risk of a potential conflict. If the ffprobe process fails or times out (duration exceeding 10 seconds), it should try again once, then fail with the video source being skipped. A popup window at the end of the import process should alert the user of any failures / skipped sources.

3. For each video added, a widget will be added to the queue with new videos being added at the bottom.
The widget should have the following items:
- The order of the clip in the project
- A "Delete" Button to delete the widget
- A dropdown with the option to resize the video (with Unchanged, 1920x1080, 1280x720, 960x540 as options, and Unchanged as the default)
- A dropdown option to select the preferred audio bitrate (with Unchanged, 128Kbps, 192Kbps, 320Kbps options and Unchanged as the default)
- Basic metadata about the source file (file name, source dimensions, duration)

4. When the user is finished adding video clips, they would click an "Export" button. This would generate a pop up dialog that prompts the user to select the output folder. It would also display:
- The number of videos being transcoded
- A dropdown for the desired output format (H.264 or H.265)
- A checkbox to indicate whether GPU acceleration should be used
- The desired CRF (for CPU transcoding)/CQ (for GPU transcoding) factor to use when transcoding (20-30 slider with a default value of 23)

The export dialog should have a "Proceed" and "Cancel" button to allow the user to abort if needed.

5. After the user has selected their export options, a background process is run to process transcoding of the source video files in the order the user selected in the application
The Export workflow should work like this:
- Queued items are processed sequentially in the order they appear in the main UI.
- For each item, generate an FFMPEG command to handle transcoding based on the user selected options for each video (which may be different between video files)
- the FFMPEG command should attempt to align audio and video start times and regenerate the timeline to address potential source video file errors. (perhaps -avoid_negative_ts make_zero -fflags +genpts - this will require testing during development)
- If the user resizes a video to dimensions that would result in a different aspect ratio, the export process should add letterboxing or pillar boxing as needed to prevent distorted output.
- If the video dimensions are set to “Unchanged” the scaling filter should be omitted and the video transcoded at the source dimensions 
- If the audio setting option is “Unchanged” the application should transcode at the source audio bitrate. If the source audio is already using AAC, the audio stream can be copied without needing to be transcoded. If more than one audio stream is present, the application should use the first one.
- If an export operation fails, the error should be logged but should not stop attempts to transcode other files in the queue. Retrying a failed export is currently out of scope.
- The application should transcode a single video source at a time
- Output files will use the same file name as the source video file with an MP4 extension. If the output file would have the same name as an existing file in the selected destination folder, a `-Converted` suffix should be added to the output file name. If a file with the `-Converted` suffix already exists it should be silently overwritten (more complex handling is currently out of scope)
- While the export process is running a modal dialog should be displayed with the following items:
- A count of succeeded/failed files
- The total number of files that were queued for transcoding 
- A scrollable list of completed/failed videos (completed files would be in green text, and failed files would be in red text)
- A progress bar showing file-level progress
When the export process has completed, the model dialog should update to show the following:
- A list of failed videos
- A link to the output folder
- A “Done” button to close the dialog

6. If the user selects the “Clear Queue” button with videos in the queue, they should receive a warning that the queue will be cleared with a “Proceed” and “Cancel” button.


## **System Specifications:**

- OS: Windows 11 Pro
- CPU: Intel i9-13900K
- RAM: 64GB (~42GB available under normal circumstances)
- GPU: NVIDIA RTX 4080 with 16GB of VRAM (~13GB available under normal circumstances)
- Storage: ~2TB available.

## **Additional requirements/preferences:**

1. From a coding standpoint, smaller Python files implementing a single class object are preferred to keep memory and context length more manageable.
2. Coding approaches should favor simpler approaches that accomplish the goal over more complex approaches that may offer little benefit for the amount of complexity they add.
3. Preferred development approach is a "walking skeleton" approach where the UI is created first, then components are developed and integrated in the order they would be used based on the workflow.
4. PyQt6 is the preferred approach to use for the user interface.
5. Code should be clearly commented for maintainability or future enhancements.
6. After implementing a component, it should be tested before resuming developing further components of the application.
7. If the application encounters an error, it should be displayed to the user in the UI as well as captured to a log file in a `logging` subfolder. The application should leverage `logging.handlers.RotatingFileHandler` to keep the log file size manageable (<=500KB). Logging should ideally use the Python `logging` module. Error messages in the UI should clearly indicate the issue, and the application should focus on graceful degradation when possible.
8. Long-running processes such as adding a folder of videos or exporting should be isolated to background worker threads to keep the UI responsive
9. Proposed user interface: A single pane application with the main window containing a scrollable column of video widgets. A `QMenuBar` object would have an "Exit" option, and a `QToolBar` would have the “Add Video”, “Add Folder”, “Export”, and “Clear Queue” options.
10. For video transcoding, FFMPEG is installed and added to the Windows PATH
11. Video widgets should read from and write to a central data model that stores the information about the scenes (file path, clip order, duration, source dimensions, selected dimensions and audio settings) without the clip widgets separately storing any information, ideally using an MVC approach  leveraging `QAbstractListModel` to handle widget/data class interactions.


## **Input Video Specifications:**

- Resolution - typically 960x540, 1280x720, 1920x1080
- Frame Rate - Typically 25 frames/second, 29.97 frames/second, 59.94 frames/second
- File types - .ts, .wmv, .mp4, .m4v
- Duration - 15-30 minutes for most videos, the longest approach 60 minute durations
- Queue size - 100 videos is likely to be the largest processed at once, but should not be a hard limit.

## **Output Video Specifications:**

- Video Codec: CPU - libx264, libx265 / GPU h264_nvenc, hevc_nvenc
- Audio Codec: AAC, match source sample rate

## **Future Considerations (Currently Out of Scope):**

- The ability to cancel bulk imports from a folder 
- Reordering video widgets
- Pausing/Cancelling the export process
- Save/Load functionality for queues and export settings
- Batched transcoding 
- GPU validation before transcoding
- More complex handling for existing files during export
- Handling for special characters in file names (will manually validate for initial version)
- Handling if FFMPEG not found in PATH/not found (will manually validate for initial version)
- Fallback to CPU transcoding if GPU transcoding fails
- Checking available disk space before export (will manually validate for initial version)
- Enhanced error reporting in the user interface
- Handling for multiple audio streams