Download not working

[Fisher]

I want to download videos on C-SPAN but every time I try to download one it says "aborted" or "error with chunk set" on firefox it sometimes works but those are videos with no audio or just the audio files. And even if that fully works the video is downloaded at a low fps rate.

I am very disappointed in the program and regret buying a license key

[Wild Willy]

There are many things in this thread that might have been helpful to you before you paid
for a license:

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

Specifically, the discussion of the VDH license, which you can find by searching for
"philosophy" within the text of that page, which advises you to try before you buy.
Another thing to search for is "problem report" within the text of that page. If you had
given us a proper problem report before you bought the license, we might have been able
to investigate your particular case & offer alternative solutions. We could still do all
of that if you're still interested.

Meanwhile, if you bought the license recently enough (within the past 3 months), the VDH
folks (of which I am NOT one) should be able to give you a refund. But you'll have to
post again explicitly asking for that. On the other hand, I have found VDH to be most
useful & I am totally satisfied with my purchase. If we pursue problem resolution with
you, you might change your mind about regretting your purchase.

[mjs]

Here is an example I found :

https://www.c-span.org/video/?524349-1/capitol-christmas-tree-arrival

When I first opened this page the audio variant was above the video variants, normally the audio should be found below. Refreshing the page a few

times didn't correct it. I closed the page then opened it again ,this time the audio is below the video :

It did download a video without audio which had a frame rate of 29.97 which is about 30 fps. That is a pretty standard frame rate so I don't know what you consider low fps. The audio file is the variant which has a time matching the video.

[mjs]

It looks like the audio file download will fail if HLS as M2TS is not enabled. It gives a MP2T - No data received.

[Wild Willy]

Thanks, mjs. I'm just not willing to scrounge around on sites looking for content. This
may or may not be the same content as what the original poster had trouble with. It's
also not guaranteed to be representative of what you'll find everywhere on the site. So
anything we do may or may not transfer to the content the original poster is having
trouble with. This is why a proper problem report is critical.

Nonetheless, I went to the page whose URL you (mjs) posted. I saw the 1024x576 video
variant you show in your image. I downloaded it.

On your warning, I then enabled the VDH setting for HLS as M2TS & downloaded the audio.
By the way, I wouldn't have bothered to force VDH to show the audio-only variant below
the video-only variants. That's purely irrelevant. It doesn't matter where in the VDH
menu the variants appear. You can download an audio-only variant that appears above a
video-only variant just the same as when it appears below. Whatever. I then used VLC to
play the downloaded mp4 video file synchronously with the downloaded m2ts audio file. It
played about 5 seconds and then the audio simply cut off. Time for our respeed trick
from here:

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

The audio downloaded, as expected, as an m2ts file. So I ran it through the ffmpeg -r
command. I used -r 30 since that is the frame rate of the original video. Yes, I know.
I'm converting an audio file. What's its frame rate? You have to assume it matches the
video. According to the VDH Hit Details on the video I downloaded, the frame rate is
29.97. No, that's 30. I've seen an explanation of this somewhere. It has to do with a
division of one number by another & it's actually an irrational number (remember that
term from your high school math days?) running out to an infinite number of decimal
places. The VLC Media Information quotes the frame rate as 29.970624. It's 30.

So I forced the speed of the downloaded m2ts from 30 fps to an m2ts @ 30 fps. Playing
that synchronously with the originally downloaded video mp4 gave a silent video. I ran
ffprobe on the resulting m2ts I had just converted & it reported that ffmpeg had
converted the file to mp2. I didn't ask for that. It seems like ffmpeg took it upon
itself to convert the m2ts to mp2. I have to say I've never encountered an mp2 file
before. This one didn't play any audio, neither when it was played synchronously in VLC
with the video mp4, nor when played by itself in VLC. Actually, VLC refused to play the
file at all.

So I did the ffmpeg -r command again, but this time I specified the file extension .mp3
in the target file name. This created (no surprise) an mp3 file that DID play
synchronously in VLC with the mp4 video. Perfect audio with video, perfectly synched,
everything perfect. I didn't sit & watch the (rather boring) video, just sampled it at
intervals. But it didn't play fine all the way through. I had video all the way to the
end of the 28:13 duration of it, but the audio disappeared at a certain point. By
careful jockeying back & forth, I determined that the audio stopped at 19:16. I went to
the web page & played the video there. It turns out the audio does indeed cut off at
19:16. So I really did have a perfect download of what's on the C-SPAN web site. The
original is damaged, in that the audio disappears at 19:16. But VDH did correctly
download what was there.

So I have to say VDH is perfectly capable of downloading the video & the audio
separately. Unfortunately, you have to turn on HLS as M2TS for the audio download. But
you can do TWO downloads, one for the video, one for the audio, then "fix" the audio by
converting it to mp3 using ffmpeg, & get something that plays perfectly fine using the
VLC synchronous playback feature. If you are dead set against having the video & the
audio in 2 files, you can always merge them using the tool for that purpose in VDH. I
suspect I could have converted the audio m2ts to mp3 using VDH, but I'll leave that as an
exercise for the student. I also suspect that using VDH to merge the video mp4 & the
audio m2ts, both as downloaded by VDH, would have corrected the audio track. I leave
this as well as an exercise for the student.

As an aside, I spent some time mining the Network Monitor to see if I could just get this
video using ffmpeg. I was able to view the master manifest using the Copy Response
trick. It seemed perfectly ordinary in every way. It confirmed that the highest
resolution on offer here was indeed 1024x576, and the other 2 resolutions in the manifest
were the ones detected by VDH. But when I ran the manifest through ffprobe, I just got
403 Forbidden errors out the wazoo. This is a lot like my Golf Channel broadcasts. I
can't ffprobe those manifests, either. So Michel does some sort of magic that gets
around the protections the site puts on its manifests. I'm sure it's a trade secret what
exactly that is. But I don't really care what that is because VDH is able to download
this content.

I also have to say that VDH ought to recognize this as integrated audio & video. The
manifest showed that the 3 video variants shared the same audio variant. So what? It's
a video that has audio. VDH should be displaying 3 variants, ALL of which should include
BOTH video AND audio. And you should NOT need to turn on HLS as M2TS to make it work.
VDH should automatically detect when that is necessary & just silently do whatever is
necessary. VDH works properly when the manifest shows that each video track has its own
unique partner audio track. But when muliple video tracks share a common audio track,
VDH fails to get it right. It gives this silly separate audio & video business. To me,
that's a bug in VDH. When both audio & video are present, VDH should present ONLY
variants that consist of BOTH video AND audio.

[mjs]

On the M2TS audio I just make it an mp4 using ffmpeg  -i  audio.m2ts -codec copy audio.mp4

I learnt that from one of the jumpy / jerky / shaky video posts. Do you get a playable audio if you try that.

[Wild Willy]

Yes, that works . . . although I did use -codec: copy, not -codec copy. You know ffmpeg
is a stickler for that sort of detail. It doesn't work without the colon after -codec.
I'm sure that was just a transcription error on your part.

But I thought that isn't what you should have to do. MP4 is a video+audio format
primarily, although it allows for audio-only as well as video-only. The target really
ought to be MP3. So I tried going from m2ts to mp3 with -codec: copy & I got a weird
error. So I removed the -codec: copy & it worked. Just for yucks, I also tried it,
still without -codec:, with a target of mp4. I also tried it with -r 30 only on the
output, and with -r 30 on both the input & output, always without -codec: & a target of
mp3. They all worked, but the Windows properties in every case claimed the duration was
28:57, even though the duration was only 28:13. This appears to be a Windows anomaly, at
least, on my system. Playing all these files in VLC showed duration 28:13 in the
Playlist & the playback terminated at 28:13. My Windows 7 is weird. I have trouble with
VDH giving incorrect resolutions as 1912x1088 when the resolutions are always really
1920x1080. So this duration anomaly just fits right in.

I would say that when you are dealing with audio-only tracks, your target file should be
mp3, not mp4. You are converting from one type to another so you should omit -codec:
copy. The speed is about the same when you target mp3 instead of mp4 & omit -codec:
copy. When you've got one of those video+audio files that gives you good audio but only
a single still image for the video, or the video flashes by in seconds but the audio
plays correctly, then the target needs to be mp4. You need to specify -r on both the
input & output in that case, but that's just running over old news. I've experimented
with -codec: copy & -r but that doesn't work. That's because you're not copying. You
really are converting, so -codec: copy & -r are mutually exclusive.

[Wild Willy]

The thing you did for the jerky video probably removed the timed_ID3 data that was
causing the jerkiness. We've already established on a number of occasions that timed_ID3
data causes the jerkiness & VDH doesn't necessarily remove it. But ffmpeg has no idea
what to do with timed_ID3 data. So running a file through ffmpeg will remove timed_ID3
data because ffmpeg just turns a blind eye to it.