|
If you're listening to two different things on the same physical audio device and want something excluded for the sake of recording then generally speaking you're going to need to resort to messing around with virtual audio devices and repeaters. The alternative is multiple physical listening devices, like wearing earphones/buds(for voip) under a set of headphones(game + recording).
|
#
?
Jun 3, 2016 07:24
|
|
|
|
| # ? Jun 9, 2024 08:50 |
|
|
So I've been thinking that it might be a good idea to not have Megui sucking up 100% of my CPU every time I'm encoding a video in there and I was wondering what I could do to maybe have Megui take up less CPU. I don't mind that the video will take longer to encode, I just worry it's killing my CPU. I've read that you can limit the amount of threads that the x264 is using but is that the best route? Or what might be the best course of action? Is there a less system intensive method I could be using?
|
|
#
?
Jun 5, 2016 02:48
|
|
|
Don't worry about it. Unless what you really want to do is do something else on your computer, in which case MeGUI should already default to low priority, so you should be able to use other higher priority programs without MeGUI slowing them down. Otherwise, unless your computer is decades old, your CPU won't cook itself. If it's getting too hot, it'll automatically throttle down (making the encode take longer) to prevent itself from overheating. There was a rather famous video of what happens if you remove the heat sink from a Pentium while it's running Quake III Arena. (Yeah, that old.) You can watch the Intel chip clock itself down to save itself from cooking. Processing slows to a near halt, but it keeps going! (The AMD in that video cooks itself.) But that video is 15 years old. Every modern processor is designed with a variable clock and every modern processor is designed to throttle down and as a last resort turn itself off if necessary. So don't worry about it. Xenoveritas fucked around with this message at 03:09 on Jun 5, 2016 |
|
#
?
Jun 5, 2016 03:06
|
|
|
Yeah, I only worry cause I hear the fan working itself when normally it's super quiet and I look in the task manager to see it's always at 99% of my CPU. It's just worrisome, ya know.
|
|
#
?
Jun 5, 2016 03:15
|
|
|
Unless the noise is bothering you, it's not a thing to worry about. The fan spinning up is because modern computers are designed to be power efficient, so when they're not busy, they slow down, consume less power, and generate less heat. As they start to heat up under load, the cooling system will work harder to cool them off. It's a sign of everything working as intended - you get both quieter regular operation and lower power usage, and the ability for the CPU to work harder with more power as necessary. Now it is possible to wear out the fan, so if the fan sounds like it's starting to die (like grinding noises) then that can be a legitimate concern. But a replacement CPU cooler - that's the heat sink and fan combined - are only like $25-50. And if the fan does die and seize up, the CPU will just slow to a crawl rather than cooking itself. In short: don't worry about it. Edit: And if the noise is bothering you, you don't want to try and cap MeGUI's CPU percentage. You could probably "fake" that by disabling multithreading or reducing the number of cores it can use (find it in the Details tab of Task Manager, right click it, and choose "Set Affinity"). What you really want to do is underclock your CPU by reducing the max clock speed it can set. Xenoveritas fucked around with this message at 03:55 on Jun 5, 2016 |
|
#
?
Jun 5, 2016 03:43
|
|
|
Niggurath posted:Yeah, I only worry cause I hear the fan working itself when normally it's super quiet and I look in the task manager to see it's always at 99% of my CPU. It's just worrisome, ya know. Did you buy a fast CPU for it to stay idle and unused?
|
|
#
?
Jun 5, 2016 09:27
|
|
|
nielsm posted:Did you buy a fast CPU for it to stay idle and unused?
|
|
#
?
Jun 5, 2016 09:34
|
|
|
I can definitely attest to the computer shutting itself down to save itself from overheating. I've had it happen to me on a middling store bought computer after I ruined airflow by placing installing a large graphics card. Everytime time I did something computer intensive it got too hot and the system would just completely shut down and I had to wait around 15 minutes before I could turn it back on. I don't have that computer anymore because I built my own computer after that and haven't had it happen since. The fans will indeed kick up in speed upon more heat generation or if overall temperature starts rising. Most of the time it's due to processing power, however other times it can be because of room temperature especially in the summer.
|
|
#
?
Jun 5, 2016 14:14
|
|
|
I'm messing with avisynth scripting, and I have my video split into several clips to remove excess footage, but I can't figure out how to apply fading so as to avoid jump cuts when I splice them back together. I assume I need to use the FadeIn and FadeOut commands and apply them to each clip as necessary, but it doesn't seem to be working right. Any pointers on what I'm doing wrong?
|
|
#
?
Jun 6, 2016 04:00
|
|
|
Do you want a fade-out, then fade-in, or a crossfade? For a crossfade: Dissolve(clip_a, clip_b, 30)
|
|
#
?
Jun 6, 2016 04:06
|
|
|
Suspicious Dish posted:Do you want a fade-out, then fade-in, or a crossfade? Also, you can lower or raise the internal filters' frame count from 30 to a different number if you want to make the fades shorter or longer respectively. Dish's example takes a second at 30 fps, obviously. That means the last second of the first clip and the first second of the next will potentially go unseen or unheard, so keep that in mind as well- you might want to start the effects later and earlier in each clip to account for that. Reminder that if you're using AvsPmod: You'll need to use an external program like VirtualDub to preview the audio of your Avs files since the built in preview is mute no matter what, so keep that in mind if you want to hear if everything's syncing up correctly.
|
|
#
?
Jun 6, 2016 04:40
|
|
|
I actually figured it out. I was going for a fade-out, then fade-in. My problem was that I was trying to apply the fades, and then splice the clips, so for example: FadeOut(clipa, 30) FadeIn(clipb, 30) clipa ++ clipb Once I changed to: FadeOut(clipa, 30) ++ FadeIn(clipb, 30) it started working as intended. And I am using VirtualDub for viewing, with tweaks done through the script editor. Thanks though.
|
|
#
?
Jun 6, 2016 05:04
|
|
|
Ah, yeah. Alternatively you could've updated the old clips' variables or used new variables. So after your sources, the following options would've worked: clipa = FadeOut(clipa, 30) clipb = FadeIn(clipb, 30) clipa ++ clipb or clipawithfadeout = FadeOut(clipa, 30) clipbwithfadeout = FadeIn(clipb, 30) clipawithfadeout ++ clipbwithfadeout Edit: Heck, you could've done it right on your sources or their AudioDubs, too, by placing a . after: clipa = MuxedVideoSource("filename.filetype").FadeOut(30) clipb = MuxedVideoSource("otherfilename.filetype").FadeIn(30) clipa ++ clipb Stuff like that. Whatever's easier to read for you's best when working with AviSynth. ElTipejoLoco fucked around with this message at 05:42 on Jun 6, 2016 |
|
#
?
Jun 6, 2016 05:16
|
|
|
Thanks, that's good to know. That should simplify my life somewhat. I looked back through the video and everything looks good now. Encoding now, and it should look nice and (relatively) pretty once I get it onto Youtube.
|
|
#
?
Jun 6, 2016 05:30
|
|
|
For people with high framerate monitors, are there any issues playing a game at 120+ fps while recording in 60?
|
|
#
?
Jun 6, 2016 11:18
|
|
|
No. The recording software will only take 60 frames per second. This does potentially cause problems if the recording software is trying to record at a crappy frame rate (like 15-20 fps, crap that the human eye sees trivially) but if it's at 60 fps you shouldn't ever notice a thing.
|
|
#
?
Jun 6, 2016 19:24
|
|
|
Coolguye posted:No. The recording software will only take 60 frames per second. This does potentially cause problems if the recording software is trying to record at a crappy frame rate (like 15-20 fps, crap that the human eye sees trivially) but if it's at 60 fps you shouldn't ever notice a thing. Okay good. I was worried there'd be weird issues with the recorder dropping frames.
|
|
#
?
Jun 7, 2016 03:50
|
|
|
I'm trying to reduce line noise due to EMI related to my crackerjack onboard motherboard mic input freaking out when the CPU breaks 70C and the GPU going at full tilt etc etc, so I can do live recordings of stuff and not just post commentary. The background noise is absolutely EMI--poo poo sounds like a radio telescope. I'm thinking a simple adapter like this might do the trick and I suppose for that buy-in I can't go too terribly wrong, but should I instead just be looking into buying a Better Mic, preferably USB which--and please correct me if I'm wrong here--shouldn't be as subject to EMI as the current XLR->mini out on my current microphone? I'm reading some people saying I should get a DAC/Amp or something, which seems kind of like overkill for something as simple as noise reduction when Voicemeeter Bananna does most of what I want in terms of amplification, EQ and monitoring. Wouldn't that USB adapter fill the same role as external sound card, removing EMI? I'm sorta open to getting a new condenser for freelance work anyway, there's nothing wrong with my current mic but the current one is pretty cheap and not having to EQ so aggressively on top of doing less noise filtering would be... nice. Willie Tomg fucked around with this message at 21:02 on Jun 7, 2016 |
|
#
?
Jun 7, 2016 20:45
|
|
|
Getting a USB mic should resolve your EMI problems. The actual ADC in a USB microphone should be in the mic itself and then everything's digital once it hits the wire. I suspect the adapter you linked should work as well - the problem is presumably EMI along the analog signal before it hits the ADC and (hopefully) moving the ADC out of the computer will help. Especially because most computer cases are made of metal, meaning the case itself acts as a Faraday cage to some degree.
|
|
#
?
Jun 7, 2016 21:42
|
|
|
Willie Tomg posted:I'm thinking a simple adapter like this might do the trick  Never knew that existed! Interesting.I use a USB condenser mic and it has constant background noise that I'm told is the result of using an integrated sound card instead of a standalone. It's fairly quiet, in general it's only audible on headphones or with the volume pretty high; but it's there. The mic is an Audio-Technica ATR so one of the cheaper USB mics, if you get a better one you might not have any problems. Other than the noise the quality is a quantum leap above the dynamic mic I had been using (let alone a headset my brother used once), so there's that. Just a warning that going USB might replace one problem with another one, heh.
|
|
#
?
Jun 7, 2016 22:58
|
|
|
Well yes, a cheap all-integrated USB microphone will have a cheap ADC and in turn have a bad noise floor. You can still risk getting analog noise in USB bus powered audio devices when the computer is under load, since the load can possibly affect the USB power supply, and if the device doesn't filter the power well those variations in power input will affect the signal. Solution is either to use a separate powered hub or just not buy cheap junk in the first place.
|
|
#
?
Jun 8, 2016 02:26
|
|
|
Yeah in advance of buying a Blue Yeti I'm gonna run my... y'know I don't actually know the make and model of my mic. I think the make and model is:nielsm posted:cheap junk It was fifty bucks with a shock mount, pop shield and swivel arm, okay?!?! I love savings!! anyway, I'm gonna try running that into an external USB sound card into a powered USB hub and *fingers crossed* I think that'll be good enough for government work.
|
|
#
?
Jun 8, 2016 04:01
|
|
|
Anybody have an idea about what's going on with my FFmpeg HuffYUV recording? A quick couple of google searches didn't really get me much, except that some people had the problem and only at certain resolutions. Mine happened at both 1080p and 720p. Recording, everything's fine, but when I start the playback (using CCCP) this kaleidoscope bar starts out small, but then rises up quickly. I figured I need to either reinstall both or something, but I figured I'd ask here before I do to see if any of you had this issue and fixed it, or knew what's up.
|
|
#
?
Jun 8, 2016 16:10
|
|
|
Niggurath posted:
I'm probably missing something really basic, but that link doesn't have a dll file anywhere?
|
|
#
?
Jun 8, 2016 18:28
|
|
|
It's a bit hard to find, but click on "14 releases", then click on "ffms2-2.22-msvc.7z"
|
|
#
?
Jun 8, 2016 18:37
|
|
|
Hmmmm. Chrome won't let me download it for some reason
|
|
#
?
Jun 8, 2016 18:47
|
|
|
What's the preferred video codec for recording VLPs? Right now I'm recording in 1080p30 with Bandicam using the Motion JPEG codec, and I'm not sure how I feel about 15 minutes of recording spitting out a 21GB file.
|
|
#
?
Jun 9, 2016 06:33
|
|
|
Um... literally anything that isn't MJPEG. Well, OK, not literally anything, I'm sure someone out there has made a worse codec. But don't use MJPEG. It's a dumb codec for a variety of reasons. For recording it really depends on your hardware and how much disk space you're willing to waste. Good suggestions include Lagarith (lossless but creates huge files) or H.264 (lossy, can be CPU taxing unless you have a GPU that can encode directly, but can create high quality files of a fairly reasonable size).
|
|
#
?
Jun 9, 2016 08:06
|
|
|
Xenoveritas posted:Um... literally anything that isn't MJPEG. Yes. quote:For recording it really depends on your hardware and how much disk space you're willing to waste. Good suggestions include Lagarith (lossless but creates huge files) or H.264 (lossy, can be CPU taxing unless you have a GPU that can encode directly, but can create high quality files of a fairly reasonable size). Lagarith is the Quality At Any Cost option, yes, and will look very good while also having a smaller footprint than MJPEG. I have complicated feelings about video codecs here but Lagarith is gorgeous and if you have the HD space for Lagarith, and aren't doing any other projects concurrently, that's my vote. If you don't have the HD space for Lagarith encoding then it gets hairy... Recording h264 NVENC in OBS or Bandicam is the most painless option I've found myself for "bulk recording"--which is where the caveat of "unless you have a GPU that can encode directly" becomes relevant because ATI GPUs cannot do this, only whorehouse sellout nvidia GPUs can. Or so says the marketing; I haven't tried on an ATI GPU, because I haven't bought one. h264 by itself is insanely CPU intensive to the point I wouldn't attempt it unless you have an aftermarket CPU cooler in play because seeing CPUs get north of 90 degrees Celsius makes me hurt even if they're rated to perform at such temps. But it works, I can attest to that! Willie Tomg fucked around with this message at 09:25 on Jun 9, 2016 |
|
#
?
Jun 9, 2016 08:51
|
|
|
Alright then. I've got a GTX 970 (bought too recently and wrong brand for me to be thinking of moving on to 1070) and an OCed water-cooled 6600K, so I should definitely be okay with h264. Thanks for the tips. Just out of curiosity, what are the specific issues with MJPEG?
|
|
#
?
Jun 9, 2016 10:03
|
|
|
LogicalFallacy posted:Just out of curiosity, what are the specific issues with MJPEG? "M-JPEG is an intraframe-only compression scheme (compared with the more computationally intensive technique of interframe prediction). Whereas modern interframe video formats, such as MPEG1, MPEG2 and H.264/MPEG-4 AVC, achieve real-world compression-ratios of 1:50 or better, M-JPEG's lack of interframe prediction limits its efficiency to 1:20 or lower, depending on the tolerance to spatial artifacting in the compressed output." "Frames exhibiting complex textures, fine curves and lines (such as writing on a newspaper) are prone to exhibit DCT-artifacts such as ringing, smudging, and macroblocking." "MJPEG is inefficient, using more bits to deliver similar quality, compared to more modern formats (such as H.264/MPEG-4 AVC)" "There are also more sophisticated entropy coding than what was practical when the first JPEG design was developed. All of these new developments make M-JPEG an inefficient recording mechanism." Also, I'm not sure if I've even seen a single mention of it in the last five years.
|
|
#
?
Jun 9, 2016 10:28
|
|
|
Ouch. Well that's good to know. I've now got Bandicam and VDubMod set up so I can run with Lagarith or H264. And now what should be my final question (hopefully) for a while. I have to use ConvertToRGB in Avisynth in order for VDubMod to play back my H264 test video. When I do my actual videos, would I need to remove that line before encoding? Or is it fine to just leave it in.
|
|
#
?
Jun 9, 2016 10:42
|
|
|
LogicalFallacy posted:Alright then. I've got a GTX 970 (bought too recently and wrong brand for me to be thinking of moving on to 1070) and an OCed water-cooled 6600K If you're this much of a nerd than you almost certainly have enough HD space for a Lagarith encode  But seriously though, if you're using Bandicam (or OBS which, I stress for the benefit of anyone else reading this, is a free alternative which also supports this standard) make that 970 get up and work for a living with NVENC h264 unless you're sure the program you're recording is GPU bottlenecking you, is my actual not-kidding suggestion*. And then tell me what it is you're recording that GPU bottlenecks a 970 in the year of our poo poo 2016 because holy moly I want to see that on general principle. FWIW I have a stock-cooled, un-OCed 4790k and recording h264 without GPU assistance while looking at temps (which got north of 90C) made me research all these other alternative options. My evo cooler master 212 is in the mail. This is what you can expect if you don't use NVENC. *Unless you actually-not-kidding can swing Lagarith in which case use that 100% for sure, its so pretty.
|
|
#
?
Jun 9, 2016 10:51
|
|
|
LogicalFallacy posted:Ouch. Well that's good to know. I've now got Bandicam and VDubMod set up so I can run with Lagarith or H264. And now what should be my final question (hopefully) for a while. I have to use ConvertToRGB in Avisynth in order for VDubMod to play back my H264 test video. When I do my actual videos, would I need to remove that line before encoding? Or is it fine to just leave it in.  if you're recording in h264, converting to RGB is extraneous and takes far more HD space than just recording in Lagarith in the first place. Converting a lossy h264 file into a lossless RGB file so you can edit and then recompress it back into your final delivery format (which will more than likely be h264 again) is: not good. I like to record in h264 because Premiere tolerates h264 nonsense videos of me and my friends playing tabletop games, I don't use VirtualDub but if it doesn't accept h264 then absolutely use Lagarith to make good-looking .avi files and if VirtualDub doesn't accept those then use a better computer program IMHO. I'm pretty sure VirtualDub accepts all .avi codecs though. seconds of google searching led me to this link for using h264 in virtualdub, but reading it gave me a palpable thankfulness for adobe programs where you just drop stuff into a timeline and it works without any of this drama this is a whole lot of words to say: record in Lagarith (unless you like tinkering and spent your entire HD budget on GPUs and CPUs) Willie Tomg fucked around with this message at 11:18 on Jun 9, 2016 |
|
#
?
Jun 9, 2016 11:08
|
|
|
You can, in fact, take advantage of an AMD GPU's on-board h.264 encoder in recent versions of OBS Studio. It's what I use with my 290X. Also, there's a bit more nuance than "just use Lagarith." Depending on what your system contains (a weak CPU) or your needs/desires (fast seeking), Lagarith may not always be ideal. For instance, I use Lagarith for games with a retro-look, as it seems to get insanely small filesizes for the quality out them compared to most other codecs I use. However, for modern-looking games, I use MagicYUV because while both it and Lagarith end up with similar sizes, MagicYUV uses quite a bit less resources to decode than Lagarith, which when thrown into an editor (in my case, Vegas), allows me to seek around without jittering around all the time. And that's just two options. There's also UT-Video and the FFMpeg variant of HuffYUV, which I'm told is good and uses less resources, but I can't get it to work for me. Basically, if you have the time, it would benefit you to try out different codecs.
|
|
#
?
Jun 9, 2016 13:59
|
|
|
VirtualDub is supposed to accept pretty much anything that's a .avi file. There's just some variance as to how many hoops you have to jump through in order for it to work. This has reminded me that a good part of the reason I decided to go with MJPEG is that it worked with VDub without any issues. Lagarith does seem to work just fine though.
|
|
#
?
Jun 9, 2016 15:47
|
|
|
Jewel posted:"M-JPEG is an intraframe-only compression scheme (compared with the more computationally intensive technique of interframe prediction). Whereas modern interframe video formats, such as MPEG1, MPEG2 and H.264/MPEG-4 AVC, achieve real-world compression-ratios of 1:50 or better, M-JPEG's lack of interframe prediction limits its efficiency to 1:20 or lower, depending on the tolerance to spatial artifacting in the compressed output." i had a laugh yesterday. my day job is building an operating system, and we capture metrics about which codecs are missing when people try to play files. one person tried to play 3gpp video another tried to play mjpeg for reference, in that same time period, ten people tried to open a .html file in our media player
|
|
#
?
Jun 9, 2016 18:58
|
|
|
I actually have a .3gp video lying on my desktop, right now, in the lower right corner, ready to watch at any time I guess the difference is, i can actually play it, because CCCP
|
|
#
?
Jun 9, 2016 20:01
|
|
|
yeah, people can download CCCP and VLC and not get sued, because the patent pools have made a promise to never go after non-commercial entities but if you sell a product, you have to pay the mafia shakedown fees, and they're ridiculous. usually $1 royalty for every codec, for every shipment, and that's not even including poo poo like HEVC which has two different patent pools, costing on the order of $5 per device. if we wanted to ship CCCP, it would bump the price of our device by around $150, paid out to around 40 different patent pools
|
|
#
?
Jun 9, 2016 21:32
|
|
|
|
| # ? Jun 9, 2024 08:50 |
|
|
Stupid idiot question here: I'm using OBS to record my video, and that'll spit out a file that uploads to YouTube just fine. So what, then, is the point of encoding video? Is it that pushing the video through Avisynth to sync up the audio tracks will spit out a file that YT won't like? I'm a comm major and what is this 
|
|
#
?
Jun 10, 2016 00:36
|
|
