VDH forcing lowres Webm, want highres MP4

[RH-downloader]

Your question

I regularly download multiple episodes of certain tv-series, where each episode is a seperate video file. This works well generally, but at a certain point (episode in the list) VDH switches from highres MP4 to lowres Webm and there is no way to change that.

This is not a server/hosting issue because I do get the highres MP4 when I copy the link of the pertaining episode to Cobalt Tools. But Cobalt Tools is slow, has many network errors and does not work well in batch.

What can I do to prevent VDH from switching to lowres Webm? I found a similar question years ago on Google Community, why is this problem not yet solved? A workaround would also be appreciated.

Addon & CoApp version and details

Windows 10 / FireFox / VDH newest version, no upgrades available

[Mattmjs]

Can you provide an example where you get the low webm format.

[RH-downloader]

Ellery Queen 1975 TV Series - 24 videos
https://ok.ru/video/c3803734

Webm videos: episodes 12, 13, 14 and 20.
MP4 videos: all the rest.

Actually, I should not have said Lowres and Highres, because the video resolution (pixel dimensions) of the videos is the same, but the Webm videos are lower quality (higher compression), roughly 50% of the size of the MP4 videos. Conversion of Webm to MP4 is possible of course, but that does not improve the quality of the videos.
Cobalt Tools (cobalt.tools) downloads the correct MP4 files for all Webm videos, using the same link to the video (click on the episode, copy paste url to cobalt tools and save).

[RH-downloader]

This is just one example, this happens for almost every tv-series. There are always a few episodes in the list that can only be downloaded as Webm by VDH. Really need a solution/workaround for this.

[Mattmjs]

Ok I looked at episode 12 and it was offered as webm with the best at 480p 500 Kb/s. But by switching the link to show a mobile
interface the video is offered as mp4. The best 480p mp4 is at 1 Mb/s. Here is the trick, look at the link for episode 12.
All you have to do is add m. before ok.ru

[Mattmjs]

You can do that for individual videos or the entire page like https://m.ok.ru/video/c3803734

[RH-downloader]

Yes, that would suffice as a workaround. I need to have some more time to see if switching to the mobile site always does the trick. But in this case it does. The problem need to be addressed though, because something in or about the video is causing VDH to behave like this.

[Mattmjs]

I believe it's the site doing this not VDH, the software only offers what it detects. Ok just either offers webm or mp4 on their site.
It could be the site or the uploader that decides what is mp4 and what is webm.

[RH-downloader]

Don't agree. Cobalt Tools downloads the correct MP4 file, so the MP4 must be on the server. It is VDH that decides to turn it into Webm. That would not be so bad, if I could change that. But VDH does not let me do that.

[GrampaWildWilly]

Then use Cobalt Tools instead of VDH. But I believe you are wrong. See my post below. You should not be so fixated on MP4 vs MKV. One format plays in VLC just as well as the other. People shouldn't care about that. Also, I don't claim to know how Cobalt Tools does what it does. It's entirely possible that when the only thing on the web site is MKV, Cobalt Tools converts it to MP4. The truth is in the Network Monitor. The Network Monitor shows you what Firefox finds. That is without reference to VDH, Cobalt Tools, or anything else. The Network Monitor operates at a level below VDH & Cobalt Tools. Look in the Network Monitor & find out what the real truth is.

[Mattmjs]

It really isn't VDH doing this, the content is already webm as soon as the video is loaded. See the image

[RH-downloader]

1. As I said in the original post "Cobalt Tools is slow, has many network errors and does not work well in batch.", so I would prefer using VDH. VDH is superior and that is the reason I would like this to be fixed.
2. It is not the Webm format itself that I am having the problems with (it is easy to convert to MP4), but the fact that the Webm file is low quality compared to the high quality MP4 file of the other episodes.
3. I don't know enough about Cobalt Tools to confirm or deny it does any conversions, but the fact is it is downloading the high quality MP4 file from the non-mobile site. And I haven't seen any conversions yet that are able to turn a low quality Webm file into high quality MP4.

[GrampaWildWilly]

The explanation that contradicts your conclusion is in the part of my post that you claim to not have the technical expertise to understand. I'm going to say this for the last time. Episode 12 is available ONLY as MKV & ONLY in 3 low resolutions. I don't know how Cobalt Tools is coming up with its results. It must be converting the input. Does it look like actual 1080p video? I suspect it is just the blurry 480p content repackaged at the higher resolution, but it is still blurry.

I'm done.

[GrampaWildWilly]

I do not work for VDH. I'm just another user. Same as Matt.

For a bit more detail, I also looked at episode 12. In my Firefox Network Monitor I did not find an HLS master manifest. That would have been an object of type x-mpegurl whose file name would most likely have contained the string m3u8. But I did find a DASH master manifest, an object of type dash whose file name would normally contain the string mpd but in this case it did not. Here's what it looked like:

I ran that URL through ffprobe & this is what I got:

ffprobe.txt

There is only MKV content here. You have a choice of 3 rather low resolution video tracks, & a choice of 3 audio tracks at various levels of variant_bitrate, the highest one being, presumably, the "best" quality audio. I would say that VDH is offering you what is there. There is no MP4 format of this . . . at least, not unless you use Matt's magic trick. However, it sounds like Matt's magic trick just gives you MP4 variants of the same low resolutions as what VDH is already giving you.

The bottom line is that VDH is offering you what is there. You want MP4? Sorry, there isn't one.

That's just for episode 12. If you want to know the state of affairs for any given episode, you're going to have to go through the process I'm showing here for each episode. You cannot conclude that if a given episode is available at 1080p that the next episode will also be available at 1080p. The web site can do whatever it wants. Some episodes may be hi-res, some may be only low-res. Some may offer MP4, some may offer only MKV. Each episode is its own independent case.

OR

You can trust VDH. It looks to me like it's doing a good job offering you what is there. If you don't want to go through the tedious task of mining the Network Monitor for information on every single episode, just accept what VDH is giving you. Don't worry. Be happy.

[RH-downloader]

I am also an ordinary VDH user but I have been using VDH a lot. Your technical explanation goes far beyond my expertise, but the point where I don't agree with you is your claim that the MP4 would not be present on the (non-mobile) site.
Because, when I use the same link (not to the mobile site, but to the non-mobile site) and paste it into Cobalt Tools, it downloads the correct MP4 file. So I assume, the MP4 must also be on the non-mobile site. Where else would Cobalt Tools get the MP4 from?

Apart from this, it does not make sense to me that somebody uploads 24 videos and puts them into a playlist, 20 of them being MP4 and 4 of them Webm. I would perhaps understand if that happened just one time, but as I said before, this issue occurs for almost every tv series that I try to download. There are always a few Webm among them. Hardly possible that so many people do something as strange as that.

[GrampaWildWilly]

I repeat. It is entirely possible that in the absence of MP4 input, Cobalt Tools converts the MKV input to MP4. You can't tell the difference between an MP4 object available on the web site compared to only MKV content available on the web site that Cobalt Tools converts to MP4 without telling you. You are jumping to conclusions based on incomplete information.

If this stuff is beyond your technical expertise, then you need to accept what I'm telling you. I have the expertise to understand at least as much as I do, which I admit is not a lot. But it seems to be more than you know. If you are unable to perform the simple task of analyzing the Network Monitor yourself, then you have no choice but to trust Matt & me. We have a lot of experience with this. There's countless posts from both of us, both on this GitHub forum & on its predecessor forum on Google Groups. You came here asking for help from people who know more than you do. You got answers from those people. If you're not willing to accept these answers, figure the stuff out for yourself. If you can't figure this out for yourself, you have to trust us.

Otherwise, quit arguing. By your own admission, you know less than we do. If you're not willing to accept our advice based on long experience, quit wasting our time.

I agree that it makes no sense for one episode to be one way & another episode to be another. But that is what we are observing on this web site. It is possible that after a time, the episodes that look weird will be "corrected" to look like the others. It is also possible that that won't happen. You should know that if you expect people to be uniformly logical all the time, you will be disappointed. You need to lower your expectations & lower your opinion of the people running this web site in Russia. The web site is in Russia. It's as likely as not that everything they're doing is on pirated software & they don't completely understand what they're doing. Don't make the mistake of applying logic to the situation.

[Mattmjs]

@RH-downloader , Cobalt Tools may be using yt-dlp behind the scenes. Many sites use it, this is what it finds on the non mobile
link. See the second last entry in the image, other than that the issue is resolved using mobile interface.

[RH-downloader]

1. Yes, it is possible that Cobalt Tools converts the video to MP4, but it can't turn a low quality Webm file into a high quality MP4 file by any means. So the high quality video (in whatever format) must be on the server and VDH does not download it.
2. Without doubt other people might have much more expertise on the subject than I do, but I do know my 1+1 = 2. You don't have to be a car mechanic to know your car has a flat tyre. And in my opinion, in this case VDH is not working as expected.
   Anyway, for the time being, I have a reasonable workaround. I do regret the problem is not confirmed as an issue to be fixed, but I don't know any other way to document it more clearly. Everybody can replay what I did but if you claim this is normal behavior, so be it. Thx for your comments.