Posted: 6/14/2016 5:22 PM
(Edited: 6/26/2016 4:41 PM)
Post subject: yt:stretch=4:3 got nuked by youtube
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
https://support.google.com/youtube/answer/146402?hl=en
Some shithead wrote:
This feature is not available for videos uploaded after June 2016.
We'll be doing aspect ratio correction for HD encodes ourselves again, like we've been doing until 2012. The problem is, upscaling x8 gives the smallest filesize of all upscalers for a video like 320x240. Not having integer scaling factors will cost us a huge boost in filesizes. So we'll need to figure out the new target resolution now for anything that requires aspect correction. Arcades, handhelds, N64 and probably some others are okay though. PS: Most of the June's encodes were fine, it all started with Amy https://www.youtube.com/watch?v=OA7riw_jIEQ https://www.youtube.com/watch?v=IsE_LOHuSg8 And then Eek! https://www.youtube.com/watch?v=VAD_ht35hyA So we'll have to reencode them. EDIT: Replace this line (#98 in TASEncodingPackage, #109 in TASEncodingPackage2) in the encoding script 
Language: avisynth
c = handheld ? b : (hd ? b : b.LanczosResize(width, height, taps=2))
with 
Language: avisynth
c = handheld ? b : b.LanczosResize(width, height, taps=2)
If you don't want to be upscaling using the usual factor 8, which generates insane overhead in file size and encoding speed due to aspect ratio correction, you can use the following formula, that we were using back then, for anything that's not 4:3 (line 51 in TEP, 71 in TEP2). 
Language: avisynth
factor = hd ? \
	(handheld == false) ? \
		(last.height >= 540) ? 2 : \
		(last.height >= 270) ? 4 : \
		(last.height >= 180) ? 6 : \
	8 : \
		(last.height >= 1440) ? 1 : \
		(last.height >=  720) ? 2 : \
		(last.height >=  360) ? 4 : \
	8 : 1
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 6/15/2016 4:03 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Well that sucks. Thanks YouTube for removing a feature that didn't need to be removed!
Posted: 6/15/2016 4:15 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Usually aspect ratio corrected encodes were small resolution anyway, so still using point upscaling to an HD size with correct aspect ratio shouldn't look too bad. The only part you need to be careful on is dealing with Luma and Chroma upscale making sure they line up with Chroma being 1/4th the resolution. To do that, I think you would need to point upsacle Luma twice. Once to both Luma and Chroma to a resolution 1/4th your target final resolution, then another upscale on Luma only to the target resolution.
Posted: 6/15/2016 4:33 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Let's take your common NES/SNES resolution of 256x224. Regular 8x in each direction would give you 2048x1792. Keeping vertical resolution would give me a resolution of 2389.333333333333x1792 aspect ratio corrected. Since YUV 4:2:0 in AviSynth requires the resolution be divisible by 4, the closest resolution would be 2388x1792. Going by what I said, with Luma being resized twice, you would first resize the RGB to 1/4 of 2388x1792, which is 1194x896: 
Language: avisynth
AVISource("ExampleClip.avi")
chroma = PointResize(1194, 896)
Then resize Luma a second time: 
Language: avisynth
luma = chroma.PointResize(2388, 1792)
Finally combine the Luma and Chroma: 
Language: avisynth
luma = luma.ConvertToYV24(matrix="Rec709", chromaresample="point")
chroma = chroma.ConvertToYV24(matrix="Rec709", chromaresample="point")
last = MergeChroma(luma, chroma)
I should note that I've not tested this, but this should work in theory.
Posted: 6/15/2016 4:39 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Aktan: can you do a comparison that proves that what we used to do before 2012 was worse than your suggestion? We were using the factor 6 for 224p, and even back then I couldn't see a single artifact in the HD encode (before uploading of course).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 6/15/2016 4:48 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
I actually don't remember what we did back then. Do you have the exact script?
Posted: 6/15/2016 4:53 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Yes. http://tasvideos.org/wiki.exe?page=EncodingGuide/HighDefinition&rev=70#ExampleScript
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 6/15/2016 4:53 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Well I went ahead and tried it, and things didn't go so well, lol. Here is the revised version: 
Language: avisynth
AVISource("ExampleClip.avi")
PointResize(1194, 896)
PointResize(2388, 1792)
ConvertToYV24(matrix="Rec709", chromaresample="point")
ConvertToYV12(matrix="Rec709", chromaresample="point")
Still two resizes, but the difference is that chroma is now being upscaled, then downscaled via point resize, so it should be the same.
Posted: 6/15/2016 4:55 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
feos wrote:
Yes. http://tasvideos.org/wiki.exe?page=EncodingGuide/HighDefinition&rev=70#ExampleScript
Mind doing the work of simplifying it for me to compare easier? =p Edit: Never mind, I figured it out. Edit 2: I've compared, and yep, the older way is better. I forgot there are resolutions that would be perfect for 4:3.
Posted: 11/10/2016 10:22 PM
Quote
Masterjun
He/Him
Site Developer, Skilled player (1987)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Exotic platforms TAS of 2020 Speedy TAS of 2018 PC TAS of 2018 Glitchy TAS of 2015 TASer of 2014 SNES TASer of 2014 TAS of 2014 SNES TAS of 2014 Funny TAS of 2014 Glitchy TAS of 2014 TASer of 2013 SNES TASer of 2013 NES TAS of 2013 SNES TAS of 2012 Funny TAS of 2012
Just for reference: It seems like the reason YouTube disabled the stretch feature was in preperation for the end screen feature, which itself was implemented for a way to interact with the video for mobile viewers.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Posted: 11/10/2016 11:07 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Nice. "Our cinema doesn't have chairs. Try eating an extra ice-cream instead." Fucking code monkeys.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.