When the video & the audio don't play at the same speed

[Wild Willy]

There's been a few reports on here of people downloading videos using VDH & the video &
the audio don't play at the same speed. I'm not talking about the audio being out of
synch with the video by a couple of seconds. That's a different issue that is easy
enough to correct using the j & k keys in VLC to time shift the audio track backwards or
forwards so the lips move on the screen at the same time as you hear the voices. No, I'm
talking about the case of the audio being perfectly audible & intelligible but the
associated video playing at double speed or some other multiple of reality. That is not
a simple synchronization problem. On the other hand, I don't believe either of these
problems is caused by VDH. I believe the serving source is to blame in both cases. I've
used VDH to download far too many videos from various sources & gotten resulting files
that played perfectly fine in VLC, with no video/audio synching problems nor problems of
any other kind. In particular, I like to record rounds of golf tournaments off the Golf
Channel component of NBC Sports. These are live streams that aren't actually live
streams, as I've detailed elsewhere in this group. The short observation I've made is
that even though the stream is live in the browser, when you try to record it with VDH,
NBC gives VDH the URL of a file on a server. I've explained this in more detail in other
threads here so I won't go over it again. The main point I want to make is that those
recordings have always been quite acceptable. Today is the first time I've hit a
problem. But I have a workaround. It's not really a solution but it allowed me to watch
this broadcast even though it was severely damaged.

So. Details. The file is an MP4, size 11.0G, duration 4:49:16, that took 1 hour & 24
minutes to download. There's no point in giving a URL because it was a live stream that
ended hours ago. The file starts with the usual NBC logo & the message, "Coverage will
begin shortly." This goes on for 46:56, actually a shorter span than what I usually see,
which is typically over an hour. At that point, the broadcast begins & all is perfectly
normal, audio & video in synch. Everything is fine for about 15 minutes. One of the
players sinks a putt & is walking off the green while the announcers are speaking. At
exactly time index 1:02:57, the announcers continue to speak normally but suddenly the
players are moving around in double time. I did a little experimenting with the VLC
speed control to determine that. By slowing playback down to 50%, the players looked
like humans playing golf again. The announcers, of course, were speaking at half speed.
What to do?

My first thought was that I could separate the video & audio tracks into separate files
using ffmpeg. I've done that before, although it did take me several hours of trial &
error, trying to understand the utterly impossible ffmpeg documentation, & multiple
Google searches. But I kept the commands I used so I could do it again without all that
pain should the need arise. I thought that need had arisen here. I thought there ought
to be a way to cut the video track at 1:02:57, then process the second part in some way
to cut its speed in half. Then I could weld those 2 pieces back together into a
video-only track (something else I have done in the past using ffmpeg) which I would then
play in VLC using the synchronous playback feature
(https://groups.google.com/g/video-downloadhelper-q-and-a/c/YwvzcYm-fP0). The prospect
of wrestling with the ffmpeg documentation again gave me pause.

I moved on to thinking maybe I could get some video editing software that could help me
with this. I did uncover the names of some free packages via a Google search. I think I
had decided it was going to be a choice between 2 possible candidates, but I didn't
relish the thought of wrestling with the user interface of yet another piece of software,
no doubt badly documented. Not only would the software be unfamiliar to me but I've
never done any video editing.

Inspired by my laziness (aren't all great accomplishments inspired by laziness?), I
suddenly had a brainwave. What if I played the file in 2 VLC windows? I could use one
window to play the file at half speed with the volume off. I could use the other window
to play the same file at regular speed with the volume turned up. Just launch playback
in the 2 VLC windows at the same time. This requires using the VLC Preferences I show in
the attached image. It was a bit tricky to get the 2 windows playing more or less in
synch. Of course, I had to skip the first 1:02:57 before playing it in 2 windows. After
considerable fiddling, stopping one playback to position the other, then getting them
both playing again, I was able to watch the golf as if everything was perfect. Things
were probably simplified somewhat by the fact that I have a regular computer monitor as
my primary system display, & I have my television defined to Windows as a secondary
monitor. The obvious choice is to play the audio using a VLC window on the primary
monitor while watching the video using a VLC window on the TV. But you don't really need
2 monitors to do this. It just helped me a bit.

In the end, I discovered by playing the file in the 2 VLC windows, that the video ended
at time index 2:54:53 while the audio ended at time index 4:46:53. The file started
perfectly in synch between audio & video but by the end of the broadcast there was a
discrepancy of nearly 2 hours between the two VLC windows. After the video ran out, I
had the usual NBC logo with the message, "Coverage has concluded," for a duration of
1:54:23 in both VLC windows. Of course, the audio window continued to play the audio
track over the message until 2:23 remained, while the video window continued to play the
broadcast at half speed up to the 2:54:53 mark. The video ended with the time index
showing 2:54:53, but that's only because I was playing it at half speed. The audio
continued all the way to 4:46:53. Throughout playback, the discrepancy in the displayed
time indexes in the 2 windows gradually grew.

I think perhaps I got a bit lucky with this. The video seemed to revert to real life
speed by playing it back at half speed. If the video had been at some weird multiple or
fraction of reality, I might have had a hard time doing this. I would have had to
discover by trial & error what speed would make the video look lifelike. If the video
had been fine but the audio had been weird, I would have had to try to figure out by
trial & error what playback speed would have made the announcers' voices sound lifelike.
Still, the idea of using 2 simultaneous VLC windows to play the same file, one with the
video but the volume at 0, the other with the audio but you don't watch the video, is
what you should take away from this. What's left is a trial & error process of figuring
out by how much to either speed up or slow down one of the windows. It would be quite a
nightmare if both tracks were at the wrong speed by differing amounts. May we all never
encounter such a case. I say this beats having to learn how to use video editing
software.

I also want to point out that I do not believe VDH causes these problems. I believe the
problems come from the source & VDH just records what it is given. I and many of you
have done too many successful VDH downloads to make me blame VDH for such problems. I
have noticed with these live golf streams that the audio & video do sometimes slip out of
synch by a fraction of a second. I find I am fiddling with the j & k controls in VLC at
multiple points during playback. I find I can get things in synch only to notice a few
minutes later that they're out of synch again. Sometimes the audio is a bit ahead of the
video, but after I get them in synch, they slip again. Then I have to either delay the
audio a bit or advance it a bit. It's like the audio goes out of synch, both too early &
too late, by differing amounts at different points in the broadcast. I suspect that this
is due to the fact that these live streams are chunked. When you cross a chunk boundary,
maybe the source material is recorded with slightly different synchronization. I'm
guessing, of course. My conclusion is that this annoyance has nothing to do with VDH &
everything to do with the source.

[jcv...@gmail.com]

thanks for the feedback !

jerome

[Wild Willy]

VDH read the live stream of today's round of golf from NBC Sports/Golf Channel into an
MP4 of size 8.6G, duration 3:57:59 (typical for a 3-hour broadcast), resolution
1920x1080, video bit rates in the 5,000kbps range, which is quite good & higher than what
they sometimes give.  The frame rate is a bit strange.  Windows Properties claims it's
72fps, VLC properties claims it's 42fps, ffprobe claims it's 72fps.

I always scan these recordings by playing them in VLC before I sit down to watch them all
the way through.  I look to see how long the "Coverage will begin shortly" notice lasts.
Today it was in the 50 minute range, better than the 90 minutes I've seen a couple of
times recently.  I then watched a few seconds of the beginning of the broadcast & it
looked fine.  Then I usually skip to about 2 minutes before the end to make sure the
"Coverage has ended" notice is there.  When I skipped to the end on this one, it wouldn't
play.  Right away I thought I've got another one of these cases of double-speed video
with normal audio.  Sure enough, after restarting playback several times & hunting around
in the middle of the video, I did find the "Coverage has ended notice," so I do have the
full broadcast here, but I also found some double-speed video.  I had to restart the
playback a few times because every time I skipped to a point past where the video ends
but the audio is still running, VLC would freeze up.  So I had to restart playback & try
jumping to an earlier time index in the file.  Once I got to a place where there was
still video, albeit at double speed, then VLC could skip around like it should.

Before I started doing my dual VLC trick, I decided maybe this can be cured by letting
VDH re-encode the thing.  So I told it to target a file type of Re-encoded MP4
(h264/aac).  After VDH had done what it claimed was about 2% of the conversion, it said
it would complete the job in about 13 hours.  They're going to be playing tomorrow's
round of the tournament by then.  It's up to 17% now after working on it for 36 minutes &
generating 132M of output.  It's saying now that it's going to complete in 2:48:30.  I'm
not waiting.  I'll be doing the dual VLC trick here in a bit.  But I will let the
conversion continue to completion to see what I get.  I'll report my results when I have
them.

[Wild Willy]

Some tips for the dual VLC trick.

My golf video was perfect for about 1 hour & 10 minutes, then the video just suddenly
sped up while the audio remained fine. For this case, I found that simply slowing the
video down to 50% was still way too fast. Using the 4 +-][ keyboard shortcuts in VLC
that control playback speed I determined that the correct speed was somewhere slower than
20% but faster than 10%. But you can't get any finer than that with the 4 keyboard
shortcuts. So I broke down & started hunting around in the VLC documentation. I didn't
find my answer directly but I did find that you can get some command line help if you
open a command window & CD to the VLC directory, which is in a subdirectory of C:\Program
Files on my system. To find the directory, go to the object in your Start Menu for
launching VLC & open its properties. You'll find the path in the properties. So once
you're in the VLC directory in your command window, execute this command:

vlc --help

This doesn't just flood your window with text faster than any human can read it. It
creates a file called vlc-help.txt in the current directory. I moved it to a more
convenient directory than C:\Program Files\blahblahblah, then I deleted it from the VLC
directory on C:. Then I looked inside the file in its new location. It shows a way you
can open VLC from a command line & pass it a file. But when I used several variations on
their theme, I could never get VLC to open my MP4. So I just executed VLC with no
parameters, let it open its usual Playlist window, then used a standard file selection to
get my MP4 into the VLC Playlist.

But that doesn't solve the speed issue. After several experiments with different speeds,
I settled on this command:

vlc --rate=0.18

That opens VLC with playback speed set to 18%. Then I added my MP4 to the VLC Playlist &
it played at this lower speed. I discovered by experimenting that if you do use the 4
keyboard shortcut keys, you lose your fine-tuned speed & you can't go back to it. So
once you open VLC with a custom speed, don't adjust the speed using the keyboard
shortcuts. In my case, 18% came pretty close to what I wanted, close enough that I
didn't fiddle with it any further. I think maybe 17% would have been closer to what I
wanted but I got tired of fiddling with it.

Once I had the golf video playing at that speed, no sound track was going to be audible,
although I dropped the volume to 0 anyway. In my second VLC instantiation, I played the
same MP4 file back at 100% speed to hear the audio track, although I ignored that video
window.

It was quite a chore to get the 2 windows more or less in synch. I don't think I ever
really got it right, seeing as I kept having to pause one or the other window to let the
unpaused window catch up. It wasn't perfect but it was all I could manage. Also, in the
window where I was viewing the golf, I had to use the Shift+RightArrow keyboard shortcut
to skip over the ads. At 18% speed, the RightArrow & Ctrl+RightArrow skip way more of
the video than they do when you're at 100% speed. So does Shift+RightArrow but it's at
least a manageably small amount & you can skip past the ads with good enough accuracy.
In the window where I was listening to the announcers, the keyboard shortcuts skipped
intervals as expected, but once I got past the point where any video was still visible,
somewhere around the middle of the nearly 4 hours of the file, VLC's response to the keys
was very sluggish. It worked, but I had to hit a shortcut, then wait while it chewed on
it before actually resuming playback of the audio further along in the file. This is not
how VLC works with a good video.

Meanwhile, my conversion of the file in VDH is still running. It's been going for a
little over 3.5 hours & the converted file is only 1.24G. The VDH blue dot progress
window says it has completed 36% of the operation & still has nearly 6.5 hours to go. I
think even if this does correct the problem, I'm still better off just wrestling with the
original file in 2 VLC windows. I interrupted my watching to come here & post this
because I found I wasn't concentrating on the golf, but rather thinking of how I wanted
to document what I've observed for future reference. I'll go back & finish watching this
& I'll be done hours before the conversion completes, even with all the juggling I have
to do to skip the ads. Still, the scientist in me wants to know if converting the file
will fix it. I predict it won't but let's wait (& wait & wait & wait) & see.

[Wild Willy]

I am astonished to report that the conversion completed after "only" 4 hours & 49
minutes. Last time I looked, which was maybe 15 minutes before it finished, VDH was
saying there was still over 6 more hours to go. I'm quite happy it was wrong but still,
I would hope to see better accuracy with this. I ended up with a file of only 1.86G,
which is way smaller than the original 8.6G. The converted file is 1920x1080, same as
the original, but the video bit rates are in the 1000kbps range, much worse than the
5000kbps range of the original. That was not my intent. Maybe I should have chosen one
of the other targets for this. I would want the bit rates preserved under most
circumstances. The frame rate seems to have been normalized to 30fps. However, I am sad
to report that my prediction was correct. Converting the file preserved the video speed
problem. I believe that even if I had chosen a different target file type, it still
would not have corrected the problem. Oh well. It was worth a shot.

[jcv...@gmail.com]

sorry it didn't fix the problem, thanks for all the feedback.

jerome

[Wild Willy]

I have found what I consider more or less a solution to this problem.  This past weekend
I recorded 4 rounds of golf off Golf Channel each day from Thursday through Sunday.  The
first 3 rounds recorded perfectly beginning to end.  The final round Sunday had a glitch.
This was a recording of a little over 4 hours that suddenly went bad around the 3:59
mark.  The tournament was pretty much over but there were a few last putts & post-round
interviews left at the moment the problem happened.  This meant that I could test out my
solution on conveniently small files.

At the fatal moment, the video sped up to approximately double speed while the audio
remained correct.  So here's the roadmap of what I was going to try to do:

1. Split the original broadcast file into separate video-only & audio-only files.
2. Process the video-only file, which had too-fast motion, into a video-only file with natural motion.
3. Play the processed video-only file synchronously with the audio-only file in VLC.
4. As a proof of concept & to compare with step 3, aggregate the corrected video track with the audio track & play that in VLC.

I did all of this in a .Bat script so I will give you a line by line description of what
I did.

First I executed this command:

Call G:\ffmpeg\Setffmpeg

I have created a script named Setffmpeg.Bat in directory G:\ffmpeg.  That directory on my
system contains the directory tree of the distribution of ffmpeg from ffmpeg.org, as I
have discussed elsewhere in this forum.  Setffmpeg.Bat consists of 1 line:

SET ffmpeg=G:\ffmpeg\ffmpeg-2021-07-11-git-79ebdbb9b9-full_build\bin

This creates an environment variable named ffmpeg that is accessible for the duration of
execution of my script.  The variable disappears when the script ends.  That's fine.
That's what I want.  I could integrate this durably into my Windows environment but I
find this approach more flexible.  The value I assign to the environment variable named
ffmpeg is the directory path to the location of ffmpeg & ffprobe (& ffplay, but that's
irrelevant here).  All my scripts that invoke ffmpeg & ffprobe begin with this invocation
of Setffmpeg.Bat.  You will see the primary usefulness of this as we go along here.  The
secondary usefulness will come at some future date when I update ffmpeg to a new release.
I will do the installation of that new release into a sub-directory within G:\ffmpeg but
in a different sub-directory than my current ffmpeg.  In order to automatically get all
my scripts to use the newer ffmpeg, all I will have to do is change the one line in
Setffmpeg.Bat.  I'll use it a few times to verify that the new release works, then I will
delete the directory tree of the old release of ffmpeg.  On the other hand, if I observe
problems with the new ffmpeg, reverting to the old release will be a simple matter of
putting Setffmpeg.Bat back to the way it had been.

With that housekeeping out of the way, here's the first step of my process.  (Throughout
this discussion, Google line wraps some of my commands.  Just remember that each
command is actually just a single line in my .Bat file.)

"%ffmpeg%\ffmpeg" -hwaccel auto -ss 3:59:40 -i "Q:\Golf\LPGA Round #4.mp4" -map 0:v -codec: copy -y "Q:\Golf\Video Only.mp4" 1>"Q:\Golf\SlowDownVideo.err" 2>"Q:\Golf\SlowDownVideo.log"

Here's the breakdown of this command, piece by piece.

The %ffmpeg% reference uses the environment variable named ffmpeg.  It shortens what I
have to code for each invocation of ffmpeg & ffprobe.  Without the environment variable,
I would have to code this minor monstrosity every time:

G:\ffmpeg\ffmpeg-2021-07-11-git-79ebdbb9b9-full_build\bin\ffmpeg

-hwaccel is supposed to take advantage of my GPU to speed up processing.  I don't know if
it helps but it doesn't cause problems so I keep it.

-ss specifies the time index where the problem of too-fast video began.

-i specifies the input file, the file name of the original recording of the round of golf.

-map selects only the video track from the input file (0:v means from the first file,
files being numbered from 0, select the video track), ignoring whatever other tracks
might be there.  In this case, there were only the video & audio tracks.

-codec: copy tells ffmpeg to simply copy the data bit for bit without reencoding it.

-y says replace the output file if it already exists, a convenience in this case, but
something you should give a few moments of careful thought to every time you code it.

The output file name is the next bit.  It should be self-explanatory.

The 2 items with > at the end of the command capture the output of ffmpeg in files for
careful inspection after the fact.  This is standard Windows redirection.  If you are
unfamiliar with it, do a web search on the subject.  Coding > causes the file to be
created if it does not already exist, or erases its current contents & starts adding new
content from the beginning if it does already exist.  In subsequent commands, I coded >>
instead of > to tell Windows to append new output to the end of the existing files.  In
practice, the 1> file is always empty, but I keep that specification for completeness,
just in case.  2> is where ffmpeg puts its log file.  I won't be paying any further
attention to this.  You'll see it in the rest of this post but I won't comment on it.

This command is intended to split the video track of the original broadcast into a
separate file.

It actually did not work.  I added debugging output (parameter -loglevel trace) to try to
figure this out.  I got a log file of about 1.8 million lines that I had to page through
because I didn't know what I was looking for.  Painful & time consuming.  I eventually
figured out that ffmpeg was dropping duplicated frames.  As I've mentioned several times
before, these allegedly livestreams from NBC Sports actually seem to be coming from a
stored file on a server, not directly from a live TV feed.  When I record a golf
broadcast, the beginning of the recording reverts back to some time before the broadcast
began.  The recording starts with anything from a half hour to an hour & a half of a
screen that just says:

Coverage will begin shortly

In the case of this particular round of golf, they put something over 50 minutes of this
uselessness on the front of the livestream, which VDH dutifully recorded.  I discovered
from the command that failed that ffmpeg sees this mass of duplicated frames & decides to
stop processing the input.  The command I show above kept generating an empty output
file.  The log file seemed to indicate that it was giving up at about 17 minutes into the
broadcast.

I searched the ffmpeg documentation for anything that might give me a clue & as usual,
found no help.  No point in repeating how lousy I think their documentation is.  Multiple
web searches looking for help turned up the opposite of what I wanted to do.  Everybody
seems to be concerned with getting ffmpeg to remove duplicated video frames from files.
Nobody seems to want to keep them, which is what I needed to do.  Nobody showed any
examples of how to stop ffmpeg from bothering to detect duplicate video frames.  If
anybody reading this can tell me how to do that, I would welcome that with great
enthusiasm.  What I did should have worked.  In coming up with that command, I tried it
on a few other files I have on my system & it worked perfectly to strip the video track
out of the original file.  So the fact that it failed on this one was a big surprise to
me.  I am quite convinced that the command should have worked but does not because of the
idiosyncratic nature of the NBC Sports livestreams, specifically the initial long stretch
of unchanging silent video that is the hallmark of their content.

So I dropped back 10 & punted.  I used the Convert function of VLC.  I set the starting
point for conversion to 3:59:40.000.  They allow you to specify thousandths of a second
in the time stamp.  I left the ending point for conversion at 0, meaning process the file
from the starting point to the end of the file.  In the subsequent conversion dialog (I
had to click the little wrench icon), I made sure that the Video Codec & Audio Codec tabs
of the dialog specified to keep the original track.  I then selected a file named
Shortened.mp4 as my output.  This did create a file of a few minutes duration containing
just the end part of the broadcast with the fast video & normal audio.  VLC did the
conversion so fast I thought it had failed.  I'm sure if I had been dealing with
something of a more substantial duration, it would have taken longer.

Then I executed this command:

"%ffmpeg%\ffmpeg" -hwaccel auto -i "Q:\Golf\Shortened.mp4" -map 0:v codec: copy -y "Q:\Golf\Video Only.mp4" 1>"Q:\Golf\SlowDownVideo.err" 2>"Q:\Golf\SlowDownVideo.log"

This also failed, but with a specific error message that told me there was some sort of
incompatibility between the input file & my requested output file.  I don't know what it
was.  The input file looked like a regular mp4 to ffprobe.  It played like a regular mp4
in VLC.  But something about it was upsetting ffmpeg.  It appears that VLC creates a
strange type of mp4.  At least, ffmpeg thinks it's strange.  So I tried this:

"%ffmpeg%\ffmpeg" -hwaccel auto -i "Q:\Golf\Shortened.mp4" -map 0:v -y "Q:\Golf\Video Only.mp4" 1>"Q:\Golf\SlowDownVideo.err" 2>"Q:\Golf\SlowDownVideo.log"

The only difference here is that I left off the -codec: parameter.  This got ffmpeg to
reencode the file into what it considers is a standard mp4.  This finally gave me a short
file containing only the sped-up video track from the end of the original broadcast.
This command is quite CPU-intensive. My case fans were blowing up a hurricane while it
was executing.  Fortunately, I was dealing with input of a short duration, barely 15
minutes, most of which was taken up by the usual "Coverage has concluded" tail that NBC
Sports likes to tack on the end of their livestreams.  I'm sure if I had been dealing
with a couple of hours' worth of content, it would have taken a considerable time to
complete.

One rather annoying thing that happens with this is that ffmpeg severely degrades the
quality of the video.  The original had bit rates in the 4,000kbps range while the output
was around 1,500kbps.  This was quite visible in the playback.  I guess ffmpeg just
figures out what it can get away with & does it.  I suppose I could fiddle around with
certain ffmpeg parameters to get it to preserve the bit rates.  That will be an exercise
for another day.

So once I finally had my video track, I did this to get the audio track:

"%ffmpeg%\ffmpeg" -hwaccel auto -ss 3:59:40 -i "Q:\Golf\LPGA Round #4.mp4" -map 0:a -codec: copy -y "Q:\Golf\Audio Only.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"

This worked perfectly on the first attempt.  The only difference between this one & the
one above is the -map parameter value 0:a.  Above, I selected the video track.  Here, I'm
selecting the audio track.

At this point, I verified the properties of the 4 files I had: the original broadcast,
the tail end of the original broadcast as massaged by VLC, the video track of the end of
the original broadcast extracted from the VLC output file, the audio track extracted from
the end of the original broadcast:

"%ffmpeg%\ffprobe" "Q:\Golf\LPGA Round #4.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"
"%ffmpeg%\ffprobe" "Q:\Golf\Shortened.mp4"  1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"
"%ffmpeg%\ffprobe" "Q:\Golf\Video Only.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"
"%ffmpeg%\ffprobe" "Q:\Golf\Audio Only.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"

Finally, I could get to trying to correct the speed of the video track.  When I played
Video Only.mp4, I tried using VLC to slow it down to 0.5 speed.  To my eye, this still
looked a bit fast.  There is a way to adjust the playback speed factor in the VLC GUI.
But it is in increments of 0.02.  I decided after trying a few different playback speeds
that I needed a finer adjustment.  So I looked at the program shortcut in my Start Menu
to discover where VLC resides on my system.  Its location is this:

"C:\Program Files\VideoLAN\VLC\vlc.exe"

As far as I know, this is the default configuration, so you will find it in the same
place.  But that's not a guarantee.  I opened a command window & changed directories to
that location.  Then I executed this command:

vlc --rate=0.455

This opened VLC with the speed factor set to the indicated value.  Then I played
Video Only.mp4 in that window.  It looked reasonably good.

Now that I had a speed factor for converting the video, I could tell ffmpeg to slow the
video down.  I have done quite a bit of web searching to find this information.  The page
where I found the advice I'm using here (sorry, I didn't make note of it) contained
suggestions for several different possible approaches.  I tried them all & found only
this one worked.  I have to believe that the guy who posted this advice had tried the
other things & they had worked for him.  But it's possible I wasn't doing it right.  It's
possible that his advice is applicable only in an environment similar to his, & mine is
not similar.  It's possible that his advice is no longer valid due to changes in ffmpeg
since he posted.  Whatever the reason, only this is what worked for me:

"%ffmpeg%\ffmpeg" -hwaccel auto -i "Q:\Golf\Video Only.mp4" -filter:v "setpts=2.1978*PTS" -y "Q:\Golf\Slow Video Only.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"

The interesting bit here is the -filter parameter on the output file.  It defines a video
filter (the :v part) to apply to the output.  The filter is setpts.  PTS is an
abbreviation for Presentation Time Stamp.  I only barely understand what I've done here
so don't press me on these things.  The weird number 2.1978 is the reciprocal of 0.455.
1/0.455=2.1978.  This is how the filter works.  If you want to slow down the video to
half speed, you code setpts=2*PTS.  If you want to speed it up to double speed, you code
setpts=0.5*PTS.  That's just the way it works.  So this command created an output file
named Slow Video Only.mp4.  When played at normal speed, it looked like the original
broadcast slowed down by a factor of 0.455, which produced reasonably natural looking
motion.

At this point, I stopped & played 2 files synchronously in VLC: Slow Video Only.mp4,
Audio Only.mp4.  The audio & the video were out of synch.  I used the usual VLC controls
(the j & k keys) to advance & delay the audio track.  I found that once I had gotten them
reasonably in synch at one point, they were out of synch again a few seconds later.  I
believe this is because 0.455 was not the perfect speed for slowing down the video.  I
could have experimented further with other speeds to try to find what would be better.  I
should have observed how much the audio was out of synch & by how much it was drifting,
whether ahead or behind the video.  But by this point, I had spent about 6 hours only to
try to watch about 5 minutes of what was left of the broadcast.  I was out of energy.
I'll try that next time I encounter this problem.  I am quite certain I will encounter it
again.  It seems to be a frequent occurrence with these Golf Channel broadcasts.

Keeping the video & audio in separate files simplifies the trial & error process for
trying different speed factors for the video.  But I also tried aggregating the 2 files
together:

"%ffmpeg%\ffmpeg" -hwaccel auto -i "Q:\Golf\Slow Video Only.mp4" -i "Q:\Golf\Audio Only.mp4" -codec: copy -y "Q:\Golf\Video with Audio.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"
"%ffmpeg%\ffprobe" "Q:\Golf\Video with Audio.mp4" 1>>"Q:\Golf\SlowDownVideo.err" 2>>"Q:\Golf\SlowDownVideo.log"

Since each of the 2 input files consists of only a single track, this command is this
simple.  If the input files contained the usual video & audio tracks, I would have to add
-map parameters to do this.

In any case, this aggregated file was no different from what I got playing the 2 files
synchronously.  I still had all the trouble synching the audio with the video.  I also
had another problem.  This was a problem both when I played the 2 files synchronously as
well as when I played the aggregated file.  Skipping forward & backward in the file in
VLC was very sluggish.  This was not something I observed with the original broadcast.
The sluggishness was the same no matter whether I had tried to synch the audio ahead or
behind the video by substantial amounts or I had left the audio offset from the video at
0, meaning with no attempt to synch.  The file was of a very short duration.  I have
noticed with longer files that sometimes, VLC gets progressively more sluggish the larger
the time index within the file that I'm playing it back.  But this file was only about 15
minutes long, & the sluggishness was observable from the start.  I don't know if I will
observe this in the future or if it was just something weird about this case.  Experience
will tell.

So this is how I dealt with the issue without getting any fancy software, free or
expensive, to edit the file.

[Wild Willy]

There is a typo in one of my ffmpeg commands in that most recent post.  I'll leave it to you to find it.  I'm not entirely sure but it may have been the source of my difficulties stripping the video track out of the original broadcast.  Kinda rookie mistake.  I feel shame.  Also, it occurred to me that I made my evasive maneuver more difficult than it needed to be.  You can tell VLC to not copy either video or audio during a Convert operation.  So VLC can be used to create separate audio & video tracks.  It is my understanding that VLC relies heavily on ffmpeg.  That would mean that my ffmpeg commands are just the equivalent of what VLC can do.  Whatever.  I like having choices for doing something.  In any case, there's another golf tournament this weekend & I'll see if any of the rounds needs to be fixed.  That's when I'll get to test this out again & see if I can manage to do the whole thing without fat-fingering anything.

[Wild Willy]

Today's round of golf recorded fine & it does not look like there's anything wrong with
it. I haven't watched it yet but skipping down to the end shows the usual "Coverage has
concluded" message. When there's trouble with the file, I can't easily find that trailer
stuff so this file must be fine.

Nevertheless, I tried some experiments on this recording to see if the things I have
lined up would have worked on this file if it had been bad. I can say that I must have
made a typo trying to fix the last round of last week's tournament. I was able to strip
off the video track of today's recording using ffmpeg. I did not have to resort to VLC.
All that stuff I said above about duplicate frames? Hogwash. In the immortal words of
Emily Litella, NEVER MIND. Still, the typo wasn't a complete waste since I discovered
that I can strip tracks out of a video using VLC.

With today's test material I found that playing back the aggregated file in VLC responded
much better to keyboard controls for skipping forward & backward than the synchronous
playback of the video & audio as separate files. I will have to observe a few more
problem files before I definitively recommend going ahead & aggregating the files every
time. At least the sluggishness I observed with last week's example was not apparent in
today's test, neither for synchronous nor aggregated playback. I have fooled around a
bit with extracting video using VLC & then processing it in some way with ffmpeg. In
every case, ffmpeg complains about some missing data for frame 0 & then throws multiple
errors throughout processing that seem to deal with missing information concerning timing
control. Ffmpeg does successfully complete the task but it seems to do so after
compensating for some things it sees as errors in the input. I have my suspicions that
VLC may strip out tracks but it doesn't do it perfectly correctly. It's possible that
the corrections ffmpeg makes cause the sluggish playback I observed with last week's
tournament. Going forward, I will not be using VLC for the task of separating video &
audio tracks. I will always prefer to use ffmpeg. I will consider VLC a fallback
resource in case something comes up that baffles ffmpeg. I don't know what that might
ever be but I'm not irrevocably closing that door. That is, if I can manage to avoid
typos, or at least notice them before I run off trying alternatives for no good reason.

For today's test I pretended that a problem came up just 10 minutes before the end of the
recording. The step of processing 10 minutes of a video track to change its speed took
rather a long time, maybe 10 or 15 minutes. I didn't pay close enough attention to give
an exact number but it seemed to go quite slow. I will have to be mentally prepared to
see this when I hit one of these problem 2 and a half HOURS before the end of a
broadcast. It might take 30 minutes, an hour, or even longer to change the speed of a
recording that long. I think I will start by chopping out maybe 5 minutes of a bad
broadcast so I can fool around with the speed factor. Changing the video speed by the
correct amount seems to be critical to being able to synch the audio with it. If I don't
have the video speed right, the audio has no chance of ever staying in synch with the
video. In addition to the various parameters I'll be coding on ffmpeg commands as I've
already described, I will additionally be using the -t parameter to limit the stripping
process to maybe 5 minutes, so I can experiment with that to determine the right factor
for changing the speed. Once I've got that right, I'll remove -t & let the complete
remainder of the file get stripped out. The slowness of the speed change step is what
has me thinking this way. I don't want to change the speed on 3 hours worth of content,
taking maybe 45 minutes, only to discover it's not the right speed & have to do it again.
Test it with 5 minutes until I get it right & then do it for real on the full file.

[Wild Willy]

After recording 3 days of this week's golf tournament perfectly with VDH, today's round had the problem.  After playing perfectly for about 1:48:11, suddenly the golfers started their Munchkin imitations while the TV announcers continued to speak normally.  The full duration of the recording was 3:26:27.

I was able to extract the full audio track from the damaged recording with ffmpeg.  The extracted audio track played fine in VLC, of course with no video.  But extracting the video track from the damaged file did not succeed.  It extracted only 1:38:12 from the front of the damaged recording.  That's not even all of the section that was fine, short by about 10 minutes.  I have been seeing this now on several of these instances of damaged recordings.  Since extracting the video seems to be a problem, perhaps this would work:

1. Extract the audio track from the damaged recording.  This appears to always work.
2. Process the damaged file as is, video and audio, to slow it down to the speed that makes the too-fast part look natural.  In the case of today's recording, I found that half-speed was what made the players look normal.  So this step would expand the file to a duration of 2x3:26:27 = 6:52:54.  Presumably, the part that was fine would now last 2x1:48:11 = 3:36:22.
3. Extract the video track from the slowed down file.  Extracting video from the original damaged recording failed, but I would hope this would work.
4. Copy the video track created in step 3 but skip the first 3:36:22.  That would be using the ffmpeg parameter -ss 3:36:22.  You might be able to combine steps 3 & 4 but I would keep them separate in case step 3 doesn't do what you expect.  But in that case, you should just give up at that point.
5. Copy the audio track from step 1 but skip the first 1:48:11.
6. Step 4 gives you an video-only file.  Step 5 gives you a audio-only file.  They should both start at the time index in the original recording where the video became twice as fast as the audio.  Play these 2 files synchronously in VLC.  The video & audio may be out of synch by a second or two.  This sort of thing is never perfectly accurate.  But you can use the j & k keys during playback in VLC to adjust the synchronization of the audio with the video.

I say that is not really a productive use of your time.  Step 2 is the one that takes time.  I've seen it take a few hours on one of these rounds of golf.  Extracting the individual tracks, as in steps 1, 3, 4, & 5, takes minimal time, maybe only a minute or two.  So step 2 is the killer.  Unless you intend to keep the file permanently & watch it repeatedly over time, I wouldn't bother with that.

Instead, I was able to watch the damaged part of the recording by doing this:

0. In preparation for what comes below, change the VLC settings so you can be running multiple instantiations of the program.  I show an image of what that looks like attached to my first post upthread.
1. Extract the audio track from the damaged recording.
2. Play the audio track from step 1 in VLC, but skip it forward & pause it at 1:48:11.  You will keep the volume in this window at 100%.
3. In a second VLC window, play the damaged video but with the audio muted.  Skip it forward to 1:48:11 & pause it.
4. Now do your best to resume playback in the 2 VLC windows so the audio synchs up with the video.

Getting the 2 windows synched up can be a bit tricky.  But with a little practice, you can get the hang of it.  For golf, the points of reference are when the club hits the ball.  I pay attention to how I hear that sound.  Do I hear it before I see it or do I see it before I hear it?  Whichever window plays the event first is the one that needs to be held back a bit.  So I switch to that window & pause it for however long it seems that window is ahead of the other.  This is usually no more than a second or two.  Then resume it.  But then there's those pesky commercials.  You need to pause both VLC windows.  Then advance one past the ad & pause it right where the program resumes.  Then do the same in the other window.  Then do your best to resume both windows as close to simultaneously as possible.  It's likely you'll need to adjust the synch again, but since commercials occur every few minutes, you'll get plenty of practice & you will get good at this.

I have 2 monitors so I think this simplifies things.  I set the muted video to play in fullscreen on my television & play the audio track on my computer monitor.  I'm sure you can get away with doing all of this on a single monitor.  I would imagine you would find fullscreen video a bit inconvenient because you would want to have access to the audio window.  But it's doable if you have fast fingers.

The critical part of all this is figuring out your reduced speed factor.  I was lucky today that the video went to double speed, so my playback speed was 50%.  But I have seen other cases when the video was 3 times normal, other cases 6 times normal, and yet other cases with some other speedup factor that was not that easy to determine.  If you don't have the video at the right speed, you'll get the 2 VLC windows synched up & soon after, they will be out of synch again.  It can be rather tedious figuring out what video speed stays synched with the audio.  I mentioned upthread that you can execute VLC from a command line like this:

vlc --rate=0.50

This gives you extremely fine control over the playback speed.  The speed factor can have several decimal places.  So you can specify a speed of something like 0.3333333.

The takeaway is this.  Instead of letting ffmpeg chew on your video for hours, you can just do this two-window trick with VLC & be done watching the video before ffmpeg would have been done processing the file.  I would mess ffmpeg to deal with this problem only if your file is one you want to keep for many future viewings.