I wanted a way to copy the content of the js file onto my system. I didn't want to just
double click it. I tried the other menu selections & they weren't giving me the file.
So I did the HAR thing & that did it. Like I said, it seems like that's the only thing
that works for some types of object but for others, you have more than one menu selection
that will work.
On your prompting, I looked in Player.js for MP4 URLs. I came up with this:
https://vod-progressive.akamaized.net/exp=1663916956~acl=%2Fvimeo-prod-skyfire-std-us%2F01%2F4936%2F29%2F749684104%2F3444886134.mp4~hmac=796ef4eb74b7049020eebca50c7c43c4a6c5ea130d7e1737ed78f01633648ca0/vimeo-prod-skyfire-std-us/01/4936/29/749684104/3444886134.mp4
This was the only instance of a recognizable full URL for an MP4 in this file. There
were probably hundreds of other instances of the string mp4 in the file, but they were
all near partial URLs or were of some other nature, like the string video/mp4.
I tried visiting that akamaized URL. It gave me the black page as if it was going to
show the built-in Firefox media player, but it never did. You'll also notice that it
looks like there's another URL embedded twice within that URL, on a site that apparently
goes by the name vimeo-prod-skyfire-std-us. But I tried various tricks to isolate parts
of that longer URL & tried to visit those addresses. When I tried to go to the akamaized
site, I got access denied. The skyfire site said site not found.
OK. So let's look at the HTML object you discovered on the
player.vimeo.com site. The
only URL for an MP4 in there is the weird one with the 2 URLs embedded within it.
So then I let the video play for a few seconds & that made a few MP4 objects appear in
the Network Monitor. You're right. Those have parcel embedded within their URLs. The
URLs in the VDH hit details are different. I tried to open the URLs VDH found. I just
got an error that said bad request. I have no idea where VDH is finding those URLs. I
suspect VDH simply is extracting information from somewhere, we haven't figured out
where, & misinterpreting certain strings as frame rates & bit rates. It's not that
anything is corrupt. It's that VDH isn't getting the information the way it should. So
when it builds the output file, it puts these bad attributes on it & it doesn't play
properly. For all we know, VDH is taking character strings & interpreting them as
numerics. This is the case that Michel has acknowledged VDH does not handle today. The
only kind of DASH content that VDH handles correctly is the almost proprietary case of
YouTube. Every other type of DASH, including our German site here, is simply not handled
correctly by VDH.
Meanwhile, I noticed a master.json in the Network Monitor. I grabbed that with a Copy
Response. It kind of looks like a proper mpd DASH manifest but not quite. I found that
it had a pattern of header information followed by entries that looked like they might be
chunk descriptors. Filtering out the chunk descriptors, this is what I found in that
master.json file.
{"clip_id":"68086bf6-c135-4c00-a16f-47551a907f4d","base_url":"../../../../../parcel/",
This appears to be some sort of header for the multimedia object. Notice the parcel
thing. Following that, I found these descriptors. Each one appears to describe a single
track of our multimedia object. Things are grouped by both square brackets & brace
brackets. I'm not showing the closing brackets. They come after the last chunk
descriptors. The first 2 things are owned by the "video":[ ] sequence. Within those
square brackets, there are 2 { } chunks. Then you have an "audio":[ ] sequence, within
which there are 3 { } chunks.
"video":[{"id":"4402bbcc","base_url":"video/","format":"dash","mime_type":"video/mp4","codecs":"avc1.640015","bitrate":309000,"avg_bitrate":206000,"duration":2508.36,"framerate":25,"width":426,"height":240,"max_segment_duration":6,"init_segment":
{"id":"2756523e","base_url":"video/","format":"dash","mime_type":"video/mp4","codecs":"avc1.64001F","bitrate":597000,"avg_bitrate":461000,"duration":2508.36,"framerate":25,"width":640,"height":360,"max_segment_duration":6,"init_segment":
"audio":[{"id":"53430c0c","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"mp4a.40.2","bitrate":191000,"avg_bitrate":191000,"duration":2508.3306666666667,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":
{"id":"72e01515","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"opus","bitrate":98000,"avg_bitrate":83000,"duration":2508.3265,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":
{"id":"5e806bce","base_url":"audio/","format":"dash","mime_type":"audio/mp4","codecs":"opus","bitrate":66000,"avg_bitrate":56000,"duration":2508.3265,"channels":1,"sample_rate":48000,"max_segment_duration":6,"init_segment":"
The first one looks like a regular video mp4 of resolution 426x240.
The second one looks like a regular video mp4 of resolution 640x360.
The third one looks like a regular audio mp4, which is actually indistinguishable from an
mp3. It looks like it would give Windows properties of sampling rate 48kHz, bit rate
191kb/s.
The fourth one looks like another audio mp4 but note the codec of opus. That's what you
see with webm files, not mp4. It looks like its sampling rate is also 48kHz with a bit
rate of 98kbps. Or maybe 83kbps. I'm not sure which number Windows would pick. For the
third one, the 2 bit rates are equal. Here, they're different.
And the fifth one looks like another webm audio track, sampling rate 48kHz again, but bit
rate either 66kbps or 56kbps.
The long stretches of the file that I am not showing look analogous to what we are
accustomed to seeing in HLS stream manifests. They aren't in anything remotely
resembling HLS format, but they appear to be trying to accomplish the same thing.
Meanwhile, I find it very odd that we have 2 webm audio tracks but no webm video track.
A webm video track would show vp9, not the avc1 in the codecs list that we see here,
twice. It's no problem for ffmpeg to merge together such disparate tracks into either a
webm or mp4, or even mkv, whichever you specify. I just wouldn't expect a structure like
this.
The fact that the items appear as individual, separate objects in the Network Monitor
does not mean they are "being supplied separately." We've gotten used to the
idiosyncrasy of VDH displaying certain variants as video-only or audio-only. I think
this is actually a shortcoming of VDH, perhaps even a bug. When I've been looking at HLS
manifests for problems reported by our fellow users, I can see that they are not actually
separate. VDH seems to like manifests in which there are unique audio & video tracks.
What I mean is, if there's 5 Programs (to use the ffprobe terminology), then Program 0
has video Stream 0:0 & audio Stream 0:1; Program 1 has 0:2 & 0:3; Program 2 has 0:4 &
0:5; and so on. Every Stream appears only once, and they're all in neat video/audio
pairs. VDH has no problem with such multimedia objects. When you get situations in
which a given audio Stream is shared across multiple Programs, VDH doesn't handle that
correctly. It shows separate video-only & audio-only tracks. Plus, if there are
multiple audio Streams, but fewer audio Streams than video Streams, so the audio Streams
are shared among the video Streams, VDH does not show all the audio Streams. But that's
just VDH. The tracks are not actually supplied separately in the sense we've gotten used
to understanding. Video players on web pages play audio with video. Ffmpeg can download
2 tracks into a single target file, either via 2 -i parameters or 2 -map parameters,
usually 2 -map parameters. It's only VDH that has conditioned us to think things are
audio-only or video-only. They are not. It's just audio tracks & video tracks OF THE
SAME multimedia object. This is a shortcoming of VDH. It just doesn't put together the
appropriate audio track with its partner video track. The information is in the
manifests. VDH isn't interpreting it correctly. There should never be a variant on a
VDH menu that is other than video with audio, unless for some reason the web site is
offering a silent video or you're looking at an audio podcast, something out of the
ordinary like that. The vast majority of the multimedia content around the web is talkie
movies. VDH should not be giving us video-only & audio-only variants.
Multimedia objects have such things as multiple video tracks & multiple audio tracks to
accommodate people with slower Internet connections. Smart web sites (most are smart)
detect your bandwidth & give you a lower resolution video with an audio track of a lower
fidelity in order to let you play the video without the constant, annoying buffering.
But we, here in VDHland, are not trying to just play stuff. We're trying to get our own
copies so we can have them forever. Or maybe, as in the case of YouTube, we're trying to
avoid the ads. Or maybe we're trying get our own copy of a 4K video that we just don't
have the bandwidth to play on a web page, but we do have the computer power to play if we
had the whole thing on our hard drive. Web sites don't necessarily give a rip about us.
Many aren't oriented toward people downloading their content. Those would be sites where
you don't see an easily accessible DOWNLOAD button. You've visited those. I have.
Also, we've certainly encountered our share of sites that have intentionally implemented
measures to thwart us. But despite all of this, we should really never think of video &
audio being "supplied separately." They're not.
But it's not all bad. This shortcoming in VDH has sure made us learn a lot about how
things work. Maybe even more than we ever really wanted to know.