There seems to be an issue with this package of audio desyncs. I believe what might be causing this is the encode is encoding at a flat 60 or 50fps instead of the native framerate of the system. However it doesn’t adjust it for audio output as well, which can cause an audio desync.
Is there a way this can be fixed in the package?
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
"last" isn't strictly needed... Here's some code that automatically calculates the necessary zoom level:
Language: Avisynth
file_name = "video clip.avi"
AVISource(file_name)
i = Get_ZoomLevel(Height, 1)
PointResize(Width * i, Height * i)
function Get_ZoomLevel(int h, int i) {
# 720 lines enables Youtube's HD mode
(h * i >= 720) ? i : Get_ZoomLevel(h, i * 2)
}
That script gives a 8x upscale to Game Boy encodes, which is way excessive for getting the YouTube 720p Edit: nevermind, it's actually optimal as it is.
Have you done a size comparison on encodes using i*2 vs i+1?
I did. Read the bottom of my post.
Edit: well, I guess you were referring to file size. In that case, it's proportional to the height difference, which depends on platform original resolution. A GB encode gets about 60% smaller, but for GBA there is no difference, as both script versions give a height of 960 for GBA (240 * 4).
Edit: I didn't do a test yet, though. I'll give you actual data later.
There you go. The first one is the result of using i * 2, and the second one is the result of using i + 1. Data comes from MediaInfo Lite. The results are pretty much what I expected: a filesize directly relative with the change in video resolution.
Edit: ok, I think there is something wrong. I have no idea why, but it seems the results are the other way around.
Edit 2: and this is why I'm not an encoder. Someone please grue this.
The results are the other way around because of how h264 stores data - upscaling by powers of 2 will compress better because each block would then be solidly uniform (because then every block maps to exactly one pixel), while for not-powers-of-two you have blocks of information containing chroma/luma for more than one source pixel. Solidly uniform data compresses well because you can just say "foo x 32" instead of "foo x 13, bar x 1, foo x 18"
The upshot of all this is that it's simply more efficient to upscale GBx footage to 8x (smaller filesize = shorter upload/download time and less bandwidth used)
For the sake of temporary encoding, I highly suggest using Lagarith. It's fast and lossless while keeping the initial AVI's filesize reasonable.
There's also the ZMBV codec which is included in DOSBox and shows up in BizHawk as "Zipped Motion Block Video". It records only the changes from one frame to the next, saving some space, which in the end may be faster.
Samsara wrote:
Language: AviSynth
AVISource("(your video file)")
PointResize(last.width * 8,last.height * 8)
"last" isn't strictly needed... Here's some code that automatically calculates the necessary zoom level:
Language: Avisynth
file_name = "video clip.avi"
AVISource(file_name)
i = Get_ZoomLevel(Height, 1)
PointResize(Width * i, Height * i)
function Get_ZoomLevel(int h, int i) {
# 720 lines enables Youtube's HD mode
(h * i >= 720) ? i : Get_ZoomLevel(h, i * 2)
}
Samsara wrote:
PointResize, to put it simply, resizes your video. There are many resizing filters available in AviSynth, but you'll almost always want to use PointResize for your TAS temp encodes. Anything sprite-based with clearly defined pixels will benefit more greatly from PointResize, which is... well, 90% of the content on this site.
If the video is from a TV-based system then "BilinearResize(960, 720)" might look better.
Just to make sure,Is this the right formula? Can I still use MeGUI or should I just stick with AVISynth?
Yes, it's the right formula... the only change is that YT doesn't call 720p "HD" any more.
MeGUI might use Avisynth internally? It's been years since I used it.
Regarding the other thread: you can use x264vfw for VirtualDub. Just know that by using VirtualDub you no longer have a completely automatic encoding process.
Guys, i all these settings is amazing to encode in hd
But i want the screen in 1 to make a nes tas hd videos
i mean is only top, and top and bottom not top and top and bottom
Please if anyone can to do this contact me or re:answer for this post
Guys, i all these settings is amazing to encode in hd
But i want the screen in 1 to make a nes tas hd videos
i mean is only top, and top and bottom not top and top and bottom
Please if anyone can to do this contact me or re:answer for this topic
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
> NES
> Top no Bottom
> NES
So... did you mean DS? Like your other post?
Only that instead you actually want a single screen, and no alternatives?
And even though it's a bit outdated (need to fix it) the second post directly under Samsara's setup is how to get top on its own.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
