Videos jump around after downloading

[人Kev]

The audio is fine, but the video is super choppy, and appears to jump back and forth very very quickly. It's strange because I've downloaded from this site before (a subscription exercise video site) and had no problems, but that was already a year or so ago.  I am on MacOS using Firefox and checked that FF, the Video Downloader, as well as the Companion App, are all at the newest versions.

Any ideas?

[jcv...@gmail.com]

Hi,

It might be a player issue, often happens with QuickTime, we recommend using VLC player.

If not working with VLC you can try to re-encode the video stream: use “Download & Convert” (or convert local for already downloaded videos) using output format “Re-encoded MP4 (h264/aac)”, sometimes it fixes the problem.

jerome

[Huan Nguyen]

Hi Jerome,

I have the same problem when downloading some videos from vimeo. Could you try downloading from this link: https://player.vimeo.com/video/793796009?color&autopause=0&loop=0&muted=0&title=1&portrait=1&byline=1&h=8f6dce1c01#t=  (or the origin site: https://dfj.vn/pre-training/)

I've tried VLC and other players but the video is lagging, while the audio is fine.

Thank you!

Vào lúc 15:02:53 UTC+8 ngày Thứ Sáu, 3 tháng 2, 2023, jcv...@gmail.com đã viết:

[人Kev]

Interesting. You are correct. It worked with VLC no problem. I'm curious what the change was though. Previous videos that I downloaded from that site work find in QT, but not these new ones. I'll try using the other output format as well to see what happens. Is it possible to set Download Helper to that encoding by default so that when I just click the size I want it does it automatically?

[jcv...@gmail.com]

Unfortunately there are issues with vimeo. You can search the forum for users tricks : https://groups.google.com/g/video-downloadhelper-q-and-a/search?q=vimeo

jerome

[jcv...@gmail.com]

you can specify the download and convert as default action.

jerome

[jc vdh]

Hi Pooya,

Sorry I did not manage to get it. It's hosted by Vimeo, there are issues with this site, but you can search the forum for users possible workarounds : https://groups.google.com/g/video-downloadhelper-q-and-a/search?q=vimeo

jerome

On Thu, 2 Mar 2023 at 01:02, pooya khan <poya...@gmail.com> wrote:

Hi can you try download the video from following site:

--
You received this message because you are subscribed to the Google Groups "Video DownloadHelper Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to video-downloadhelper...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/video-downloadhelper-q-and-a/873f728f-9b14-41da-b6e4-b41bf3878570n%40googlegroups.com.

[mjs]

> I did not manage to get it.

What does that mean Jerome ? Did it fail or error messages ?

[Wild Willy]

Look upthread here for a post from fellow user Huan Nguyen. In his post, he gave 2 URLs.
I visited the first one, the one on web site player.vimeo.com. At first, the VDH menu
was empty. So I clicked the play button in the video & let it play for a few seconds.
That got VDH to populate its menu with a few variants. One was marked DASH streaming -
1920x1080 - 33:16 - 5.9Mbps - MP4. I downloaded that one. VDH had no trouble getting an
MP4. The web site was giving me an average of about 3 million bytes per second download
speed. I didn't measure the time of the download but it was only a few minutes. After
the download completed, VDH spent a few seconds aggregating the video & audio. Because
this was similar to downloading from YouTube, I can't tell what the download time was.
The created & last update time stamps on the file were the same. The file didn't exist
until the aggregation finished. Minor detail.

I looked at the Properties of this file & the video information was ridiculous. I
expected there to be problems playing this file & I was right. The video froze on the
first frame & the audio continued to play without a problem. This is a classic case we
discuss at length over here:

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

I looked at the Hit Details of the file I had downloaded to determine that the video was
actually 30 frames per second, not the over 15,000 fps quoted in the file Properties. I
then did an ffmpeg respeed operation to repair the video & reset its frame rate to 30
fps. The respeed operation took about 23 minutes. The file that resulted from this
respeeding played perfectly. I didn't sit & watch the video all the way through. I only
sampled the video at intervals. It mostly showed a guy speaking a language I don't
understand. I'm guessing it was Vietnamese. In the middle of the video there was a
short section that appeared to be a NASA clip in English. In any case, it played
perfectly with both video & audio all the way to the end.

The image attached below shows a side by side comparison of the Windows file Properties
of the original file downloaded by VDH & the file generated by the ffmpeg respeed
operation. The attached text file below shows ffprobe reports for the 2 files.

I'm running Windows 7 64-bit, Firefox 110.0.1 64-bit, licensed VDH 7.6.5a3 beta (same as
7.6.6), CoApp 1.6.3, VLC 3.0.18 Vetinari.

Just for yucks, I wanted to see if I could get this thing with ffmpeg. The Hit Details
provided by VDH show a URL for the video track & another URL for the audio track. But
when I tried to run ffmpeg supplying it with two -i parameters using those URLs, the web
site threw an error. By the way, you can't use -codec: copy when you have two -i
parameters like this. So I reverted to mining the Network Monitor. I had to use the
gear icon in the video player to set the resolution to 1920x1080. Then I had to
experiment with the MP4 objects that were showing up in the Network Monitor. I did the
open in tab trick on the entries in the Network Monitor to open each track in its own
Firefox tab. Eventually, I got a URL for the video track at 1920x1080 & a URL for the
audio track. It involved removing a string of &range= from the ends of the URLs.
Eventually, I had what I needed to feed to ffmpeg. It gave me the same video as what
came out of the respeed operation. It took about 21 minutes to download. I suspect this
is due to the . . . muxing . . . I think that's the right word. Since I couldn't use
-codec: copy, ffmpeg had to do more processing so things went slower. This time was
comparable to the time for the respeed operation, which does a similar kind of processing.

Interestingly, the separate video & audio tracks were recognized by VDH. I thought I'd
download them with VDH just to see if it would work. Both downloads completed
successfully. The audio download completed in a few seconds & the video took about 2
minutes. I was not convinced the video download would give a usable result because the
original VDH download had given one of those too-fast videos. But the video-only
download was usable. I played these 2 tracks synchronously in VLC & I had the same video
as the one that came out of the respeed operation.

So you have 3 choices with this item:

1. Download it with VDH & respeed it with ffmpeg.
2. Mine the Network Monitor to determine the URLs of the separate video & audio tracks,
then download those with ffmpeg via two -i parameters to give a single output file.
3. Using the same video & audio tracks from alternative 2, download those individually
with VDH & play the 2 files synchronously in VLC. This alternative actually took the
least time of the 3.