5 hours ago
I know it is over a year later, but I recently ran into this exact issue and kept working on it until I found a probable cause (and solution).
In my case I believe it is due to bitrate spikes. The problem occurs in "large" high definition videos that were created over a decade ago and I had never tried playing via Chromecast until recently.
My solution has been to re-encode all of the problem videos with a max bitrate cap (ffmpeg -maxrate).
I have actually been starting with -maxrate 30M which fixes the problem for me most of the time and helps preserve more of the original video quality. Then there are a few of my videos that will freeze in a different place after that re-encoding, so I go back to the source and try again with a lower value like 20M. And for a very very few I had to go down to 15M. I see recommendations on the Internet that 10 - 12M is the actual max bitrate for old Chromecast devices. It's a bit tedious to do the re-encoding, and then start playback, and then wait to see if the movie plays all the way through... but this workflow "works" for me.
Re-muxing did not help me and I was unable to find a way to determine by looking at the files themselves that they would be problematic... it would be nice to be able to scan my library and only re-encode the the files that are likely to be broken, without having to actually watch every movie through a Chromecast device to see if it actually breaks.
p.s. ChatGPT can be pretty dumb about a lot of things but it seems to have some good suggestions about ffmpeg encoding and media playback. It pointed me at the bitrate issue with early Chromecast devices and other possible issues like the following, none of which panned out, but seemed plausible (but could totally be hallucinations):
In my case I believe it is due to bitrate spikes. The problem occurs in "large" high definition videos that were created over a decade ago and I had never tried playing via Chromecast until recently.
My solution has been to re-encode all of the problem videos with a max bitrate cap (ffmpeg -maxrate).
Code:
ffmpeg -i 'Big File (HD).mkv' -c:v libx264 -preset slow -maxrate 15M -crf 18 -c:a copy 'Big File (HD) maxrate 15M crf 18.mkv'I have actually been starting with -maxrate 30M which fixes the problem for me most of the time and helps preserve more of the original video quality. Then there are a few of my videos that will freeze in a different place after that re-encoding, so I go back to the source and try again with a lower value like 20M. And for a very very few I had to go down to 15M. I see recommendations on the Internet that 10 - 12M is the actual max bitrate for old Chromecast devices. It's a bit tedious to do the re-encoding, and then start playback, and then wait to see if the movie plays all the way through... but this workflow "works" for me.
Re-muxing did not help me and I was unable to find a way to determine by looking at the files themselves that they would be problematic... it would be nice to be able to scan my library and only re-encode the the files that are likely to be broken, without having to actually watch every movie through a Chromecast device to see if it actually breaks.
p.s. ChatGPT can be pretty dumb about a lot of things but it seems to have some good suggestions about ffmpeg encoding and media playback. It pointed me at the bitrate issue with early Chromecast devices and other possible issues like the following, none of which panned out, but seemed plausible (but could totally be hallucinations):
Quote:Your file was muxed with:
mkvmerge v3.2.0 (2010)
libmatroska v0.8.1
Those are 14–15 years old, very early implementations with known issues involving:Chromecast is very sensitive to seek table errors, and symptoms match:
- broken cluster seeking
- incorrect cue positions
- timestamp rounding errors
- bad index tables
- incorrect handling of B-frames in MKV
✔ plays fine until it hits a bad cluster
✔ freezes at exactly the same timestamp every time
✔ other players (VLC, MPV) work — because they are far more forgiving
Old x264 builds could produce:
- slightly non-compliant B-frame timing
- weird keyframe/cue misalignment
- edge-case bitstream behaviors modern hardware decoders dislike
Chromecast’s H.264 decoder is generally strict.
