Problem With Videos Downloaded From Vimeo.Com

[Lawrence Martin]

Problem URL
https://vimeo.com/827536470

The name & release of your operating system
Windows 11

The name & release of your web browser
Firefox 112.0.2

The release number of your VDH & whether you have a license
7.6.6  demo license

The release number of your CoApp

1.6.3

Resulting download after aggregation the video plays at the wrong speed.  However, I can correct the video using ts muxeR to demux then remux the file.  File plays correctly after that.

Thanks.

Larry.

[Wild Willy]

An ideal problem report!  Thank you!

Just to keep up with you . . . I am using Windows 7 64-bit, Firefox 114.0.1 64-bit, VDH 7.6.5a3 beta (same as 7.6.6), CoApp 1.6.3.

I'm assuming this problem report follows the standard so closely because you are well aware of this:

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

You just needed to hunt for the string "vimeo" on that page.  That would have given you the link to the extensive discussion we've had on here about Vimeo content & all the problems it has posed for VDH.  And while I'm mentioning this page, do another search on there but for "stealth quote" this time.  It's important.  Please do it.  I've got images embedded in what I'm posting.  That makes it doubly important that you learn how to avoid stealth quoting.

I went to your web page & downloaded the variant shown here:

I decided to change the target file name:

Here's what it looked like while it was downloading.

That was early in the download.  It gradually slowed down to about 1 million bytes per second.  In any case, the download appeared to complete successfully after about 2 minutes.  This is what I had:

Clearly, the video bit rates are totally bogus.  When I played the file in VLC, it acted exactly as you described.  So it needed to be repaired.

Before I repaired it, I needed to find out what its frame rate was supposed to be:

You used muxeR to do this.  That's a tool I have never heard of.  I used ffmpeg.  You can see how in the attached file Vimeo download (VDH)mp4 Log.txt.  Look carefully for the places in that file where H264 occurs.  (Actually, it's h264, but the thing is case insensitive.)  There were some rather odd errors detected by ffmpeg.  They don't appear to have made much difference.  This is how things were after running that:

Those video bit rates may seem a bit high.  They actually are not.  This is a 4K video.  These bit rates are pretty standard for 4K content.  I'm a bit (pun pun) surprised that they are in this range.  I believe if you get 4K content from YouTube, you would see bit rates well under 10,000kbps, maybe even under 5,000kbps.  So I have to commend Vimeo for not cutting corners on this one.

To nobody's surprise, this repaired video played just fine in VLC, despite all the errors ffmpeg threw up.  I don't know what it was objecting to.  I have observed that it often complains about things that don't seem to hurt the outcome at all.

I'm wondering where they got the power to run the electronics.  I didn't hear a diesel running a generator.  Maybe it was far enough away to not be picked up by the microphones.  Maybe they used a solar power source.  That would be admirable.  I didn't see any wires attached to dancer boy.  He certainly was giving off enough energy to power it all.

[Wild Willy]

But you could do this another way that would not necessitate repairing the result.

You have to open the Network Monitor, then reload the web page.

Copy Response places the json into your system clipboard.  It is just plain text.  Paste it into your favorite text editor.  I use Notepad++ instead of plain old Notepad for many reasons, some of which you will see here.  So here's what the json looks like:

It's way too off-topic for this forum for me to explain how to install & use Notepad++, & how to use Notepad++ plugins.  I refer you to this web site:

https://notepad-plus-plus.org

I don't need to deal with the dog's breakfast that is this json, which is what pretty much all jsons look like.  I executed the Format JSON entry on the menu you can see in that image.

Notepad++ has a nice feature that kicks in when you highlight a string.  It highlights the string you have chosen, but it also highlights all other occurrences of the same string in the file.  In that image, I highlighted the first manifest URL.  Notepad++ simultaneously highlighted the other 3 occurrences of it.  So the first manifest URL is just repeated.

Experience has shown that you can pick either the akamized manifest or the skyfire manifest.  You will find the same results in both places.  I decided to use the akamized manifest.  It was first.  It's basically a random choice.  Don't dwell on that.

Running that manifest through ffprobe gave the results you can see in attached file ffprobe.txt.  It describes a single WebVTT captions track, a single audio track, & 7 video tracks of various resolutions.

I was surprised to discover that there are actually English subtitles being offered here.  I was hoping they would be the lyrics to the song since I couldn't make out any of them.  To my ear, they could have been in any language at all.  I ran the 2 invocations of ffmpeg you can see in attached files Vimeo download (ffmpeg)mp4 Log.txt & Vimeo download (ffmpeg)vtt Log.txt

A word about attachments.  I attached the files to this post in the order in which I mention them in this narrative.  Google, in its infinite wisdom, has decided to place them in reverse order.  This is what always happens.  So annoying.  So look at the file names, not their positions below.

For the sharp eyed among you, I was taking so long to write all of this that the manifest timed out.  I had to reload the web page, which generated all new objects in the Network Monitor.  So the manifest used in the ffmpeg invocations is not the one I'm showing above in the Notepad++ screens.  That's not unusual.  This sort of thing happens all the time on lots of web sites.  It doesn't change this little tutorial.  The URLs I'm showing won't work for anybody else anyway.  Not only do they time out, as I just found out.  But they also uniquely identify my web session to the server.  You need to visit the web page yourself & do all of this.  Do not bother copying the URLs out of the things I've posted here.  They won't work for you.  What will work is the process I've described here.

Unfortunately, the captions aren't really worthwhile.  Here is the entire subtitle file:

----------------

WEBVTT

02:50.363 --> 02:51.493
They're coming down.

----------------

Looking again at the ffprobe of the manifest, I saw that the captions stream is labelled as being "auto-generated."  The technology for machine recognition of lyrics appears to be not particularly reliable, at least not today.  But if you encounter a case like this one, in which captions are offered, this process will get them for you.

In any case, here is what these new results look like:

This is the same video as I got by repairing the one VDH downloaded, & VLC confirms that.  The difference is I did this in one step without the need to repair the results.

So you've got a choice:
Download it with VDH then repair it.
Download it in one step with ffmpeg.  If there are captions, which VDH doesn't handle, you can get them with ffmpeg.

[Lawrence Martin]

Thanks Wild for the extensive reply. Here is the app I was using to demur then remix. 

https://www.videohelp.com/software/tsMuxeR

This app is virtually a front end to an ffmpeg fork. The is another one I use for demux, remux and cutting and joining MP4s. 

https://www.videohelp.com/software/My-MP4Box-GUI

It’s old but it still good at what it does.  Either app will identify frame rates of the elementary streams after they are demuxed. 

I think the final program stream frame rate is posted wrong.  Some of the diagnostics I did showed a frame rate of 24000fps. This tells me the developer is somehow missing a decimal point. (24.000 fps it should be)

Cheers!

[Wild Willy]

You say 24fps. Interesting. In the log I posted above of ffmpeg splitting the tracks
up, I did ffprobe on the output file that was the raw H264 video track. It says in there
that it's 25fps. Not 24 & some fraction, like you often see. 25 on the nose. I thought
that was a nice confirmation of what VDH had detected. I suppose it's another way to
discover the frame rate. Just split the video track off & ffprobe that. Then proceed to
the respeed step using that information. I did the whole thing in one flow but doing it
as 2 steps could be a possibility if you don't already have a frame rate.

If the guy posted the video at that speed when he meant to do it at another, hey,
software can't read minds. I'm not sure the human eye can detect the difference between
24fps & 25fps. It looked OK to me at 25fps. But I'll take your word for it on 24fps.
In any case, it's good to have multiple tools to work with. Thanks for posting about
yours.