YouTube video encoding samples from 2011 and 2019 + MediaInfo (“Let's Drown - Super Mario 64”)
Video Item Preview
Share or Embed This Item
movies
YouTube video encoding samples from 2011 and 2019 + MediaInfo (“Let's Drown - Super Mario 64”)
- by
- iisthemoose
- Publication date
- 2008-12-12
- Topics
- HURGHT, Mario, Super Mario, N64, Super Mario 64, emulation, drown, Let's drown, gaming, games, video games, water, underwater, Nintendo, Nintendo 64
- Language
- English
The file
Video title: Let's Drown - Super Mario 64
Video URL: https://www.youtube.com/watch?v=UXCzeszG-I0
Let's Drown - Super Mario 64-UXCzeszG-I0.mkv
was downloaded in 2019 using youtube-dl
, the other three files in 2011 using RealPlayer.
Video title: Let's Drown - Super Mario 64
Video URL: https://www.youtube.com/watch?v=UXCzeszG-I0
MediaInfo (metadata):
General
Complete name : Let's Drown - Super Mario 64-480p.flv
Format : Flash Video
File size : 7.43 MiB
Duration : 1mn 28s
Overall bit rate : 707 Kbps
httphostheader : v17.lscache6.c.youtube.com
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 7
Duration : 1mn 27s
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (29970/1000) fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 10
Duration : 1mn 28s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Frame rate : 43.066 fps (1024 spf)
Compression mode : Lossy
General
Complete name : Let's Drown - Super Mario 64(HQ-HD!).mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/avc1/mp42)
File size : 22.3 MiB
Duration : 1mn 27s
Overall bit rate mode : Variable
Overall bit rate : 2 128 Kbps
Encoded date : UTC 2009-01-13 14:13:45
Tagged date : UTC 2009-01-13 14:13:45
gsst : 0
gstd : 88235
gssd : B4A7DD041HH1299604628550060
gshh : v1.cache3.c.youtube.com
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 27s
Bit rate : 1 999 Kbps
Maximum bit rate : 3 250 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.072
Stream size : 20.9 MiB (94%)
Title : (C) 2007 Google Inc. v08.13.2007.
Encoded date : UTC 2009-01-13 14:13:45
Tagged date : UTC 2009-01-13 14:13:45
Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1mn 27s
Bit rate mode : Variable
Bit rate : 125 Kbps
Maximum bit rate : 158 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Frame rate : 43.066 fps (1024 spf)
Compression mode : Lossy
Stream size : 1.31 MiB (6%)
Title : (C) 2007 Google Inc. v08.13.2007.
Encoded date : UTC 2009-01-13 14:13:45
Tagged date : UTC 2009-01-13 14:13:45
General
Complete name : Let's Drown - Super Mario 64.meta
File size : 1 010 Bytes
General
Unique ID : 214526542121000005243688622006921413755 (0xA1644F236253AD5B7668A41F801D447B)
Complete name : Let's Drown - Super Mario 64-UXCzeszG-I0.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 25.9 MiB
Duration : 1mn 27s
Overall bit rate : 2 471 Kbps
Writing application : Lavf56.40.101
Writing library : Lavf56.40.101 / Lavf56.40.101
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 27s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 155 r2901 7d0ff22
Default : Yes
Forced : No
Encoded date : UTC 2019-05-24 20:01:39
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
DURATION : 00:01:27.734000000
HANDLER_NAME : ISO Media file produced by Google Inc. Created on: 05/24/2019.
Audio
ID : 2
Format : Opus
Codec ID : A_OPUS
Duration : 1mn 27s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Language : English
Default : Yes
Forced : No
DURATION : 00:01:27.781000000
- Addeddate
- 2020-02-15 19:17:31
- Identifier
- YT2011-2019
- Scanner
- Internet Archive HTML5 Uploader 1.6.4
- Source
- YouTube
comment
Reviews
Reviewer:
iAmLifte
-
-
October 9, 2022
Subject: Analysis
Subject: Analysis
Some amateurs like to use this archive as proof YouTube is serving lower quality files than before. Here's my rebuttal:
3 files uploaded:
Let's Drown - Super Mario 64-480p.flv - 480p 30fps - Irrelevant to this analysis
Let's Drown - Super Mario 64(HQ-HD!).mp4 - 2009 720p 30fps
Let's Drown - Super Mario 64-UXCzeszG-I0.mkv - 2019 720p 60fps
First of all, most people seem to stop at using the embedded player in this page and switching back and forth between the videos to see the differences in quality. This is wrong. Archive.org is serving re-encoded files because the embedded player only plays mp4. It's re-encoding the 2019 mkv file, it's playing back the untouched 2009 mp4 file. When using the embedded player here, this gives the wrong impression that the 2019 file is worse quality - of course the re-encoded file will look worse. This is not the case as I will describe.
When looking at the actual files uploaded here, we have a 2009 mp4 file and a 2019 mkv file. Containers are irrelevant, they're both H.264 files. We're ignoring audio.
A little history:
YouTube rolled out 720p 30fps video on November 2008 (https://www.cnet.com/tech/services-and-software/youtube-videos-go-hd-with-a-simple-hack/)
YouTube rolled out 1080p 30fps video on November 2009. (https://www.cnet.com/tech/services-and-software/youtube-to-get-high-def-1080p-player/)
YouTube rolled out 720p/1080p 60fps video on 2014 (https://www.theverge.com/2014/10/29/7121143/youtube-adds-support-for-60fps-video-playback)
The 2019 file we have is a new 720p 60fps encode. Since YouTube was offering 720p 60fps since 2014, it's safe to assume there was a 2014 720p 60fps encode that was replaced, we don't have it here.
Analysis of files - 2009 vs 2019:
In terms of framerate, the 2009 file is 30fps, the 2019 file is 60fps. It's apparent the 2019 file is better because it has the higher framerate.
In terms of bitrate, the 2009 file is 1481kbps and the 2019 file is 2336kbps. It's apparent the 2019 file has better bitrate and is poised to have better quality.
In terms of visual comparison, it's apparent that the 2009 file is bitstarved and suffers from more visual artifacts, more ringing, more blocking. The 2019 file has much less of these issues.
Comparison 1: https://imgsli.com/MTI5MzY4
Comparison 2: https://imgsli.com/MTI5MzY5
Final:
2019 video in this archive is better quality than the 2009 video.
Extra:
Dates/years for the files were identified via metadata, they include the date that the file was either downloaded or created on YouTube's backend. It's possible the 2009 file is actually from late 2008 since that's when YouTube started rolling out 720p but I'm going by what the metadata says, possible the metadata date is simply referring to the date the file was downloaded from YouTube locally, not when it was encoded by YouTube.
I've identified that the 2019 file here is the itag format 298 that is currently being served in 2022. It's unknown which itag format the 2009 file is but we can assume with strong certainty that it's itag 22 since that's the itag first used to deliver 720p. YouTube still delivers an itag 22 file and it's still 720p 30fps but the encode is a different one than the 2009 file (currently being served a new encode also from 2019). I could do a comparison between the two itag 22 encodes, old and new, but that's not the point of my post.
VP9 Comparisons:
Comparison 2 Extra - 2019 H.264 vs 2019 VP9: https://imgsli.com/MTI5Mzcw
Comparison 2 Extra - 2009 H.264 vs 2019 VP9: https://imgsli.com/MTI5Mzcx
VP9 has its own set of issues but it seems generally better than the 2009 H.264.
It's apparent YouTube keeps the original uploaded files and they use that as the source to do their various encodes. This can be verified via Google Takeout, it should give you back the original uploaded file. YouTube claimed in 2007 that they were keeping the original files (https://www.cnet.com/tech/services-and-software/high-quality-youtube-videos-coming-soon/), we can assume they've kept pretty much everything since or even before that.
Why does YouTube make new encodes? Device compatibility and because codecs improve. Just like VP6 was superseeded, H.264 will be as well. YouTube keeps H.264 around mostly for compatibility but if you're on PC, most of the time you get served VP9 by default. Also, further tuning and refining of encoding settings can lead to improved video quality.
3 files uploaded:
Let's Drown - Super Mario 64-480p.flv - 480p 30fps - Irrelevant to this analysis
Let's Drown - Super Mario 64(HQ-HD!).mp4 - 2009 720p 30fps
Let's Drown - Super Mario 64-UXCzeszG-I0.mkv - 2019 720p 60fps
First of all, most people seem to stop at using the embedded player in this page and switching back and forth between the videos to see the differences in quality. This is wrong. Archive.org is serving re-encoded files because the embedded player only plays mp4. It's re-encoding the 2019 mkv file, it's playing back the untouched 2009 mp4 file. When using the embedded player here, this gives the wrong impression that the 2019 file is worse quality - of course the re-encoded file will look worse. This is not the case as I will describe.
When looking at the actual files uploaded here, we have a 2009 mp4 file and a 2019 mkv file. Containers are irrelevant, they're both H.264 files. We're ignoring audio.
A little history:
YouTube rolled out 720p 30fps video on November 2008 (https://www.cnet.com/tech/services-and-software/youtube-videos-go-hd-with-a-simple-hack/)
YouTube rolled out 1080p 30fps video on November 2009. (https://www.cnet.com/tech/services-and-software/youtube-to-get-high-def-1080p-player/)
YouTube rolled out 720p/1080p 60fps video on 2014 (https://www.theverge.com/2014/10/29/7121143/youtube-adds-support-for-60fps-video-playback)
The 2019 file we have is a new 720p 60fps encode. Since YouTube was offering 720p 60fps since 2014, it's safe to assume there was a 2014 720p 60fps encode that was replaced, we don't have it here.
Analysis of files - 2009 vs 2019:
In terms of framerate, the 2009 file is 30fps, the 2019 file is 60fps. It's apparent the 2019 file is better because it has the higher framerate.
In terms of bitrate, the 2009 file is 1481kbps and the 2019 file is 2336kbps. It's apparent the 2019 file has better bitrate and is poised to have better quality.
In terms of visual comparison, it's apparent that the 2009 file is bitstarved and suffers from more visual artifacts, more ringing, more blocking. The 2019 file has much less of these issues.
Comparison 1: https://imgsli.com/MTI5MzY4
Comparison 2: https://imgsli.com/MTI5MzY5
Final:
2019 video in this archive is better quality than the 2009 video.
Extra:
Dates/years for the files were identified via metadata, they include the date that the file was either downloaded or created on YouTube's backend. It's possible the 2009 file is actually from late 2008 since that's when YouTube started rolling out 720p but I'm going by what the metadata says, possible the metadata date is simply referring to the date the file was downloaded from YouTube locally, not when it was encoded by YouTube.
I've identified that the 2019 file here is the itag format 298 that is currently being served in 2022. It's unknown which itag format the 2009 file is but we can assume with strong certainty that it's itag 22 since that's the itag first used to deliver 720p. YouTube still delivers an itag 22 file and it's still 720p 30fps but the encode is a different one than the 2009 file (currently being served a new encode also from 2019). I could do a comparison between the two itag 22 encodes, old and new, but that's not the point of my post.
VP9 Comparisons:
Comparison 2 Extra - 2019 H.264 vs 2019 VP9: https://imgsli.com/MTI5Mzcw
Comparison 2 Extra - 2009 H.264 vs 2019 VP9: https://imgsli.com/MTI5Mzcx
VP9 has its own set of issues but it seems generally better than the 2009 H.264.
It's apparent YouTube keeps the original uploaded files and they use that as the source to do their various encodes. This can be verified via Google Takeout, it should give you back the original uploaded file. YouTube claimed in 2007 that they were keeping the original files (https://www.cnet.com/tech/services-and-software/high-quality-youtube-videos-coming-soon/), we can assume they've kept pretty much everything since or even before that.
Why does YouTube make new encodes? Device compatibility and because codecs improve. Just like VP6 was superseeded, H.264 will be as well. YouTube keeps H.264 around mostly for compatibility but if you're on PC, most of the time you get served VP9 by default. Also, further tuning and refining of encoding settings can lead to improved video quality.
1,040 Views
DOWNLOAD OPTIONS
IN COLLECTIONS
Community VideoUploaded by TechLord on