Fix concatenated file size inflation by preserving source bitrate#204
Fix concatenated file size inflation by preserving source bitrate#204
Conversation
When re-encoding (audioCodec != "copy"), ffmpeg defaults to 128kbps which inflates output when source files use lower bitrates (e.g. 32k for audiobooks). Now probes the first input file's bitrate via ffprobe and passes -b:a to match. https://claude.ai/code/session_01V69UAXC51BGJok9wBP1xmN
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8f861e091c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // getAudioBitrate probes the audio bitrate of the given file using ffprobe. | ||
| // Returns bitrate as a string like "128000" (bits per second). | ||
| func (conv *FFMpegMediaProcessor) getAudioBitrate(filepath string) (string, error) { | ||
| cmd := exec.Command( |
There was a problem hiding this comment.
Concatenate is context-aware, but getAudioBitrate launches ffprobe with exec.Command instead of exec.CommandContext, so cancellation/timeouts are ignored during the new probe step. If ffprobe stalls (for example on problematic media on slow storage), the job can run past the flow timeout before it even starts ffmpeg, which is a regression introduced by this commit’s preflight probe.
Useful? React with 👍 / 👎.
2 participants
No description provided.