Problems with downloaded videos - Gothenburg Symphony Orchestra

[pstrg]

Gothenburg Symphony Orchestra (Göteborg Symfoniker) site (gso.se) offers very good quality musical programs, but they're are available only for a couple of months.
VDH reports DASH streaming is used.
If they're downloaded, audio is fine but video is either frozen or strangely accelerated.
As it's not a paid site, I imagine there is no DRM on them.

Latest frustration is:
 https://www.gso.se/en/gsoplay/video/stravinsky-psalmsymfoni/

1) It's only me, or does it affect everybody?
2) Is there a way to check what's wrong with them?

[Wild Willy]

It seems that Firefox 113.0.2 has once again broken my ability to insert images inline in
a post. I've had this problem in the past. It lasted for several releases of Firefox.
I have no idea how long this will last this time. I can only hope it's not long. In the
meantime, you'll have to suffer along with me. I wanted to post this with images inline
but I can't. So they're in a bunch at the bottom. Best I can do at the moment.

I went to your Gothenburg Symphony Orchestra page & used VDH to download the 3840x2160
variant there. I got the results you can see in attached image #01.

Playing that in VLC got the same results as you did. So now I cram some boilerplate in
your face by way of explaining what I did. But don't assume that because it's
boilerplate that you can just skip it. It is boilerplate only in the sense that I have
it handy to copy into posts because I do it all the time. That's just for my
convenience. For you, it is important information that you need. Click here:

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

Be sure you carefully read the first 2 paragraphs there. Once you have read that, you
can check out the references within that web page that I am about to give you. But don't
just find the relevant link & click it. READ the context around the link. I recommend
you bookmark that link & read the entire page, if not now, if not in one sitting, bit by
bit over time.

You find a reference on that web page by searching the text of that page using various
search keys. The search keys I am suggesting are these:

too fast
stealth quote
short tutorial

Next, look for "too fast" within the text of that web page. That will give you a link.
Click that, read what you find, & do your best to absorb what is there. It is an
explanation of what I did, which you can find below this bit of boilerplate advice.

Next, look for "stealth quote" within the text of that web page. That will give you
another link to click. Click that, read what you find, & follow the advice, not just for
your posts in this thread, not just for your posts in this forum, but for your posts
anywhere on Google Groups.

Next, look for "short tutorial" within the text of that web page. That explains why your
response here will use the Reply all button. It also explains why you will NOT use the
Reply to author button.

So much for boilerplate. Once I had the damaged video, I went back to the concert page &
did what you can see in attached images #02 - #05.

This gave me the utterly critical, indispensable information that I needed to repair what
I had downloaded. I then repaired the file. The repair operation is documented in
attached file ffmpegCloneSceneLogFile.txt. It shows you the command I executed along
with the activity log of the repair. It ends with a display of the repaired file. The
results looked like what you can see in attached image #06.

This played just fine in VLC. Too bad our conductor didn't also sing, at least not that
we could hear. Others took care of that duty.

[Wild Willy]

But this approach is rather tedious. First, you have to do the download in VDH. Then
you have to discover that the file is damaged. Then you have to repair it. You can see
in the log file attached above that it takes rather a long time to change the speed of
the video. There is a better way, also discussed in the "too fast" reference I gave
above.

I went back to the concert page. I opened the Firefox Network Monitor. I reloaded the
page. I got lots of bewildering content in the Network Monitor. But I noticed the
telltale mentions of Vimeo. This is a key to what to do next, as discussed extensively
in the "too fast" reference. You need to read that if you want to understand what I did
next. Yes, it's long. There are no shortcuts. Knowledge takes effort. Put in the
effort.

At this point, I knew I wanted to find an entry in the Network Monitor that came from the
player.vimeo.com domain. See attached image #07.

As you can see, there were 2 such entries. I wanted the HTML entry. That is obscured by
the popup context menu in image #07. That indication is in the column under the Type
heading. I executed the Copy Response function on the popup context menu. That put a
text file into my system clipboard. I pasted that into my text editor. I use Notepad++
but Notepad will serve the purpose just as well. I then did a Find on "m3u8" within that
file. There were 7 search hits. The first 4 of these were in the URL you can see in
attached image #08.

The URL. Singular. The same URL occurs 4 times. Notepad++ has a nice highlighting
feature. If you highlight one string, all other occurrences of the same string also get
highlighted. It's a bit hard to tell in image #08 because all 4 strings occur almost
back to back. But look carefully & you'll see the same URL is there 4 times. You could
probably guess now that the other 3 search hits on m3u8 are all the same as well, as
shown in attached image #09.

These are URLs for m3u8 files. Those are HLS master manifests. HLS. Not DASH, as VDH
claimed. HLS.

So I ran ffprobe on these 2 URLs, which gave the results you can see in the attached file
m3u8 ffprobe.txt.

Oops. This is supposed to give us a better way of getting this video. Unfortunately,
the web site is blocking it. These master manifests contain information that would have
given us a way to download this video with ffmpeg. On a hunch, I changed the URLs to
show mpd instead of m3u8. By convention, a DASH manifest is usually named with the file
extension mpd. Those results are in attached file mpd ffprobe.txt. That got the same
result as the m3u8. It didn't say File Not Found, which is interesting. It just gave me
the same error as the HLS manifests. Oh well. Such is life in the chaotic world of
Internet multimedia.

[Wild Willy]

But all is not lost. That "too fast" reference does offer several approaches. You
shouldn't just give up at your first check. Check is not checkmate.

I went back to the concert page & clicked play in the video. That got me some additional
content in the Network Monitor, as shown in attached image #10. I was looking
specifically for a json with the name master.json. I grabbed its URL, as you can see in
attached image #11. This was the URL that got copied:

https://65vod-adaptive.akamaized.net/exp=1684979934~acl=%2Ffc838fcb-127e-44d8-9676-e114a24a5260%2F%2A~hmac=36e8825c01f367e3a402d455e8752a84260c22c014f331ccac25b82d3610f810/fc838fcb-127e-44d8-9676-e114a24a5260/sep/video/2d72e3f3,5a4702fa,7b0eff24,8357845a,9ba90e81,a1c7e943,a635df31/audio/4f24f717,6ef3c539,ca340e66/master.json?base64_init=1&query_string_ranges=1

I changed that URL by adjusting the name. I changed .json to .m3u8. I ran that modified
URL through ffprobe. I was sort of expecting that to fail. To my surprise, I got what
you can see in attached file json ffprobe.txt. That allowed me to download the file with
ffmpeg. Those results are in attached file Stravinsky Gothenburg SO Haniganmp4 Log.txt.
This got me the same file that resulted from the repair I had done. It played just fine.
For comparison, I offer attached image #12. Note the bit rates are rather better than
what came out of the repair.

[mjs]

The repair approach that while it works it is slow because the video is re-encoded. But there is a much faster repair option , a script was shared

that automates the entire process. Willy have you tried it ?

[Wild Willy]

But wait. There's more. I double clicked a different entry in the Network Monitor,
shown in attached image #13. That opened a new tab. The story continues in attached
images #14 - #16.

I won't belabor that. Firefox downloaded this as a media file of audio without video.

Now go back to the Network Monitor & play the same trick with the next entry, as shown in
attached images #17 - #22.

Firefox downloaded this as a media file of video without audio. The results of the 2
downloads are shown in attached images #23 & #24. Very curious results in image #24.
They show 0 for the video bit rates. I don't know why that is. It was a very low
resolution video. But it did play just fine. Attached image #25 shows the Media
Information from VLC while it was playing. The bit rates are admittedly very low, but
they're not 0. The frame rate shows as 0 in image #24 as well. But it played so there
was definitely a non-zero frame rate. Very strange.

VLC was quite happy to play these files synchronously. You don't need to merge the video
& the audio together in order to play them. You can, but you don't have to. You'll
probably want to find the reference for "synchronous" in the Table of Contents as well as
the reference right after that one.

[Wild Willy]

Sorry about that preceding post. I don't know why the images are in scrambled order. I
deleted the post a couple of times because I thought I had figured out what I had done
wrong. But at my end, the images are in numerical order. It's not my fault. To get the
idea, look at them in order. I do wish I could have done this with the images inline.

Anyway, the bottom line is there's always multiple solutions to a problem. Pick the one
you like best.

You didn't offer any of this information but you should make it a habit to do so:

I am running Windows 7 64-bit, Firefox 113.0.2 64-bit, licensed VDH 7.6.5a3 beta (same as
7.6.6), CoApp 1.6.3. You can see my version of ffmpeg in the attached log files.

This is covered under another reference in the Table of Contents: problem report.

Note to mjs: I tried this with -codec: copy. It just copied the file retaining the
damage. It seems -codec: copy must be omitted when you respeed a video. That's why it
takes so long. As for that script that alleged to automate the whole process, I vaguely
remember looking at it & thinking it was totally customized to the one situation. I
believe he also used some other tools like Handbrake & something else. We could continue
our discussion of this over where that script is located.

[Wild Willy]

People keep sending me private E-mails. I post over & over again for people to look in
the Table of Contents for a reference to "short tutorial." It is important that
everybody read that. Please, stop sending me E-mails. Read that "short tutorial"
reference. I mentioned it above. I'm mentioning it again. "Short tutorial." Look for
it. Read it. Follow the advice.

[pstrg]

Thank you Wild Billy for the very detailed answer, I will be able to read it in detail later today.

In fact, did not note that the environment information was missing from the output message.
My setup is

Windows 10 Pro 64 bit (22H2 / 19045.3031); Firefox 113.0.2; VDH 7.6.6 (licensed); VdhCoApp 1.6.3