Talk:MPEG-2

Patents
When do the patents expire? Great job on the list of patent holders, but does anyone have the list of actual For Part 1 and 2 you can look into the ITU-T Patent Database, since they both parts are common texts. They are known in the ITU-T side as H.222.0 and H.262, respectively. Here is the URL for the database:

http://itu.int/ITU-T/dbase/patent


 * 2020s. US 7,020,204 doesn't expire until at least 2021.  There is now a list of US patents in the article, so feel free to check more closely.  Jrincayc (talk) 15:32, 1 June 2008 (UTC)

Okay, using this program: (Program snipped, new version put on my user page at User:Jrincayc/Patent_utils)

piped through sort -n got the following list so the answer is July 2023, unless some of the patents don't count Jrincayc (talk) 03:40, 6 June 2008 (UTC):


 * Back in the early 90's, the rule for patent life was basically the later of 20 years from date of filing or 17 from the date of issue. Some patents, however are continuations or divisions of other patents.  A continuation is where the assignee files another set of claims using the original disclosure at some point during the patent examination, where as a divsional is where an application is split into two sets of claims related to different parts of the invention which each get seperate examinations.  The example above of US7,020,204 is actually a division of US6,563,875 which itself is a continuation of another application which is based on a foreign patent application filed back in 1988 and therefore expires well before 2022.  The expiration of continuations is generally close to the expiration of the original 'parent' applicaton.  The table below does not account for these factors.  Generally, most of the patents should be expired by around the 20th anniversary of the public release in 1996 (~2016).  Many will be well before that.   Dspark76 (talk) 23:48, 3 June 2010 (UTC)
 * Update, I just looked on the MPEG LA List and US 7,020,204 already expired on January 29, 2010. Dspark76 (talk) 00:01, 4 June 2010 (UTC)
 * I have updated the program to try and take account of continuations and divisions. However, all the information is not in machine parseable form.  (On example of missing data is that Patent term adjustment data is not available in the text versions, only in the pdfs.)  Never the less, this should be better. Jrincayc (talk) 03:44, 11 April 2011 (UTC)
 * Now the program grabs the term extension from Google's OCRed data. These should be closer.  However, there are still some times that the data needed is only in the English that is in the case text, so these still can be somewhat inaccurate.  US7,020,204 is now calculated by the program to be January 1, 2010, which is a lot closer to its actual expiration date of January 29, 2010 than before, when it was 2022.  Jrincayc (talk) 12:34, 21 April 2011 (UTC)

As a table using User:Jrincayc/Patent_utils:

How many seconds of bitrate buffer is allowed in the restriction of MPEG-2 DVD?
In compressing Your materials into MPEG2 format (for DVD), for the best results You should go with VARIABLE 2 PASS compression, where the lowest bitrate shouldn't be under 1.5 Mb/s, and the hightest 8 Mb/s...


 * There's nothing wrong with going under 1.5Mb/s. Some scenes CANNOT be coded with a bitrate higher than this. Many others will look just fine below this bitrate. Snacky 17:57, 27 May 2006 (UTC)

Although, some aplications will allow You even 12 Mbit/s, and the movie DVD standard bitrate is (not officialy, but "from mouht to mouth") declared maximum 9 Mb/s, You shouldn't go above 8 Mbit/s...


 * The problem is that players aren't required by the spec to play stuff like this, and many of them won't. If your player plays it, more power to you. The spec (officially) allows a maximum video bitrate of about 9.8mbit/s. Feel free to go above 8mbit/s, as any compliant player will support this with no problem. Read the DVD article. Snacky 17:57, 27 May 2006 (UTC)

So, 8 would be the anwer:), I guess!

PS

Higher bitrates can be as harmful as too low bitrates, 'cause high bitrates can be too demanding for the reading equipment (doesn't matter if You try to watch it from hard disk or from real stand-alone DVD player), you can expect some twitching and trambling...


 * "maximum bitrate" is only a meaningful in the context of a buffer size, which is 1835 kbits in the case of DVD. In theory, this means local bitrate may actually exceed the allowed max (9800kbit/s) as long as it does so for a period of less than about 0.187 seconds, and as long as it doesn't fill up the 1835 kbit buffer. Snacky 17:57, 27 May 2006 (UTC)

Improvements to this article
Request made by Daniel.Cardenas on the article page but moved to here.

"Please help improve this article with a more novice introduction. A simple diagram that describes compression would be very helpful. For example compression is achieved thru time bases similarities in the frames and spacial, nearby pixels, similarities."

Maybe this information is elsewhere in Wikipedia in the form of a simple summary (rather than spread out descriptions). AlyM 08:50, 22 April 2006 (UTC)
 * It think this request works better in the main article. Perhaps as a footer or something.  Something like the standard wikipedia text that says this is a stub.  The article in in current state is rated poor by me for the average person.  It needs much more introductory material.  Daniel.Cardenas


 * Sure, using an appropriate stub-type marker or something would be fine (perhaps cleanup, confusing or technical), but not having a section in the article requesting the change. Article content vs. meta-content or something. AlyM 17:37, 22 April 2006 (UTC)

Split off "Video coding"
Since almost all modern motion compensated codecs use the same techniques, there should be a separate article about it. And it could start based off of the "Video coding (simplified)" section. That exact section could be copied word-for-word to the much leaner MPEG-1 article, and it'd be equally accurate. Snacky 19:34, 28 May 2006 (UTC)


 * Definately, a simple and generic video coding article would be better than having the content here. AlyM 15:30, 29 May 2006 (UTC)

High BitRates
The bit rates in the tables seem to high. For example 80 Mbps for ATSC. I thought it was more like 20 Mbps for high-def 1080i. GregorLarson 18:35, 10 August 2006 (UTC)
 * You misunderstood the profile & level charts.


 * 80mbps is the highest bitrate allowed by MP@HL. Therefore, any application that needs LESS than this bitrate could conform to MP@HL.


 * The Applications on the right side column are intended as examples. I edited the column header in hopes of preventing any more confusion. Snacky 18:54, 10 August 2006 (UTC)

The Panasonic MPEG-2-based HD product bitrate is reported at 300Mbit/s. That's too high; a single-layer HD-DVD is 15gB, which would be, which does not match the 1:42:00 minimum for HD-DVD with MPEG-2. I am far more inclined to believe it is 20Mbit/s as reported at Comparison of high definition optical disc formats. -- Adam Katz 19:07, 2 October 2007 (UTC)
 * It's not wrong. As Snacky said, 300Mbps is maximum bit rate allowed in 422P@HL (ISO/IEC 13818-2 table 8-13). An application which conforms to 422P@HL, such as "The Panasonic MPEG-2-based HD product", may and likely use less bit rate. To clarify it, I've added some explanation in the article. Motonari 20:27, 2 October 2007 (UTC)

Intro Block Diagram
http://en.wikipedia.org/wiki/File:Mpeg.svg The diagram may be misleading as it does not show the lower level containerization of the MPEG PES (Program Elementary Stream) as being a level below TS (DVB Transport Stream). Also, DVB-S2 is an 8 point constellation of QPSK that allows for additional bitrate in the satellite transponder by optimizing the error correction scheme and the Nyguist roll-off factor, but the DVB-S2 System does not modulate MPEG-4 directly as shown. The same MPEG containerization scheme and the same 188/204 DVB Transport Stream Schemes are used. Also, MPEG-4 does appear in DVB-C, DVB-S, and DVB-T (particularly in Italy and Spain) but the higher bandwidth requirements of MPEG-4 HD force fewer PES per carrier. This is a problem that is improved bt DVB-S2, and will be improved by DVB-T2 (coming soon), and DVB-C2 (under definition). Never-the-less, DVB-S, C, and T do carry high definition (not implied by the diagram). 123.192.95.51 (talk) 11:27, 21 December 2009 (UTC) Stan Hemphill, Taipei, Taiwan - 21 Dec 2009

Revised Intro and Video Coding Sections
I starting looking at this and related articles when a change in the kernel of the Linux operating system caused a program that I use to record digital TV to stop working. In attempting to find a way to get it working again, I sought information about the nature of the incoming signal, e.g., details about MPEG-2 packets. Unfortunately, I found the existing wikipedia articles hard to understand (and I am a retired electronics engineer.) There was lots of technical jargon but little clarity. After some further research elsewhere on the web, I thought that I would see if I could rewrite parts of the current MPEG-2 article to make it clearer.

I rewrote the first paragraph primarily to emphasize the importance of standard. The value of the industries applying this standard is in the hundreds of billions of dollars. The number of viewers who use the standard today or who will start using it in the near future -- most unknowingly, of course -- is probably in the hundreds of millions.

MPEG-2 is not a group of standards. Rather, it is one standard with several parts.

I moved the sentence about patents in the first paragraph to the patent section. The issue of patents is important but I doubt that it is the primary concern of most readers of this article.

I rewrote the section on video compression, primarily, to introduce the technical ideas in a more logical order starting with the basic idea of a digital TV picture.

I added a reference to the ISO site and to a couple of external links that I found helpful. Also, I corrected a minor error in the "See Also" section.

Some further changes seem desirable:
 * 1)  Move the ISO/IEC 13818 section to immediately after the introductory section and merge it with the introduction paragraphs that discuss the parts of the standard.  Also, there is now an 11th part to the MPEG-2 standard: IPMP (Intellectual Property Management and Protection).
 * 2)  Expand the section on MPEG-2 audio compression to summarize how it works.
 * 3)  Make the separate MPEG-2 Transport Stream article a section of the MPEG-2 article.

For what it's worth, I found copies of the various parts of MPEG-2 standard on the web. But I wonder about copyright issues. ISO will sell you copies of each part of the standard but they are pricey.

I did get my DTV recording program working by changing the name of a variable. The problem had nothing to do with MPEG-2.

Ivar Y 15:37, 26 November 2006 (UTC)


 * The entire video coding discussion should be moved to either Video coding or some other separate article. (hint: 99% of what's said about it in this article would also be true in MPEG-4 Part 2, MPEG-1, H.263...) I suggest you work on that instead. Then, the redundant section should be mostly removed from this article. Merging transport stream and audio is probably a bad idea. Snacky 20:14, 26 November 2006 (UTC)


 * I half agree with you. However, I think that when people come to the MPEG-2 article, they should be given information about MPEG-2.  They should see more than a list of unfamiliar or vague technical terms configured as hyperlinks.  If people are looking for a picture of George Washington, they want a complete picture in one location.  They don't want to be told that they can find a pictures of ears in the article on ears, that a picture of eyes is available in the article on eyes, that noses are discussed at still another location, and so on.


 * On the other hand, I agree that it is undesirable to keep reinventing descriptions of common processes like video compression.


 * One solution, which in practice may be difficult to achieve, is to provide a summary description of important processes (e.g., video compression) in the immediate article (e.g., MPEG-2) and to link to the more specialized articles (e.g., about video compression) for a more detailed discussion.


 * Unfortunately, when I start looking in the wikipedia for articles relating to video compression, I find lots of them:


 * video compression
 * video coding
 * video codec
 * JPEG
 * quantization (image processing)
 * color quantization
 * multimedia compression
 * H.262
 * digital video
 * interlace
 * B pictures


 * Ivar Y 07:20, 27 November 2006 (UTC)

Aspect ratio
NTSC MPEG-2 also allows for a 640x480 resolution at 29.97 fps. El Mariachi94 06:30, 1 December 2006 (UTC)El Mariachi94

D-frame
The video compression article mentions "D-frame". What is a D-frame ?

When I click on "D-frame" to learn more, I am redirected here to MPEG-2. But this MPEG-2 article never mentions "D-frame". (Is there some other article that would be a more appropriate destination for that redirect?) --68.0.120.35 03:09, 8 February 2007 (UTC)


 * There is no "D-frame" in MPEG-2 video (see ISO/IEC 13818-2 Table 6-12), therefore this redirection sounds wrong. Motonari 16:57, 29 September 2007 (UTC)

There are D-Frames in MPEG-1. They are intra frames that have only DC component, so the image is made of very big (8x8 blocks) blocks. They have been created with intension for fast-play-forward (as they don't need use of full IDCT tranform). —Preceding unsigned comment added by 89.215.50.234 (talk) 22:13, 21 October 2007 (UTC)

Interlacing is not for reducing the amount of data
Interlacing was necessary to avoid flickering because the frequency had to be synchroneous to the power supply frequency; 50 Hz (Europe) or 60 Hz (USA) was not enough.

The amount of data is determined by the number of image per second, 25 i/s (Europe) or 30 i/s (USA).

Interlacing does not reduce the number of image per second, it just avoids flickering.

Of course, with higher frequencies like today, you could increase the image rate, but mind that 18 i/s is enough to have a good fluidity (cinema at the time of silent films). Cinema is at 24 i/s because of optic sound (increasing speed ⇒ increasing bandwidth) and TV is at 25 or 30 i/s to match the power supply frequency (pb of parasites, now solved).

cdang| write me 15:08, 22 March 2007 (UTC)


 * Yes, it is.
 * This is what Interlace article states: storing a full video frame and scanning it twice would require a frame buffer, a method that did not become feasible until the late 1980s. In addition, the limits of vacuum tube technology required that CRTs for TV be scanned at AC line frequency in order to prevent interference. (This was 60 Hz in the US, 50 Hz Europe.) In 1936 when the analog standards were being set in the UK, CRTs could only scan at around 200 lines in 1/50th of a second. By using interlace, a pair of 202.5-line fields could be superimposed to become a sharper 405 line frame. The vertical scan frequency remained 50 Hz, so flicker was not a problem, but visible detail was noticeably improved. After the Second World War, improvements in technology allowed the US and the rest of Europe to adopt systems using progressively more bandwidth to scan higher line counts, and achieve better pictures. However the fundamentals of interlaced scanning were at the heart of all of these systems.


 * If the speed of scan were better, than there would be no interlace - each frame would be scanned in progressive mode and projected twice, so the main reason was limited bandwidth.


 * Yes, interlace does not reduce number of images per second, but it lowers factual resolution of each image thereby reducing amount of data - 25p has twice as much data as 25i at the same resolution.
 * --Alexander Iwaschkin 15:53, 22 March 2007 (UTC)

MC is performed before DCT and Quantization
In Macroblocks, it reads:

To correct for this, the encoder computes the strings of coefficient values as described above for both macroblocks and, then, subtracts one from the other.

Encoders first subtract a reconstructed block (= pixel value) from a predicted block, and then computes DCT coefficient on the difference. So, I'm afraid the current article has an error here. Motonari 17:35, 29 September 2007 (UTC)

422P@LL? 422P@H14?
In the latest published standard (ISO/IEC 13818-2 2000), there is no 422P@LL nor 422P@H14. As far as I know, there is no plan to add them. Could anyone provide a reference if there is good reason to say "Potential future"? If there is no such references, I suggest to remove them.

Additionally, 422P@HL is not "potential future" but they are well defined and actually used. I will remove "potential" of that. NTT VASA Series —Preceding unsigned comment added by Motonari (talk • contribs) 06:29, 30 September 2007 (UTC)

Do the MPEG-2 files keep history if any program changes them?
They say that files of MPEG-2 or latest type keep a record-history of changes being done to them by programs. Is this true? And is it also true that MPEG-1 does not do that? —Preceding unsigned comment added by 150.140.226.32 (talk) 23:18, 18 March 2008 (UTC)

In Mpeg-2 DVD, why 4:3 and 720x480?
This has never made sense to me: Why does the Mpeg-2 standard, in DVD format, allow 4:3, but no resolutions that calculate to 4:3? Have you ever noticed that the aspect ratios allowed can never be achieved using the allowed resolutions? Why is that? There must be a reason. —Preceding unsigned comment added by 71.169.156.93 (talk) 16:10, 6 September 2008 (UTC)


 * Because the pixels in the 720x480 4:3 format are not "square". Their height is 10% larger than their width (which makes a 704x480 area within the 720x480 exactly 4:3 and leaves the rest for "overscan").  The 720x480 sampling was designed (a long time ago) so that its sampling rate had a nice relationship with the existing analog signals.  It didn't really matter (at that time) that the width and height of each sample on the screen are not the same, because television displays were not built based on that assumption. The newer 16:9 HDTV formats (1280x720 and 1920x1080) were designed differently — using the more digital-centric "square pixel" concept rather than building them for compatibility with old analog television signals. —Cat5nap (talk) 16:31, 6 September 2008 (UTC)

I just noticed a reference on the Cyberlink website to "MPEG-2 HD". It would be nice if someone could explain this particular iteration of the MPEG-2 format. Thanks.96.10.22.202 (talk) 17:02, 2 November 2008 (UTC)

Different extensions
Hi, It'd be nice to have the different filename extensions of MPEG-2, as there is on the article of MPEG-1. Does someone know them all ? —Preceding unsigned comment added by 86.199.63.221 (talk • contribs) 21:31, 6 December 2008


 * I want to second that! ! !  Someone asked me to try to recover MPEG-2 files which came from a camcorder, I searched the internet but I couldn't find out which extensions I should be looking for. —Preceding unsigned comment added by 78.149.158.52 (talk • contribs) 01:40, 15 February 2009


 * Filename extensions are usually .m2v .mpeg .mpg m2a and .vob; though when recovering data; I'd just look at any big file regardless of extensions; because people tend to use different (nonstandard) extensions all the time Nidomedia (talk) 14:42, 1 April 2009 (UTC)


 * Yes, but the big question is about MPEG-2 clips that contain both video and audio. -82.80.57.79 (talk) 06:55, 16 October 2009 (UTC)

HD camera size
How did the hd camera bitrate came to be? any calculation I do results in a different number. Nidomedia (talk) 14:42, 1 April 2009 (UTC)

Frame Rate
The frame rate discussion in the video coding section implies that the fields in interlaced video are obtained by taking alternate lines from a (progressive) frame. This is not the case - the fields represent different points in time, and it would be better to say that odd lines are taken from one frame of a 50 (or 59.94) fps video signal and even lines from the next. (A more complicated algorithm incorporating vertical low-pass filtering is actually used in modern video cameras). The only exception to this rule is if a low frame-rate progressive signal (eg 1080p25)is being conveyed using a technology designed for interlaced video at a higher field rate (eg HD-SDI at 1080i50) - a process known as "pre-segmented frame" representation. Elvum (talk) 09:57, 11 December 2008 (UTC)

DVB Picture Sizes
I just thought I'd throw it in that "standard definition" DVB-T in the UK (called Freeview, for which there are currently no high definition channels) is done in 1024x576 interlaced. This is a 16:9 ratio for 576i (PAL). I don't know whether it isn't listed because it's not listed in an MPEG spec somewhere but it's definitely used. 86.16.148.129 (talk) 13:54, 17 April 2009 (UTC)

Why did the 422P@Main Level entry go away?
Back in early 2008, someone deleted the 422P entry from the table of profiles. Why? 422P@main level is a perfectly valid MPEG-2 profile. Is there any good reason not to restore it in the table? 74.95.46.250 (talk) 18:02, 9 June 2009 (UTC)
 * I've done a bit of research and apparently the 422P profile was added in 1997, as an amendment to the 1995 first edition MPEG-2 Part 2 spec, and later (probably) included in the 2000 second edition. Unfortunately, the 2000 edition is not freely available, but the 1995 one is, so some editors might mistakenly believe 422P doesn't exist. I don't have access to the 2000 edition, so I can't make the necessary changes, hopefully someone else does. C xong (talk) 04:25, 4 August 2010 (UTC)
 * I've just gotten my hands on the 2000 edition and I've added two new profiles: 4:2:2 and multi-view. HTH C xong (talk) 01:37, 6 August 2010 (UTC)

60i not 30i
The article seems to use a convention different to virtually everywhere else I've seen, halving the number used for interlaced frames. Generally NTSC is considered "60i" (or 59.xxi), and PAL "50i", but for some reason this article uses 30i and 25i respectively.

Before changing it, I'd like to double check: is there some discussion somewhere where Wikipedia settled on this unusual convention? Otherwise I'll change it to the same convention I see in TV specification lists, MPEG encoder descriptions, etc... 66.149.58.8 (talk) 23:00, 21 June 2009 (UTC)

Subtitle Patent?
Does the subtitling technology over MPEG-2 count as an essential component? Maybe it should be added to the patent list. Its owned by Philips. See SUBTITLING TRANSMISSION SYSTEM. Patent numbers: Patent Information can be found here: Abstract is Here: "A method of simultaneously transmitting a video signal and encoded data representing graphic images is disclosed. The invention is particularly applicable for transmitting multilingual subtitles with a video program. The graphic images are rectangular regions within the active video area. They are transmitted in the form of bitmaps. The invention not only allows any character font or size to be displayed, but also the definition of e.g. a program provider's logo. The encoded data includes a time stamp to specify the time at which a subtitle is to be displayed. Preferred embodiments of the invention include the transmission of colour-look-up-table (CLUT) data and a compatibility code indicating a required minimum number of entries of said colour-look-up-table. For receivers with a CLUT having more entries than necessary, a map table is transmitted for mapping the pixel data width to the input width of the relevant CLUT. The method is applicable to Direct Video Broadcast systems wherein the video signal is MPEG2 encoded and the graphic images are accommodated in a private data stream of an MPEG2 Transport Stream." Speedplane (talk) 17:56, 14 July 2009 (UTC)
 * WO9619077
 * US6661467
 * PT745307
 * MX9603393
 * JP2008079325
 * http://v3.espacenet.com/publicationDetails/biblio?DB=EPODOC&adjacent=true&locale=en_V3&FT=D&date=20000115&CC=AT&NR=188327T&KC=T

Impact of MPEG LA patent portfolio remains unclear in article
It seems that many/most digital still cameras and video camcorders (among them professional models selling for $8000) use only a license for "personal use and non-commercial" purposes (likely mobile phones with cameras as well).

According to this is for instance problematic when showing a clip on a site together with advertisements (as on youtube, vimeo or on a private web site which also uses advertisements).--95.117.227.52 (talk) 14:23, 2 May 2010 (UTC)
 * Seems like a useful addition to the article. Go for it.  Jrincayc (talk) 02:58, 3 May 2010 (UTC)
 * I'm not that much into the topic and there seems to be more than one position about this . Not being familiar with the US legal system (or for that matter the legal system of the country I live in) and not being a native speaker I'm not going to add this to the article. Thanks for the encouragement though:) --95.117.202.214 (talk) 19:19, 5 May 2010 (UTC)

playing DVDs recorded in MPEG-2 on a PC
I have several pieces of software which normally play DVDs on my computer without problems. Recently I bought a DVD that does not play. Windows Media Player says that I have to purchase a plug-in to make the DVD play because it is MPEG-2. Does anyone have more information about this? —Preceding unsigned comment added by 72.89.74.153 (talk) 20:47, 8 September 2010 (UTC)

Not a word about Blu-Ray, nor HD-DVD ?
Interesting ;-P KSM-2501ZX, IP address:= 189.120.138.176 (talk) 19:26, 12 September 2010 (UTC)

Chronology
I was just reading here that "Silicon Philosophies - formerly Front Porch Video - engineered the world's first MPEG-2 encoder for Toshiba and Warner in 1996". I came to the article, not specifically to check on the accuracy of that, but to get a general idea of the development timeline. No joy. I note the section already has an expansion tag. Some fleshing out would be welcome. Wwwhatsup (talk) 11:57, 24 January 2013 (UTC)

Patent pool licenses.
The Patent pool section lists prices of $2-$2.50 and lists the year 2010. According to the official website the prices changed on 1 January 2016.

Quotes:

From January 1, 2016 forward, the royalty rate for MPEG-2 Decoding Products will be $0.50 per unit with right of voluntary termination on 30-days written notice, but Licensees may elect a royalty of $0.35 with right of voluntary termination on or after January 1, 2018 on 30-days written notice.

From January 1, 2016 forward, the royalty rate for MPEG-2 Encoding Products will be $0.50 per unit with right of voluntary termination on 30-days written notice, but Licensees may elect a royalty of $0.35 with right of voluntary termination on or after January 1, 2018 on 30-days written notice.

From January 1, 2016 forward, the royalty rate for Consumer Products will be $0.50 per codec with right of voluntary termination on 30-days written notice, but Licensees may elect a royalty of $0.35 with right of voluntary termination on or after January 1, 2018 on 30-days written notice.

Sjfeenstra (talk) 12:38, 3 June 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 5 external links on MPEG-2. 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 tag to http://jongyeob.com/moniwiki/pds/upload/13818-7.pdf
 * Added archive https://web.archive.org/web/20100408061828/http://mpeg.chiariglione.org/meetings/firenze/prfloren.htm to http://mpeg.chiariglione.org/meetings/firenze/prfloren.htm
 * Added archive https://web.archive.org/web/20080605162539/http://www.mpegla.com/m2/m2-patentlist.cfm to http://www.mpegla.com/m2/m2-patentlist.cfm
 * Added tag to http://www.audiompeg.com/us_patents.asp
 * Added archive https://web.archive.org/web/20080528022049/http://www.mpegla.com/m2/m2-att1.pdf to http://www.mpegla.com/m2/m2-att1.pdf
 * Added archive https://web.archive.org/web/20080309044041/http://www.shenick.com/pdfs/Testing_MPEG_IPTV_VOD_QOE.pdf to http://www.shenick.com/pdfs/Testing_MPEG_IPTV_VOD_QOE.pdf
 * Added archive https://web.archive.org/web/20111206012523/http://mpeg.chiariglione.org/mpeg_books.php to http://mpeg.chiariglione.org/mpeg_books.php

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

Cheers.— InternetArchiveBot  (Report bug) 00:03, 29 May 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 5 external links on MPEG-2. 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/20110519041216/http://www.itu.int/dms_pubrec/itu-t/rec/h/T-REC-H.222.0-200605-I!!SUM-HTM-E.htm to http://www.itu.int/dms_pubrec/itu-t/rec/h/T-REC-H.222.0-200605-I!!SUM-HTM-E.htm
 * Added archive https://web.archive.org/web/20100128120057/http://www.smpte-ra.org/mpegreg/mpeg.html to http://smpte-ra.org/mpegreg/mpeg.html
 * Added archive https://web.archive.org/web/20150208104604/http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm to http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm
 * Added archive https://web.archive.org/web/20111101083247/http://ride.chiariglione.org/MP2_development_part_A.php to http://ride.chiariglione.org/MP2_development_part_A.php
 * Added archive https://archive.is/20130102130545/http://www.audiompeg.com/ to http://www.audiompeg.com/

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

Cheers.— InternetArchiveBot  (Report bug) 19:09, 10 January 2018 (UTC)

Just a reminder about writing for non-experts - acronyms are cryptic
It would be nice if the acronym "MPEG" (Motion Pictures Experts Group) was defined as it is here the first time it appears in any article where it is mentioned. There seems to be only one of the major MPEG-related articles where this currently happens, and then only as a caption above the summary box on the right. Notice that the definition was not used in the second MPEG occurrence or this, the third MPEG occurrence.

This applies to any article using acronyms. They usually flummox the non-expert. Sometimes deliberately by self-flummoxed experts.

Acronyms:

the plural form of acronym; a word that apparently no one on the internet feels is worthy of being defined.

Miguel Bueno:"Brown Thunder, do you use acronyms as a part of speech. "

Brown Thunder: "OMG, Yes! #YOLO"
 * 1) acronym#yolo#lol#rofl#omg#omfg

What is the acronym for BAD?

Bad Ass Divas, Broken As Defined, Bald And Dangerous

Reference sources not formally cited to avoid markup complexity by Wikipedia non-expert:

thefreedictionary..., Urban Dictionary...