Talk:Comparison of video codecs

Reliable sources

I have some information on Forbidden Technologies Blackbird video codec, which I helped develop. I am working on this article which mentions it. What level of reliable source do people on this comparison expect for codec information? And what do people here count as reliable sources?

The FORscene article is now live. Stephen B Streater 17:44, 11 June 2006 (UTC)

More codecs to compare.

Since codecs are COmpression/DECompression libraries, here are a bunch of well-known ones:

• Dirac, the open source HD BBC codec —Preceding unsigned comment added by 94.217.103.181 (talk) 13:50, 3 April 2009 (UTC)
• DivX4/5/6
• XviD
• FFmpeg (libavcodec)
• 3ivx
• MPEG-1
• MPEG-2
• RealVideo
• Sorenson (used in QuickTime video encoding typically)
• x264
• MPEG-4 Part 10 (H.264, MPEG-4 AVC)
• MPEG-4 ASP
• Theora
• WMV1/2/3

—The preceding unsigned comment was added by JVz (talk • contribs) 00:15, 5 July 2006 (UTC).

Given the ambitious title, the tables should at least make an effort to include more than a handful of entires right from the start, even if the fields are left blank for now. AndreasWittenstein 02:01, 29 March 2007 (UTC)

I think the standards should be included in the article as opposed to actual codecs. E.g. H.264 (the standard) instead of x264, MPEG-4 ASP instead of DivX/XviD/3ivx. The differences between the actual codecs are so small that it wouldn't be very useful to include them all separately.

FFmpeg doesn't qualify for inclusion, it's an encoder for all kinds of codecs rather than a codec. MrTroy 06:36, 5 July 2006 (UTC)

I think this whole article is flawed and confused. It suggests it compares codecs, that is software. The table includes details such as price, license etc., which is related to the particular software implementation, not the specifications (for example, Theora licensed under BSD, that is, it's a piece of software). Yet, these things are mixed with specifications (compression standards such as H.264). So I think this article should either be completely reworked from the ground up or simply deleted. — J. M. 02:22, 14 December 2006 (UTC)

In ordinary usage, 'video codec' refers to a product, not a coding specification, so this article should only compare actual codecs. A comparison of Image compression coding specfications should entitled as such, though I personally can't imagine much use for such an article. AndreasWittenstein 02:01, 29 March 2007 (UTC)

Yes, like I said earlier, the whole article doesn't make sense. It says it compares codecs, but then it includes the H.264 compression standard with all those nonsensical details such as "Latest stable version" and "Cost (USD)". So I removed H.264, but now the article seems even more useless than before, comparing only 5 video codecs, missing many other popular ones. —J. M. 04:43, 29 March 2007 (UTC)

More features in comparison

A lot of codecs are very similar. The article would benefit from new columns to show the differences. I suggest

• The problem the codec is designed to solve

• How the codec degrades when datarate is reduced
• How the codec degrades when available CPU for playback is reduced

It's impossible to include that kind of information in a table-based page like this. You would need to include graphs, screenshots, etc. That's not encyclopedic (or Wikipedic), that's something for a website about digital video. MrTroy 12:27, 5 July 2006 (UTC)

I agree that a detailed analysis of whether one version was better than another in different circumstances should be in your website review. The idea here would be to say whether frame rate or image quality are reduced, for example. This wouldn't need a graph. See MPEG/Blackbird example below. Stephen B Streater 14:12, 5 July 2006 (UTC)

• Whether the codec can handle varying bandwidth and CPU as often happens with streaming
• Is a live version available
• Implementation details
• Dynamism

To illustrate how this might work, consider the FORscene video codec, Blackbird, and how it differs from MPEG:

• MPEG is designed for video streaming, Blackbird is designed for Web-based video editing
• MPEG goes blocky when datarate is reduced, Blackbird gives lower frame rate
• MPEG can't play back on slower systems, Blackbird gives lower frame rate
• MPEG datarate is decided at compression time, so can't handle streaming over a connection with an unpredictably varying datarate very well. Blackbird sets image size depending on sampled datarate, and adjusts frame rate to use available datarate during playback
• MPEG has a few frames latency for live video. Blackbird latency is higher - typically a few seconds
• MPEG players are often implemented in embedded systems eg set top boxes. Blackbird player is implemented in Java which means upgrades can be distributed without requiring a computer upgrade
• Each MPEG standard is fixed. Blackbird's Java implementation means it can be upgraded at any time

Any thoughts? Stephen B Streater 09:59, 5 July 2006 (UTC)

I agree only about the first one, it's actually an useful information. The rest though, would sound like weasel words in favor of Blackbird. --ren 06:34, 19 September 2006 (UTC)

I find the choice of features odd. Under what circumstances would someone want to know the 'highest supported bitrate'? Whether a codec contains patented techniques might be useful for an article about algorithms or specifications, but why for codecs? In order for other contributors to have an incentive to add to this article, it needs to be structured to provide an overview information of general interest to readers, rather than just a few random features of a few random codecs. AndreasWittenstein 02:16, 29 March 2007 (UTC)

Bias in patents

While I am personally against software patents, many people aren't. The use of "but yes" and "but no" here is obviously biased. In respect of WP:NPOV, I propose discontinuing the use of those templates on this page (whatever the outcome of the template deletion). --Karnesky 01:44, 13 March 2007 (UTC)

This isn't very useful

i'd expect a list like this would compare the size of the same movie(s) compressed by the different codecs (maybe i'll do it myself) --193.136.128.14 13:26, 17 May 2007 (UTC)

It's not so simple. Every codec I know allows you to set a target bitrate. There's no single best bitrate for a given resolution. Using the same codec you would want to set a much higher bitrate/quantizer for something you're going to edit than for something you're going to stream over the web. So it's hard to give a typical compression ratio for a codec. If what you mean is compressed size at same quality, well, quality is quite subjective, and codecs have a number of settings depending on what you want to optimize for (quality, encoding/decoding CPU/time, device compatibility) so it would have to be a series of graphs instead of a single number. OK, roughly speaking, typical MPEG2:ASP:AVC compression rates relate as about 1:3:6, but what use are these numbers?--87.162.6.190 (talk) 18:41, 5 August 2009 (UTC)

Perhaps it's not possible, but I would also very much like to see something like this. — Preceding unsigned comment added by Torr3 (talk • contribs) 14:04, 6 April 2014 (UTC)

Patented

What does the "Patented" column mean? Does it mean the particular codec (software implemetation) is patented or the encoding method (specification, compression format) it uses? I would naturally expect the latter, as that's what's relevant and important in most cases. But then Xvid, FFmpeg and x264 should be marked as patented, too, because they use the patented MPEG-4 compression formats. Anyway, this whole patent section is as confusing as the rest of the article. —J. M. 00:39, 25 May 2007 (UTC)

No reply, so I changed the descriptions—what matters for users (and also for example for Linux distribution makers) is whether the compression standard the codecs use is patented or not. Xvid, FFmpeg and x264 use patented MPEG-4 (and other, in the case of FFmpeg) compression formats, that's why patents apply to them in the countries where software patents apply. —J. M. 03:40, 26 May 2007 (UTC)

QUALITY comparison of codecs?

I'm trying to find a nice, simple resource that compares MPEG2 versus VC1 (aka wmv) codecs. I found pages that compare audio codecs, for example, saying that an AAC+ file can be compressed to half the size of a MP3 file, and yet still score the same in listener tests. ----- Doesn't wikipedia have a similar comparison for video? - Theaveng 16:00, 14 September 2007 (UTC)

There are already several useful links in the article. Bear in mind anything too simple is misleading and anyone who tells you AAC+ can be compressed to half the size of an MP3 file yet still score the same in listener tests is probably talking bullshit since tests tend to vary a lot based on sample type. VC1 can usually achieve roughly equivalent quality to MPEG2 at a lower bitrate. But MPEG4 AVC/h.264 is usually better still. [1] for some comparisons include several different codecs in 2006 [2] and quite a few comparisons of AVC codecs (usually throwing in one MPEG4 ASP sample as well I believe). They don't have VC1 unfortunately this isn't their fault. They rely on the support of vendors/codec developers but MS didn't want to participate [3]. In any case I would also recommend the doom9 forums in general, there are a lot of people there who actually know what they're talking about Nil Einne (talk) 17:26, 19 December 2007 (UTC)

If you review the wiki article about Audio Codecs, there are several tests there (not just one), and they do indeed reveal that an AAC+ codec (which includes SBR to preserve high frequencies) can encode at half the bitrate of MP3, and still score equal quality ratings by the listeners. - Theaveng (talk) 18:33, 20 December 2007 (UTC)

MERGEFROM: "Differences between mp4 & 3gpp file formats"

As mentioned on its talk page, there is no reason for "Differences between mp4 & 3gpp file format" to be a stand-alone article -- the information therein should be merged here. --Ean5533 ( View! / Talk!) 04:30, 16 February 2008 (UTC)

• Wouldn't MPEG-4 Part 14 be more appropriate than this article ? This article is about video codecs. Not about the container. - 70.27.3.191 (talk) 11:04, 23 September 2008 (UTC)

Operating system support

Sorenson 3 and others are "supported" on unix machines running x86 type of cpu and possibly others via emulation. It's done by a mockup MS-Window DLL interface in mplayer asfair. However maybe the article author had some other definition of "supported" ..? Electron9 (talk) 08:27, 15 August 2008 (UTC)

By that logic, everything might be supported everywhere. You can run an x86 emulator on a SPARC machine on NetBSD, run ReactOS in the emulator and play videos using the Sorenson DLL in it. Does that mean the Sorenson library supports NetBSD on the SPARC platform? The Sorenson library is made for Microsoft Windows and Mac OS X by the Sorenson authors and that's what the "support" section means.—J. M. (talk) 11:48, 15 August 2008 (UTC)

Let's limit it to that you can actually run the codec nativly. In the case of MS-Window DLLs that means it's possible to run them on any x86 cpu equipped unix system with help of the (mplayer) unix<->DLL interface. As any instruction level emulation would impact performance. Ofcourse the blessing from the producer is still missing. And it's good to make a point of that. Electron9 (talk) 11:37, 16 August 2008 (UTC)

You can definitely mention that in the article. However, "operating system support" in software almost universally, always means what the software maker supports, in all lists on every website in every article. And generally, Wikipedia follows usual conventions. For example, it is normal to say that Microsoft Office suports Microsoft Windows and Mac OS X because Microsoft makes its flagship office suite for these two operating systems – and the fact that you can actually run Office on any UNIX-like operating system via Wine absolutely does not mean that in the "operating system support", for example the "Linux" table cell should say "Yes". Noone writes it like that. Microsoft does not make Office for Linux. In fact, this is a general thing that in my opinion does not belong in specific information about any particular software product. Generally, you can always find ways how to make software compiled for system X run on system Y, this is nothing specific to Sorenson or any other codec or piece of software, so it does not make sense to mention it specifically for each software product separately. This is just information that is usually explained separately in other articles. That's why I would just change the "Operating system support" title to something more clear to avoid this kind of confusion.—J. M. (talk) 15:59, 16 August 2008 (UTC)

I was hoping this section would tell me what video formats I can play straight out of the box on various systems.--98.227.72.161 (talk) 11:41, 3 December 2009 (UTC)

Then you're reading the wrong article. Something like "Comparison of video formats" would be more appropriate. A codec is not a format. Codec is a software product. An implementation. And that's what this article is about. It compares software products. There are many codecs that implement the same format. In fact, there are only a a couple of video formats that are commonly used today. The vast majority of the popular codecs just implement one of those popular formats (it is a very popular misconception to think that all codecs use their own format, that codec is a format— it's just a common myth). If a video codec XY is not available for your operating system, it does not mean that you cannot play the video format on your system. You can use other codecs (i.e. software products) that implement the format (if they're available for your OS). Modern graphics cards can also decode popular video formats in hardware.—J. M. (talk) 22:19, 3 December 2009 (UTC)

How come DivX encoding is marked as "not natively supported on Unix and Unix-like OS'es" ? I recently converted a bunch of movies to divx using mencoder, which runs perfectly on Linux. Here's a howto that shows how to do this with mencoder. —Preceding unsigned comment added by Tomvanbraeckel (talk • contribs) 12:29, 31 December 2009 (UTC)

It is explained in that section. It is the first and the only sentence of the "Native operating system support" section. But alright, I will explain it in more detail.

No—that howto does not show anything about DivX at all.

You don't understand what DivX is. You are not alone, this is an extremely common confusion. I recommend reading the DivX article, which explains what DivX is. Like I already explained, this article is about software products, not about formats. That's the number one thing you have to understand—the difference between a software product and a format.

You don't convert movies "to DivX", that's nonsense. DivX is a brand name of software products made by the DivX company. You don't convert video to a brand name or to a company. You can convert movies with the DivX codec, using the DivX codec. Because the DivX codec is a software product. It is an MPEG-4 codec. That is, video created with the DivX codec is MPEG-4 video—video in the MPEG-4 format (ASP or AVC). Not "DivX video" (that's just marketing drivel used for advertising, not a serious technical term—just like a text file created in Notepad is not a "Notepad file", you don't save it "to Notepad", or a JPEG picture saved in Adobe Photoshop is not a "Photoshop picture").

But you can't do it with MEncoder, because MEncoder does not support DivX. Note: supporting the DivX codec does not mean supporting MPEG-4 video (of course MPlayer/MEncoder supports MPEG-4 video). Supporting the DivX codec means supporting the DivX software product in another software product. For example, if a program XY supports DivX encoding, it means it can use the DivX codec for encoding. Not some other, compatible product. Exactly this one, only this one. The DivX codec, nothing else than that. Because the DivX codec is a proprietary software product made by DivX, Inc. Available for Windows and Mac OS X.

MEncoder (just like virtually all free software multimedia products) uses libavcodec (that's the "lavc" on the command line), and that's exactly what's used in the article you mention—it does not use DvX, it does not have anything to do with DivX. It uses the libavcodec software library for converting video into the MPEG-4 ASP video format (not "to DivX"—by the way, DivX is a registered trademark, nothing else than DivX can be called DivX). Of course the final video is compatible with the DivX codec and many other codecs, too, because it is MPEG-4 video, and the DivX codec is an MPEG-4 codec. That is, all MPEG-4 ASP codecs (Xvid, 3ivx etc.) work with the same video format, MPEG-4 ASP. Video encoded with one of them can be decoded with the others. You encode to MPEG-4 ASP, not "to DivX", "to Xvid", "to 3ivx" or "to libavcodec".

As I already explained, this article compares software products. DivX Pro Codec is a software product that's currently available for Windows and Mac OS X. And that's what the table is about.J. M. (talk) 01:15, 1 January 2010 (UTC)

ffdshow & ProRes 422

Where would ffdshow & ProRes 422 fall in this comparison? —IncidentFlux ^{[ TalkBack | Contributions ]} 17:38, 31 October 2008 (UTC)

ffdshow it a codec pack, not a codec per se. That is, it includes codecs made by third parties, not by the ffdshow authors, who just wrap them in a DirectShow/VfW filter. Most notably, it uses the libavcodec codecs from FFmpeg. And FFmpeg is already mentioned in the article.—J. M. (talk) 20:53, 31 October 2008 (UTC)

Hmmm, I've never heard it called that, it may be a codec pack (in the generic sense, not technical), but, I think it has its place on the template somewhere because it's one of the best and cleanest ones I've come across so far. Shouldn't there be a section for filters? —IncidentFlux ^{[ TalkBack | Contributions ]} 21:16, 31 October 2008 (UTC)

And what would you compare? And why? Let's see some of the criteria from the article:

1. Video quality per bitrate: irrelevant, because ffdshow includes many different audio and video codecs
2. Performance characteristics: irrelevant, see above
3. Objective video quality: irrelevant, see above
4. Supported rate control strategies: irrelevant, see above
5. Compression type: irrelevant, see above
6. Basic algorithm: irrelevant, see above

And so on. ffdshow is just a collection of codecs made by other people. If you want to compare the video quality or speed, then you have to compare the real codecs. Which means for example FFmpeg MPEG-4, FFmpeg H.264 and other encoders and decoders included in ffdshow. And like I said, FFmpeg is already there in the article. The FFmpeg people are the ones who do the real work, not the ffdshow authors. In fact, ffdshow basically means FFmpeg for DirectShow (although it now includes various other things made by other people, too).—J. M. (talk) 21:31, 31 October 2008 (UTC)

Alright, but I still think these filters / codepacks, need proper attention, somewhere if not here. But what about ProRes 422, surely that fits here?—IncidentFlux ^{[ TalkBack | Contributions ]} 09:48, 1 November 2008 (UTC)

Agree on Merging

• I agree on merging this article with Comparison of video codecs. --Mahmudmasri (talk) 01:29, 19 July 2009 (UTC)

If you mean merge the Differences between mp4 & 3gpp file formats with this one, then that's utter nonsense. I explained it on the other article talk page (this article discusses software products that produce video bitstreams, while the other article compares container formats, so the two articles compare completely unrelated things in every way). So I suggest removing the merge template from both articles, as it was obviously put there by someone who did not understand what he/she was doing (first, he/she does not understand the difference between a video format and a container format, second, he/she does not understand the difference between a format and a software product).—J. M. (talk) 02:21, 19 July 2009 (UTC)

Any objections to removing the merge template?—J. M. (talk) 00:00, 8 August 2009 (UTC)

No objections, plus agreement with the template removal on the other article talk page, so I'm removing it.—J. M. (talk) 04:58, 13 August 2009 (UTC)

No recent shootout?

Is the 2005 Doom9 shootout really the latest independent test for the major codecs? That's a shame. Google just acquired On2 and claim VP7/VP8 is much better than H.264, Theora claims to be comparable to H.264 (wishful thinking IMO)... blurb everywhere, where are the objective data to support it?--87.162.6.190 (talk) 18:59, 5 August 2009 (UTC)

Compression Ratios.

A comparison of compression ratios would be most usefull.(Fractalhints (talk) 18:50, 18 March 2010 (UTC))

This has been touched on before. One reason it hasn't been added is that the compression ratios can often be improved by sacrifices in other areas, such as video quality and compression speed. It makes most sense in the case of lossless compression, but even there the nature of the input can make a big difference. Stephen B Streater (talk) 07:34, 19 March 2010 (UTC)

Codecs or encoders? Specifications or implementations?

This article can't seem to decide whether it's documenting codecs (encoder/decoder specifications) or encoders (implementations). For example, the same table lists both VP6 (codec) and Windows Media Encoder (an encoder product). That doesn't make sense. I strongly recommend that the table be appropriately split into 2 tables. —Preceding unsigned comment added by 174.21.199.110 (talk) 19:54, 9 November 2010 (UTC)

Codecs are not encoder/decoder specifications. A codec is an encoder/decoder (or compressor/decompressor)—that's the definition of the word codec. "A video codec is a device or software" that encodes and decodes video. A video codec is not a specification, a video codec is an implementation. And that's what this article compares. And it also makes it perfectly clear. Even the first sentence of the article explains what a video codec is, and therefore what the article is about, and the following sections clearly explain that the article is about software products (price, version, OS support, license etc.), not about specifications (e.g. "A codec is not a format"). I don't think the article could make it any more clear than that.—J. M. (talk) 20:15, 9 November 2010 (UTC)

General video codec information — creator/company, license/price, etc.

Hello, I am not an expert wikipedia editor, but it seems that you have 3 columns in that chart that do not contain any information for all but one codec. —Preceding unsigned comment added by 129.179.32.1 (talk) 21:24, 14 February 2011 (UTC)

YULS

The YULS codec needs adding Lmatt (talk) 22:39, 15 April 2011 (UTC)

Which codecs allow for random positioning?

This seems like important/basic information. I have a ~2GB mkv file on network storage. I want to skip to the middle of the video with VLC but VLC wants to play thru the entire video (internally/quickly) to get to that point in the video. Doing this takes about half the time it would take to watch the video up to that point. So either VLC is inferior or the codec (I am not sure which it is, assuming mkv is a container) cannot do random positioning.

In short. It seems like a table of what codecs can be opened midstream and how gracefully and to what precision they are able to do so would be good to have here. --12.213.80.36 (talk) 08:56, 5 December 2011 (UTC)

This has nothing to do with codecs. First, the ability to seek in the file depends on things such as container format, the way the container was created, the audio and video stream format and their properties, the player and the way it handles seeking, whether the file is read from the disc or streamed over a network, the transport protocol etc. Second, this article is about codecs, and codecs are software products (as the "open-source" attribute in the title suggests), not formats. Software products are tools that create/read files or streams in some format, so generally it does not matter which particular software product (tool) you use, what matters is the format you choose. You do not "open codecs midstream", because codecs are software libraries, and you do not open libraries midstream (at least when you play back a video).—J. M. (talk) 16:41, 5 December 2011 (UTC)

Efficiency

As many, many complaints on this talkpage show, the most essential aspect about video codecs is their efficiency, that is the file size (or data rate)/quality ratio. Now you're gonna say again "But maaaaan, there's so many different settings you can make!" Well Sherlock, that's why most professional comparisons go by industry standards!

In other words, Wikipedia is still lacking a comparison of digital video format and broadcast standards (DVD MPEG-2, DV, DVB, BD MPEG-4 AVC...) based upon efficiency, giving file size and/or data rate for a variety of industry standards at a number of resolutions, profiles, etc (per second, per minute, per hour, per 2-hour standard movie running time).

For instance, did you know that at the same length and SD resolution, a video will be less than half in file size as DVD MPEG-2 video than as more recent BD MPEG-4 AVC? As DVD MPEG-2, a 2-hour SD rez movie can be 4GB small, whereas as MPEG4 AVC@SD rez, it's 9-11 GB (Main Profile, aka DVB, vs. High Profile, for storage media, such as BD)? Which means that the newer standard is less efficient than the old one, even at the same resolution. --79.193.41.170 (talk) 13:55, 27 May 2012 (UTC)

This is exactly the reason why this article exists, and why there are always comparisons of codecs, not comparison of formats everywhere on the web. We can only meaningfully compare encoders, because the quality depends on the encoder, on the software or hardware implementation. In other words, a bad MPEG-4 encoder can give (much) worse quality for the same file size than an excellent MPEG-2 encoder. And even the best MPEG-4 encoder can give worse quality than a bad MPEG-2 encoder if "bad" encoding options are selected, because, yes, there are many ways to configure the encoder. The term "industry standards" really does not apply here, because an industry standard means a format or a subset of a format, but there are still many different encoders available for that format or its subset (such as the MPEG-4 AVC profiles), and many ways to configure them. A video format does not "perform", only the encoder does. And there can be (and are) are wild differences in quality among various encoders for the same format, even though, of course, encoders for newer, more modern formats typically tend to give better results than encoders for older, more simple formats, as the newer formats are more advanced. But it's not a hard rule.—J. M. (talk) 23:00, 27 May 2012 (UTC)

Daala is missing

See http://xiph.org/daala/ — Preceding unsigned comment added by 128.70.197.164 (talk) 14:09, 15 May 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 7 external links on Comparison of video codecs. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20081107213150/http://diracvideo.org/ to http://www.diracvideo.org/
• Added archive https://web.archive.org/web/20091216173026/http://www.ffavs.net/ to http://www.ffavs.net/
• Added archive https://web.archive.org/web/20040804142359/http://www.realnetworks.com/products/codecs/realvideo.html to http://www.realnetworks.com/products/codecs/realvideo.html
• Added archive https://web.archive.org/web/20070205154511/http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txt to http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txt
• Added archive https://web.archive.org/web/20080223010804/http://www.doom9.org/codec-comparisons.htm to http://www.doom9.org/codec-comparisons.htm
• Added archive https://web.archive.org/web/20070823063012/http://people.csail.mit.edu/tbuehler/video/codecs/ to http://people.csail.mit.edu/tbuehler/video/codecs/
• Added archive https://web.archive.org/web/20090620051634/http://etill.net/projects/dirac_theora_evaluation/ to http://etill.net/projects/dirac_theora_evaluation/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:59, 11 August 2017 (UTC)