|
zfleeman posted:Your resolution is really high at a really low bitrate for recording. Keep your encoder at 'veryfast' and up the bitrate to... 20000? 15000? I'm not sure what will look good at that resolution, but I do 20000 bitrate at 1080p for x264. Consider rescaling to 1080p. 25000 bitrate and rescaling to 1080p works like a dream. Thanks. I have literally no concept of what bitrate does or anything so I just used the default for ages.
|
![]() |
|
![]()
|
# ? Jun 6, 2024 04:53 |
|
More bits!
|
![]() |
|
zfleeman posted:More bits! This is something you should be saying while you stream on twitch.
|
![]() |
|
Natural 20 posted:I have literally no concept of what bitrate does or anything so I just used the default for ages. Quick and dirty explainer time! A "bit" is a binary digit, a 0 or a 1. It's handy for storing information in an electronic medium because you can represent the values with "on" and "off" in a circuit, but a single bit can only store one of two values. To store complex stuff like meaningful numbers, documents, pictures, or videos, you need to combine multiple bits into a single value. Two bits can represent four values: 00, 01, 10, and 11. The number of values increases exponentially with the number of bits used - 8 bits can store 256 distinct values, 32 bits gets you into the billions, and 64 bits cover more than the expected number of seconds in the lifespan of the universe. Of course, the bits alone are pretty meaningless until you assign some significance to them. Obviously, each pattern of bits is a binary representation of a number (and you can encode negative numbers in a variety of ways), but then you have encodings like ASCII or Unicode that assign each numerical value a character or symbol, so that you can turn text into bits. Graphical data, for the most part, is split into pixels, and each pixel will be represented by a number to indicate its color. There are lots of ways to do that, but I'm going to stick with RGB24, which assigns 24 bits to each pixel - 8 bits for the amount of red, 8 bits for the green, and 8 bits for the blue. A graphic file will also have a header to describe features of the image such as its dimensions, so that the graphics driver can assemble the pixels correctly into the image. Video data, setting aside the audio portion, is a series of images, plus information like frame rate, dimensions, which color scheme it's encoded in, and so on. The video portion of the file is a gigantic string of bits that are split up into frames, each of which is a string of pixels, each of which is a string of bits. You really get to appreciate the power of graphics processors when you consider how rapidly they can read such a file and convert it into the video you see on your screen. But just how many bits are there in a video? Let's say it's a 1920x1080 video with RGB24 pixels and 30 frames per second. Without compression, that's 1920x1080x24x30 bits per second, or 1,492,992,000 bits per second. Fortunately, video encoders do things like store only part of some frames, or combine two pixels into fewer bits, to cut down on the size needed to store the video. But there's only so much you can decrease the size of a file before you start to lose some of the data. The fewer bits you have available, the fewer distinct files you can possibly store. Try to reduce the size too much, and the encoder can't possibly keep all of the detail in each frame. However, encoders have algorithms that try to determine, based on the content of the frames, which data will be least harmful to lose in representing the video. Pixels that don't change for a long time, or change to values that are very close to the previous values, won't affect the final product as much if they're skipped over for a frame or two, while if the whole image is changing rapidly, it's going to take a lot of bits to keep up. So going a bit below the minimum for lossless encoding might not be noticeable, but the fewer bits you make available, the worse the video will look. That's what the bit rate is - how many bits you make available per unit of video, usually seconds - and why it's important to how your videos look, as well as why different values are appropriate for different videos. But, as has been said, the more bits, the better it will look, until you hit the bit rate for uncompressed video. Nidoking fucked around with this message at 00:12 on Jun 13, 2019 |
![]() |
|
Nidoking posted:Quick and dirty explainer time! Is the rate that you choose to use largely experimental then? What's to stop me setting the rate to the maximum possible and just not caring apart from filesize?
|
![]() |
|
Nothing’s stopping you, but you’ll long have missed the point of diminishing returns. Its a waste of hard drive space and it’ll take forever to upload if you max out your bit sliders. Plus, youtube reencodes your video anyway so the world will only see up to a certain bitrate.
|
![]() |
|
Natural 20 posted:Is the rate that you choose to use largely experimental then? What's to stop me setting the rate to the maximum possible and just not caring apart from filesize? It's largely experimental, yeah. The necessary bitrate to get good-quality video depends on a ton of factors, including things like how similar each frame is to the next (not very similar in your case), what colors you have and how many of them there are, how sharp the lines are, etc. It's kind of like the PNG vs. JPG decision for screenshot LPs.
|
![]() |
Since you're using x264 for the encoder setting, you can also change the Rate Control setting to CRF mode instead of CBR. CBR = Constant Bit Rate CRF = Constant Rate Factor In CRF mode you don't tell the encoder how many bits it is allowed to use per second, but instead you give it a "rate factor", which is basically a number indicating how much quality you're willing to sacrifice. Lower rate factor = better quality, higher rate factor = worse quality. The actual bitrate of the video will be incidental to the rate factor you select, and will be variable such that sections of with lots of motion will be given more bits than sections with little motion. CRF 0 is specified to be true lossless encoding, i.e. decoding it will result in pixel-by-pixel the exact same as the input, but it's also very slow to process. Not all decoders are able to decode lossless H.264 video either. Other than that, CRF 1 to 8 are extremely high quality, 9 to 16 are very high quality, 17 to 24 are medium-high quality, and above that gets into the bad quality territory. You'll also need to experiment with CRF settings to find one that fits your needs, but the advantage of using CRF instead of CBR is that the quality will be approximately constant across the entire video.
|
|
![]() |
|
I need a replacement for my outdated MP4Box plugin for MeGUI. What should I be looking for to encode MP4 or MKV files? EDIT: Apparently it fixed itself when I tried to uncheck that from the things that update. Stabbey_the_Clown fucked around with this message at 03:54 on Jun 15, 2019 |
![]() |
|
Stabbey_the_Clown posted:I need a replacement for my outdated MP4Box plugin for MeGUI. What should I be looking for to encode MP4 or MKV files? I've just been using the mkvmerge in MeGUI and haven't had any problems.
|
![]() |
|
I've been using Dxtory with Desmume to record my footage for some DS games, but the resulting test videos I took don't look too good. https://www.youtube.com/watch?v=bx5YEmMmM2U This one, for instance, has a lot of screen flickering. https://www.youtube.com/watch?v=YUVRAOdw66Y And this one had the audio and opening video desync to the point where the title theme ended before the opening video did. I was also curious if it was at all possible to only record the top screen rather than both. Or if someone could help me record it in a way that looks fancy, like so: https://www.youtube.com/watch?v=3CMoH-7CquI Blueberry Pancakes fucked around with this message at 21:14 on Jun 16, 2019 |
![]() |
|
Blueberry Pancakes posted:I've been using Dxtory with Desmume to record my footage for some DS games, but the resulting test videos I took don't look too good.
|
![]() |
|
I tried in-game recording and the top screen went black and stopped showing anything. I'm wondering if I might need to use a different DS emulator.
|
![]() |
|
Hey, I suspect the answer to this question is "you need better hardware," but in case there's an intermediate step I can take... I just had to kill a video LP because I tried recording at 1080p, and while the gameplay was fine, the recording got super choppy and I ended up with a bunch of unusable footage. And I was stupid enough to only test the first few minutes when I thought I had it handled, but the type of footage in the first few minutes is different from what was causing the problems in the first place. I went from this 720p-but-smooth video: https://www.youtube.com/watch?v=_LAQwMwApjY To this 1080p-but-stuttering and unwatchable video: https://www.youtube.com/watch?v=TjANl_9gu-Q Skip to about the 10 minute mark in each; my critical mistake was not realizing that the in-combat stuff of XCOM is more taxing than just the geoscape stuff, so things that look fine at the beginning really start to chug once the game is in combat and showing various effects on-screen. I was using OBS to record, and the only setting I really changed video-wise was recording resolution which got turned all the way up. I don't see any OBS stuff in the OP, so I guess what I'm asking: 1.) Is there another video editor that will have an easier time capturing footage at 1080p? Or is this simply just an issue with "my computer is from 2011 and it's limited in what it can do?" 2.) Are there other things I can do that might get resolution up but not make things unwatchable, whether in OBS or otherwise? I'm willing to restart the LP, but I don't want to do so until I know I have the video as best as is currently capable. (Not going to buy a new machine to do an LP, though!) e: duh, of course specs and encoder settings are important. Will get that in tonight. PC specs ![]() Have not changed any of this since I bought it. Recording settings: What seems to work: Base resolution: 1920x1080 Output resolution: 1280x720 Downscale filter: 16 samples FPS: 30 What I was trying: 1920x1080 for both 32 samples FPS 60 Other stuff: Renderer: Direct3d11 Color format: NV12 YUV Color Space, Range: 601 and partial respectively FairGame fucked around with this message at 21:41 on Jun 21, 2019 |
![]() |
Well what are your PC specs, and what are your encoder settings in OBS?
|
|
![]() |
|
Oddly enough, the problem seems to have resolved itself somehow. ![]() The next time I took videos with OBS everything came out perfect. https://www.youtube.com/watch?v=ISxVXifGqP4
|
![]() |
|
I'm having a similar problem to FairGame, in that I've been banging my head against OBS for days trying to get a recording that isn't choppy but also doesn't look like rear end. At this point I'd like to know if I'm wasting my time with the setup I have. If not, what settings will give me something decent? -Processor: AMD Ryzen 5 2600X -RAM: 16 GB -Graphics: Radeon RX 570 144 HZ refresh monitor Recording onto my SSD Trying to record Pathologic 2. Not the most graphically intensive game, but I've tried lowering the graphics settings with limited success. The gameplay itself looks fine on my end, but the recordings keep getting choppy and throwing out encoder overload errors. Yes, I have played around a lot with the OBS settings, but I can't seem to strike any kind of balance between quality and speed. I'm totally new at this so I would really appreciate any protips.
|
![]() |
|
I would second nielsim's question: Codec, bitrate, size and framerate are more important. Are both of you using h264? I've found that to be very crisp but also very inconsistent re: dropped frames doing single-system recording due to CPU load. NVENC isn't really an option on a Radeon card, and uses a pretty gnarly color compression unless you crank like a 9k bitrate at 1080p60, but is buttery smooth. I once did a workflow with a Lagarith codec that was GPU agnostic that looked GREAT, but if you're recording to the SSD you're playing on then that file size is probably unworkable--it was unwieldy enough recording to a 3TB drive ![]()
|
![]() |
|
FairGame posted:1.) Is there another video editor that will have an easier time capturing footage at 1080p? Or is this simply just an issue with "my computer is from 2011 and it's limited in what it can do?" The choppiness is present in the beginning section of the video as well, it's just that with limited panning/movement it doesn't stand out so much. Your problem is mostly "computer old", but I noticed that your high res choppy video was also 60 fps, dropping that to 30, which xcom won't suffer for, may fix all your problems. If you're desperate to put out 60fps video you can try bumping the cpu usage preset up a notch(in the settings faster means less cpu intensive), and if that doesn't do it then you can check your OBS settings and see if you have the option to use intel quicksync, which will use the hardware encoder built into your CPU's integrated graphics chip. You might have to crank up the bitrate more than you normally would in order to get something usable. If it's not in the list of encoders you may have to jump through some hoops to get it going. Klingon w Bowl Cut posted:I'm having a similar problem to FairGame, in that I've been banging my head against OBS for days trying to get a recording that isn't choppy but also doesn't look like rear end. At this point I'd like to know if I'm wasting my time with the setup I have. If not, what settings will give me something decent? If you've been playing around with OBS without knowing what you're doing then for every one thing you had tinkered with that might have helped you may have changed two more things that have undone any gains. You mentioned a 144hz monitor, have you done anything wacky like changing the fps settings in OBS to 144hz to match the monitor? If you're trying to get it to do 144fps video in real time it might explain the problem?
|
![]() |
|
Thank you. I really have no idea what I’m doing, so I appreciate the specific suggestions. It may well be just “computer old,” but I’m glad you’re helping me with the opportunity to try.
|
![]() |
|
Willie Tomg posted:I would second nielsim's question: Codec, bitrate, size and framerate are more important. lohli posted:If you've been playing around with OBS without knowing what you're doing then for every one thing you had tinkered with that might have helped you may have changed two more things that have undone any gains. That makes me think though. I had Vsync on in the game, do you think that could be an issue?
|
![]() |
Klingon w Bowl Cut posted:Bitrate I've moved between 1000kbps and 2500kbps. Framerate I've tried 30fps and 60fps. I haven't tried any of the advanced output mode stuff. Stick to 30 fps for now, try 60 if it's not smooth enough. Those bitrates are way too low, try around 10 times that.
|
|
![]() |
|
nielsm posted:Stick to 30 fps for now, try 60 if it's not smooth enough.
|
![]() |
|
I just now realized I had my microphone set to duck when desktop audio peaked instead of vice versa. It's never a smart mistake ![]()
|
![]() |
|
Hey, so I'm trying to encode subtitles (.rear end) for a youtube upload, but when I did so in Avidemux, the subs were all offset like 2 frames too early. When I watch in vlc with the external subs it looks fine. Does anyone know how I can fix this in the program or should I just figure out how to do it in Avisynth?
|
![]() |
Adding .rear end subtitles in Avisynth is stupidly easy so definitely try that.code:
|
|
![]() |
|
Is there a best setup known (bitrate, cpu preset, etc) for Streamlabs OBS for my system? Rocking an i9-9900k @ 5ghz and RTX 2080ti because I hate money and wish I had less of it. Internet speed specced at 300/20, actually tested at 350/25. Deviant fucked around with this message at 14:35 on Jun 24, 2019 |
![]() |
|
Deviant posted:Is there a best setup known (bitrate, cpu preset, etc) for Streamlabs OBS for my system? Rocking an i9-9900k @ 5ghz and RTX 2080ti because I hate money and wish I had less of it. With that setup your possible pinch point isn't going to be your system, but inconsistent service rather than max throughput. Streamers dropping frames and calling Time Warner/Cox Cable everything but children of god as they see what they can trim down in their bitrates while resetting their router is a very fun aesthetic. If your ISP is good, then count your blessings and disregard all that. If you're streaming to twitch, 6-7000 kbps should be pretty graceful for 1080p60 with automatic keyframes. Maybe bump it to 8000 if you aren't dropping frames at 7. With streamlabs, double check that it's actually uploading to the Twitch server nearest you. I had a bastard of a time trying to diagnose dropped frames when I moved from OBS Studio to Streamlabs until I realized Streamlabs defaulted to San Francisco Twitch servers, which was kind of a problem living in the Southern US and all. After I switched it up it's buttery smooth. If you're using NVENC codec be sure to use the new RTX encoding; you paid a semester's college tuition for that GPU so it may as well get up and work for a living, heh. Have fun! ![]()
|
![]() |
|
Willie Tomg posted:With that setup your possible pinch point isn't going to be your system, but inconsistent service rather than max throughput. Streamers dropping frames and calling Time Warner/Cox Cable everything but children of god as they see what they can trim down in their bitrates while resetting their router is a very fun aesthetic. If your ISP is good, then count your blessings and disregard all that. Okay, I'm set to 7000kbps, Hardware NVENC (new), and output (Scaled) res of 1080p @ 60fps. Hopefully that'll do it, and I could drop to 720p @ 30fps if my game needs more PC power, yeah?
|
![]() |
|
If you throttle it down to 720p30 for either PC or internet reasons (though I'll reiterate a dicey upstream is far more likely: your hardware spec will be good for a couple years at least) you could knock that down to 4000-5000kbps easily enough. https://stream.twitch.tv/encoding/
|
![]() |
Never mind i'll just switch plugins
hashashash fucked around with this message at 00:19 on Jun 28, 2019 |
|
![]() |
|
I was doing some test renders in Vegas Pro 14* for a video project I'm tinkering on and started having really annoying issues with DebugMode Frameserver crashing every second time I used it after installing, where it would work again once if I just installed it again over top of itself. Turns out that a new version got released roughly a week ago specifically for 64-bit versions of Magix Vegas Pro and Premiere that seems to have fixed my problem. https://www.debugmode.com/frameserver/ *Turns out that Shotcut can't do masking on multiple stacked chroma keyed tracks (keyed color shows in the edges of the mask) and also hilariously it can't reorder video tracks without you manually editing the order by opening the project file in notepad.
|
![]() |
|
I got a decade old laptop with no GPU, 3GB RAM, Celeron 900 @ 2.2 GHz, lil 300GB HDD- I want to record some gameplay for a video, obvi not in 1080 lol, but prolly more like 800x600- haven't done this in years, and that was on a desktop machine with better specs (RIP)- is there a go-to toolchain/method for recording on a low-end system? Can't really pick up any equipment; I'm extremely broke, else I'd just get the $200 or so in parts needed to repair the desktop feel like I'm going to have to balance compression on a lovely CPU with very little HDD space but I'm not sure where to start as the last time I did this I had like 4TB to play with
|
![]() |
|
Peanut Butler posted:I got a decade old laptop with no GPU, 3GB RAM, Celeron 900 @ 2.2 GHz, lil 300GB HDD- I want to record some gameplay for a video, obvi not in 1080 lol, but prolly more like 800x600- When I did my Submachine SSLP I first recorded it as raw video footage using OBS at mostly default settings. I think the only time I directly uploaded video instead of screenshots was for the credits sequence: https://www.youtube.com/watch?v=xJc9m-xg5No This was done on an old and slow laptop without a GPU. This all worked out because Submachine are tiny little games that don't require much resources to run so OBS could take all it needed. And also because I wasn't playing the HD versions but the original 400x514px flash versions, combined with the graphical style of those games, meant low resolution was barely noticable in the end result. I wasn't able to record any high-quality full screen games using that setup.
|
![]() |
|
Ladies and gentlemen, Goons of all ages, I present... an automated way to upload to LPix for Linux and Mac users! The script, which I'll call MegaSend, uses Python, and needs some slight setup to get it going. Get the script here: From GitHub! Now version 1.1. Please feel free to host this script elsewhere. Setup (once only) 1.Your computer needs Python installed. Most Linux distributions will have some version of Python installed by default. If you're a Mac user, you also have Python installed, but you will want to use the Homebrew package manager to install Python anyway, with the command: code:
2. Your computer needs the 'requests' web-request module for python installed. On Mac, once you have Python, you can install it with the "pip" python package-management tool. code:
3. Download the script and put it somewhere you can run it from the command line. 'nuff said. 4. Open the script in a text editor and put in your LPix username and password where indicated. There's a comment at the top saying "HEY YOU!", and the username and password variables are set under it, in the single quotes. Change those to your personal LPix details, and save the script. If you don't do this, your uploads will probably fail with an authentication error (in simple terms, the system has no idea who you are). If you have a boosted upload limit, you can change the value of my_mb_limit, slightly further down, to let the script know. Otherwise, it will skip files over 2 MB. Operation Let's say you put the script and your images in the same folder, to make the examples simpler. Now, just feed the script one or more filenames to upload, separated by spaces. code:
You can use the --log or --tlog command-line options to log uploaded image URLs to a file, surrounded by [img] (--log) or [timg] (--tlog) tags. code:
code:
Quackles fucked around with this message at 09:30 on Jul 25, 2019 |
![]() |
|
Added to OP under Image Guides. ![]()
|
![]() |
|
Thanks! I added a link to my GitHub with the script, too.
|
![]() |
|
That's really helpful, thank you for that!
|
![]() |
|
I’d like to make a feature request to have all those image URLs dumped to a text file on completion, I think that could be very useful for people getting the image links into their updates.
|
![]() |
|
![]()
|
# ? Jun 6, 2024 04:53 |
|
ChaosArgate posted:I’d like to make a feature request to have all those image URLs dumped to a text file on completion, I think that could be very useful for people getting the image links into their updates. Hell, with that it would be a single line of code extra to already put [img] tags around them in the text file.
|
![]() |