Jaksta Media Recorder for Windows for Windows Technical Support Forum

I have been noticing an issue recording Twitch streams. Since I have never managed to get Media Recorder to properly use my Twitch credentials, I've been having recordings that start with 15 seconds of "Commercial Break In Progress" screen, after which the recording crashes VLC. I can manually skip the transition and the recording keeps playing but with weird audio playback that had the correct pitch, but skips every couple of seconds.

Now, if I play this video in WMP, It doesn't crash after the Commercial section and the audio is continuous and correct, but weirdly pitched downwards. 

I suspect that if I could present my credentials correctly it wouldn't give me the initial commercial break section and the rest of the recording would be fine. Can't prove that though.

I have clips I can share but the smallest one is 33MB which is too big to attach so here's a OneDrive link to it instead https://1drv.ms/v/s!Amc8giVoxLuKn1eI4-NysPNLdB4Q?e=nf2jg4

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

I realized that the original clip sounds fine if you aren't used to the streamer's voice, so I'm including one with music you can reference to hear what the pitch is supposed to be. This one is 3 GB though so be warned. https://1drv.ms/v/s!Amc8giVoxLuKn1i5mRJhEzq9SyFh?e=MaWFix

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

No good. All that seemed to do was make it so my streams never muxed successfully and they still have the same issues. I'm changing that back and still need a solution for this.

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

I have the same issue since sometime in 2020. not on all streams on twitch but many i follow.

the audio (be it music or voice) is slowed down compared to the video. and despite being slower every couple of seconds in regular intervalls there is silence for a some milli seconds.

it makes those files useless. the same happened using some freeware tools except for one that worked. i want to be able to use jaksta though.

I have tried

mp4, mkv

switching to ffmpeg

incl the mpeg file option

all the same results.

this is a 24/7 stream though most of the day trading charts with EDM music, but you will figure this high bpm music plays too slow, has audio gaps. every day there is also some live voice session but you figure this alone from the music. just as an easy example to check this out

https://www.twitch.tv/tr4d3r10

--- Import ---
Author: Matt
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

another thing, for some streams this happened when a streamer upgraded from 720p to 1080p streaming while using same PC / hardware. just a faster internet line to be able to do this.

resulted in unusuable streams. since sometime around january this year for this guy.

the other stream above though is having those issues since 2020

example clip from 2020 january 31st

--- Import ---
Author: Matt
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

I can assist with anything you need to track this down. Something I noticed while trying to salvage these files. If you increate the pitch by x1.09 it sounds correct, which happens to be almost exactly the difference between 44100HZ and 48000HZ, so I suspect there is some sort of misunderstanding happening during the recording.

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

it's odd though they it's just not the pitch being much slower than just 9% but even it's slower there are many gaps of just silience. so I cannot get a coherent sentence from the person talking.

and for music streams it's just completely useless.

likely also not lipsync. i have tried remuxing with mkvtoolnix or using the other built in features of jaskta which fileformat and grabbing tool to use jaksta's own vs ffmpeg. all failed. and whyever this failed for some streams when they changed their resolution but not their audio settings.

no such issue with streamlink. I wish jaksta could support his command line tool in settings.

--- Import ---
Author: Matt
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

Try playing back in NOT VLC. Windows Media Player (Yes really) seems to work better for this very specific problem. You can hear all the audio (Just pitch shifted downward) 

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

Its caused by a feature of the HLS protocol called discontinuity which twitch use when streaming ads.  working on supporting it.

--- Import ---
Author: CRS
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

Once you do get this fixed, I wonder if we could get a description of exactly what had been going wrong. I have many recordings that I created over these last several months because there were live streams with no vods I would have no other opportunity to record, so any information on what happened that could assist in finding a way to salvage these recordings would be appreciated. 

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

same would apply to me. I have terabtyes of ruined recordings since i never checked those until just recently. 

--- Import ---
Author: Matt
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

has this issue been fixed yet?

--- Import ---
Author: Matt
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

Just wondering if this Discontinuity issue was still on the roadmap to get fixed.

--- Import ---
Author: Ken Kopin
Created At: 2021-11-23T11:13:32+08:00
Updated At: 2021-11-23T11:13:32+08:00
Views: 57
Votes: 0
--- Import ---

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"