|
In AviSynth? Use TextSub. You'll pull your hair out trying to figure out how to do Unicode characters using Subtitle. The short answer is that I'm pretty sure the character encoding used by AviSynth is "whatever the OS default is" and I have no idea what that is these days. (I'm guessing it's still Win-1252, but you know - who knows.) You might be able to pass UTF-8 characters to Subtitle and it may or may not work depending on the exact version of Windows you're using. Because AviSynth is using the Windows GDI for text rendering under the hood, whether or not that works depends on the text APIs they're calling, and I honestly have no clue what would happen if you pass them UTF-8. My guess is that they'd treat it as being in the system default encoding, which is probably not UTF-8. The best thing is that what'll actually happen depends on the locale your OS is in. I have no idea if you can force the system default encoding to be UTF-8 under Windows and whether or not you'd even want to, because that could break other things. So in the end, the answer is "just use TextSub." Aegisub is designed to deal with Unicode, AviSynth is not.
|
#
¿
Oct 8, 2017 07:25
|
|
|
|
| # ¿ Apr 28, 2024 14:03 |
|
|
This is a USB wired headset, right? Unless the wire is being run past something generating interference, there really shouldn't be any interference being introduced unless the headset itself is dying. Because USB is digital, you should either get the full signal or just garbage, you shouldn't get an added buzzing sound. However, at some point, the digital signal has to become analog, and past that, you could get interference. If you're sure that the wire isn't running past anything (I've gotten buzzing sounds by having an analog cable run below a laptop before), then it's probably the headphones starting to die, as something that used to be shielded past the DAC isn't. It is obnoxiously common for digital headsets to be able to cause interference with themselves, especially as they throw more "smarts" into the headphones themselves. (I've found it most common with wireless headsets, though - Astro wireless headsets would "buzz" because the wireless receiver itself caused noise on the analog speaker lines.)
|
|
#
¿
Oct 18, 2017 14:38
|
|
|
ShadowPlay has always recorded at a variable frame rate. Your first video properties also show a variable frame rate. The only difference is the new "original frame rate" field and I have no idea what that is. When using ShadowPlay, you're always going to have to deal with variable frame rates. Exactly how to deal with that depends on what you're using to encode the video, but at best you got lucky before.
|
|
#
¿
Oct 30, 2017 23:57
|
|
|
There may be a solution. Supposedly FFMpegSource fixed this ages ago, but there used to be a bug with the way it parsed ShadowPlay videos which can be resolved using FFMpeg directly. The basic idea is to have FFMpeg fix the audio using its own audio sync filter, and then let FFMpegSource convert the variable frame rate to constant frame rate and dub the synced audio over it.
|
|
#
¿
Oct 31, 2017 07:39
|
|
|
I have no clue, but my guess is "maybe" depending on how long you intend to make the recordings. The problem is that a lot of cameras restrict recording to a maximum of 29 minutes so that they can avoid being taxed as a video camera. I tried to Google if the iPhone is one of them and no one seemed to be sure. The other issues appear to be heating (apparently some people have tried long recordings and had the iPhone overheat and disable the recording), free space, and battery life. Really you're going to have to make a test recording and see how it turns out. I can't seem to find an answer for how well the iPhone works in extended recording scenarios.
|
|
#
¿
Nov 2, 2017 20:22
|
|
|
You've been able to capture video off an iPhone for a while now - the previous method involved a Mac with QuickTime installed, though. (They had a feature intended for app developers to take videos of their app running. It does some cute things to the status bar for demo purposes, like hiding the carrier, showing the battery and signal strength as full, and making the clock read 9:41.) It's worth knowing about if you have a Mac sitting around because I think it's higher quality than the internal screen recording produces but I've never really compared the two methods.
|
|
#
¿
Nov 6, 2017 04:50
|
|
|
Adobe Premiere apparently doesn't support whatever color space the original was in, or is trying to convert it incorrectly. I'm not 100% sure if that's supposed to be 1 frame or 2 in Premiere but what you're seeing is how the frames are actually laid out in planar color spaces. I'm not sure what's up with the pink, but the green looks to be what YUV would be in grayscale: the large one is the luma plane (Y), and the remaining two small things below it are the chroma U and V planes. (They're half size because the human eye is better as seeing luma (brightness) than it is at seeing color (chroma) so you can use lower resolution chroma planes to save space.) You may have some option set somewhere that forces Premiere to treat video as a certain color space or something? It's a color space issue in any case.
|
|
#
¿
Jan 13, 2018 08:59
|
|
|
|
| # ¿ Apr 28, 2024 14:03 |
|
|
ufarn posted:I've actually never been able to figure out how to enforce this for AviSynth+ and the plugins manually, what's the right way to go about that, given that AviSynth+ just installs in Program Files (x86)? Can you switch back and forth between x86 and x64 for AviSynth and just use the relevant plugin folder? Pick one (I'd recommend 32-bit because a lot of codecs are still only 32-bit) and only install those. Windows requires programs be either 32-bit or 64-bit so you don't usually get both, so just pick one and stick with it. (Unless AviSynth+ comes with both versions for some reason, although I'm pretty sure Windows says to install to Program Files if that's the case. Anything in Program Files (x86) should be 32-bit, but I know there are installers that ignore that.) You can conceptually switch between 32-bit and 64-bit assuming you then use either a 32-bit program or 64-bit program to do the final encoding - but don't. Just pick one and only install AviSynth plugins of that bit size. ZiegeDame posted:I mean either resolution or frame-rate is bad and it causes weird slowdown in the game I'm playing in a way that OBS never has. Ideally I'm looking for a setup that can take advantage of the fact that I'm already encoding an image to stream to Twitch in order to use my CPU/GPU as efficiently as possible. Is such a thing even possible? Like, from a purely theoretical standpoint? Maybe. However, Discord uses WebRTC for its screensharing, and WebRTC requires the VP9 codec. Twitch on the other hand uses h.264.
|
|
#
¿
Mar 3, 2018 17:50
|
|