[Ffmpeg-devel-irc] ffmpeg.log.20181025

[burek]

[00:18:35 CEST] <kepstin> it wouldn't hurt to give the 'fieldmatch' filter a try, and see what it can put back together.
[00:19:16 CEST] <kepstin> lots of options for controlling matching and it dynamically adjusts for video cuts
[00:20:10 CEST] <kepstin> oh never mind, you have blended frames
[00:20:18 CEST] <kepstin> yeah, I don't know any way to fix that
[00:22:38 CEST] <kepstin> it looks like someone telecined the video then scaled it down to 1/2 height :/
[00:23:43 CEST] <kepstin> is this a fmv from a video game? if it was originally a console game (PS2?), getting it from there might work better than a pc release since you'll likely get the original interlaced video.
[01:58:40 CEST] <qwertymodo> @kepstin, it was originally released on PS1, but the quality was compressed to hell and only 15FPS, the PC re-release was obviously a brand new scan of the original animation, rendered at 1080p30
[01:59:24 CEST] <qwertymodo> there were a few other releases through the years, but all much lower resolution, this is the highest-res version ever released
[02:00:18 CEST] <kepstin> ah, that's too bad :/
[02:01:45 CEST] <qwertymodo> it's a bummer, because the non-blended frames are fantastic, they're obviously direct 1080p scans, not upscales or anything like that
[02:02:00 CEST] <qwertymodo> so if they had just rendered at the native 24fps, it would have looked perfect
[02:03:11 CEST] <kepstin> I assume that the people encoding the video for the game got it as 60i content and saw combing, and ran it through a simple deinterlacing filter rather than detelecine it :/
[02:07:07 CEST] <iive> qwertymodo, you can actually try something in gimp/photoshop
[02:07:25 CEST] <iive> take 2 frames. one crisp, one blended.
[02:07:43 CEST] <kepstin> you get this, which is kinda eh https://www.kepstin.ca/dump/subtract.png
[02:07:47 CEST] <kepstin> too much compression artifacts
[02:08:26 CEST] <iive> yeh...
[02:08:55 CEST] <iive> doing spp on both frames might improve it a bit, but still.
[02:09:02 CEST] <kepstin> hmm, that was done using a linear light subtract, it's possible the blending was done gamma-incorrect, i should try that to compare.
[02:09:27 CEST] <iive> spp is post-process filter
[02:09:46 CEST] <kepstin> nah, that's the best match.
[02:09:56 CEST] <qwertymodo> which frame did you put on top when you did the subtract?
[02:10:11 CEST] <PhantomOfNyx> Hey there so I'm in a bit of an odd situation, my attempt is with x264 to try to have as accurate rendering as possible long story short I stream MMORPG's and the big problem with the default settings is I move 5 steps and everything turns into blurr with blurr on it ( even with slow encoding ) I have a pretty beefy CPU ( too many cores tbh ) was wondering if it would be worthwhile to go crazy with an rc-lookahead and lookahead-th
[02:10:23 CEST] <qwertymodo> I can try that with one of the 1080p frames and see if that works any better with fewer artifacts
[02:10:50 CEST] <PhantomOfNyx> Or anyone have any suggestions, I feel like I've almost tried everything I could think of
[02:10:58 CEST] <iive> PhantomOfNyx, you are probably using extremely low bitrate
[02:11:15 CEST] <kepstin> qwertymodo: that's the first two pngs from your imgur upload
[02:11:22 CEST] <PhantomOfNyx> well twitch limits you to 6500kbs ( but even 720p at that does the same )
[02:11:54 CEST] <iive> 6,5Mbps should be enough. just be sure you are not using wrong setting e.g. 6,5Kbps
[02:11:55 CEST] <qwertymodo> right, but which layer was on top, the clear frame or the blended one?
[02:12:23 CEST] <PhantomOfNyx> Well not sure if the default presets is wrong settings but if so yes I am indeed xD
[02:12:37 CEST] <kepstin> qwertymodo: if you take a blended frame, and put a known frame on top in subtract mode (linear light - if you're using gimp make sure it's 2.10) at 50%, then use levels (again, switch to linear light) to adjust the white level, again 50% of max.
[02:12:58 CEST] <PhantomOfNyx> Nah In all seriousness I've tried almost everything I could think of but again I'm only this knowledgeable on the subject
[02:14:31 CEST] <qwertymodo> what do you mean linear light?
[02:14:39 CEST] <PhantomOfNyx> but yeah I'm quite honestly running out of ideas, I've tweaked a bit and it seems that changing to b-adapt=2 does wonders
[02:14:53 CEST] <iive> assuming that blend = (previous + current)/2 ; where we have the previous and the blend
[02:15:28 CEST] <iive> PhantomOfNyx, are you using libx264 ?
[02:15:45 CEST] <PhantomOfNyx> yeah fairly certain that would be it.
[02:16:10 CEST] <iive> try crf=18 and see how bit the stream goes. 22 should be fine too.
[02:16:21 CEST] <kepstin> qwertymodo: yeah, so current = (blend - previous) * 2; - the key point is that you have to match the same gamma settings as were used in the original blend
[02:16:40 CEST] <PhantomOfNyx> So slow preset and add the crf=18 as a modification to it ? iivve
[02:17:19 CEST] <iive> PhantomOfNyx,  yes
[02:17:33 CEST] <kepstin> qwertymodo: so if the original blend was done in sRGB (or similar gamma) you have to use that when undoing the blend. I found that your example pngs looks decent when done in linear light in GIMP. Note that if you can do the blending in the original YUV it might be best?
[02:18:03 CEST] <iive> kepstin, the blend is probably done in YUV
[02:18:40 CEST] <kepstin> yeah, given that it was probably blended by a simple deinterlacing filter
[02:19:53 CEST] <PhantomOfNyx> there we go definitely improved above what I had before for what seems like 0 extra performance cost o_O
[02:20:18 CEST] <PhantomOfNyx> thanks iiv, would I benefit from lowering the crf further or any other magical tweaks you can recommend ?
[02:20:48 CEST] <PhantomOfNyx> also I hear that enabling all my threads for encoding is a bad idea but would adding a few threads for lookahead hurt anything ?
[02:20:49 CEST] <kepstin> qwertymodo: one thing to note is that you have two copies of the frame that's only available blended - one blended with the previous frame, one blended with the next frame. You can probably do the subtraction on both then average the two results to get a single better looking frame result.
[02:20:56 CEST] <iive> PhantomOfNyx, lower crf would make the stream bigger, so you may hit bandwidth limit
[02:21:15 CEST] <iive> PhantomOfNyx, try -preset faster -crf 22
[02:21:47 CEST] <iive> 18 is literally perfect quality
[02:22:01 CEST] <PhantomOfNyx> ah makes sense. why faster above slow?
[02:22:33 CEST] <PhantomOfNyx> just out of curiosity
[02:22:38 CEST] <iive> in my tests, the slower gave me just 5% smaller file size
[02:23:09 CEST] <iive> you can also try -nr 150
[02:23:14 CEST] <PhantomOfNyx> Ah I can't handle slower I can get away with slow
[02:23:28 CEST] <PhantomOfNyx> ah yeah I've been using nr but haven't been able to see any difference
[02:23:31 CEST] <kepstin> slower modes tend to add more variability to frame encoding time, iirc, which also means you're more likely to have issues with a live stream.
[02:23:42 CEST] <PhantomOfNyx> was playing around with 50-1000 and it didnt' seem to do anything
[02:24:15 CEST] <kepstin> (although if you're using something like -tune zerolatency, that turns off enough x264 features that the slower modes don't really help all that much, i think)
[02:24:32 CEST] <PhantomOfNyx> That's true kepstin, also just out of curiousity would sliced threads be worth attempting to add if you want to try to lower your stream delay a bit
[02:25:03 CEST] <PhantomOfNyx> Ah nah I usually go with tune film as it seems to be the most solid at removing the grain I had issues with
[02:25:15 CEST] <PhantomOfNyx> still a bit there but definitely ALOT more detail right now :D
[02:25:25 CEST] <kepstin> the 'film' tune is designed to preserve grain and find detail, not remove it
[02:25:38 CEST] <kepstin> well, the 'grain' tune does that
[02:25:42 CEST] <iive> you might want to run some filter to remove the grain. some denoise
[02:25:49 CEST] <kepstin> i guess 'film' is somewhere inbetween
[02:25:56 CEST] <PhantomOfNyx> Well sorry my definition of grain is basically blurr on stream that doesn't look good xD
[02:26:15 CEST] <iive> film grain is just white noise
[02:26:24 CEST] <kepstin> grain is very small lighter/darker spots that change between each frame (noise)
[02:27:10 CEST] <PhantomOfNyx> hmm so you suggest I stop using film as a tune but what would you recommend instead for optimal live quality of well video games :) ?
[02:27:24 CEST] <furq> use whatever looks good to you
[02:27:30 CEST] <PhantomOfNyx> and then instead run deblock:-2:-2
[02:27:31 CEST] <iive> encoder could spend most of its bandwidth encoding that noise, and destroy the signal.
[02:27:32 CEST] <kepstin> honestly, if it works well for the content in your game, go for it
[02:27:33 CEST] <furq> if you're streaming video games then there's no film grain anyway
[02:27:35 CEST] <PhantomOfNyx> or something like that
[02:27:44 CEST] <furq> but film will generally just preserve fine detail
[02:27:53 CEST] <PhantomOfNyx> yeah that's kinda what i want to keep
[02:28:00 CEST] <iive> PhantomOfNyx, try -vf hqdn3d
[02:28:02 CEST] <PhantomOfNyx> so if you have a better idea I'm all for it :D
[02:28:08 CEST] <kepstin> depending on the exact type of content in your game, you might also try -tune touhou ;)
[02:28:11 CEST] <furq> iive: he doesn't have any film grain
[02:28:20 CEST] <iive> oh...
[02:28:26 CEST] <iive> he did say a game...
[02:28:28 CEST] <PhantomOfNyx> Wait there is seriously a tune touhou ?
[02:28:28 CEST] <kepstin> (that's helpful for keeping details on smallish, ~16px stuff moving around)
[02:28:58 CEST] <iive> of course, some of the core x264 were very into touhou
[02:29:09 CEST] <furq> bad game
[02:29:10 CEST] <iive> core developers...
[02:29:16 CEST] <PhantomOfNyx> That's amazing! xD
[02:29:28 CEST] <PhantomOfNyx> I don't play it myself but I have friends obsessed with it
[02:29:51 CEST] <PhantomOfNyx> but yeah if you're not pulling my leg I'll try that tune
[02:29:55 CEST] <iive> bad apple :P
[02:29:58 CEST] <PhantomOfNyx> just never seen it mentioned
[02:30:02 CEST] <furq> it's going to be a bad fit for anything other than STGs
[02:30:04 CEST] <PhantomOfNyx> .... anywhere
[02:30:10 CEST] <PhantomOfNyx> ah well xD
[02:30:15 CEST] <PhantomOfNyx> then lets not
[02:30:17 CEST] <furq> also yeah it's not in --fullhelp
[02:30:22 CEST] <kepstin> i'm pretty sure it was mostly added as a joke, but it does actually help anything with small sharp-edged sprites moving around independently. Oddly enough, it helps with mouse cursors on desktop screen capture a bit.
[02:30:23 CEST] <furq> presumably out of a well-deserved sense of shame
[02:30:50 CEST] <PhantomOfNyx> might I ask what this does
[02:30:52 CEST] <PhantomOfNyx> vf hqdn3d
[02:30:59 CEST] <furq> it's a denoise filter
[02:31:00 CEST] <PhantomOfNyx> Never seen it mentioned or heard of it before
[02:31:05 CEST] <PhantomOfNyx> Ah
[02:31:06 CEST] <furq> you probably don't need it
[02:31:20 CEST] <iive> you need to remove film grain.
[02:31:31 CEST] <iive> i know of only one game that adds it.
[02:31:41 CEST] <furq> there's loads of games that add dumbass film grain effects
[02:31:45 CEST] <furq> basically every game that has zombies in it does it
[02:31:51 CEST] <kepstin> PhantomOfNyx: it does high quality (hq) denoise (dn) using the *third dimension* (3d), which happens to be time, in video context.
[02:31:53 CEST] <iive> yep
[02:32:13 CEST] <PhantomOfNyx> Thanks, I'm all for learning but sometimes this stuff can be hard to find xD
[02:32:25 CEST] <iive> man ffmpeg-filters
[02:32:28 CEST] <qwertymodo> ok, so I tried the subtraction for both copies of the blended frame, and added the two results together, and it actually looks decent
[02:32:28 CEST] <PhantomOfNyx> but I really appreciate your acceptence of my newbishness x3
[02:32:29 CEST] <furq> i would link the libavfilter documentation page but it has like 300 filters in it
[02:32:41 CEST] <furq> so that's probably not going to help without being pointed at specific entries
[02:32:53 CEST] <PhantomOfNyx> yeah nah I will give this one a shot
[02:33:12 CEST] <furq> like i said you don't really want hqdn3d unless you have noise or film grain to remove
[02:33:17 CEST] <furq> otherwise it's just going to remove fine detail
[02:33:21 CEST] <PhantomOfNyx> I noticed that testing vbv instead of crf Did alot of quality of my streams but twitch introduced low latency and it does NOT like variable bitrate
[02:33:29 CEST] <iive> it may cause blur on movement
[02:33:59 CEST] <kepstin> PhantomOfNyx: 'crf' mode creates very highly variable bitrate
[02:34:08 CEST] <iive> i mean the hqdn3d may cause blur
[02:34:13 CEST] <qwertymodo> my main purpose for this is actually going to be reduced resolution, so that'll help mask some of the remaining artifacts
[02:34:42 CEST] <qwertymodo> Here's what it looks like: https://i.imgur.com/aCE9GIV.png
[02:34:49 CEST] <kepstin> PhantomOfNyx: 'vbv' is a method for constraining bitrate - for streaming, you'd want to use either crf mode or vbr mode along with 'vbv' controls (maxrate, bufsize) to make sure the stream doesn't exceed the bandwidth limit.
[02:34:52 CEST] <furq> qwertymodo: like i said, there might be an avisynth or vapoursynth filter that does this automatically
[02:35:09 CEST] <furq> although if the blending isn't at fixed intervals then maybe you will have to do it all by hand
[02:35:35 CEST] <PhantomOfNyx> Oh I know that one I quite liked vbv and had it tuned pretty well but again twitch doesn't like it for their low latency service
[02:35:41 CEST] <PhantomOfNyx> as they want a constant bitrate
[02:35:48 CEST] <iive> n8 ppl.
[02:35:50 CEST] <furq> there are definitely filters that fix blended fields remarkably well, but what you have is one step worse
[02:35:53 CEST] <qwertymodo> top and bottom of the example were existing clear frames, middle was an un-blended frame
[02:35:57 CEST] <kepstin> PhantomOfNyx: 'vbv' is how you create constant bitrate (or nearly so) streams.
[02:36:20 CEST] <kepstin> PhantomOfNyx: 'crf' makes highly variable bitrate, which twitch doesn't like
[02:36:27 CEST] <furq> you can use crf with maxrate
[02:36:51 CEST] <PhantomOfNyx> yeah pretty much all streaming application got maxrate set per default
[02:36:56 CEST] <kepstin> yeah, but it's still variable, it'll drop below the maxrate when possible
[02:37:12 CEST] <furq> so will abr
[02:37:16 CEST] <furq> admittedly not as much
[02:37:18 CEST] <PhantomOfNyx> found out by tweaking back when I was playing with vbv and i managed to pull trough like 15k bitrate somehow
[02:37:23 CEST] <furq> unless you use nal padding or something
[02:37:38 CEST] <kepstin> stuff like twitch wants as close to constant bitrate as possible to compensate for issues with tcp window scaling and network buffering and such
[02:38:02 CEST] <furq> i'm surprised they care considering they restream everything as hls anyway
[02:39:11 CEST] <kepstin> i'm kind of surprised that webrtc cdns for low latency video streaming haven't really picked up yet.
[02:39:31 CEST] <furq> there's not a great deal of demand for low latency
[02:39:40 CEST] <PhantomOfNyx> Actually mixer attempted that with a butchered mix of webrtc and libx264...
[02:39:46 CEST] <furq> obviously stuff like youtube and twitch would gain nothing from it
[02:39:50 CEST] <PhantomOfNyx> lets just say the stability is less than ... amazing
[02:40:13 CEST] <kepstin> qwertymodo: that's not terrible but it looks like you don't quite have the brightness levels matched yet :/
[02:40:26 CEST] <PhantomOfNyx> well twitch is slowly introducing a low latency feature I suspect it takes x264 and converts it somehow partly to webrtc
[02:40:35 CEST] <PhantomOfNyx> not sure what happens but they remux it somehow
[02:41:04 CEST] <PhantomOfNyx> but was informed it really didn't like variable bitrate in the "re-coding process"
[02:42:15 CEST] <furq> are you sure they're using webrtc for that
[02:42:31 CEST] <PhantomOfNyx> I know mixer is, I honestly don't know what twitch does
[02:42:46 CEST] <PhantomOfNyx> FTL is partly based on parts of webrtc
[02:42:59 CEST] <furq> the problem with webrtc is that at least one browser uses openh264 exclusively for it
[02:42:59 CEST] <PhantomOfNyx> but again it's only small parts and it comes out as a worst of both worlds kinda thing
[02:43:03 CEST] <furq> which means you're stuck with h264 baseline
[02:43:42 CEST] <PhantomOfNyx> Yep honestly I don't mean to be rude but I would REALLY love to see the industry move to h.265 already
[02:43:51 CEST] <PhantomOfNyx> Like the NUMA support would be glorious
[02:44:04 CEST] <PhantomOfNyx> I sit with a 2950x threadripper in a dedicated render machine
[02:44:22 CEST] <PhantomOfNyx> And i just keep hitting walls with x264
[02:44:52 CEST] <furq> hevc doesn't have compelling enough efficiency advantages in most scenarios to justify dealing with the licensing bullshit
[02:45:59 CEST] <furq> i'm not sure if realtime 1080p is even going to beat x264 at all most of the time
[02:46:04 CEST] <furq> unless you have a dedicated box to throw at it
[02:46:39 CEST] <PhantomOfNyx> Well yeah but most people on twitch don't even attempt 1080p
[02:46:49 CEST] <PhantomOfNyx> thing is officially are we limited to 6k bitrate
[02:47:01 CEST] <PhantomOfNyx> and that just doesn't cut it for anything else than 30fps 1080p
[02:47:25 CEST] <PhantomOfNyx> but quote from devs from twitch themselves they are tweaking for 60 fps because they feel that gives a better gaming stream experience
[02:48:04 CEST] <PhantomOfNyx> but you would need some kind of insane beast of a machine to get 1080p 60 down to 6k without looking worse than 1600x900 60
[02:48:32 CEST] <furq> depends on the game really
[02:48:41 CEST] <furq> obviously if you're playing quake or something then no chance
[02:49:09 CEST] <PhantomOfNyx> Well most who want 60fps plays Call of duty4 overwatch or etc
[02:49:19 CEST] <PhantomOfNyx> so yeah not going to happen xD
[02:49:38 CEST] <PhantomOfNyx> but I agree I could probably throw a pretty neat stream of hearthstone in 1080p 60 xD
[02:50:41 CEST] <PhantomOfNyx> added the filter and I can't judge if it made the blurr on movement worse or better
[02:51:22 CEST] <PhantomOfNyx> My frustration really comes from watching the game just POP into clarity because of how big the difference between movement and standing still is
[02:51:39 CEST] <PhantomOfNyx> I would be quite willing to take an overall quality loss to make sure it's even
[02:51:54 CEST] <PhantomOfNyx> because that pop drives me up the wall mentally ._.
[02:54:02 CEST] <PhantomOfNyx> but once again thanks for the help so far furq and kepstin I've atleast gotten a bit further, do you think adding a bigger lookahead and possibly dedicating some threads to it would help with the "pop"
[02:54:51 CEST] <kepstin> no, quality 'popping' is almost always due to not having enough bitrate to encode the video at consistent quality
[02:55:15 CEST] <kepstin> sometimes you can tweak settings to lower the quality so everything looks consistent :/
[02:56:01 CEST] <PhantomOfNyx> yeh but thing is popping happens it doesn't matter if I attempt 540p at 6k bitrate or 900 p
[02:56:09 CEST] <PhantomOfNyx> it seems to be consistent with this game though
[02:56:23 CEST] <PhantomOfNyx> but the short answer would be better compression
[02:56:50 CEST] <PhantomOfNyx> I seemed to fix some of it by adding b-adapt:2 before but that parameter MURDERS my for a good word
[02:57:09 CEST] <PhantomOfNyx> wait is cpu a bad word?
[02:57:15 CEST] <PhantomOfNyx> hmm weird
[02:57:30 CEST] <PhantomOfNyx> probably a keyboard flunk then x3
[02:57:37 CEST] <kepstin> with realtime streaming you can't really get substantially enough better compression than x264 medium or fast to make a difference for this
[02:58:16 CEST] <kepstin> using a lower quality (higher crf, if you're in crf mode) should help, and using abr mode instead of crf should make the quality a bit more even over time usually.
[02:59:06 CEST] <furq> those quality pops (if i'm understanding you right) are pretty characteristic of abr and maxrate
[02:59:11 CEST] <furq> or just maxrate in general really
[02:59:35 CEST] <kepstin> assuming a big enough bufsize and abr set below maxrate, i'd expect the effect to be minimal
[02:59:47 CEST] <furq> tweaking bufsize should help yeah
[02:59:51 CEST] <PhantomOfNyx> yeah currently using "CBR" as it's called.
[02:59:53 CEST] <furq> idk how much twitch will accept though
[03:00:11 CEST] <PhantomOfNyx> so a bigger custom buffer ?
[03:00:17 CEST] <PhantomOfNyx> that's what bufsize means right ?
[03:00:17 CEST] <kepstin> PhantomOfNyx: what keyframe interval and framerate are you using?
[03:00:20 CEST] <furq> if by cbr you mean nal-hrd=cbr then that doesn't really do anything for the picture quality
[03:00:27 CEST] <PhantomOfNyx> Twitch recommends: 2
[03:00:33 CEST] <furq> ??
[03:00:38 CEST] <furq> gop size of 2?
[03:00:48 CEST] <furq> does OBS measure that in seconds or something
[03:00:49 CEST] <kepstin> keyframe interval of 2 seconds, i assume
[03:01:04 CEST] <PhantomOfNyx> Oh yeah sorry
[03:01:09 CEST] <PhantomOfNyx> 120
[03:01:15 CEST] <PhantomOfNyx> would be the translation
[03:01:29 CEST] <furq> also you're definitely not using tune zerolatency, right
[03:01:46 CEST] <PhantomOfNyx> Nope wouldn't touch that at all.
[03:01:49 CEST] <PhantomOfNyx> it looks horrible
[03:01:50 CEST] <PhantomOfNyx> no offense
[03:01:55 CEST] <furq> yes it does
[03:02:06 CEST] <kepstin> setting bufsize to an amount big enough to hold a full gop at your max bitrate should be accepted by twitch, i think
[03:02:12 CEST] <furq> you see loads of guides for streaming to twitch/youtube etc that recommend turning that on
[03:02:16 CEST] <furq> and it's really the worst advice
[03:02:23 CEST] <furq> it's a pet hate of mine
[03:03:05 CEST] <PhantomOfNyx> Actually mixer used us to force to use it for a while because Muh latency
[03:03:16 CEST] <PhantomOfNyx> then I learned that they don't support bframes and was like bollocks
[03:03:19 CEST] <furq> well if mixer is using webrtc then it makes no difference anyway
[03:03:24 CEST] <kepstin> e.g. 10mbit/s for 2 seconds means vbv bufsize of around 20mbit, or 2.5mbyte
[03:03:28 CEST] <furq> because yeah, webrtc is effectively baseline only
[03:03:32 CEST] <furq> so no bframes or cabac
[03:03:52 CEST] <PhantomOfNyx> yep oh someone should probably give the memo to them about cabac I didn't know that one
[03:03:52 CEST] <furq> so you might as well use zerolatency, those are the two major features it disables
[03:04:01 CEST] <furq> there's nothing they can do if they're using webrtc
[03:04:04 CEST] <PhantomOfNyx> but mixer in short have ALOT of issues because everyone is using x264 profiles
[03:04:10 CEST] <PhantomOfNyx> <_<
[03:04:16 CEST] <furq> webrtc means baseline or it won't work in firefox
[03:04:39 CEST] <furq> or vp9 and nobody can generate that in realtime anyway
[03:04:46 CEST] <PhantomOfNyx> yeah nah I moved to twitch for a reason I want muh bframes and my shiny
[03:04:50 CEST] <kepstin> there's an issue open on openh264 about adding support for decoding high, but... yeah, i'm not expecting that any time soon
[03:04:58 CEST] <furq> even main would be great
[03:05:40 CEST] <PhantomOfNyx> yeah I think I'm starting to grasp where all mixers issues come from
[03:05:42 CEST] <kepstin> it's annoying because i think it uses the system ffmpeg or h264 decoder for regular video playback (e.g. youtube and stuff)
[03:06:03 CEST] <furq> it does
[03:08:35 CEST] <PhantomOfNyx> Hmm I think you guys got me in the right direction
[03:09:09 CEST] <PhantomOfNyx> now with that said Slow doesn't really hurt my processing power at all, is there anything you can recommend for a bit better encoding to prevent the "pop"
[03:09:52 CEST] <PhantomOfNyx> or should I just add a bunch of Bframes to the extreme and add all the fancy b-frame parameters?
[03:10:22 CEST] <PhantomOfNyx> b-pyramid=2 b-adapt=2 etc
[03:10:46 CEST] <PhantomOfNyx> also would it be better to add a high amount of bframes with b-adapt=1 or just stick with 4-6 at 2 ?
[03:12:29 CEST] <PhantomOfNyx> Also furq any reason you asked for iframes would you suggest increasing or decreasing them from 120 ?
[03:16:32 CEST] <furq> i didn't ask for that
[03:18:40 CEST] <kepstin> I asked about keyframe interval, because knowing it can inform a useful range of bufsize values.
[03:18:55 CEST] <kepstin> (and increasing bufsize should improve quality consistency)
[03:22:55 CEST] <PhantomOfNyx> it's -vbv bufsize= right ?
[03:23:13 CEST] <PhantomOfNyx> and what would you recommend for a baseline 6-6.5k bitrate ?
[03:27:34 CEST] <furq> just -bufsize
[03:27:58 CEST] <furq> bitrate * gop size (in seconds) is a good place to start
[03:28:01 CEST] <furq> so probably 12000k
[03:28:10 CEST] <PhantomOfNyx> Well I have a preset option in obs I can fill called vbv buffer
[03:28:16 CEST] <furq> yeah that's the same thing
[03:28:22 CEST] <PhantomOfNyx> figured as much
[03:28:33 CEST] <PhantomOfNyx> but no reason to make it harder than it is
[03:28:58 CEST] <PhantomOfNyx> so with a 6k bitrate outwards to twitch how big a buffer would I want
[03:29:12 CEST] <PhantomOfNyx> not sure what gop size is ._.
[03:29:14 CEST] <PhantomOfNyx> sorry
[03:29:20 CEST] <furq> keyframe interval
[03:29:33 CEST] <PhantomOfNyx> ah wait wouldn't that create insane delay O_O
[03:29:40 CEST] <PhantomOfNyx> that's 12k
[03:29:52 CEST] <furq> not really
[03:30:45 CEST] <PhantomOfNyx> Well I'll trust you but omg O_O that's like a massive buffer and you're certain that won't create like massive delay for my viewers
[03:30:52 CEST] <PhantomOfNyx> I sit at a 1.8sec average
[03:31:01 CEST] <furq> 12000k is two seconds of buffer
[03:31:05 CEST] <furq> your stream is 6000k
[03:31:49 CEST] <PhantomOfNyx> How does this work exactly ( mind explaining it? )
[03:32:39 CEST] <furq> the encoder has (in this case) a 12 megabit buffer that it evicts every two seconds
[03:32:52 CEST] <furq> so within the space of that buffer, the rate can spike as high as it wants to
[03:33:08 CEST] <furq> as long as the total for that two seconds is no more than 12 megabits
[03:33:09 CEST] <PhantomOfNyx> Hmm didn't seem to get rid of movement blurr ?
[03:33:44 CEST] <furq> well yeah if you have more than two seconds where it wants to use more than 6mbit then it's no use
[03:33:48 CEST] <furq> it should at least help
[03:33:57 CEST] <furq> you probably also want to have rc-lookahead set very high
[03:34:08 CEST] <PhantomOfNyx> yeah that was the one I was asking about
[03:34:16 CEST] <PhantomOfNyx> also I can see you can dedicate threads to lookahead
[03:34:19 CEST] <furq> rc-lookahead is the number of frames ahead the encoder will look to make rate control decisions
[03:34:30 CEST] <PhantomOfNyx> seeing I have 32 threads I wouldn't mind dedicating a few for that
[03:34:59 CEST] <furq> if you have that many threads you might as well just dedicate some to x264 and use veryslow with 120 lookahead
[03:35:25 CEST] <PhantomOfNyx> Pfft tried very slow, my cpu can't handle it
[03:35:29 CEST] <furq> you obviously get diminishing returns at some point though
[03:35:37 CEST] <PhantomOfNyx> Can't even hit slower
[03:35:47 CEST] <PhantomOfNyx> but I got plenty of wiggle room on slow
[03:36:17 CEST] <furq> are you setting thread affinity
[03:36:20 CEST] <PhantomOfNyx> but I've been informed setting threads=28 is a bad idea because you loose quality with this many threads
[03:36:34 CEST] <furq> not really?
[03:36:51 CEST] <furq> losing quality with more threads is only true of slice multithreading
[03:36:55 CEST] <furq> frame multithreading isn't really affected
[03:37:03 CEST] <furq> the speed of using more threads doesn't scale linearly though
[03:37:28 CEST] <PhantomOfNyx> so no quality difference just lower gain per thread ( value )
[03:37:33 CEST] <furq> yeah
[03:37:43 CEST] <furq> i guess if this is 1080p60 then maybe veryslow is a stretch even with a 2950X
[03:37:48 CEST] <furq> or half of one
[03:38:16 CEST] <PhantomOfNyx> Nah I got quad channel memory setup but windows Does NOT like Numa
[03:38:56 CEST] <PhantomOfNyx> but I'm sitting at 1600x900:60
[03:39:03 CEST] <PhantomOfNyx> which honestly takes a fair amount as well
[03:39:18 CEST] <PhantomOfNyx> I could probably handle 720p on slower
[03:39:36 CEST] <PhantomOfNyx> but xsplit doesn't have a slower default profile anyway
[03:39:51 CEST] <PhantomOfNyx> so It's fine I'm just adding on the slow profile. for tweaks
[03:40:35 CEST] <PhantomOfNyx> but quick question would I gain from increasing of lowering my iframes
[03:41:24 CEST] <furq> if you mean keyframe interval then no
[03:41:35 CEST] <furq> higher interval is more efficient but will have higher latency
[03:42:13 CEST] <PhantomOfNyx> Yeah but I was thinking maybe 1 iframe per frame with a 12k buffer
[03:43:06 CEST] <PhantomOfNyx> seems to look the same but at a much lower delay
[03:48:25 CEST] <PhantomOfNyx> furq if I asked really nicely could I get you to take a look at the result ? ( potentially allow me to dm you on discord or the like ? )
[04:15:06 CEST] <fumo> Hi, I'm writing an app in C that integrates the libavcodec library to take some raw image data from a binary file and encode it with the "mpeg2video".  I used the example in the API documentation https://ffmpeg.org/doxygen/trunk/encode_video_8c-example.html as a starting point and my app seems to be working great.  One issue is that when I play the resulting video with VLC, VLC doesn't show the length of the video or increment the time
[04:15:06 CEST] <fumo> as it plays, just shows zeros at both ends as the video plays (the video does play fine though).  Is there something I'm missing to get that working?  maybe something I'm not setting in the frame structure before sending it to the encoder with avcodec_send_frame()? This is first time using any of these libraries or ffmpeg in general.
[05:46:55 CEST] <worstje> I am using the method of different codec concatenation as listed in https://trac.ffmpeg.org/wiki/Concatenate (on Windows), but I am running into a snag known as the command line limit. I realized I can filter_complex_script to take some pressure off, but it is the huge amount of '-i inputfile's that are breaking me up. Is there a way to have ffmpeg look for all the separate inputs in a different file?
[08:25:58 CEST] <kepstin> worstje: you can try using the 'movie' or 'amovie' filters in your filter script rather than inputs on the ffmpeg command line.
[08:28:27 CEST] <worstje> kepstin: Hmm, I'll have to look into those. I was not aware filters could load inputs. I guess it is time to lose a day understanding how filters work in detail, then.
[10:37:07 CEST] <Accord> I'm trying to add a video overlay at the very end of a background video, right now it's one frame short so the last frame of the background video doesn't have the overlay
[10:38:08 CEST] <Accord>     '[0:v] setpts=PTS-STARTPTS [src] ; movie=alpha.mov, trim=0.0:duration=1.163, setpts=PTS-STARTPTS + 5.0/TB, scale=1920:1080 [o1] ; [src][o1] overlay=eof_action=pass [mid1]', '-c:v', 'libx264', '-preset', 'superfast', '-crf', '20', '-pix_fmt', 'yuv420p', '-r', '25.0', '-map', '[mid1]', '-map', '0:a', 'out.mp4']
[10:38:21 CEST] <Accord> sorry
[10:38:22 CEST] <Accord> ['ffmpeg', '-y', '-ss', '3.236', '-t', '6.163', '-i', u'input.mp4', '-filter_complex', '[0:v] setpts=PTS-STARTPTS [src] ; movie=alpha.mov, trim=0.0:duration=1.163, setpts=PTS-STARTPTS + 5.0/TB, scale=1920:1080 [o1] ; [src][o1] overlay=eof_action=pass [mid1]', '-c:v', 'libx264', '-preset', 'superfast', '-crf', '20', '-pix_fmt', 'yuv420p', '-r', '25.0', '-map', '[mid1]', '-map', '0:a', 'out.mp4']
[10:38:54 CEST] <Accord> so the input video has 6.163, the alpha is trimmed to 1.163 and offset to 5.0 seconds
[10:39:15 CEST] <Accord> is there a better way to do this without having to worry about misalignment?
[18:13:48 CEST] <sakrecoer> hi, recently i asked about how to scale a video up in size without aliasing. i need my edges sharp for pixel art. i got a great answer, wrote it down... but i lost the note... :( anybody could give me a hint?
[18:15:46 CEST] <furq> sakrecoer: -vf scale=123:456:flags=neighbor
[18:15:56 CEST] <furq> assuming you're scaling to a multiple of the original size
[18:16:22 CEST] <sakrecoer> thank you so much furq!!!! <3
[18:16:48 CEST] <sakrecoer> backing the note up trice his time! hehe
[18:17:49 CEST] <sakrecoer> furq: "123:456" being the final size i want right?
[18:17:52 CEST] <furq> yeah
[18:18:02 CEST] <sakrecoer> super! cheersÂ!!
[18:18:04 CEST] <furq> only ever use neighbor for upscaling to exact multiples
[18:18:14 CEST] <sakrecoer> noted!
[18:18:28 CEST] <furq> if you just want something sharper than bicubic then use spline or lanczos
[18:20:57 CEST] <sakrecoer> awesome! thank you! :)
[20:10:20 CEST] <Mista_D> can FFMpeg decode source file at specific speed please? Need 1 x RT
[20:11:09 CEST] <JEEB> libavcodec doesn't care, so you'll have to time your decoding yourself in your API usage
[20:12:25 CEST] <durandal_1707> Mista_D: with ffmpeg tool, there is -re switch
[20:13:58 CEST] <Mista_D> durandal_1707: thanks, that works, any way to tweak it? to set at x2.0 RT?
[20:14:08 CEST] <JEEB> nope
[20:14:48 CEST] <JEEB> also it has no back-up mechanism if the timestamps go wee-wee :)
[20:15:03 CEST] <durandal_1707> Mista_D: it is nice hack
[20:17:16 CEST] <furq> you can probably rescale the input framerate and use -re if you want something that isn't realtime
[20:17:31 CEST] <furq> which is definitely a hack but not nice
[21:10:28 CEST] <thebombzen> is there a way to run h264_mp4toannexb on a raw video stream with the avvC data concatenated in front?
[21:56:29 CEST] <analogical> how do I enable audio when I use ffplay in windows?
[22:02:10 CEST] <durandal_1707> analogical: it should already do audio
[23:26:27 CEST] <alimiracle> hi I try useing ffmpeg to copy attachment streams, like subtitles and fonts I use this ffmpeg -y -v error -i video-test.mp4 -map 0 -c:s copy -c:t copy -c:d copy -vn -an -f matroska data.enc but its gave me this error Output file #0 does not contain any stream
[23:27:30 CEST] <alimiracle> hi
[23:27:40 CEST] <alimiracle> I try useing ffmpeg to copy attachment streams, like subtitles
[23:27:50 CEST] <alimiracle> I use this
[23:27:58 CEST] <alimiracle> ffmpeg -y -v error -i video-test.mp4 -map 0 -c:s copy -c:t copy -c:d copy -vn -an -f matroska data.enc
[23:28:19 CEST] <alimiracle> Output file #0 does not contain any stream
[23:30:37 CEST] <relaxed> alimiracle: pastebin.com your output
[23:31:25 CEST] <alimiracle> hay, the error is Output file #0 does not contain any stream
[23:32:56 CEST] <relaxed> try mapping (-map) only the streams you want
[23:35:32 CEST] <alimiracle> relaxed> I nede mapping all the streams
[23:37:09 CEST] <relaxed> except audio and video?  try, ffmpeg -i input -map 0:t -map 0:s -c copy output.mkv
[23:37:38 CEST] <furq> alimiracle: pastebin the full output, not just the error
[23:38:13 CEST] <furq> you probably also don't want to use -c:s copy if the source is mp4 because i don't think anything else supports mov_text
[23:38:49 CEST] <furq> and you'll definitely want -copy_unknown as well
[23:41:53 CEST] <alimiracle> <furq> the error is the full output
[23:50:21 CEST] <furq> well yeah get rid of -v error
[23:58:38 CEST] <alimiracle> this all the error https://paste.kde.org/p3hym0ykk
[23:59:26 CEST] <alimiracle> <furq> this all the error https://paste.kde.org/p3hym0ykk
[00:00:00 CEST] --- Fri Oct 26 2018