Jaksta

Is this still on the roadmap to be fixed? It is really off that such a good program has such a large problem with one of the biggest streaming services.

Coming back to this thread years later with an answer - I finally worked out exactly what goes

wrong, and how to repair the old recordings. This never got fixed in Jaksta, so if you're

sitting on old Twitch recordings like I was, here's how

to rescue them.

(This is a lot - There's a TL;DR at the end)

WHAT'S WRONG

Twitch shows viewers who aren't logged in a ~15 second "Commercial Break In Progress" slate at

the start. That slate is encoded differently from the stream: 29.97 fps video and 44.1 kHz

audio. CRS was right that the switch is marked with an HLS "discontinuity". The damage happens

when Jaksta finishes the recording: it checks the START of the file (the slate) and then

copies the whole stream into the MP4 using the slate's settings. So:

- the audio gets LABELED 44.1 kHz, but most streams are really 48 kHz. Players run it about 9%

  slow, which is the pitched-down sound (and why speeding it up ~9% sounded right)

- the video gets forced to 29.97 fps, which leaves uneven, colliding timestamps (VLC crashes,

  skipping, editors choking)

If a streamer happens to broadcast 44.1 kHz audio, it matches the slate, so their pitch is

fine and only the timestamps are bad. That's why it hit most streamers but not all. Files

without the slate at the start are labeled correctly.

The video and audio data themselves are fine. Only the labels and timestamps are wrong, so

nothing is actually lost.

THE FIX (ffmpeg)

You need a recent ffmpeg, which includes ffprobe (e.g. the "full" build from gyan.dev).

Work on a copy and keep your original until you've listened to the result.

1) Find where the slate ends. List the keyframes in the first 40 seconds:

  ffprobe -v error -select_streams v:0 -read_intervals "%+40" -show_entries packet=pts_time,flags -of csv=p=0 "INPUT.mp4" | findstr ",K"

   The slate has keyframes exactly every 2.002 s (0, 2.002, 4.004 ... 14.014). The first time

   that breaks the pattern (often 15.000, but I've seen 14.994 to 15.097) is where the real

   stream starts. Call it SEAM. If there's no 2.002 s pattern, there's no slate.

2) Find the real frame rate. Count video packets in 10 seconds from the middle of the file

   (change 600 to any time well into the recording):

  ffprobe -v error -select_streams v:0 -read_intervals "600%+10" -count_packets -show_entries stream=nb_read_packets -of csv=p=0 "INPUT.mp4"

   About 300 = 30 fps, about 600 = 60 fps.

3) Check whether the audio really is 48 kHz. Compare the audio packet timestamps during the

   slate with after it:

  ffprobe -v error -select_streams a:0 -read_intervals "2%+8" -show_entries packet=pts -of csv=p=0 "INPUT.mp4"

  ffprobe -v error -select_streams a:0 -read_intervals "40%+8" -show_entries packet=pts -of csv=p=0 "INPUT.mp4"

   Look at the differences between consecutive numbers:

     slate ~1024, after ~941 -> the stream is 48 kHz under a 44.1 label: needs the fix (most files)

     both ~1024 -> genuinely 44.1 kHz: leave out asetrate below

   (Some 2023 files are really MPEG-TS inside a .mp4. There the numbers are ~2090 for 44.1 kHz

   and ~1920 for 48 kHz.)

4) Convert. This cuts the slate, relabels the audio, rebuilds clean timestamps, and re-encodes

   to HEVC, which usually comes out at 40-60% of the original size:

  ffmpeg -ss SEAM -i "INPUT.mp4" -map 0:v:0 -map 0:a:0 -vf "fps=30" -af "asetrate=48000,asetpts=N/SR/TB" -c:v hevc_nvenc -preset p5 -cq 26 -maxrate 5M -bufsize 10M -tag:v hvc1 -c:a aac -b:a 160k -movflags +faststart "OUTPUT fixed.mp4"

   - fps=30 or fps=60, from step 2

   - genuinely 44.1 kHz (step 3): use -af "asetpts=N/SR/TB" instead

   - no slate: drop -ss SEAM, and drop asetrate (the label is already right)

   - the 5M cap keeps busy 60 fps streams from coming out bigger than the original

   - other hardware: AMD -c:v hevc_amf -rc cqp -qp_i 26 -qp_p 26

                     Intel -c:v hevc_qsv -global_quality 26

                     CPU -c:v libx265 -preset medium -crf 24 (slow)

     I tested the NVIDIA version; the others are the usual equivalents, so adjust to taste.

5) Check it. The fixed file should be the original's length minus the slate, e.g. 2:39:17 ->

   2:39:02. If it comes out ~8% shorter, something is wrong. Then listen to a voice you know.

DON'T speed up the video to match the audio. The timeline is already real time; only the audio

label is wrong. Speeding things up drops frames and causes tiny audio skips.

TL;DR: for most old Jaksta Twitch recordings (slate at the start, voices pitched low), this one command fixes it. Use fps=60 for 60 fps streams. The full steps above cover the exceptions.

ffmpeg -ss 15.1 -i "INPUT.mp4" -map 0:v:0 -map 0:a:0 -vf fps=30 -af "asetrate=48000,asetpts=N/SR/TB" -c:v libx265 -crf 24 -preset medium -tag:v hvc1 -c:a aac -b:a 160k -movflags +faststart "OUTPUT fixed.mp4"