Handbrake Output Visually Freezes on Interstitial

Question

I downloaded an m3u8 stream using a Chrome plugin, and it created an mp4 file which I can play fully in VLC.

Next, I am attempting to use Handbrake to encode this file to be played on an old iPod Nano. I am using the Apple 240p30 preset. The resulting mp4 does play on my Mac (Preview, Quicktime) and on my Nano.

However, the final video has a glitch whereby at the first interstitial (commercial) the video fast-forwards for a second and then freezes permanently, while the audio carries on valiantly for the entire 30 minutes of the video. This happens when I play it on the Mac and Nano.

I'm a software engineer, so I tried researching this problem but I came up blank, possibly because I do not know the terminology and am not deeply familiar with the various ways that video encoding works. The most likely lead was this thread about MCEBuddy which I believe uses Handbrake under the hood. The description of "I have noticed similar behavior. The video freezes at the commercial cut point (chapter break) but the audio keeps going" matches what I am experiencing.

Does anyone familiar with Handbrake know how to configure it to avoid this behavior?

Answer 1

After some further investigation, I found that when you use the Apple 240p30 preset, Handbrake uses the x264 encoder. I tried various command-line options for this tool but was not able to affect a change. If the problem relates to keyframes, there seem to be options to create keyframes at various intervals in the output, but not to detect where they are in the input, nor to affect the demuxer beyond choosing which library to use (and they must be bundled with the compiled x264 software, which I can't know if they are or not with Handbrake).

Instead, going earlier on the chain, I revisited the m3u8 downloader Chrome plugin, and tried to export as a .ts file instead of .mp4, and when I ran this through Handbrake it worked perfectly. Presumably this was then a problem with the downloader plugin and not Handbrake. I am guessing that VLC was simply robust enough to fudge over the issue and continue to play the original file, whereas x264 was not.

Problem solved.