Recording - All output files corrupted
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.1k
- Forks
- 2.2k
- Avg merge
- 7h 35m
- Merged PRs (30d)
- 51
Description
First and foremost consider this:
Description
No exception, it seems the first key frames of the output files are empty or corrupted.
Expected behavior
The video files should be solid from back to back.
Actual behavior
While we can play the video, depending on the player, without problems, editing it or resuming from a previous state results in garbled reproduction, indistinguishable codec ouput.
Steps to reproduce the bug
- Start and stop recording for a few seconds, or minutes if needed
- Play the video, it mostly will be OK, if you put the player to resume from where it stopped, you'll see the file is actually corrupted
- I cut the last 10 seconds and later the first 10 seconds of the ouput file without recoding it, I noticed the file was totally corrupted when cutting the first secs, interestingly, checking properties\details in Windows I see it shows, among other info, "0 FPS", possibly indicating empty or corrupted first video frames.
Bisect Results
[Try to bisect and tell us when this started happening]
Version/Commit
Build Date: Feb 3 2020
Git Version: fdb7f972a6
- RetroArch: 1.8.4, nightly
Environment information
- OS: Windows 10 x64
- Compiler: [In case you are running local builds]
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the recording workflow on Windows 10 with RetroArch 1.8.4 at commit fdb7f972a6, then check the output when played, resumed, or cut without re-encoding. Done means recordings have valid initial frames and remain intact when resumed or edited from the beginning.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100