This is a decoding failure inside PyAV's error handler, not the real underlying fault. av.error.err_check converts ffmpeg's error message into a Python string using ascii. When ffmpeg returns a message containing non-ASCII bytes (0xc3 is a UTF-8 lead byte, meaning an accented/Chinese character), that conversion fails, and the true ffmpeg error is hidden.So the trigger is an ffmpeg-level failure with non-ASCII text in the error message or path. Solution:1. 1. Sanitize the input path: rename the video to pure ASCII (letters, digits, underscores) and place it in a shallow ASCII-only directory, for example /home/odelator/videos/1.mp4. Delete accented letters (é, ñ, ü), Chinese characters, spaces and emoji from both the file name and the folder names. 0xc3 at position 32 strongly suggests this.2. Set the system locale to UTF-8 before starting. Run locale in a terminal; if LANG/LC_ALL is empty, C or POSIX, then export and restart: export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 then uv run sp.py.3. Confirm the file is actually a valid, ffmpeg-decodable video. Run ffprobe -hide_banner /home/odelator/videos/1.mp4 in a terminal. If ffprobe itself reports an error, the file is corrupt or uses an unsupported codec; re-download it or remux it to standard H.264/AAC MP4 (ffmpeg -i input -c copy output.mp4) and import that.4. Also strip non-ASCII metadata from the container. MKV files with an accented/Chinese title tag in the container metadata trigger this even when the file name is ASCII. Remuxing with -map_metadata -1 (ffmpeg -i in.mkv -map 0 -c copy -map_metadata -1 out.mp4) removes it.5. Retry with Clear Output checked so no cached intermediate files from the failed run are reused. ### Please refer to the related documentation: - MacOS/Linux installation - Quick start