Corrupted video frame rate

[Thomas S 1517]

After downloading just fine some files have a corrupted video frame rate
which causes
- VLC to playing audio without the video

- Windows Fotos to play the video very, very fast.

Environment:
Windows 10, Firefox, Video DownloadHelper 7.6.0

VLC shows:

https://www.metadata2go.com/ shows

I can provide more information including the file itself.
Any help appreciated.

[mjs]

Try all the video qualities that are available in the vdh menu, to see which ones have a proper frame rate. You may get one that works.

--

A vdh user

[Wild Willy]

We now have a collection of threads, most of them fairly recent, all of them sharing the distressing commonality that the original poster seems to have disappeared & lost interest in the discussion.  Moreover, not a single one of these cases includes a proper problem description.

https://groups.google.com/g/video-downloadhelper-q-and-a/c/xB1XQOFs0zo
https://groups.google.com/g/video-downloadhelper-q-and-a/c/WfQfhriLDNI
https://groups.google.com/g/video-downloadhelper-q-and-a/c/i8bP8DOVN00
https://groups.google.com/g/video-downloadhelper-q-and-a/c/4BaGtP_xbQY

In all of these cases, I have offered this thread as a workaround.  I admit it doesn't fix VDH.  I also have to say that it is unclear whether VDH is the cause of this problem.  But it is a problem I have observed & I have come up with a way to deal with the issue:

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

This thread is new enough that I can't yet judge whether the original poster has lost interest.  Based on the trend, I am not optimistic:

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

On the other hand, this user posted what is very close to a proper problem description.  So maybe I should be more optimistic.

Here is the problem description.  Something happens intermittently that causes the video to run at a ridiculously fast rate while the audio plays normally.  I first noticed this a year ago & I have seen this multiple times in the interim.  I get it with Golf Channel livestreamed tournaments.  But I get it maybe once every 10 or 15 rounds of golf.  The intermittency of the problem does make it nearly impossible to nail down.  I just wish one of these posters, I don't care which one, would follow up.  Try my approach.  Does it help?  Did it trigger a better idea you could be cajoled into sharing with us here in public?  This is a problem that I wish could be identified & I would welcome a workaround that is less of a kludge than the one I've been using.  But I've offered the kludge & nobody else has offered anything.  Nobody else has even said whether they can apply my kludge.  Nobody else has said whether they have a better idea.  I'm pretty sure this is not a problem with VDH but I'm not 100% certain.  Since it is intermittent, Michel probably can't replicate it so there isn't any hope a fix to VDH is forthcoming.  The assumption that this is caused by VDH is not entirely supported by the facts.  The fact is that most downloads with VDH DO NOT exhibit this too-fast-video problem.  So blaming VDH is a hard sell.  My suspicion is that there is some field in the control block of the video that indicates the video speed.  I believe this control block is known as the MOOV atom.  My suspicion is that one field in the MOOV atom needs to be repaired.  How did the field get corrupted?  Beats me.  Maybe there was momentary noise on the line.  I though TCP/IP had built-in safeguards to prevent such corruption but I believe it is not foolproof.  It can correct single-bit errors but it might not catch double-bit errors.  Maybe the video was encoded incorrectly by the serving web site.  Maybe this, maybe that.  Maybe maybe maybe.  How do you repair the damage?  Beats me.  I don't know the internal structure of a MOOV atom.  But you'll notice my repeated us of the word, "suspicion."  I'm guessing.  I'm not a guru in these matters.  I'm a guru only in watching golf tournaments.  I'm also a guru in railing against the deplorable state of apparent apathy among the people posting these problems . . . and problems in general in this forum.  All I know is that the video in these cases is not totally corrupted.  If you slow playback down by some factor, you will see a proper video.  The slow down factor is something you can determine only by trial & error.  Sometimes you can play it at 50%, sometimes 25%. sometimes it's some fraction that is probably an irrational number.  Irrational number.  A mathematical term.  If you don't know it, look it up.

Trying all the resolutions -- resolutions, not qualities -- offered by VDH is probably not productive.  For one thing, I see this problem with livestreams.  I don't know the problem has occurred until after the livestream ends.  You can't chase play the livestream while VDH is recording it.  I've tried.  You can't do it.  So you can't know you've got the too-fast-video problem until the recording is complete.  So by the time I might reach the decision of trying the other resolutions, the livestream is no longer available at any resolution, even the one I just recorded.  So that suggestion is a non-starter.  Besides, like I say, the problem usually does NOT occur.

All I can do is post this comment in each of the applicable threads & hope somebody sees it & progresses this discussion.

[Thomas S 1517]

Not sure my fix/workaround has already been reported somewhere else in this conversation, but here is it anyway:
After I downloaded a video from Vimeo I check the frame rate in the details dialog of Windows Explorer.

If it is unreasonable high I run the following script:

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

I can now see the video at the correct rate in 100% of the cases I tried it.
(It's strange to me that the size the mp4 file is reduced though.)

Hope this helps,
Thomas

[Wild Willy]

That's a great solution! I don't know that you necessarily need the -r on the input side
but it probably doesn't hurt. Also, you could just as easily code

-r 24
-r 30
-r 60

Those are other common frame rates.

The size might be reduced because the bit rates of the video & audio might be reduced.
Did you look at the other attributes listed on the Details tab of the Properties dialog?
What does it say for the original & what does it say for the corrected file? Is the
audio affected? Does it play the audio in synch with the video for the whole file?

[mjs]

Who would of thought that the video could be be fixed using ffmpeg. I didn't think such a thing would be possible.

The file size does go down because the data rate and bit rate go down but this solution introduces a peculiar oddity in that the duration went

up. The original video with the high frame rate had a duration of 104.41 while the repaired video had an increased duration to 117.38

An extra 13 minutes. I used the video found on this page as an example :

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

Thomas , since you brought a solution to the problem you should check out the alternative methods outlined here :

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

[Wild Willy]

I retested this. First I downloaded the file with VDH, knowing it would be messed up.
Sure enough, playing that back gave me a single still image to go along with the 1 hour+
of perfectly good audio.

Then I tried changing the speed but I specified -r 30 only on the output file. My
results made me laugh. Now, accompanying the perfect audio, the entire video flashed by
in about 5 seconds. I guess that's an improvement.

Coding -r 30 on both the input & the output gave me a good video, with audio that synched
with the video for the entire duration of the file. Of course, I didn't sit & watch it.
I only sampled it, but every spot where I stopped seemed to be fine. I did watch about
the last 30 seconds, during which you can see the guy speaking. The audio was properly
synched with the movement of his lips.

I suspect you can choose pretty much any frame rate for the -r parameter. I should
think, though, that the -r value for the input file has to match the -r value for the
output. Maybe for a non-damaged input file, you could entirely omit the -r parameter on
the input file, or the two -r parameter values could be different. But for a file like
this one, which is damaged, you probably need to keep them the same. I chose -r 30
because it's a common frame rate. I should think you could choose really any frame rate
& it would work. On something like this, where the video is rather grainy & more like a
PowerPoint slide show than an actual video, the frame rate is not very important. The
resulting bit rates are quite low, also in keeping with the low quality of the video.

My corrected file was the same duration as the original. I don't know why you didn't get
the same result. The bit rates in the corrected file are lower because the original bit
rates are simply bogus, way too high to be believable. I imagine the shrinkage of the
file size is related to that. It is quite a dramatic downsizing, too, being only a bit
over half the size of the original.

I'll have to try this approach next time I get one of my golf tournaments recorded with
too-fast video & correct audio. This would be so much simpler than the complicated thing
I have been trying to do so far.

I am attaching all my results in a zip file. This should make the total size of the
attachments smaller, but my real motivation for this is that I wanted to include the .bat
files I used to correct the video. Google won't let you attach .bat files to posts. It
does accept zip files but they are very smart about things. They look inside the zip
file & if they see a .bat file in there, they reject the attachment. So I had to rename
the .bat files within the zip file. It should be obvious from the file names which files
I had to rename.

[jcv...@gmail.com]

Thanks a lot !

We take note ! :)

jerome

[mjs]

On my first test I followed the -r 25 parameter Thomas posted and that made the video 13 minutes longer. But redoing the repair with -r 30

parameter Willy used produced a video at the correct duration. I don't know why it behaved like that.

[Thomas S 1517]

Yes, you need to know or find out the correct video frame rate first. The corrupted file doesn't tell directly.
In my case I knew from similar videos that the frame rate is 25.

If you don't know it you probably need to try until the video matches the audio properly.

[mjs]

Using my Copy Response method outlined in the Too fast video discussion it showed the fps to be 30 which takes the guess work out of it.

This is something other users will need to consider when making the repair.

[Wild Willy]

To amplify on what mjs has said, open the Network Monitor, then visit the video page.  Reload the page if necessary, necessary being if you visit the page & let it load completely, then open the Network Monitor (F12 or Ctrl+Shift+i), the Network Monitor is likely to be empty.  Just reload the page (F5) & the Network Monitor will populate with useful information.  Then . . .

Copy Response puts the item from the Network Monitor into your system clipboard.  Switch tasks to your favorite text editor.  That would be Notepad, Wordpad, or (as I show here) Notepad++, or whatever you use.  Just don't use a word processor (Office Word or Open Office Writer).  Paste what you just copied into your text editor.  Find the string m3u8.

This lets you locate a URL for a manifest.

You can see here that there are multiple choices for a manifest URL.  Pick one.  Any one will do.  Copy/paste it into an invocation of ffprobe & execute that.  You will get results similar to the attached file ffprobe.txt.  Information in there (scroll down near the bottom) tells you the frame rate of the multimedia object, in this case, an MP4.

Looking back near the top of the ffprobe report, you will see an error message about ffprobe failing to support subtitles.  This is simply a lie.  I don't know why ffprobe always says this.  The error message shows you the URL of the subtitles.  In this case, it is a partial URL & it is the URL of yet another manifest.  That tells you that this site is not supplying the subtitles as a simple file, but rather it is supplying them as an HLS stream via another manifest.  You need to piece together the full URL.  You take this bit from the error message:

../../../../../../subtitles/48972962/playlist.m3u8?d=3881.666667&subtoken=189cb1b45ae12ba876b2f237437de651ac1777c388d41d38433b9e64261a4533

That's all 1 line.  Google splits it to fit within the web page.  But it's really just a single line.

Then look at the next URL below that in the ffprobe report:

https://125vod-adaptive.akamaized.net/exp=1667433342~acl=%2F019e4ba2-8490-4d80-a4a3-58a8951e5244%2F%2A~hmac=2e76df4db521a2065062b74926a443e76f17e459a0ec059fb42f6b51c735eb93/019e4ba2-8490-4d80-a4a3-58a8951e5244/sep/audio/e83af5ba/playlist.m3u8?query_string_ranges=1

Again, it's just 1 line.  Take the first part of this URL:

https://125vod-adaptive.akamaized.net/exp=1667433342~acl=%2F019e4ba2-8490-4d80-a4a3-58a8951e5244%2F%2A~hmac=2e76df4db521a2065062b74926a443e76f17e459a0ec059fb42f6b51c735eb93/019e4ba2-8490-4d80-a4a3-58a8951e5244/

And stick it on the front of the subtitles partial URL:

https://125vod-adaptive.akamaized.net/exp=1667433342~acl=%2F019e4ba2-8490-4d80-a4a3-58a8951e5244%2F%2A~hmac=2e76df4db521a2065062b74926a443e76f17e459a0ec059fb42f6b51c735eb93/019e4ba2-8490-4d80-a4a3-58a8951e5244/subtitles/48972962/playlist.m3u8?d=3881.666667&subtoken=189cb1b45ae12ba876b2f237437de651ac1777c388d41d38433b9e64261a4533

This is also just 1 line.  This is the manifest URL for the subtitles.  You can tell it's a manifest from the presence of the string m3u8 in the URL.  Look closely.  You'll find it.  Give this to ffmpeg & it will retrieve your subtitles for you.  I got them in 3 seconds.  In this case, you will get a file of type WEBVTT.  The file name you specify should have an extension of .vtt.  According to my count, there are 1,312 captions in this file.

Mind you, if you're going to all this trouble to find the URL for the manifest for this video, you may as well just download it from the outset with ffmpeg instead of getting it with VDH & repairing it.  You need ffmpeg anyway for the subtitles so it's just easier to get this with ffmpeg.