Too fast video - possible solutions or workarounds.

[mjs]

There have been a number reports of downloaded videos where the video speeds by very quickly as though it is on fast forward. Then for the remainder a frozen frame with audio Only. Some of these reports sound like the problem is with private Vimeo videos embedded on other sites. Video Downloadhelper appears to download the video only from a dash manifest regarding Vimeo videos. The problem could be with video hosted elsewhere.

This post proposes possible solutions or workarounds for too fast video. First lets deal with Vimeo. If it isn't working in VDH even after checking every video resolution then it sounds like a problem with the dash manifest. So lets avoid that and try other options.

Try these tutorials on YouTube, they're of course done in Chrome but can also be done in

Firefox in a slightly different way.

Example 1:

 https://youtube.com/watch?v=CQu4IUMPqxA

Example 2:

https://youtube.com/watch?v=CDomGOjyisY

In example 1 for Firefox , you right click on the url and click or hover over Copy Value then click Copy Response. As seen in image :

Now paste what you copied in a rich text editor such as WordPad or something similar.

To get an mp4 link of the video use the find function and type mp4 then click find next.

Keep clicking find next to get the resolution you want. You'll see width:1920 , and after that a url. This is the 1080p resolution.

Copy this url as seen in image and open it in a new tab , right click save video as. Choose name and directory to save video.

In example video 2 for Firefox , find the script part shown in the video and right click on it. Then click or hover over Copy then click Inner HTML.

Paste what was copied in a rich text editor like before then repeat the step to find the mp4 url as shown in the first example to download video.

I'll post another way using youtube-dl for Vimeo.

[Wild Willy]

Good work! I can attest that this also happens with livestreams I have recorded from the
NBC Sports/Golf Channel web site. These recordings are HLS & at least 90% of them record
perfectly. For example, I've recorded the first 3 rounds of a golf tournament Thursday,
yesterday, & today. There were no problems with them. But every once in a while I'll
get the too fast video problem with one of these golf livestreams. Since these are
livestreams, there is no possibility of "trying all the resolutions." I don't know until
the recording ends whether the problem has occurred. By then, obviously, the livestream
is no longer available. Worse. Trying to access the manifests through Network Monitor
gives 403 Forbidden - access denied. These download with VDH so Michel is doing some
sort of magic to get the livestreams. But I can't even look at the master manifest.
There is a master manifest but all attempts on my part to read it are blocked by the 403
error.

I opened a thread over a year ago in which I have posted an extensive discussion of this
problem with an explanation of the evasive maneuvers for repairing one of these too fast
videos over here:

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

Although mjs is focusing on Vimeo content & my discussion focuses on Golf Channel
livestreams, my evasive maneuvers should be able to repair the Vimeo videos as well.
However, if mjs's advice to try all resolutions turns out to work for your video, that is
certainly easier than my evasive maneuvers.

[mjs]

Downloading  private Vimeo video using youtube-dl. What is needed :

On Windows , youtube-dl , ffmpeg ( includes ffprobe and ffplay )  I have the .zip version which can can be extracted by Windows. And  Microsoft Visual C++ 2010 Service Pack 1 Redistributable Package (x86)  ( install this if you don't have it )

On Linux and Mac , you need only youtube-dl  and ffmpeg installed. I don't know about Mac computers but in Linux you should be able to install both from your software manager.

This will be explained on Windows. Once you have everything and ffmpeg has been extracted make a new folder called youtube-dl. 

Next place youtube-dl, ffmpeg ,ffprobe and ffplay inside this folder. Then put the folder in your desired directory.

With the folder open you'll see what looks like an address bar above it. Click in there and type cmd and press enter. You have now opened the command prompt for the directory youtube-dl is located in. To select youtube-dl press the tab button until you see it then give a space .

Next copy url of the video in your browser address bar . What we want to is bring up a list of formats for the video. So type  -F  give another space then paste the url and press enter. With a list of formats we can choose what to download and that also means avoiding dash manifest variants.  Example of what it looks like in below log file.

To a choose format repeat those steps to select youtube-dl, give a space.Try the http-1080p
version. Type -f  http-1080p then paste url and press enter. This version won't be downloaded from a manifest.

If you choose a hls version you type  -f  hls-fastly_skyfire-5614 give a space then paste url and press enter.

The format code has to be exactly as you see it from the list of formats.

The first example should look like this :

The second example should look like this :

[mjs]

For too fast video downloaded from other hosting platforms besides Vimeo , ffmpeg may be the only way. It could be something called

timed_id3 data included in the manifest. Using ffmpeg you can omit this. This might seem intimidating and complicated but further down

the discussion there is a simplified way using ffprobe.

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

[mjs]

If the problem resides on Vimeo.com rather the video being embedded on an external site, try this method.

Go to the video that has the issue, let the page finish loading. Then press F12 or Ctrl + Shift + I  to open the Developer Tools.

Click on Network , click in the Filter bar and type player.vimeo.com then reload the page with the video. There should be a url it finds.

Double click this or you can also right on it and open in new tab. Now scroll down about half way down and you'll find mp4 links corresponding

to the resolution. Choose the one you want and open the mp4 link in a new page. Now right click on it and save video as, choose a name and a directory to save video.

[mjs]

Lets look at an example video I was sent by email : https://akademie.dubistgenug.de/aufzeichnung/

It is in German , I don't know the German language but lets see how it went in VDH. I downloaded this video in Linux and Windows in the 2 resolutions available.

They both played fast like it was on fast forward , in VLC though it just had a frozen frame with the audio playing. And the Windows version had no

watermark added as I have no license. The thing to note is both versions have a extremely high frame, a typical video should have 25 frames,

30 frames or 60 frames. The one on the left is from Linux and the one on the right is from Windows:

On Windows no watermark , even though it said one was added :

Now lets see how it went without VDH. I downloaded the video another 2 times both being Video only and no audio as I just wanted to see

how the video played. I used 2 different methods, one is the youtube-dl method I've already mentioned. On this method I wanted to see if the dash

version had a problem because VDH downloads the video from a dash manifest. I downloaded it and it played fine at normal speed.

The other method I used which I'll show is a less convenient way as the video and audio would be downloaded separately in the browser.

On the page for the video select the resolution you want by clicking the gear icon in the video player. Then press f12 to open the developer tools.

Click on Network and click Media. Reload the page with the video and you should see media urls. If you don't then start the video for a few seconds then pause it. There are both audio and video in there. The audio is on top and the second url is the video:

 

Note the &range=numbers  in the image , this is the part of the url that needs to be removed when you open the url in a new tab.

Just double click on it or right click on it and open in a new tab. Then click in the browser address bar and go all the way to the end of the link and

remove &range=numbers and press enter. You can then save the media whether it being video or audio by right clicking on it and Save video / audio as. In this instance I've only downloaded the video , but you can get both video and audio and play them together in VLC or merge the 2 files with VDH or ffmpeg itself. The video played fine once again at normal.

Video properties on the left , a dash variant downloaded using youtub-dl . Video properties on the right , video downloaded in browser by using the
developer tools. You can see they're the same :

The conclusion is that for whatever reason VDH gets a video with a very high frame rate and it plays too fast. Is that because the dash manifest

is damaged or is it something else. I don't know but I've shown it can be downloaded using other methods and it plays fine at normal speed.

[Wild Willy]

I visited your German web page. I don't speak German either so I can't comment on what
the guy was talking about. I found it interesting that this page has both a video player
& an audio player. I guess you can just listen to the guy if you don't want to watch
him. Without launching playback in either player, VDH recognized both the audio only
file & the video. I tried downloading the video with VDH & got results similar to yours:
no video with good audio & totally strange Windows File Properties on the Details tab.

Then I took a slightly different approach to yours. As advised (sort of) in those
YouTube videos by Vid Down Madness you quoted in your first post, I looked in the Network
Monitor for something with the word player in its name. I found an item named player.js.
I popped up the context menu on that in the Network Monitor & executed the "Save All As
HAR" function. I have no idea what a HAR is. Half a laugh? In the resulting file
selection dialog, I called the file vimeo.json, changing both the file name & the file
extension. I then edited it with Notepad++. I searched for m3u8 & found 8 occurrences
of a master.m3u8. I didn't study the URLs. They are long & full of gibberish letters &
digits. But it seemed like it was 8 occurrences of the same HLS manifest URL. So I
copied the URL out of there & gave it to ffprobe.

Aside: It seems like there's some sort of escaping convention in effect in json files.
Every " seems to be coded as \" instead of just ". This tripped me up in a previous
attempt to interpret one of these json files. In that other case, I thought a URL ended
with \. Not true. It was simply that the " terminating the URL was being escaped as \".

As I was saying, I ran ffprobe on the HLS manifest URL. It gave the results you can see
in the file I've attached. You can also see in there the ugly URL of the HLS manifest
that was the target of this ffprobe report.

You can see 3 Programs in the ffprobe report. You'll notice that audio Stream 0:0 is
shared by all 3 Programs. Two of the 3 video Streams are of resolution 640x360, 25fps.
But Stream 0:1 says its variant_bitrate is 759711, while Stream 0:2 says its
variant_bitrate is 774254. That makes Stream 0:2 the one of higher quality, although at
such a low resolution, the difference is probably hardly noticeable. Stream 0:3 was of
resolution 426x240 & I didn't consider it. This means that I would be using -map 0:2
-map 0:0 to get this video with ffmpeg.

Which I did. It took 00:04:05 to get an MP4 of about 162M, an average of a bit under
700,000 bytes per second download speed. I am attaching the image of the Windows File
Properties Details tab. Of course, the file played fine in VLC.

I suppose I should give the reference for how to use ffmpeg. Start here:

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

Then do a search for the text "cannot download" on that page. That will give you a link
you should click. It's all explained in there.

While I was in the json file, I also searched for mpd, hoping to find a DASH manifest.
There were several occurrences of video/vnd.mpeg.dash.mpd. This is clearly a partial
URL. But I tried prepending https://i.vimeocdn.com/ to come up with a complete URL.
That didn't work. The HLS manifest resides on akamaized.net, but prepending that to the
DASH manifest partial URL didn't work either. I don't know how to come up with a DASH
manifest URL given what I see in the json file. Looking at the hit details of the file I
downloaded with VDH is no help. There is no manifest mentioned in there, only media
URLs. I don't know if an actual DASH manifest exists. It could be that information in
the json is manipulated to come up with media URLs for downloading. VDH finds something
in there but I can't figure out how or what.

But this is moot. Michel has posted on here that only the YouTube style of DASH is
supported by VDH:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/yj0X6iZxBVo/m/jqU_cjO5EAAJ

I was unclear about the relationship between YouTube & Vimeo. They are apparently not
related at all. Vimeo has had a string of ownership changes & as far as I can tell, is
currently independent, publicly traded on NASDAQ. There is a Wikipedia article on them
(of course). YouTube, as we well know, is owned by Google.

I think I was confusing Vimeo with Vevo. Vevo, also the subject of a Wikipedia article,
is also separate from YouTube. But the article says Vevo is focused on "YouTube
syndication." I don't really know what that means. I think it means Vevo has some sort
of relationship with YouTube that Vimeo does not. I have downloaded videos from YouTube
that have the Vevo flag on them. In any case, Vevo is not YouTube. And Vevo is not
Vimeo.

Whatever. VDH doesn't understand how to handle embedded Vimeo content. I think there is
just enough similarity between YouTube & embedded Vimeo to confuse VDH. I have
successfully used VDH to download Vimeo videos. Well, one at least:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/yRowBqZXoKQ
https://groups.google.com/g/video-downloadhelper-q-and-a/c/GRHKV7ryDuk/m/9ygPXk7BBwAJ

So it must be that whatever a web site has to do to embed a Vimeo video, it adds this
layer of complexity involving the json that is not there on Vimeo directly. And that
causes problems for VDH.

Between mjs & myself, we have offered you have an array of options for successfully
downloading embedded Vimeo videos that VDH fails to download.

I'd like to comment on the Network Monitor. It is a handy tool at the center of a lot of
discusion on this forum. It is the place to start improvising an alternative approach
when VDH fails. When you have trouble downloading something with VDH, open the Network
Monitor & see what's there. Try the things mjs & I have suggested. Maybe you'll come up
with your own twist on things. If you do, please post your innovation here. Sometimes,
when you open a video in its own window, as mjs has described, you can use VDH to
download it from there. Sometimes. No guarantees. Lots of web pages consist of all
manner of things besides the video you want to play. These are things like links to
similar videos or to other parts of a series of videos. Or the strip down the right side
of YouTube pages giving links to other videos that may or may not have anything to do
with the video you're interested in. When you double click on an MP4 or WEBM or MKV in
the Network Monitor, you are generating a web page that contains only that one video.
Perhaps this narrow focus helps VDH recognize what it needs to. Perhaps it strips away
certain levels of complication that trip VDH up on the original page. But you can
usually use VDH when you have one of these mostly empty pages. You can also, as mjs
describes, pop up the context menu on the video player & use the browser's "Save Video
As" function. Whatever works.

[mjs]

I haven't done it that way before , how do you get the manifests from notepad++

 If you follow how I did it using Copy Response on the player.vimeo.com url  it has the same manifests in there.

Also in there I found one reference to dash :

"cdn_url":"https://f.vimeocdn.com","vimeo_api_url":"api.vimeo.com","request":{"files":{"dash":{"separate_av":true,"streams":[{"profile":"d0b41bac-2bf2-4310-8113-df764d486192","quality":"240p","id":"4402bbcc-d1dd-43c5-b298-ecf0e14c68b4","fps":25},{"profile":"f9e4a5d7-8043-4af3-b231-641ca735a130","quality":"360p","id":"2756523e-fec1-4716-86d8-a6c2adb283c0","fps":25

It looks like instructions to play audio and video as separate streams , if so then that is what I see in the developer tools / Network.

[Wild Willy]

First question answered in the attached sequence of images.

Copy Response . . . Interesting. I broke down & tried to find information on what HAR
is. HTTP Archive. It appears that your Copy Response & my Save All As HAR do the exact
same thing. Interesting that you found player in an item retrieved from domain
player.vimeo. com, while I found player in the file name player.js, which was in domain
f.vimeocdn.com. It looks like we've taken different paths to almost the same target.
Almost. Not quite. But like I said, we're offering an array of possible solutions.
People should take away from this that there are multiple ways of doing things. You need
to keep an open mind. Observe details. Improvise. Guess. Different sites will present
their data differently. Just use the Network Monitor to mine for gems.

The character string dash occurs many times in the json file in my illustrations. There
appear to be a lot of references to the dash character for drawing . . . something, I
don't know what. Only a few occurrences of the string dash seem related to DASH
streaming. None of them is near anything that looks like a URL I could use. There are
plenty of partial URLs, but I don't know how to complete them into usable URLs like
https://sitename/something/something/something. The example you gave is a bunch of
unintelligible stuff that doesn't give up a URL either. DASH seems to be a whole
different class of problem. HLS is easy as pie by comparison. Complete URLs to
manifests, ffprobe, wam bam, ffmpeg gets your video lickety split, next case. Maybe
that's why VDH has such trouble with DASH. Everybody seems to cook their own. VDH
handles the type of DASH that exists on YouTube. Handles it well. I get stuff off of
YouTube regularly with VDH & it's rarely a problem. I've kind of sort of figured out how
to get stuff off of YouTube with ffmpeg, but I get download speeds of 25,000 bytes per
second. Just as a proof of concept, I downloaded something from YouTube with ffmpeg a
week ago. It was about 1 hour duration & the download took FIVE HOURS! There is just no
advantage to using ffmpeg on YouTube. It is very much a desperation tool for me there.
But that's YouTube. Obviously, embedded Vimeo content is a problem for VDH. On the
other hand, content hosted directly on Vimeo seems to be no problem at all for VDH. But
that stuff is HLS. We've had a number of problem reports from European web sites that
use DASH & I've been able to find mpd DASH manifests in those cases. I've gotten
complete URLs to the DASH manifests out of the Network Monitor. At that point, it's
basically the same as HLS. I pump the DASH manifest through ffprobe & it gives reports
that look the same as any HLS results. Then I just run ffmpeg the same as for HLS
streams. VDH has problems with those sites but ffmpeg works like a charm. There's just
no predicting. Each case seems to need its own unique hand-crafted solution. I see our
effort here as a way for people to try stuff like we've done. It may work the same as
we're describing here. Or there may be differences. The uniting, underlying,
fundamental principle is the Network Monitor. Mine for gems. You don't know what you're
going to find until you start looking.

[Wild Willy]

It is important to understand that there are circumstances in which no downloader, not
VDH, not ffmpeg, not youtube-dl, no product will successfully download the content you
want. In such a situation, your only recourse is a screen recorder. I have something
called Open Broadcaster Software. OBS. I stumbled upon mention of it one day when I was
doing web searches on some other subject. It sounded like something I could use so I got
it. It works well enough in the few situations in which I have used it. I don't want to
project that I am any kind of expert on the subject. I found OBS, it worked well enough
for me, & I stopped my search. There are other products out there that do the same
thing. They may be better, they may be worse, I can't say. A screen recorder is always
a last resort solution. When you use such a product, it records the video & audio
playing on your system. You have to set the recorder to record, then launch playback of
the item you want to record. If it's 5 minutes long, it will take 5 minutes to make the
recording. If it's 4 hours long, it will take 4 hours to make the recording. While the
recording is in progress, you pretty much can't do anything else on your system. If you
switch tasks, the recorder will faithfully record the momentary interruption of what's
displayed caused by Alt+Tab. At least, that's how it works on my Windows 7 system. When
I've recorded things, I generally start the recording, then go to sleep. Clearly,
downloading is always preferable. But in the cases I describe below, a screen recorder
may be your only option.

The most common way of preventing downloads is Digital Rights Management. DRM. DRM is
one of the few things in the world of multimedia that seems to be something of an
international standard. Its primary purpose is to prevent downloading of content. You
can easily tell whether something is protected by DRM. Go into your browser settings &
disable the DRM support. Then try to play the content. If it plays, then it's not
protected by DRM & downloading is probably possible. If playback fails, turn the DRM
support back on. If the content now plays, clearly it is protected by DRM, and you'll be
out of luck.

But that's not the only way web sites thwart downloaders. We've been talking about
finding manifests, jsons, MP4s, & the like in the Network Monitor. If you try to
retrieve these objects on a site that wants to thwart downloaders, you can encounter the
error 403 Forbidden - access denied. This indicates that the item you tried to access is
protected by a password. Of course, the web site does not publish the password so once
again, you'll be out of luck.

And there's yet another thing you can encounter. In order for VDH or ffmpeg or any other
product to read content from a web site, it must send certain commands to the web site.
The web site could have been configured in such a way that those commands are not
implemented. You'll get an error message like Invalid Command. One time I even saw an
error message that said Command Not Implemented. Once again, you'll be out of luck.

But, you say, I can play the content with the player embedded on the web page. How is
that possible but I can't download the content? I am not an expert on this but I believe
the embedded player uses encrypted commands & secret passwords & things like that. The
web site knows how to communicate with the player on the web page on your system. But
when you try to download the same content or even just inspect it, you will be blocked
one way or another.

Now, it is possible to see some of these errors when there's nothing blocking
downloading. I've hit the 403 error when I've entered an incorrect URL. So before you
decide to resort to the screen recorder, inspect the URL you've used in ffprobe, ffmpeg,
youtube-dl, or whatever tool you're using. Inspect it carefully. Inspect it twice.
Inspect it three times. Inspect it till your eyes hurt. URLs are typically such ugly
monstrosities that you should be copy/pasting them, not trying to retype them yourself.
But maybe you accidentally brushed a key on your keyboard & oops, bad URL. So be careful.

[Wild Willy]

I was intrigued by your use of the menu entry Copy Response. I went back to that German
video & found the item named player.js that I had found. I tried several menu
selections, including Copy Response, and what I got was not useful in every case, except
for Save All As HAR. But when I went to the entry you found in domain player.vimeo.com,
the Copy Response gave me something that was useful, meaning it included the URLs of the
HLS manifests. Comparing Save All As HAR with Copy Response on this object shows that
there is a bunch more stuff obtained with Save All As HAR, but the additional stuff is
not actually useful. The useful stuff is retrieved with Copy Response for the object
you found. Copy Response retrieves 2 lines, & the second line is empty. Mind you, that
first line is thousands of characters long. Save All As HAR retrieves thousands of
lines, but only the 1 line in there is useful, & that line is the same one I got with
Copy Response.

So it seems that those menu functions retrieve different things depending on the type of
object you're looking at in the Network Monitor. Your object was HTML, mine was js, but
the two objects gave different results for the same menu functions. Something to keep in
mind for future reference.

[mjs]

In your Save all HAR method , did you have some idea it would work or was it just pure luck. Also if you check ,in addition to the manifests there

is also a mp4 link in there. The same mp4 link is found in the Copy Response way.

What is VDH doing with these downloads that the video gets messed up is my question. I've been thinking it gets the video from a dash manifest

but I'm not sure that is correct. Probably Dash streams where the audio and video play separately .

The hit details for that video from VDH :

https://30vod-adaptive.akamaized.net/exp=1663913260~acl=%2F68086bf6-c135-4c00-a16f-47551a907f4d%2F%2A~hmac=384ce212715f4fa4f044ffbd6fd3f00761787a2b758a27be565af9fdc106953e/68086bf6-c135-4c00-a16f-47551a907f4d/sep/video/4402bbcc,2756523e/audio/53430c0c,5e806bce,72e01515/dash-audio.mp4

https://30vod-adaptive.akamaized.net/exp=1663913260~acl=%2F68086bf6-c135-4c00-a16f-47551a907f4d%2F%2A~hmac=384ce212715f4fa4f044ffbd6fd3f00761787a2b758a27be565af9fdc106953e/68086bf6-c135-4c00-a16f-47551a907f4d/sep/video/4402bbcc,2756523e/audio/53430c0c,5e806bce,72e01515/dash-video.mp4

While the Developer Tools shows:

https://30vod-adaptive.akamaized.net/exp=1663913260~acl=%2F68086bf6-c135-4c00-a16f-47551a907f4d%2F%2A~hmac=384ce212715f4fa4f044ffbd6fd3f00761787a2b758a27be565af9fdc106953e/68086bf6-c135-4c00-a16f-47551a907f4d/parcel/audio/5e806bce.mp4?r=dXM%3D&range=5883-51754

https://30vod-adaptive.akamaized.net/exp=1663913260~acl=%2F68086bf6-c135-4c00-a16f-47551a907f4d%2F%2A~hmac=384ce212715f4fa4f044ffbd6fd3f00761787a2b758a27be565af9fdc106953e/68086bf6-c135-4c00-a16f-47551a907f4d/parcel/video/4402bbcc.mp4?r=dXMtZWFzdDE%3D&range=5882-191205

The urls all look very similar but the difference is the part in red.

[Wild Willy]

I wanted a way to copy the content of the js file onto my system. I didn't want to just
double click it. I tried the other menu selections & they weren't giving me the file.
So I did the HAR thing & that did it. Like I said, it seems like that's the only thing
that works for some types of object but for others, you have more than one menu selection
that will work.

On your prompting, I looked in Player.js for MP4 URLs. I came up with this:

https://vod-progressive.akamaized.net/exp=1663916956~acl=%2Fvimeo-prod-skyfire-std-us%2F01%2F4936%2F29%2F749684104%2F3444886134.mp4~hmac=796ef4eb74b7049020eebca50c7c43c4a6c5ea130d7e1737ed78f01633648ca0/vimeo-prod-skyfire-std-us/01/4936/29/749684104/3444886134.mp4

This was the only instance of a recognizable full URL for an MP4 in this file. There
were probably hundreds of other instances of the string mp4 in the file, but they were
all near partial URLs or were of some other nature, like the string video/mp4.

I tried visiting that akamaized URL. It gave me the black page as if it was going to
show the built-in Firefox media player, but it never did. You'll also notice that it
looks like there's another URL embedded twice within that URL, on a site that apparently
goes by the name vimeo-prod-skyfire-std-us. But I tried various tricks to isolate parts
of that longer URL & tried to visit those addresses. When I tried to go to the akamaized
site, I got access denied. The skyfire site said site not found.

OK. So let's look at the HTML object you discovered on the player.vimeo.com site. The
only URL for an MP4 in there is the weird one with the 2 URLs embedded within it.

So then I let the video play for a few seconds & that made a few MP4 objects appear in
the Network Monitor. You're right. Those have parcel embedded within their URLs. The
URLs in the VDH hit details are different. I tried to open the URLs VDH found. I just
got an error that said bad request. I have no idea where VDH is finding those URLs. I
suspect VDH simply is extracting information from somewhere, we haven't figured out
where, & misinterpreting certain strings as frame rates & bit rates. It's not that
anything is corrupt. It's that VDH isn't getting the information the way it should. So
when it builds the output file, it puts these bad attributes on it & it doesn't play
properly. For all we know, VDH is taking character strings & interpreting them as
numerics. This is the case that Michel has acknowledged VDH does not handle today. The
only kind of DASH content that VDH handles correctly is the almost proprietary case of
YouTube. Every other type of DASH, including our German site here, is simply not handled
correctly by VDH.

Meanwhile, I noticed a master.json in the Network Monitor. I grabbed that with a Copy
Response. It kind of looks like a proper mpd DASH manifest but not quite. I found that
it had a pattern of header information followed by entries that looked like they might be
chunk descriptors. Filtering out the chunk descriptors, this is what I found in that
master.json file.

{"clip_id":"68086bf6-c135-4c00-a16f-47551a907f4d","base_url":"../../../../../parcel/",

This appears to be some sort of header for the multimedia object. Notice the parcel
thing. Following that, I found these descriptors. Each one appears to describe a single
track of our multimedia object. Things are grouped by both square brackets & brace
brackets. I'm not showing the closing brackets. They come after the last chunk
descriptors. The first 2 things are owned by the "video":[ ] sequence. Within those
square brackets, there are 2 { } chunks. Then you have an "audio":[ ] sequence, within
which there are 3 { } chunks.

"video":[{"id":"4402bbcc","base_url":"video/","format":"dash","mime_type":"video/mp4","codecs":"avc1.640015","bitrate":309000,"avg_bitrate":206000,"duration":2508.36,"framerate":25,"width":426,"height":240,"max_segment_duration":6,"init_segment":

{"id":"2756523e","base_url":"video/","format":"dash","mime_type":"video/mp4","codecs":"avc1.64001F","bitrate":597000,"avg_bitrate":461000,"duration":2508.36,"framerate":25,"width":640,"height":360,"max_segment_duration":6,"init_segment":

"audio":[{"id":"53430c0c","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"mp4a.40.2","bitrate":191000,"avg_bitrate":191000,"duration":2508.3306666666667,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":

{"id":"72e01515","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"opus","bitrate":98000,"avg_bitrate":83000,"duration":2508.3265,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":

{"id":"5e806bce","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"opus","bitrate":66000,"avg_bitrate":56000,"duration":2508.3265,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":"

The first one looks like a regular video mp4 of resolution 426x240.

The second one looks like a regular video mp4 of resolution 640x360.

The third one looks like a regular audio mp4, which is actually indistinguishable from an
mp3. It looks like it would give Windows properties of sampling rate 48kHz, bit rate
191kb/s.

The fourth one looks like another audio mp4 but note the codec of opus. That's what you
see with webm files, not mp4. It looks like its sampling rate is also 48kHz with a bit
rate of 98kbps. Or maybe 83kbps. I'm not sure which number Windows would pick. For the
third one, the 2 bit rates are equal. Here, they're different.

And the fifth one looks like another webm audio track, sampling rate 48kHz again, but bit
rate either 66kbps or 56kbps.

The long stretches of the file that I am not showing look analogous to what we are
accustomed to seeing in HLS stream manifests. They aren't in anything remotely
resembling HLS format, but they appear to be trying to accomplish the same thing.

Meanwhile, I find it very odd that we have 2 webm audio tracks but no webm video track.
A webm video track would show vp9, not the avc1 in the codecs list that we see here,
twice. It's no problem for ffmpeg to merge together such disparate tracks into either a
webm or mp4, or even mkv, whichever you specify. I just wouldn't expect a structure like
this.

The fact that the items appear as individual, separate objects in the Network Monitor
does not mean they are "being supplied separately." We've gotten used to the
idiosyncrasy of VDH displaying certain variants as video-only or audio-only. I think
this is actually a shortcoming of VDH, perhaps even a bug. When I've been looking at HLS
manifests for problems reported by our fellow users, I can see that they are not actually
separate. VDH seems to like manifests in which there are unique audio & video tracks.
What I mean is, if there's 5 Programs (to use the ffprobe terminology), then Program 0
has video Stream 0:0 & audio Stream 0:1; Program 1 has 0:2 & 0:3; Program 2 has 0:4 &
0:5; and so on. Every Stream appears only once, and they're all in neat video/audio
pairs. VDH has no problem with such multimedia objects. When you get situations in
which a given audio Stream is shared across multiple Programs, VDH doesn't handle that
correctly. It shows separate video-only & audio-only tracks. Plus, if there are
multiple audio Streams, but fewer audio Streams than video Streams, so the audio Streams
are shared among the video Streams, VDH does not show all the audio Streams. But that's
just VDH. The tracks are not actually supplied separately in the sense we've gotten used
to understanding. Video players on web pages play audio with video. Ffmpeg can download
2 tracks into a single target file, either via 2 -i parameters or 2 -map parameters,
usually 2 -map parameters. It's only VDH that has conditioned us to think things are
audio-only or video-only. They are not. It's just audio tracks & video tracks OF THE
SAME multimedia object. This is a shortcoming of VDH. It just doesn't put together the
appropriate audio track with its partner video track. The information is in the
manifests. VDH isn't interpreting it correctly. There should never be a variant on a
VDH menu that is other than video with audio, unless for some reason the web site is
offering a silent video or you're looking at an audio podcast, something out of the
ordinary like that. The vast majority of the multimedia content around the web is talkie
movies. VDH should not be giving us video-only & audio-only variants.

Multimedia objects have such things as multiple video tracks & multiple audio tracks to
accommodate people with slower Internet connections. Smart web sites (most are smart)
detect your bandwidth & give you a lower resolution video with an audio track of a lower
fidelity in order to let you play the video without the constant, annoying buffering.
But we, here in VDHland, are not trying to just play stuff. We're trying to get our own
copies so we can have them forever. Or maybe, as in the case of YouTube, we're trying to
avoid the ads. Or maybe we're trying get our own copy of a 4K video that we just don't
have the bandwidth to play on a web page, but we do have the computer power to play if we
had the whole thing on our hard drive. Web sites don't necessarily give a rip about us.
Many aren't oriented toward people downloading their content. Those would be sites where
you don't see an easily accessible DOWNLOAD button. You've visited those. I have.
Also, we've certainly encountered our share of sites that have intentionally implemented
measures to thwart us. But despite all of this, we should really never think of video &
audio being "supplied separately." They're not.

But it's not all bad. This shortcoming in VDH has sure made us learn a lot about how
things work. Maybe even more than we ever really wanted to know.

[Wild Willy]

Oops. ERROR. When I visited this URL:

https://vod-progressive.akamaized.net/exp=1663916956~acl=%2Fvimeo-prod-skyfire-std-us%2F01%2F4936%2F29%2F749684104%2F3444886134.mp4~hmac=796ef4eb74b7049020eebca50c7c43c4a6c5ea130d7e1737ed78f01633648ca0/vimeo-prod-skyfire-std-us/01/4936/29/749684104/3444886134.mp4

I thought Firefox was not going to show me a video player. The page was just blank. I
was wrong. When I tried again just now, I thought to actually move my mouse around on
the page. Well, whaddaya know? There's a video player there. The German video plays
just fine with that URL. Strangely, the VDH menu remains empty even after launching
playback. Of course, the Save Video As trick works.

Actually, it worked once & now it's telling me I am not authorized to visit that web
page. I suspect it timed out just now. It has been a while since I extracted that URL
from the json. There's probably a new one there now. Yes. I made a new trip to the
page & the URL is different. The gobbledygook strings are different. Typical. The
point is, there is an mp4 URL inside these weird script objects & it does take you to the
video on a page by itself. I am quite perplexed why VDH doesn't recognize it when it's
presented like this. I ran ffprobe on the URL:

> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
> 'https://vod-progressive.akamaized.net/exp=1663927646~acl=%2Fvimeo-prod-skyfire-std-us%2F01%2F4936%2F29%2F749684104%2F3444886134.mp4~hmac=e4c538706106060b8a1e5a53e313d7d08cd5f8b38f8f65cfaf55a3d68f1b1b52/vimeo-prod-skyfire-std-us/01/4936/29/749684104/3444886134.mp4':
> Metadata:
> major_brand : mp42
> minor_version : 0
> compatible_brands: mp42mp41isomavc1
> creation_time : 2022-09-14T18:22:03.000000Z
> Duration: 00:41:48.33, start: 0.000000, bitrate: 523 kb/s
> Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m, progressive), 640x360, 442 kb/s, 25 fps, 25 tbr, 25 tbn (default)
> Metadata:
> creation_time : 2022-09-14T18:22:03.000000Z
> handler_name : L-SMASH Video Handler
> vendor_id : [0][0][0][0]
> encoder : AVC Coding
> Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 77 kb/s (default)
> Metadata:
> creation_time : 2022-09-14T18:22:03.000000Z
> handler_name : L-SMASH Audio Handler
> vendor_id : [0][0][0][0]

You can see the URL is different from the one in my preceding post. This information
looks pretty ordinary. I don't know why VDH wouldn't recognize it.

[mjs]

Another example video brought to the forum, this one is a bit of an unusual case.

https://www.konserthuset.se/en/play/alfven-and-nilsson/

Using the copy response method outlined up the top there are no mp4 urls to be found. So the next step is to use the find function again to

find m3u8. This should find .m3u8 manifest links. These can be used in ffmpeg to get the video and audio and merged into a single file.

The youtube-dl method will work but it will only get the video and audio separately.

I also tried using network method and removing &range=numbers to the links I found. It wouldn't bring up the video for 1080p and 720p

resolution videos encountering some error. It did work on the other resolutions.

[Wild Willy]

I looked into this video, too. I found that no MP4s showed up in the Network Monitor
until I let the thing play for a couple of seconds. I used the gear in the player to
override the Auto resolution selection. I found, as you did, that the 1080p & 720p
selections with the gear did make some new MP4s show up in the Network Monitor. But then
the double click followed by removing &range just gave some sort of HTML error. The
highest resolution under the gear that gave an MP4 that would actually open after
removing the &range was 540p, a rather pitifully low resolution.

I did locate an object in the Network Monitor from domain player.vimeo,com. There was
only one such object from that domain. Curiously, it was of type html. Using your Copy
Response trick, I was able to save this html file on my system. It looks like most of
the text in this file is inscrutable <script> tags. However, I was able to locate the
URL of a master manifest. I ran that through ffprobe. That did yield a way to get at
the 1920x1080 video. I didn't bother downloading it because frankly I'm too tired at the
moment. I actually found 2 URLs for master manifests. Each one occurred twice in the
html file. One manifest resided on akamaized.net & the other on skyfire.vimeocdn.com.
Running them through ffprobe gave what appeared to be the same results for each one. So
ffmpeg looks like the way to go for this video.

[Wild Willy]

The user posting over here:

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

posted 2 videos, both embedded Vimeo content. Once I was more awake, I delved into the
two videos more deeply. In the case of the Nilsson/Alfvén concert, the object at
player.vimeo,com contained 4 URLs for HLS manifests (m3u8). But it turned out those were
only 2 unique URLs, the other 2 being duplicates. One URL was on akamaized & the other
was on skyfire. I used each manifest to download the concert with ffmpeg. The resulting
MP4 files were identical. Both akamaized & skyfire served the same 1920x1080 version of
the concert, which was of duration about 1 hour 45 minutes. The downloads lasted about
10 minutes each. Of course, they both played fine, although I just skimmed them.

For the Mahler concert, the object at player.vimeo.com offered 7 URLs for HLS manifests.
There was once again a pattern of duplicates. Of the 4 URLs on akamized, there were
really only 2 manifests, each one duplicated once. Of the 3 manifests on skyfire, once
again there were only 2 unique URLs, one of them being duplicated. I retrieved one
version of the concert from each source. Running all 7 manifests through ffprobe showed
that the same content was available in all cases. But I wanted to download from each of
akamaized & skyfire just to cover all the bases. This time, the download from akamized
took about 26 minutes. This was unexpectedly long, seeing as the duration of this show
was just under 1 hour, considerably shorter than the other concert. But then, this
concert was offered in 3840x2160, so the file was much bigger. It played fine as far as
I could tell sampling it. The download from skyfire took over 40 minutes. The Resource
Monitor was showing that for this download, skyfire was all over the map with its speed
of download. It would show 6 million bytes per second for a few minutes, then it would
suddenly drop to 100,000 bytes per second for a few minutes. I don't know what was up
with that. The download of the other concert from skyfire ran at the same speed as
akamaized. In any case, the skyfire download did eventually complete & I had another
copy of the same concert, which played fine. Curiously, the version from skyfire was
very slightly smaller even though it was of the same duration. The bit rates from
skyfire were also slightly lower than from akamaized. But even at that, the bit rates in
both downloads were around 25,000 kbps, which is exceptionally good quality for a
3840x2160 resolution video. Typically, 4K content shows bit rates in the 15,000 kbps
range. So they went all out with this Mahler show.

The ffprobe results for the Mahler manifests showed the usual bogus error about inability
to interpret the subtitles stream. So I reconstructed the URL for a subtitles manifest
from the ffprobe error message. I was able to download captions from akamaized but the
skyfire download failed. When I looked at what ffmpeg had gotten from akamaized as the
vtt file, I decided not to bother actually troubleshooting the skyfire subtitles. The
vtt file was completely bogus. Besides, there was no talking in any language in the
video so I don't know where those captions were coming from. Still, it points out once
again that using ffprobe/ffmpeg will often show you subtitles you can't access any other
way.

[mjs]

Repair the downloaded video with ffmpeg

There is a way to fix the video by using a command in ffmpeg , solution found here :
https://groups.google.com/g/video-downloadhelper-q-and-a/c/SSgY9oLoHdw

If you haven't used ffmpeg before , there is a link to a page to learn how to use it in this thread.

This is the command to use in ffmpeg :  ffmpeg -r 25 -i  in.mp4  -r 25  out.mp4

This would be ok to use if the video originally had a frame rate of 25 fps but what if the video had a different frame rate.

How could the correct frame rate be verified.

To do that I used this example video found here:

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

You need to go to the embedded video that was downloaded with the high frame and use the Copy Response method found up the top of this thread. Use your preferred text editor and use the find function to look for fps. I used WordPad.

The first instance of fps it finds shows that it is 30 fps :

So the ffmpeg command needs to be :  ffmpeg -r 30 -i in.mp4 -r 30 out.mp4

Tip : if the input file has a long file name then type it's first letter then press tab and it will automatically complete it.

[The Big Lebowski]

Sorry guys

I tried to read everything that was posted but i completly lost track on the way

I'm not too technical though, so maybe that's why i didn't understand everything

All i can say, is that I clearly suffer from the same behaviour

I try to download a video using VDH (got a premium license) and although sound is ok, video is too fast

When i open developper console, i can see those lines :

https://16vod-adaptive.akamaized.net/exp=1667788688~acl=%2Fd09ef64d-b626-48f0-be89-f7c851df0ae7%2F%2A~hmac=6a9cd2abbb2272934e5df5fc4dce4bcf787449313ee31dd12c91357d08d7a5a5/d09ef64d-b626-48f0-be89-f7c851df0ae7/parcel/video/aa3835d9.mp4
https://16vod-adaptive.akamaized.net/exp=1667788688~acl=%2Fd09ef64d-b626-48f0-be89-f7c851df0ae7%2F%2A~hmac=6a9cd2abbb2272934e5df5fc4dce4bcf787449313ee31dd12c91357d08d7a5a5/d09ef64d-b626-48f0-be89-f7c851df0ae7/parcel/audio/d015b44a.mp4

There are 2 steams, one for audio, one for video

copy/paste for the audio steam in another tab makes me able to save the sound. But it doesn't work that way for video, hence why i'm lost

I saw ffmpeg might be able to help but still, i'm lost

Can anyone assist me with the different steps, even if it has to be manuel ?

(DVH developper won't fix that misbehaviour by the way so that the software can handle this automatically by itself ?)

[mjs]

Is that you in the other discussion

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

Do you want to do a screen share . A program like TeamViewer has a meeting function. You generate a meeting id and send it in a private

message. A day and time needs to be scheduled . My time zone is GMT +11

[Wild Willy]

It's time for a new ffmpeg tutorial. Give me the URL of your web page & I'll use it as
the example in a new tutorial.

[mjs]

The Big Lebowski , you almost got the video. I've seen it error like that on certain resolutions so you've done it right. But it might have to be done

another way to download it or try the repair. If your video is public then post it here. Otherwise with a screen share l can walk you through the steps.

[Wild Willy]

There's also the issue of timeouts. I have observed on some sites that the time it takes
me to copy/paste a URL for a master manifest from the Network Monitor into a script that
executes the ffprobe command is actually too long. It's a matter of only a few seconds,
yet the ffprobe tells me 403 Forbidden. I just reload the page & try again. I have seen
it take me 4 or 5 reloads before I manage to do it quick enough that the ffprobe succeeds.

Of course, I am doing the ffprobe in preparation for doing a download with ffmpeg. So
after I inspect the ffprobe report, I have had to do yet more reloads to get a new URL
for a master manifest & eventually the ffmpeg invocation will not only launch but
actually continue & successfully download.

The Metropolitan Opera is a site whose timeout seems to be comfortably long, perhaps
hours. That makes sense because most operas last at least a couple of hours. Some could
go on for 4 hours or even longer.

But the CBS TV livestream is one that has given me this timeout problem. Their timeout
appears to be a bit variable, seeming to be as short as 2 seconds & as long as 20
seconds. I think they don't append new information to an old master manifest, but rather
they just create a whole new manifest. They must do this every, I don't know, 5 or 10
seconds. So if I'm taking my information nearer the end of their 10-second window, it
closes right behind me & I'm out in the cold. Only repeated attempts make it work. And
it does eventually work. I have recorded entire NFL games from the CBS TV live feed,
recordings that result in files of duration as long as 5 hours. (I usually start before
kickoff & pad it out to allow for the possibility of overtime.) Those recordings are
actually quite beautiful, being 1920x1080 @ 60fps with bit rates in the 10,000kbps range.
I don't clearly recall but they might even be in surround sound. It's just that there's
a bit of difficulty getting it to start.

[Wild Willy]

Often, not always, but a lot of the time, you can get VDH to tell you the frame rate of a video.

This can be much easier than what mjs describes above.  Can be.  It doesn't always work.  Obviously, you can't do this when VDH doesn't recognize anything.  If the web site is not using HLS, you may still be able to find the frame rate in the Hit Details, but it's very much on a case by case basis.  Still, this can be a handy time saver when VDH offers such information.  Just be prepared to have go looking in more difficult places, as mjs describes above.

[Alex DaTro]

great, thank you soooo much!
I tried many of the discussed solutions, but none worked for me (I am no computer expert), but with ffmpeg : 

ffmpeg -r 25 -i  in.mp4  -r 25  out.mp4

it works easily

[Otavio Ferreira Martins]

You saved my life! Finally a solution that works, thank you so much!!

[Wild Willy]

Alex, Otavio, thanks so much for your feedback. It's comments like yours that encourage
me. Sometimes, I feel like I'm speaking into a vacuum. But knowing that some people are
being helped keeps me going.

I do have to say that what we have outlined here does not always work. For the World Cup
that is going on now, the TV coverage here in the States is being provided by Fox & FS1.
I thought there might be certain games I would like to record, especially during the next
few days when we will be having simultaneous matches played for the final round robin
group stage matches. I experimented with the Fox feed & it was quite amenable to
recording, both with VDH & ffmpeg. But I was getting very strange results with FS1.

I would let VDH record for a couple of minutes on FS1 & then stop the recording. Using
the stop button in the VDH blue dot status menu did not seem to be reliable. I kept
getting failures that left me with an unplayable file. So I reverted to pulling the
electricity feed from my Internet connection. That gave me a file that would play but it
was damaged. The first 30 seconds or so would be fine, then the video would go to about
double speed while the audio played fine. The video would eventually run out & freeze on
the last frame while the audio would play fine for the remainder of the video, which was
only about another minute & a half. I tried with & without HLS as M2TS enabled. It made
no difference. It was always good for a bit, then suddenly the video track would get too
fast.

The ffmpeg -r trick did not correct the problem. Ffprobe said the file was of duration
30 seconds, so ffmpeg would stop after respeeding the part of the video that didn't need
respeeding. VLC would play the entire 2 minutes, with the last part of the video too
fast, but ffmpeg simply would not process the too-fast part of the video. That part of
the file was simply invisible to ffmpeg.

Even stranger, every recording I made with VDH got the same content. It was the first 30
seconds of some stupid ad, followed by the next ads sped up for however long I let the
stream record. I never did get actual program content recorded.

So I started experimenting with ffmpeg. I found what seemed to be a master manifest
easily enough. But when I used that to record 2 minutes of the stream, I was getting
very strange results. To limit the recording to 2 minutes, I used -t 00:02:00. This
does not tell ffmpeg to stop recording after 2 minutes have elapsed. It tells ffmpeg to
stop recording after the result file has reached a duration of 2 minutes. My recordings
were taking over 4 minutes of elapsed time to write a file whose duration was 2 minutes.
And every recording was of the same ads that VDH had been recording.

The ffmpeg log showed a bunch of very strange processing. There would be a few
screenloads worth of log messages showing ffmpeg reading something from the manifest that
contained the word "discontinuity." This would be in lines that said ffmpeg was skipping
the input from the manifest. It is not unusual for manifests to contain descriptive
lines that ffmpeg simply skips over. Ffmpeg is looking for the next line in the manifest
that refers to a chunk of video content. So I would see all this noise content that
ffmpeg was skipping over. This would go one for several dozen or a few hundred lines,
I'm not sure, I didn't count them. Then finally, there would be a line starting with
frame= indicating that it was writing something into the output file. Those lines show
the time index of what it's writing. They also show a speed factor indicating how fast
the recording is progressing. The speed factor was usually about 0.2. That means ffmpeg
was recording at about 1/5 the speed of the content. So 1 minute of content was going to
take 5 minutes to record. Not very encouraging.

The fact that I was always getting ads led me to believe I wasn't letting the recording
run long enough to get to the program content. So I decided to record one of the matches
I was going to sit & watch through my cable box anyway, independent of the livestream
coming into my computer. I set ffmpeg to run for -t 04:00:00 to see what I would get.

I was already watching the next match when ffmpeg finally terminated. That was after
recording for SIX HOURS. Remember, -t is about the duration of the output file, not
about how long the command runs. I had a file of duration about 48 minutes. It took SIX
HOURS to record 48 minutes worth of content. So the recording did not stop because of my
-t parameter. Inspecting the ffmpeg log, which was ridiculously huge, showed that ffmpeg
had stopped because it had started getting 404 Not Found errors on the manifest. This is
one of the normal ways a livestream is supposed to terminate. The serving site is
supposed to simply remove the manifest for the livestream from the server. Another
normal way a livestream terminates is for the server to just stop updating the manifest
with information about new chunks of content. There are ffmpeg parameters that limit the
number of retries ffmpeg attempts against a manifest that is no longer being updated. I
explain those in my ffmpeg tutorial (see the reference upthread here). But in the case
of this particular football match, FS1 finally got around to removing the manifest for
the stream a couple of hours after the match had ended. And at that point, ffmpeg had
taken 6 hours to record less than 1 hour of content. The ffmpeg log showed an
overwhelming mass of the noise processing, with frame= lines few & far between, & a speed
factor far less than 1.

But I did have a perfectly playable MP4 of duration 48 minutes. It contained the same
handful of ads repeated over & over. It appears that FS1 has multiple streams, & one of
them is for the ads. So where was the actual football match? I was not having a whole
lot of success finding the master manifest for the real FS1 stream in the Network
Monitor.

So I made a bit of a guess. I looked in the VDH menu for variants that looked like they
might be promising. I picked one & looked at its Hit Details, as I describe above. I
fished the master manifest URL out of there. I passed that to ffmpeg. While ffmpeg was
running, I looked in the ffmpeg log it was writing. You don't have to wait until ffmpeg
terminates to read the ffmpeg log. At least, you don't with Notepad++. I don't know
about other text editors, like Notepad or Wordpad. But Notepad++ is perfectly happy to
open the ffmpeg log while it is still being written. Notepad++ is also perfectly happy
to reopen the log file to show the new lines that have been written at the bottom of the
file while you have been reading it. I discovered that sometimes, I was getting the
advertising stream. If I saw the long stretches of ffmpeg not writing frame= records, I
knew I was not recording the live stream of football. I would just cancel that
recording, empty the VDH menu with the little trash can in the tools you can hover up at
the bottom of the VDH menu, reload the page, let the stream play for a couple of seconds,
then hunt through the VDH menu for a variant that looked promising & get another manifest
from its Hit Details. It's a painstaking & tedious process, but eventually I found a
manifest that allowed ffmpeg to record the actual program FS1 was broadcasting.

I suppose you could argue that if I was getting a manifest URL from Hit Details in VDH, I
could just record that variant with VDH. True. The problem is terminating the
recording. You can't set a timer on a VDH recording. The livestream in question is from
a TV channel. They don't stop. The stream continues with whatever is on the air next.
VDH would record forever. And I have found that the VDH blue dot status menu is not a
reliable way to end a VDH recording. Sometimes it stops the recording properly & you
have a media file you can play. But sometimes it stops the recording & you have a file
that can't be played & can't be repaired. Yes, you can just pull the plug on your
Internet connection, but that's not always something you want to do, like if you're
recording 2 things at the same time. So ffmpeg is my choice here over VDH.

So the lesson to take away from this thread is not that ffmpeg -r is some kind of magic
spell that cures all ills. The lesson to take away from this thread is that you have to
be ready to improvise. Make guesses. Use the Network Monitor. Use VDH. Use ffprobe &
ffmpeg. Use them all together & figure out something that gets you the content you want.
And still be prepared to declare defeat. There will be content that you simply can't
record no matter which of our techniques you try. Some web sites just will not
cooperate. The only way to figure that out is to try everything we've discussed here.
And if you come up with something we have not discussed, do please add to the pool of
knowledge here by adding your comments to this discussion.

[mjs]

If you opt to go with the ffmpeg fix for your video then you still need to find out what the correct frame rate is.

Willy has shown the easiest way to do that by going to your video and using VDH to get the frame rate. I'll show what this looks like for

vimeo videos.

Hover over the VDH menu and to the right of the video hit is a button.

Clicking this opens a another menu. Then click Details.

This opens the details page for the video. Scroll down this page and look for videoMPD. To the right is a green triangle.

Click this to expand more information about the video and the correct frame rate.

Here it shows it to be 25

[mjs]

Here is another solution for those on Mac computers :  https://groups.google.com/g/video-downloadhelper-q-and-a/c/lx-rAMAC3PU