VDH keeps saying No Data Received

[Flying Quokka]

Hi,

I've just installed VDH, but it won't download the video on this page (I've tried several of the available formats, but none work):

https://secure.palmbeachgroup.com/?cid=MKT601347&eid=MKT603357&assetId=AST219329&page=1

It just keeps saying No Data Received.

The error details are:

MP2T - No data received

moz-extension://40fe2c09-d0b0-4e13-9da1-de79556f72f1/background/main.js:1
value@moz-extension://40fe2c09-d0b0-4e13-9da1-de79556f72f1/background/main.js:1:153266
value@moz-extension://40fe2c09-d0b0-4e13-9da1-de79556f72f1/background/main.js:1:142032
444/value/r/<@moz-extension://40fe2c09-d0b0-4e13-9da1-de79556f72f1/background/main.js:1:77793

Can you tell me how to get VDH to download the video without errors?

Debbie

[Wild Willy]

When I went to the page whose URL you gave, VDH presented me with what you can see in
attached image #01. This looked very much to me like the typical situation of video
without audio paired with audio without video. Yes, it was a guess, but the clue to me
was that the one variant listed its resolution as 1920x1080 while the other variant had
no resolution information displayed. So I launched the downloads of both variants, as
you can see in attached image #02. The download of the supposed video ended as you can
see in attached image #03, confirming your observation. The download of the supposed
audio terminated successfully after 4 minutes. You can see the results in attached image
#04. It looks like an audio without video & playing it in VLC confirmed exactly that. I
didn't actually sit & listen to it, just skimmed it, sampling it every 5 minutes or so.
It appeared to be all there.

So what to do? I'm such a broken record. I did what I always do. I opened the Network
Monitor via F12, filtered on manifests, & reloaded the page. More background is over
here:

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

Look for the reference to the alternative technique to try when VDH fails. I got what
you can see in attached image #05. To those of us who were downloading the free nightly
streams from the Metropolitan Opera during the COVID lockdown, this is entirely familiar.
I clicked MB2 in the video player to pop up its context menu. Brightcove. No surprise.
I wanted both the URL of the first manifest, the one with master in its name, as well as
the contents of the manifest. So I did what you can see in attached image #06. After
copying the URL to the clipboard, I pasted it into this command, which I executed from a
..Bat file:

ffprobe.exe -protocol_whitelist file,crypto,data,http,https,tls,tcp
"https://manifest.prod.boltdns.net/manifest/v1/hls/v4/aes128/5102072647001/b36a1dc7-1d4a-4fee-ac6b-8b17b7344d61/10s/master.m3u8?fastly_token=NjFlMDkxNThfNzViNmMwMjY4Njk5ZmUxYTNiYzg5ZmY2MzVlOGEzZWY0NjUxZjEwNzkzOTdhNTY5NDU2Zjc0YTkyMTBkNThiNg%3D%3D"

That's a single line. Google wraps it to make it fit on this web page, but I executed it
as a single line. This command generated the output you can see in attached file
ffprobe.txt. Double clicking on the manifest entry in the Network Monitor gave me the
Firefox dialog that allows me to save the file on my system. I have attached the entire
master manifest as file masterm3u8.txt. I had to change the file name from master.m3u8
because Google does not permit attaching files with the extension m3u8.

Comparing the ffprobe output with the contents of the manifest, you can conclude the
following:

Program 0 consists of audio Stream #0:0 named GROUP-ID="audio-0", paired with video
Stream #0:1 of resolution 640x360.

Program 1 consists of audio Stream #0:2 named GROUP-ID="audio-1", paired with video
Stream #0:3 of resolution 480x270.

Program 2 consists of audio Stream #0:4 named GROUP-ID="audio-2", paired with video
Stream #0:5 of resolution 640x360.

You'll notice here that there are 2 video streams of resolution 640x360. You can
distinguish them in the ffprobe output by looking at their variant_bitrate values,
respectively 873400 & 1128600. You can also look in the manifest & distinguish them by
their BANDWIDTH values, respectively 873400 & 1128600. Not surprisingly, the ffprobe
output & the manifest match. Presumably, the resolution 640x360 video stream with the
higher number is of a higher quality & will result in a larger file when you download it.
The audio stream #0:0 associated with the first of these video streams shows a bit rate
of 95 kb/s, while the audio stream #0:4 associated with the second of these video streams
shows a bit rate of 126 kb/s. Presumably the one with the higher bit rate is of better
audio fidelity & will result in a larger file when you download it.

Programs 3-6 all include audio Stream #0:6 named GROUP-ID="audio-3". In these 4
programs, the paired video streams are, respectively,
Stream #0:7 of resolution 960x540,
Stream #0:8 of resolution 960x540,
Stream #0:9 of resolution 1280x720,
Stream #0:10 of resolution 1920x1080.

You can distinguish the 2 video streams of 960x540 in the ffprobe output by looking at
their variant_bitrate values, respectively 1503700 & 2049300. You can also look in the
manifest & distinguish them by their BANDWIDTH values, respectively 1503700 & 2049300.
Not surprisingly, the ffprobe output & the manifest match. Presumably, the resolution
960x540 video stream with the higher number is of a higher quality & will result in a
larger file when you download it.

You can see that VDH did this same analysis. Look again in attached image #01. You'll
see every one of the video streams I've just described. VDH has conveniently sorted them
with the highest resolution variant first & each succeeding variant on the menu being of
a lower resolution, and in the case of the repeated resolutions, with the higher quality
one first. You can correlate the Mbps numbers on the VDH menu with the variant_bitrate
numbers in the ffprobe output & the BANDWIDTH numbers in the manifest.

On the other hand, there is only the one audio stream in the VDH menu. Which one is it?
The web site offers 4 audio streams of varying fidelity. VDH doesn't give us any clue
which one it chose. You could argue that it's the same video in all cases, regardless of
its resolution, so any of the audio streams would match up. True enough. But they are
of varying fidelity & VDH doesn't make it easy for us to choose the best one or the one
we might want.

Here's how you download the 1920x1080 video stream & its partner audio stream:

ffmpeg.exe -protocol_whitelist file,crypto,data,http,https,tls,tcp -hwaccel auto -i
"https://manifest.prod.boltdns.net/manifest/v1/hls/v4/aes128/5102072647001/b36a1dc7-1d4a-4fee-ac6b-8b17b7344d61/10s/master.m3u8?fastly_token=NjFlMDkxNThfNzViNmMwMjY4Njk5ZmUxYTNiYzg5ZmY2MzVlOGEzZWY0NjUxZjEwNzkzOTdhNTY5NDU2Zjc0YTkyMTBkNThiNgDD"
-codec: copy -map 0:6 -map 0:10 "Q:\VDH Testing\Palm Beach Video with Audio.mp4"

Again, that's all one line. The ugly URL in the -i parameter is the URL of the master
manifest. Note the correlation between the two -map parameters & the stream identifiers
in the ffprobe output. You can see the result of this download in attached image #07.
This download ran at a line speed on the order of 4.5 million bytes per second, quite
decent. It took about 11 minutes. It played fine in VLC (see attached image #08) with
both audio & video all the way to the end. You can see the video; you'll have to trust
me on the audio. Again, I didn't sit & watch it, just sampled it.

So once again, the question is why didn't VDH get this when ffmpeg had no problem with
it? You can get this video if you make the effort to learn what I posted in the other
thread on this forum, the one I mentioned above about the alternative technique. Then
follow the steps I've shown here, which are a subset of what I explain over there. But
that doesn't explain the failure in VDH. It is most puzzling.