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.

[Glenn M]

I know these posts are over a year old, but I have a possible solution to your problem.

I recently downloaded some videos from vimeo, and their frame rates were very high, like 15,000 fps.

When I tried to play the file, the video fast forwards and is finished in a few seconds, while the audio plays at the normal rate.

I looked around on the ffmpeg forum, did not find much, and posted a question.

One of the responses was a link to this post:

https://superuser.com/questions/1088382/change-framerate-in-ffmpeg-without-reencoding

That contains a way to change the frame rate without re-encoding:

ffmpeg -i input.mp4 -bsf:v setts=ts=STARTPTS+N/TB_OUT/XX -codec: copy output.mp4
where XX is the frame rate you want, like 30.

I ran this on my videos, and it fixed the problem.

In a few of the videos the audio drifted farther and farther out of sync.

Turns out those were 25 fps instead of 30.

Re-running the script for 25 fps solved that problem.

You might be able to run that script on your entire video

instead of cutting the video into pieces,

and you don't need to separate the video and audio.

You might have to experiment to get the video frame rate that matches the audio.

Another issue you were having is the messages before and after the actual program, plus commercials.

Once you have the video corrected, it should be easy to cut out the unwanted sections.

I normally use the free program avidemux for trimming out unwanted sections

( https://avidemux.sourceforge.net/ ).

However, when using it on either a bad or corrected file, it reports a timing problem and wants to process it before opening it.

After the processing, there were audio/video sync problems with the bad file, but not the corrected file.

Another simple free editor good for cutting is 

AVI Trimmer+  https://www.solveigmm.com/en/products/avi-trimmer-mkv/

It seems to be able to handle both the bad and corrected files.

Good Luck.

[mjs]

Thanks Glenn,

I didn't think there was a way to do that without re encoding the video , but I tried it by uninstalling the latest companion app and installing

companion app 1.6.3 since I don't even get video with the latest 2x versions only audio. Then I downloaded a 30+ minute video.

The video was messed up with over 15000 fps. I used your method with the correct frame rate and it was done in under 4 seconds.

I did it a second time with an older method that fixes the video at correct fps but re encodes it and took over 15 minutes.

There is another way faster way that involves copying the raw video and audio then generating a new file with correct frame rate but this

is a 3 step process. Also there is no guess work on the frame rate, there are ways to find out what it is. You can find out more in the

Too fast video discussion. Search the forum for it and read through it.

[Wild Willy]

This smelly old thread brings back memories, not all of them good. As mjs said, we
figured out what to do a while ago & explained it at length in that thread with "too
fast" in its title. The 3-step process mjs mentions is something I've encapsulated in
a .bat file, so it's really only 1 step when I have to apply it, something I have done
numerous times in this forum. I've posted the ffmpeg log file of that process in a
number of those threads as well, so you can look at those should you come across any of
those discussions. I'm not sure if that technique would have corrected any of these
faulty golf broadcasts. All of the examples we've dealt with in the too fast cases have
had all the video crammed into the first few seconds of the file. My golf errors were
usually an hour or 2 after the start of the file. The file would have an hour or 2 of
perfect recording, and then the video would speed up. But it wouldn't speed up by a
factor of several hundred, making the video flash by in a few seconds, as in all of the
too fast cases we've worked on. The golf sped up by only a factor of 2 or 3 usually. I
believe our too fast technique would have dealt with this but I never had the chance to
try it out, as I explain next. So it remains an untested hypothesis.

As I've just hinted, I have not had any problems with this out-of-synch issue with golf
tournaments in rather a long time. No, it's not because VDH has been doing a flawless
job of recording the golf. Truth is that VDH is no longer capable of recording the golf
tournaments. But this is not a flaw in VDH. It is a flaw in NBC Sports. The wankers
went & put all their content behind DRM protection. As I recall, that happened shortly
after New Year 2023. The few times I've been forced to record some golf since then
because I wouldn't be home, I've resorted to using OBS to just do a screen recording. I
have occasionally recorded NFL games off the local CBS affiliate's stream & this works
well in ffmpeg. I get 1920x1080 videos with bit rates in the 10,000kbps range & 60fps.
They are really nice looking videos. I haven't tried any of those with VDH because VDH,
or more accurately the CoApp, only recently went to downloads via ffmpeg. Plus only the
latest CoApp reliably terminates inflight downloads/recordings & gives you a usable file.
So I might be tempted to try VDH on a football game on CBS at some point. ABC/ESPN also
have protected their content with DRM so VDH & ffmpeg are out of the question for them.
I've had some success using ffmpeg on Fox but it's been inconsistent. I don't have much
occasion to want anything from them anyway so it's not an issue for me. I should try VDH
on some hockey just to see if it works now. It didn't used to. VDH has not worked on XM
radio. They do something weird. It's not DRM directly, but I haven't been able to
record their streams. But I haven't tried it with the latest VDH. Maybe I will just to
see if it works. Nope, doesn't work. VDH gives an ever-growing proliferation of short
AAC files. Side download on one of them generates a Grabinfo error. I've tried messing
with the Network Monitor on XM & anything I've tried to ffprobe gives 403 Forbidden.
It's like they have stealth DRM going on. I have used OBS to record XM, though. That
works well enough on the few occasions I've tried that. The video track isn't very
interesting but the audio is fine.

[Wild Willy]

I read that superuser discussion. I'm not so sure this fancy thing with the bitstream
filter (-bsf:v setts) is much of an improvement on the respeeding technique we got from
another user in the too fast discussion. At the very top of the superuser discussion
there is an example that attempts to use the -r parameter in a quite similar way to our
respeeding technique. I did some experimenting with -r when the suggestion was first
floated in our too fast discussion. I found that it was not good enough to specify -r
only on the input file or -r only on the output file. The only way the technique works
is to supply the same -r value on both the input file AND the output file. The example
in the superuser discussion shows -r only on the output file. Nobody suggested he also
code -r on his input file. I would have liked to have seen that. But that thread was
opened SEVEN YEARS ago.

Glenn, next time you are doing one of these fancy repairs with the bitstream filter, I
would be most curious to find out if the simple approach using -r on both the input &
output files works just as well. But don't just try it based on what I've said here. Go
read the too fast thread. That's where the topic is discussed more completely.

I'd also like to understand what exactly STARTPTS+N/TB_OUT/60 does. Is the plus sign for
performing an addition? Are the slashes for performing divisions? Or are they just
separators? I've looked in the documentation that comes with ffmpeg & as usual, it's no
help. They don't have any examples that use this stuff. All those things are documented
in section 18.29 but it's the usual sort of gibberish you find with the ffmpeg
documentation. If you already know what it means, then it's probably a good reminder.
But then, such a user only barely needs the documentation. If you are trying to learn
this stuff, the documentation raises more questions than provides answers. You seem to
understand this. Do please elaborate on this.

[Troy Jennene Gibby]

Thanks for posting this update entry from a year-old string of post, since many folks have the same issue. I, for one, am not a guru nor am I able to read code, yet I can follow directions and get the hang of the posting thread enough to try & solve my problem. My video would not play despite being able to get the video <vimeo> to download & save. I've been at it for last 3 days, figuring I could make this work by reading and following some of the solutions listed in this forum. I did follow what Glenn M suggested, and for the first time in 3 days I was able to play the video & get it to play correctly with audio. I did an uninstall and cleared my app pref's & re-installed. Thanks it worked.

Microsoft WIN 11

Vdh 8.0.0.6 

Mozilla Firefox

[Wild Willy]

At the moment, the latest VDH for Firefox is 8.1.0.0a5 beta with CoApp 2.0.5. With this
combination, I did a short test on a live hockey broadcast available here:

http://onhockey.tv/

There was only one variant displayed on the VDH menu. The icon with it was something
retrieved from the web page, not a standard VDH icon indicating what kind of download it
would be. So I used the secondary VDH menu to make sure I was selecting a Side Download,
which was available. I let VDH record about a minute of it & then killed it. That was
successful. It left me with a 1-minute mp4 that did play fine in VLC. I may be making a
huge logical leap but it does appear that the latest VDH is capable of recording these
hockey games, something the old VDH could not do in the past. This is very good news.

[Wild Willy]

I mentioned XM radio above. I've just tried again to get VDH to Side Download something
from XM. The variant on the VDH menu claimed it was over 5 hours long. I thought I
might let it run for 5 minutes & then kill it & see what I had. When I went into the
blue dot, the icon on the inflight download was not the usual kill button. Hovering my
mouse over the icon told me, "Copy the media URL to the clipboard." I could not be less
interested in doing that. Out of curiosity, I went to the Resource Monitor to see what
ffmpeg was doing. To my surprise, ffmpeg was not there. But ffprobe was. It's still
there. I've let it run for the past 20 minutes or so. It claims to be using a steady
40,000 to 45,000 bytes per second of my bandwidth. I sure would like to know what it's
doing. But VDH doesn't give us any debugging output. I know from experience that
ffprobe can generate something useful that I would be able to read even if I abruptly
canceled it. But I don't have such a thing in this case. I hope refreshing the
extension kills this instance of ffprobe. And I have no hope that anybody on the inside
can investigate this because XM is a subscription service. I would, of course, volunteer
to test a version of the software that included special debugging instrumentation. I
know. I'm dreaming in technicolor.

[Wild Willy]

Well surprise surprise. After an inordinately long delay, VDH finally ended the
download. I had not yet refreshed the extension like I said I was going to. VDH failed
with the GrabInfo error. It took ffprobe nearly half an hour to figure out that it
couldn't get the information it needed? I sure would like to have been able to read that
ffprobe report. My suspicion is that it was getting endless 403 Forbidden errors. I
wish I could have more than vague suspicions.

[Elusis]

So I have a Vimeo download, and it has this same problem. I'm looking at Troy's post but we have a very different setup - I'm on a Mac, for one thing (Ventura 13.5.2). Can anyone point me to a straightforward fix for my download and its out-of-sync audio/video?

For what it's worth, even when I've reloaded the page, subsequent efforts to download the video have thrown this series of 3 errors each time.

[mjs]

@Elusis , have you got ffmpeg installed. Once you have it you need to find out what the correct frame rate is.

This discussion shows how to do that: https://groups.google.com/g/video-downloadhelper-q-and-a/c/sNfTCMYfiTU

Jump to Dec 20, 2022 , after finding the frame rate you can use the fix Glenn posted above.

[Wild Willy]

When you say "straightforward" I'm thinking you're looking for something that will take 5
or 10 seconds & involves only 1 or 2 steps. I don't have such advice. The advice I have
is in a thread in this forum with the words "too fast" in its title. Search for it, then
read it. That will take you a certain amount of time & several steps. But each step is
easy. You just need to clear your mind, concentrate, & read carefully. Read the whole
discussion & follow links to other threads & read those as well. We didn't come to these
realizations in a few seconds so you shouldn't expect to get something that works in a
few seconds. It takes effort. Spend the time. You will get a solution.

"Gone" is usually a condition that is corrected by reloading the page. But you say you
did that. I think one other thing you needed to do was empty the VDH menu. Before you
reload the page, hover over the arrow in the bottom left of the VDH menu. That makes
some previously invisible icons appear. Hover over each icon to get a tooltip telling
you what each one is for. One of the icons is a trash can. Click that. After you click
the trash can, thus emptying the VDH menu, reload the page. My suspicion is that you
repeatedly clicked an old entry in the VDH menu even after each page reload. VDH places
its new content AFTER stuff that's already in the menu. You have to scroll it down to
find the new stuff after each page reload. So my guess is you were attempting to
download something that was no longer there. Most things expire so you have to make sure
you're always looking at current variants. The easiest way to do that is to just empty
the VDH menu, THEN reload the page. That way, the VDH menu contains ONLY new stuff.

In addition, you need to be using the latest VDH beta for Firefox & the latest CoApp.
Check out these references:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/jRjBH5lDctw
https://groups.google.com/g/video-downloadhelper-q-and-a/c/guxm6mUhm8s

They will explain what it takes to get on the latest versions of the software. Some of
it has been updated since I wrote the posts in those 2 threads. Be sure you get the
latest releases, possibly newer than the ones whose version numbers I quote in those
threads. The latest versions still don't handle Vimeo correctly, but you should have the
latest versions so you don't report any problems that are already solved by the latest
versions.

For completeness, keep this handy:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/BzPLK2YyL-s

Before you report a problem, scan that thread to see if maybe your issue is covered in
there. Use that to find relevant discussions before you post questions that might
already be answered in this forum.

[Kiwi Avi]

I've tried quite a few options but still no success.

Can anyone give me a hand with this page please.

https://www.decodeyourattachmentstyle.com/live1699353200961

These are a working documents and it is quite hard to always be connected to the web in order to go through the info in them.

[Wild Willy]

I went to your page & scrolled it down to the first of the 5 videos on that page. You
can see what VDH was telling me in the attached image #01. So I did what VDH told me to
do on that menu. You can see what happened in attached image #02. I let the video play
for a few seconds, then paused it. Then I opened the VDH menu. This is how these things
are supposed to work. I downloaded the 1920x1080 variant at the top of the VDH menu.
The download went fine. The file VDH created played fine in VLC. I didn't sit & watch
the thing, just sampled it at intervals to make sure it was playing fine. It was, with
both video & audio, at each sample point. I let it play the last 10 seconds or so to
make sure the whole thing was there.

This is on Windows 7 64-bit, Firefox 115.5.0esr 64-bit (the latest one that Mozilla will
let me run on W7), VDH 8.1.0.0a8 beta, CoApp 2.0.8. The operating system & browser are
probably of little consequence. I'm fairly confident the versions of VDH & CoApp are
critical. Those are what you should be using. Where can you find them? Check out this
thread that I updated just a little while ago today:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/XDN1zsEpQ_E

Read my advice there. It applies to you.

[mjs]

Willy did you get a fully playable video ? I have the same beta version but went to companion version 2.0.9 but I still don't get a video.

Only audio.

[Wild Willy]

Yes, perfect in every way, video & audio. You've mentioned this before & it's very
puzzling. I have to repeat that in situations like this, I do so desperately wish there
were some kind of debugging instrumentation in VDH that we could turn on & off. We could
look at some kind of internal execution trace log & perhaps puzzle some things out on our
own. Failing that, we could send the log in to either Michel or Paul & one of them could
no doubt pinpoint the error in no time. But we're stuck with this, where you say it
fails for me & I say it works perfectly for me. That leaves us where? Nowhere is where.
It's frustrating.

Not long after Paul revealed himself, I raised this issue of debugging instrumentation &
he implied it was already something he had been thinking about. But it's one of those
chicken & egg situations. They are knee deep in bug corrections & product enhancements.
When are they going to put some effort into a feature that only they will see? Except
debug logging would help with bug corrections. I have to believe they've got some
special version of VDH they use to develop it & that version has loads of debug
instrumentation in it. They should think hard about making that debugging version the
standard public version, at least in the betas. It serves everybody's best interests to
have such a thing. I'm quite astonished it wasn't already in the product before I'd ever
even heard of it.