Damn I forgot to mention. To properly see the source footage in the OP post (and btw maybe the YT streams too) one needs to set the monitor to 60 Hz!!! At 75 or whatever else it will not ever show 60 fps video correctly. Uh, can you guys all try that?
As I figured, this doesn't change it much. I still see source/60FPS YT as fast blinking while deblink is pure transparent. I should note that most LCD displays nowadays is running at 60 Hz anyway, but I'm on CRT running at 100 Hz.
This does bring another thought as to why you see the source as "transparent". Slow LCD with slow response time has ghosting effects which may blur the fast flicker into looking like "transparent". This may be it all this time.
Moar Testing
----
Debian Jessie (same hardware as prex tests)
Google Chrome Version 40.0.2214.45 beta (64-bit) has considerably more flicker on the 60fps YouTube encode compared to when I watched in Windows, and I seem to be falling back to 30 fps more than I should be.
Iceweasel didn't even allow me to go above 360p.
----
Windows 7 on the alternate machine - there's not enough CPU processing space to watch consistently on YouTube at 60 fps, which leads me to believe it's largely made possible by dedicated GPUs. (The alternate machine is a laptop that doesn't have a dedicated GPU, while the desktop I've been testing on before has something resembling a GPU. I still need to crack it open and see exactly what hardware I've been working with for about 2 years now). The AVI Files play back just fine.
On Mac OS X, with Firefox Samus blinks both on 360p and 720p. I don't understand why it works differently in Windows.
With Chrome the sprite blinks in 360p in the same way, and in 720p60 it blinks significantly faster, and all movement is visibly smoother (which isn't surprising; in other words, the 60Hz version is working as it should).
This sounds about right; the current position is that YouTube only supports 60fps in Chrome. That someone reported it working in IE is unusual given the fact that Google and Microsoft are supposed to be competitors on that front and 60fps YouTube is a fairly recent thing. I'll test my desktop in Debian Jessie here momentarily as well as the alternate machine I've got here.
Windows 8.1 Stock IE11
{image of it apparently working}
Can you post an image of your About Internet Explorer box, like this?
I have IE11 as well but don't get the 60fps options. If it's just due to a difference between Windows versions then that's a thing that needs to be accounted for.
Alrighty then, works in the older version but not the newer version.
I can't get a 60fps option in IE regardless of whether or not I'm in HTML5 mode. I want to say it's because of OS differences but I can't be sure without either someone with Win8.1 and the most recent IE saying if they can get 60 fps or not or exileut upgrading and reporting if it breaks or not. And I don't want to ask exileut to upgrade IE versions because (1) it may break and (2) apparently they're actively avoiding upgrading IE for reasons.
Alrighty then, works in the older version but not the newer version.
I can't get a 60fps option in IE regardless of whether or not I'm in HTML5 mode. I want to say it's because of OS differences but I can't be sure without either someone with Win8.1 and the most recent IE saying if they can get 60 fps or not or exileut upgrading and reporting if it breaks or not. And I don't want to ask exileut to upgrade IE versions because (1) it may break and (2) apparently they're actively avoiding upgrading IE for reasons.
Alrighty then, works in the older version but not the newer version.
I can't get a 60fps option in IE regardless of whether or not I'm in HTML5 mode. I want to say it's because of OS differences but I can't be sure without either someone with Win8.1 and the most recent IE saying if they can get 60 fps or not or exileut upgrading and reporting if it breaks or not. And I don't want to ask exileut to upgrade IE versions because (1) it may break and (2) apparently they're actively avoiding upgrading IE for reasons.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
Additionally to YouTube, I thought it's a good opportunity to check how G-Sync behaves. So here is what I've got (Samus blinking test; MPC-HC x64 from K-Lite Codec Pack Mega):
Lossless footage:
120 Hz + VSync is almost perfect (there were a couple of "late" frames, but due to 120 Hz they are almost invisible);
120 Hz no VSync is a bit worse due to there being more "late" frames;
60 Hz + VSync is worse (the "late" frames are really visible and there were a bunch of them;
60 Hz no VSync is almost perfect, there were only two "late" frames, but this is still worse than 120 Hz + VSync due to the "late" frames being much more visible;
G-Sync actually turned out to look the worst of everything (including YouTube) for some reason, I didn't expect that.
So the flow goes like this: 120 Hz + VSync > 60 Hz no VSync > 120 Hz no VSync > 60 Hz VSync > G-Sync.
YouTube:
120 Hz - many "late" frames;
60 Hz - nearly perfect.
Once again, G-Sync for some reason turned out to be the worst of all although it should've given a perfect footage(?). And 120 Hz + VSync on the lossless footage turned out to be the best of all for me.
Once again, G-Sync for some reason turned out to be the worst of all although it should've given a perfect footage(?). And 120 Hz + VSync on the lossless footage turned out to be the best of all for me.
To be honest, I don't know what G-Sync is. My current impression is that it's another way of encoding the footage. If that's the case, you'd probably want to compare the G-Sync version with direct emulator playback as opposed to the comparison files presented in the OP.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Lossless dumps are exact copies of what you see in an emulator.
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.
Once again, G-Sync for some reason turned out to be the worst of all although it should've given a perfect footage(?). And 120 Hz + VSync on the lossless footage turned out to be the best of all for me.
To be honest, I don't know what G-Sync is. My current impression is that it's another way of encoding the footage. If that's the case, you'd probably want to compare the G-Sync version with direct emulator playback as opposed to the comparison files presented in the OP.
You know, with the power of the internet, it's just one search away. Basically a (proprietary, grr) technology, where the GPU adapts the monitor refresh rate to its rendering rate.
All syllogisms have three parts, therefore this is not a syllogism.
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
I believe YouTube is VSynced by default (not to mention windowed applications are VSynced by Windows no matter what, and fullscreen flash players are usually windowed borderless), but for <something> + VSync I was referring to the video player's option to enable or disable VSync.
G-Sync is NVidia's resent technology that is supposed to refresh the monitor as soon as a frame is ready and not on a fixed timestamp, and it seems to work well in games, so perhaps it's just the video player not playing well with it?
Looks more true to console+TV (even more so than SD encodes).
Wider compatibility. Can be viewed by everyone incapable of using proper 60 fps youtube feature (looks deblinked when falling back to 30 fps too).
Benefits from full fps alone:
Saves publishers encoding/uploading time.
Doesn't have artifacts caused by wrong masking algorithm.
Note 1: I didn't test it all on Windows 7, maybe it'd work better there.
Note 2: Youtube does work for 59 fps too: http://www.youtube.com/watch?v=ywpeh-STXcY
Note 3: Not only games rely on alternate frame flickering, some systems use it to compensate for sprite limit, making all objects per scanline that overcome it blink every frame, and even "worse" - TASers abuse it too, some runs would look weird without accounting for alternate frame flickering. So my personal choice would be "default to full fps+deblink unless you're sure it's not needed".
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.
Deblinking here refers to the process of taking a 60 fps input and translating it into a 30 fps video output where transparency or blinking is preserved. Otherwise, since blinking typically means alternating between full opacity and completely invisible every other frame, the result is that, taking metroid as an example, either samus isn't blinking at all or can't be seen.
Remember that unless viewing with a 60 fps capable browser, you will see the result as a 30 fps video. I believe youtube just throws away half the frames, resulting in this ugly behavior. Deblinking is supposed to fix this so that youtube does not have to change the fps.
In native 60fps the video with no deblinking is clearly best. I think a better question is: Which one do you prefer if you are limited to watching in 30fps?
I turned html5 off to test this in IE11.
Full FPS encode:
I still see blinking when Samus takes damage and when arm pumping. There are times when Samus is invisible for a few frames in a row, and times when she is solid. The elevator looks the worst. It is not consistent. So however youtube cuts 60fps down to 30fps, it is not exactly every other frame of the source.
Deblinked encode:
It is much more clear exactly where Samus is all the time. There are artifacts around the sprite. Samus is blurry when running at full speed. Riding the elevator looks much better.
Do I think the deblinked version looks better at 30fps? Yes.
Do I think the deblinked version looks better at 60fps? No.
I understand the deblinking is a backwards compatibility compromise. It makes encodes look better for 30fps viewers(probably the majority) and worse for 60fps viewers.
If this is what it takes to start making more 60fps encodes, I am all for it.
Note 3: Not only games rely on alternate frame flickering, some systems use it to compensate for sprite limit, making all objects per scanline that overcome it blink every frame, and even "worse" - TASers abuse it too, some runs would look weird without accounting for alternate frame flickering. So my personal choice would be "default to full fps+deblink unless you're sure it's not needed".
Agreed.
Imo other games look better with 60fps deblink as well, like SM. While arm pumping does look worse, replacing fake transparency with actual transparency when Samus is taking damage or on the elevator looks much better.
On the other hand S3K's bosses look somewhat worse when taking damage because they are changing their color palette every other frame instead of disappearing every other frame
Either way, it's a great compromise, and I look forward to seeing 60fps encodes (other than Yoshi's Island) on tvc :D
(Once Firefox updates... grumble grumble)
Imo other games look better with 60fps deblink as well, like SM. While arm pumping does look worse, replacing fake transparency with actual transparency when Samus is taking damage or on the elevator looks much better.
I think the right word for this would be translucency. Transparency would be when Samus is completely invisible. (Yeah I used it like that, too.)
/OT
Imo other games look better with 60fps deblink as well, like SM. While arm pumping does look worse, replacing fake transparency with actual transparency when Samus is taking damage or on the elevator looks much better.
I think the right word for this would be translucency. Transparency would be when Samus is completely invisible. (Yeah I used it like that, too.)
/OT
In scenes with just motion, you should be taking every other frame. 0101
In scenes with just blinking, you should be taking 2 of 4. 0011 (or 3 of 6. 001011)
The problem comes when there is both. Since every other loses the blinking, while uneven patterns stutter the motion.
Deblink attempts to separate the two, so the motion can be smooth while keeping the blinking.
My concern is how youtube is doing the 60->30fps decimation.
If it just blindly applies 001011 to the whole thing any time it detects any blinking, then motion is going to suffer even in places where there is no blinking.
I have IE11 as well but don't get the 60fps options. If it's just due to a difference between Windows versions then that's a thing that needs to be accounted for.
