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

[burek]

[00:25:21 CET] <TD-Linux> browsers can mostly only handle the limited subset of mkv that is webm
[00:39:12 CET] <JeffATL> all else (clock, cache, ram) being equal, is 64-bit ffmpeg on 64-bit CPU a lot faster than 32-bit ffmpeg on 32-bit CPU?
[00:41:37 CET] <furq> no
[00:42:19 CET] <JeffATL> furq: hmmm
[00:42:26 CET] <furq> 64-bit should be slightly faster on a 64-bit cpu
[00:44:26 CET] <JeffATL> wonder if i should troll goodwill for some more serious 64-bit hardware
[00:45:20 CET] <furq> it's a bit moot because most 64-bit cpus have extensions that no 32-bit cpu has (afaik)
[00:45:37 CET] <JeffATL> i have a pair of 32-bit servers in the rack in the basement with fairly speedy CPUs; one's 1-core and the other is 1-core with hyperthreading
[00:45:40 CET] <furq> i don't think any 32-bit x86 cpus have sse4
[00:45:51 CET] <furq> pentium 4s are not "fairly speedy"
[00:46:23 CET] <furq> x264 also benefits hugely from multiple threads
[00:46:26 CET] <JeffATL> furq: sse4 is a big deal?
[00:46:45 CET] <furq> every little helps
[00:47:02 CET] <furq> there's also the avx stuff on newer i7s
[00:47:22 CET] <matthiaskrgr> new, well ..
[00:47:29 CET] <JeffATL> this amd64x2 that i'm using now only has sse/sse2
[00:47:40 CET] <furq> yeah that's some old stuff
[00:47:49 CET] <matthiaskrgr> I have a cpu from 2011 and it supports avx(1)
[00:47:56 CET] <furq> i've seen pretty cheap first-gen i7 servers on ebay
[00:48:07 CET] <furq> or the xeon equivalents
[00:49:06 CET] <furq> well, very cheap. haswell stuff is pretty cheap
[00:51:06 CET] <furq> http://www.ebay.com/itm/Dell-PowerEdge-R610-Server-2x-Xeon-2-40GHz-6-Core-16GB-RAM-6x146GB-PC319-/332022178116?hash=item4d4e106144:g:-q4AAOSwImRYG7bt
[00:51:16 CET] <furq> there's tons of stuff like that on there which is still relatively powerful
[00:51:25 CET] <JeffATL> yeah, i just dont' have much firepower in ths house right now
[00:52:14 CET] <JeffATL> and what i have access to is a VPN hop and 25 miles away
[00:54:05 CET] <JeffATL> hey furq - what's about the fastest-computing lossless video encoding? writing out an interemediate file in rawvideo worked great but it was also ~350GiB
[00:54:47 CET] <furq> ffvhuff
[00:54:51 CET] <JeffATL> i've got libx264 -crf 0 running now and getting SD at 14fps
[00:55:33 CET] <furq> try with -preset ultrafast
[00:55:52 CET] <furq> ffvhuff is the fastest thing in ffmpeg by some distance but it's not nearly as efficient as ffv1 or x264 lossless
[00:56:33 CET] <furq> try ffv1 as well, that doesn't benefit from many threads as well as x264 does
[00:56:36 CET] <furq> particularly for sd
[00:56:50 CET] <JeffATL> furq: -preset ultrafast gives 100fps
[00:57:00 CET] <furq> nice
[00:57:30 CET] <JeffATL> but that's not lossless, is it? it won't matter much if it's a little lossy
[00:57:42 CET] <furq> the preset makes no difference to whether it's lossless
[00:58:00 CET] <furq> it'll just make the output bigger
[00:58:46 CET] <JeffATL> ffvhuff  120fps
[01:11:36 CET] <JeffATL> looks like kdenlive can read the flvhuff-encoded vid just fine. the entire output will wind up being 79GiB
[01:11:56 CET] <JeffATL> which even on an SSD might not be lovely to load into kdenlive
[01:12:19 CET] <furq> i'd expect x264 to be much smaller
[01:12:53 CET] <JeffATL> libx264 -preset ultrafast -crf 0 gives me 256Mib/minute; without the -crf 0 it's 21MiB/min
[01:13:18 CET] <furq> how big is ffvhuff per minute
[01:13:59 CET] <JeffATL> 331MiB/min
[01:13:59 CET] <mike15161651> can ffmpeg output to ape?
[01:14:06 CET] <furq> no
[01:14:23 CET] <mike15161651> any plugins or anything that would let it?
[01:14:27 CET] <furq> no
[01:14:31 CET] <furq> it can decode ape but not encode it
[01:14:37 CET] <furq> please don't use ape though
[01:14:45 CET] <mike15161651> why?
[01:14:50 CET] <furq> because it's dumb
[01:14:52 CET] <furq> just use flac
[01:15:00 CET] <mike15161651> any particular reason?
[01:15:17 CET] <furq> it's really slow and not supported anywhere
[01:15:23 CET] <furq> and you get maybe 2% extra compression
[01:17:08 CET] <mike15161651> well thanks, good to know; I assume that as such there are no plans to support it in the future either?
[01:17:17 CET] <furq> maybe, maybe not
[01:17:36 CET] <furq> the reference encoder is closed-source so someone would have to care enough to write their own
[01:17:57 CET] <furq> and nobody uses it outside of japan and russia
[01:18:39 CET] <blue_misfit> JeffATL, don't use crf 0
[01:19:00 CET] <blue_misfit> if you want "really really high quality, but not necessarily lossless"
[01:19:13 CET] <blue_misfit> just use crf 2 or something
[01:19:17 CET] <JeffATL> blue_misfit: ok
[01:19:25 CET] <blue_misfit> you can go as low as ~10-14 IMO
[01:19:50 CET] <JeffATL> blue_misfit: fair. my source isn't great anyway
[01:19:54 CET] <blue_misfit> but if you really want something that will be perceptually lossless and survive multi generational encoding you should be looking into something designed for that
[01:19:58 CET] <blue_misfit> ProRes is quite good for tis task
[01:20:11 CET] <blue_misfit> DNxHD is okay too
[01:20:13 CET] <furq> JeffATL: did you try ffv1
[01:20:15 CET] <blue_misfit> both are quite widely supported
[01:21:05 CET] <JeffATL> furq: trying now
[01:22:14 CET] <JeffATL> furq: ffv1 gave me about 50fps and 196MiB/min
[01:23:17 CET] <JeffATL> that's not unreasoable
[01:23:26 CET] <furq> is that a dualcore cpu
[01:23:32 CET] <furq> try with -threads 2 -slices 4
[01:23:40 CET] <JeffATL> furq: yes - two distinct AMD cores
[01:24:25 CET] <JeffATL> furq: with which, ffv1?
[01:25:28 CET] <JeffATL> nm, those are general options
[01:25:53 CET] <furq> i meant for ffv1
[01:26:06 CET] <furq> i don't think -slices does anything with the other two, and you shouldn't use -threads with x264
[01:26:14 CET] <furq> x264 will autoselect the right number of threads
[01:26:16 CET] <JeffATL> furq: 71fps but both cores aren't quite going to 100%
[01:26:31 CET] <furq> maybe try increasing threads and/or slices then
[01:26:52 CET] <furq> probably threads first because slices will decrease compression efficiency
[01:28:24 CET] <JeffATL> furq: increasing threads or slices doesn't seem to make any difference
[01:28:41 CET] <furq> fun
[01:31:22 CET] <JeffATL> barring any objections i'm gonna run with ffmpeg -i M7.mkv -threads 2 -slices 2 -c:a copy -c:v ffv1 ~/M7_intermediate.mkv
[01:31:53 CET] <JeffATL> source fle already d-interlaced and cropped/padded
[01:33:04 CET] <furq> i don't think 2 is a valid value for slices
[01:33:08 CET] <JeffATL> blue_misfit: BTW, what i'm trying to do is write an intermediate file that i can cut up into clips using kdenlive - i'll aac/h264 on the way out of that
[01:33:17 CET] <JeffATL> furq - you're right
[01:33:24 CET] <JeffATL> i meant 4 there
[01:33:26 CET] <furq> oh ok
[01:33:45 CET] <furq> https://trac.ffmpeg.org/wiki/Encode/FFV1
[01:33:53 CET] <furq> you can try messing with some of those other options but idk if they'll do anything
[01:34:22 CET] <furq> iirc you shouldn't touch -g but everything else is fair game
[01:34:23 CET] <JeffATL> i did try 6 slices' no speed improvement
[01:35:51 CET] <blue_misfit> JeffATL, use a small keyint as well
[01:36:03 CET] <blue_misfit> anywhere from .5 to 1 second is fine and will edit nicely
[01:36:16 CET] <blue_misfit> this is all 8 bit 4:2:0 right?
[01:43:45 CET] <JeffATL> blue_misfit: dunno that answer
[01:44:11 CET] <furq> what's the source
[01:45:29 CET] <JeffATL> furq: orignally, mp2/mp2. but my 1st intermediate file that i'm using as source here is mp2/rawvideo
[01:46:00 CET] <JeffATL> next time i won't do this in two stages
[01:46:13 CET] <blue_misfit> mp2 meaning MPEG-2 video and MPEG-1 Layer 2 Audio?
[01:46:42 CET] <furq> mpeg2video only supports yuv420p and yuv422p afaik
[01:46:48 CET] <blue_misfit> correct
[01:46:50 CET] <JeffATL> blue_misfit: ffprobe says "mp2" for audio
[01:46:52 CET] <furq> and if you've done all the conversion with ffmpeg it should preserve that anyway
[01:46:56 CET] <blue_misfit> yeah
[01:47:00 CET] <furq> although it's almost certainly 4:2:0
[05:28:44 CET] <basiclaser> hi whats exit code -4 ? I cant find a comprehensive list of codes.
[05:38:22 CET] <yong> Not exactly an ffmpeg question, but what's the deal with ExactAudioCopy? The program description says it can read audio CDs "almost perfectly", but aren't audio CDs basically just data CDs with .wav pcm_s16le files on them? How would there occur any errors when reading it, assuming it's not so scratched that it's basically broken?
[05:44:27 CET] <furq> yong: no
[05:46:02 CET] <yong> furq: Care to expand on that :p
[05:46:06 CET] <furq> https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_encoding
[05:46:57 CET] <kepstin> audio CDs actually kind of suck, they have very little error correction (data CDs add a big chunk of ECC that reduces capacity) and don't have very accurate seeking (modern drives work around that at least, so they're consistent - but not perfectly aligned)
[05:47:10 CET] <furq> yeah and you have shit like drive offsets to worry about
[05:47:35 CET] <furq> and things like bad implementations of caching and c2
[05:48:02 CET] <furq> it's somewhat rare to get a damaged rip, but if you don't use something like EAC then you'll have no idea that it's damaged
[05:48:08 CET] <kepstin> yeah, the fact that most drives cache erroneous reads - because they don't realize that there are errors - is fun :/
[05:48:32 CET] <furq> i say somewhat rare, i've never ripped a CD with anything other than EAC
[05:48:45 CET] <furq> and i've never seen a cd rip that wasn't done with eac or xld
[05:48:50 CET] <furq> to my knowledge, anyway
[05:49:01 CET] <thebombzen> well some people are weird and rip CDs with things like iTunes
[05:49:09 CET] <furq> i guess those are the only ones that spit out logs so i wouldn't know
[05:49:13 CET] <kepstin> if you're not using EAC, you usually get decent results by just ripping twice and comparing, if they're both the same it's probably ok
[05:49:31 CET] <furq> well that's where accuraterip comes in
[05:49:35 CET] <furq> and CTDB
[05:50:10 CET] <thebombzen> Also keep in mind that something like EAC is less useful nowadays because modern CD drives are very good
[05:50:15 CET] Action: kepstin notes that EAC runs well in wine, or at least it used to
[05:50:21 CET] <furq> which is also handy for finding out that someone's "100%" rip is a 100% rip of a bootleg and is therefore useless
[05:50:41 CET] <furq> not like that happened to me literally five minutes ago or anything
[05:50:51 CET] <kepstin> hmm? modern drives tend to have worse caching than older ones, and other than the accurate seeking improvements aren't really any better
[05:51:03 CET] <thebombzen> no it terms of reading CDs
[05:51:12 CET] <thebombzen> they're better at reading scratched CDs
[05:51:35 CET] <furq> isn't there a database somewhere of the most reliable cd drives
[05:51:41 CET] <yong> So what you're telling me is that I can install an application from a CD without having to worry about byte being corrupted because data CDs have a lot of error correction burned in, but audio CDs don't have that to increase capacity?
[05:51:49 CET] <furq> i'm pretty sure the 10-year-old pioneer drive i've got in my nas is still in the top 10
[05:52:18 CET] <yong> In that case I have a follow up question
[05:52:27 CET] <yong> wtf were these people thinking?
[05:52:28 CET] <kepstin> maybe if you're comparing with *really* old drives, sure, but CD reading tech basically hasn't changed in many years...
[05:52:35 CET] <furq> yong: that and cd drives will just pass redbook read errors through
[05:52:41 CET] <furq> because the worst that'll happen is an audible pop
[05:52:54 CET] <furq> whereas obviously a bit flip in something on a cd-rom is not acceptable
[05:53:28 CET] <yong> I mean how much playtime would've been lost if they just used the same error correction as in data CDs?
[05:53:46 CET] <kepstin> it would be about 80% the runtime
[05:53:58 CET] <furq> redbook predates cd-rom by quite some time iirc
[05:54:05 CET] <thebombzen> CDDA is about 80 minutes so that would reduce it to about 64
[05:54:32 CET] <furq> yeah
[05:54:39 CET] <thebombzen> but given that the precursor was viyl
[05:54:42 CET] <thebombzen> vinyl
[05:54:43 CET] <furq> redbook was 1980, yellow book was 1988
[05:54:51 CET] <kepstin> at the time cdda was created, getting the digital tech to handle that kind of ecc would probably have pushed it even more out of the price range of consumers :/
[05:54:51 CET] <thebombzen> CDDA is really long
[05:56:28 CET] <kepstin> i dunno if you'd say precursor was vinyl; probably tapes (mini cassettes in particular) would be more accurate
[05:56:39 CET] <furq> there are also mode 2 cd-roms which have as much error correction as cdda
[05:56:56 CET] <furq> that was used for stuff like vcd where error concealment was possible
[05:56:59 CET] <kepstin> those are used mostly for VCD applications, I think
[05:57:03 CET] <furq> yeah
[05:57:15 CET] <kepstin> yeah, worse case was you just get some video artifacts, still watchable
[05:57:54 CET] <kepstin> of course, you're talking something like 240p mpeg1 for that, so i'm not sure you could really say it was watchable to start with
[05:57:56 CET] <furq> 13% more capacity apparently
[05:58:14 CET] <furq> so i guess you'd get 70 minutes out of cdda
[05:59:43 CET] <furq> cds are dead anyway so who cares
[06:00:01 CET] <furq> now everything is 24/192 flac the way god intended
[06:00:15 CET] <yong> can you hear the difference?^^
[06:00:25 CET] <furq> no but i can brag about it on the internet
[06:00:30 CET] <furq> and that's what's truly important in life
[06:00:45 CET] <yong> god bless
[06:00:54 CET] <furq> on which note, i have some flac here which was only offered for download in 24/48
[06:01:08 CET] <furq> is there a "right way" to convert that to 16/48 or will pretty much anything give the same result
[06:01:41 CET] <yong> I mean, converting bit depth is really quite uncomplicated
[06:02:05 CET] <yong> You just cut off the lowest 8 bit, maybe do rounding, but I'm not even sure if the difference would be audible
[06:02:08 CET] <furq> well yeah i know how to do it, i just don't know if there's some nuance to it that i'm missing
[06:02:22 CET] <yong> It's not like you could do anything fancy with it like with resampling :p
[06:02:32 CET] <furq> yeah fortunately it isn't 24/96
[06:02:46 CET] <kepstin> if you want to do it properly, you should dither it
[06:03:02 CET] <kepstin> but it would probably be unnoticable, of course
[06:03:16 CET] <furq> i am all about doing things properly for no audible reason
[06:03:38 CET] <furq> can i do it with ffmpeg
[06:03:53 CET] <yong> Would you still need to add dither? I mean, isn't that just to reduce the ADC artifacts?
[06:03:56 CET] <kepstin> good question, I dunno if the ffmpeg converter dithers or not
[06:04:06 CET] <furq> i've got the sox resampler
[06:04:16 CET] <kepstin> sox is supposed to be pretty good, yeah
[06:05:12 CET] <kepstin> dithering reduces some distortion effects due to quantization
[06:05:40 CET] <kepstin> turns correlated noise int uncorrelated noise (white noise, more or less) that's less noticable
[06:06:17 CET] <yong> What's the point of having 96k (or even 192k) sampling rates anyway? I've heard that it's easier to build band limiters for those sample rates, but couldn't you just record with 192khz and then downsample in software essentially losslessly?
[06:06:19 CET] <kepstin> unless you're listening to really quiet audio cranked all the way up, you probably won't notice it either way with 16bit audio :/
[06:07:06 CET] <kepstin> yong: there's basically no point, unless you really need to record ultrasonics for some reason... (recording bat noises maybe?)
[06:07:17 CET] <furq> yong: like i said, bragging on the internet
[06:07:23 CET] <furq> and even off the internet
[06:07:46 CET] <furq> and also it gives you an incentive to buy a bunch of new stuff which you've already got
[06:08:55 CET] <furq> http://audiophile.rocks/sata.html
[06:08:56 CET] <furq> such as this
[06:09:27 CET] <kepstin> most of the 24bit stuff that's out there, they don't even make use of the fact that there's more headroom available in the audio format :/
[06:09:35 CET] <furq> yeah it's just box ticking
[06:09:40 CET] <kepstin> so you still get clipped/limited audio
[06:10:08 CET] <yong> furq: That seems like a very useful cable, but why did they put a black dildo on it?
[06:10:33 CET] <furq> for the purest sound
[06:10:53 CET] <furq> Night is the best SATA cable ever designed, while being much smaller and easier to install than our previous top of the line models like Unreal MEGA and Black Star which were 55mm thick.
[06:11:06 CET] <yong> kepstin: clipped audio? Do 16 bit songs clip a lot? Oo
[06:11:14 CET] <furq> some people have told me that this is a joke site, but i've seen these cables on ebay from third parties
[06:11:18 CET] <furq> so they must actually be for sale
[06:11:23 CET] <kepstin> yong: there's no reason for people to clip audio in 16bit files
[06:12:03 CET] <kepstin> (and indeed in modern stuff they usually don't - instead they use a dynamic range reducing limiter to make peaks get crushed right before they would clip instead)
[06:12:25 CET] <yong> Ouch
[06:12:26 CET] <furq> nice, a 500 EUR network cable
[06:12:28 CET] <kepstin> which is still not really needed, they could just make the audio quieter and it would be fine :/
[06:12:44 CET] <yong> But I guess that's just people trying to master their shit to be really loud
[06:12:45 CET] <yong> yeah
[06:13:22 CET] <furq> yeah people who can't master to 16-bit aren't going to be able to master to 24-bit
[06:13:36 CET] <yong> furq: Maybe it started out as a joke site, but when they realized that people were actually willing to pay $500 for a cable they couldn't resist
[06:13:43 CET] <furq> http://jplay.eu/jcat/
[06:13:50 CET] <furq> this is somehow even worse
[06:14:53 CET] <furq> i should find that article about the japanese guy who spent 4 million yen having a custom audiophile power pole installed in his back yard because the regular non-audiophile power coming off the grid was too noisy
[06:15:09 CET] <kepstin> hey, that's actually something that almost makes sense. Many USB-powered ADCs are really sensitive to noise off USB port power, which isn't well regulated in computers (particularly if plugged into AC)
[06:15:42 CET] <furq> oh sorry, it was only one million yen
[06:15:45 CET] <kepstin> but good ADCs usually have some power conditioning built in (it usually just means adding a cap or two, really)
[06:15:51 CET] <furq> https://www.engadget.com/2016/08/15/japan-audiophiles-install-own-electricity-poles/
[06:16:35 CET] <furq> kepstin: that doesn't excuse the sata and ethernet cables
[06:16:53 CET] <kepstin> (and obviously a good ADC will be clocking off its own crystal rather than attempting to match usb clock)
[06:17:06 CET] <furq> the products themselves aren't nearly as funny as the audiophiles trying to justify their existence on forums
[06:17:12 CET] <yong> Well, I guess if you're connecting a DAC with bad internal voltage control directly to the power line that could actually make a difference in theory?
[06:17:20 CET] <furq> but if i start down that rabbit hole i'll be here till the summer
[06:17:59 CET] <furq> yong: the solution there is to buy a dac with good internal voltage control
[06:18:05 CET] <furq> which probably costs less than $10,000
[06:18:23 CET] <yong> You'd think that, but maybe he wasn't gonna bother reading reviews and shit
[06:18:53 CET] <furq> it's a shame that abx testing reduces sound quality or we'd be able to find out if it helped
[06:19:00 CET] <furq> (yes, i have read someone sincerely state that as fact)
[06:19:58 CET] <yong> It's all about quantum mechanics you know
[06:20:13 CET] <yong> Once you know that you're listening to 32 bit floating point music
[06:20:28 CET] <yong> That's when it has an effect
[06:27:46 CET] <llamapixel> Have robots play the actual instruments, speaker listeners are so 2017...
[06:29:48 CET] <yong> llamapixel: Instruments? The only way to get proper audio quality is to generate it digitally, those damn microphones mess everything up
[06:30:32 CET] <llamapixel> robots and instruments have no microphones between you can your ear hole ;)
[06:33:15 CET] <yong> Still though, instruments don't have 24 bit accuracy, so they're useless
[06:37:49 CET] <llamapixel> https://www.youtube.com/watch?v=evHVh4bqaOQ
[06:39:31 CET] <yong> Hmm so on the off chance that someone here actually heard those speakers: I still have Z-5500's from years ago, how much would I have to spend more or less to get comparable audio quality for stereo music? I'm just wondering how these compare to stereo speakers
[06:39:36 CET] <furq> uncle peter's band is coming along nicely
[06:40:33 CET] <furq> i only really deal with headphones
[06:42:54 CET] <yong> yeah I'm only using headphones too, but I'll spend some time outside of a badly isolated apartment this year, so I was wondering
[07:02:08 CET] <b0br> llamapixel - nice name :)
[07:07:42 CET] <basiclaser> anybody help me find the source of 'ffmpeg exited with code -4' ?
[07:17:23 CET] <basiclaser> is there a place with all the exit codes? i cant find it
[07:36:28 CET] <thebombzen> basiclaser: it's not zero
[07:36:31 CET] <thebombzen> so it's an error
[07:43:11 CET] <thebombzen> furq: I was literally talking to my roommate about silly audiophiles earlier today
[07:43:27 CET] <thebombzen> "Why would you spend 50 dollars on an audio cable?"
[07:43:33 CET] <thebombzen> "Because it has better quality."
[07:43:38 CET] <thebombzen> "But it doesn't have better quality."
[07:43:47 CET] <thebombzen> "Exactly."
[07:47:22 CET] <llamapixel> Presbycusis
[07:51:34 CET] <furq> $50? bargain
[07:53:02 CET] <furq> at least with analogue interconnects there is at least the possibility that it sounds better
[07:53:59 CET] <furq> the $500 sata/ethernet/hdmi cables (all gold-plated and oxygen-free of course) are the really tragic ones
[07:54:15 CET] <furq> make sure you plug your sata cable in the right way round!
[07:55:09 CET] <furq> i should dig up that forum thread where a guy is sincerely arguing that aiff sounds better than wav
[07:55:27 CET] <furq> obviously flac is no good, that goes without saying
[08:10:00 CET] <dysfigured> can anyone help me figure out why my x11grab script produces such poor quality? https://github.com/DanielFGray/yaxg/blob/master/yaxg#L174
[08:19:44 CET] <durandal_170> furq: give the forum thread
[08:21:34 CET] <thebombzen> wait
[08:21:40 CET] <thebombzen> "aiff sounds better than wav"
[08:21:41 CET] <thebombzen> um
[08:21:49 CET] <thebombzen> that one's even worse than flac
[08:21:56 CET] <thebombzen> cause they're both uncompressed pcm
[08:23:04 CET] <thebombzen> dysfigured: maybe because
[08:23:15 CET] <thebombzen> you're recording your screen to 2400 kbps vp8?
[08:25:16 CET] <yong> furq: You know what's worse than $500 sata cables? Youtube still using limited color range
[08:25:23 CET] <dysfigured> tbh half of this stuff is way over my head and i have barely a clue what i'm doing with ffmpeg. pretty sure i just stole that off stackoverflow
[08:25:26 CET] <yong> I just don't get it, are they trying to be compatible with 90's TVs?
[08:25:33 CET] <dysfigured> thebombzen: what would i change to make it better
[08:25:55 CET] <thebombzen> increase the bitrate
[08:26:08 CET] <thebombzen> 2400 kbps is low for 1080p vp8
[08:26:25 CET] <thebombzen> yong: what do you mean?
[08:26:31 CET] <yong> dysfigured: What are you trying to do with the recording?
[08:26:42 CET] <dysfigured> create a high-quality recording of the screen
[08:26:50 CET] <yong> Local?
[08:27:03 CET] <dysfigured> yeah, whatever i'm doing on my desktop
[08:27:03 CET] <yong> Does the codec matter to you? Do you need vp8?
[08:27:04 CET] <thebombzen> I would use x264, not vp8
[08:27:36 CET] <dysfigured> i don't really care what it is, as long as it's webm
[08:28:17 CET] <yong> dysfigured: try changing -c:v libvpx to -c:v libx264 and -b:v 2400k to -b:v 50000k, or alternatively -crf 18, and -preset veryslow to -preset veryfast
[08:28:41 CET] <yong> That should give you a visually lossless recording
[08:29:06 CET] <kerio> yong: -qp 0
[08:29:07 CET] <thebombzen> although you'd need to change -f webm to -f matroska
[08:29:13 CET] <thebombzen> kerio: "visually"
[08:29:28 CET] <kerio> -c:v libx264rgb -qp 0
[08:29:35 CET] <kerio> or you're a pleb
[08:29:38 CET] <thebombzen> well
[08:29:45 CET] <thebombzen> not everyone wants to do that
[08:29:53 CET] <thebombzen> I do that tho
[08:30:00 CET] <dysfigured>  Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM
[08:30:04 CET] <yong> thebombzen: My comment about youtube? YouTube uses limited (yuv420p, 16-235) color range instead of full (yuvj420p, 0-255) color range. No idea why
[08:30:20 CET] <yong> dysfigured: Do you need a webm container?
[08:30:22 CET] <kerio> does libx264rgb actually encode 24bpp
[08:30:26 CET] <thebombzen> yong: using limited colored range is fairly standard
[08:30:38 CET] <dysfigured> yong: yes
[08:30:40 CET] <yong> dysfigured: Otherwise change -f webm to -f mp4 or -f mov or -f mkv
[08:30:43 CET] <yong> Hmmm
[08:30:45 CET] <kerio> dysfigured: if you need webm and you want to record directly to webm, then you have to use vp9
[08:30:48 CET] <kerio> ...but why, tho
[08:30:57 CET] <thebombzen> kerio: why?
[08:30:59 CET] <dysfigured> for image board uploads that only support webm
[08:31:05 CET] <yong> dysfigured: Why do you need webm? That's annoying because vp8 is meh and vp9 is really, really slow
[08:31:07 CET] <thebombzen> kerio: why not record to vp8?
[08:31:16 CET] <kerio> ...because vp9 is better?
[08:31:18 CET] <thebombzen> vp9 is too slow to record in realtime
[08:31:26 CET] <kerio> is it now :o
[08:31:29 CET] <thebombzen> yes it is
[08:31:39 CET] <dysfigured> what about recording to mp4 and making a second pass and converting to webm afterwards?
[08:31:45 CET] <kerio> oh wait vp9 is the chinese bootleg hevc
[08:31:50 CET] <kerio> yea make it vp8
[08:32:31 CET] <thebombzen> I believe the term is "pushed Google HEVC"
[08:32:53 CET] <yong> dysfigured: If you want to upload it to a website or something, it's usually better to make a really high quality local recording (with libx264 and -preset veryfast or even ultrafast, and qp 18/crf 18/b:v 50000k), and then re-encode to something you can upload (with -preset slow)
[08:33:10 CET] <thebombzen> yong: this is 2017, we use crf with x264
[08:33:34 CET] <thebombzen> there's really not a reason to NOT use -b:v if you're going to transcode it anyway
[08:33:42 CET] <thebombzen> so there's really not a reason TO use it
[08:33:43 CET] <thebombzen> lol
[08:34:25 CET] <thebombzen> -crf is the best rate control in terms of quality per bitrate (and lets you target a constant quality!) so that's nice but it can be impractical for streaming
[08:34:30 CET] <thebombzen> but if you're not streaming it then whatevs
[08:35:04 CET] <yong> Well, in my experience re-encoding abr/cbr content looks better (my guess is that the minrate never drops below some threshold), although I don't have conclusive evidence for that
[08:35:18 CET] <yong> But depending on the content (just showing a few windows with text), abr might be super wasteful
[08:35:28 CET] <dysfigured> if i'm being honest, all of this is greek to me. i just wanted to make a script that records high quality webms you can upload, i don't mind making the user wait for transcode process
[08:35:44 CET] <thebombzen> wait you want to write a script that lets someone ELSE do this?
[08:35:56 CET] <dysfigured> yes.
[08:35:59 CET] <thebombzen> Because that has been done before
[08:36:10 CET] <dysfigured> this is a bit different
[08:36:29 CET] <dysfigured> https://github.com/DanielFGray/yaxg/
[08:37:37 CET] <dysfigured> the goal is to give the same api for capturing webms gifs or pngs, and adding a callback functionality for "post-processing"
[08:37:58 CET] <dysfigured> it currently uses byzanz-record for gifs, which is horrible and i want to drop it for plain ffmpeg
[08:37:59 CET] <thebombzen> why do you keep saying "capturing webms"
[08:38:03 CET] <thebombzen> the phrase is "capturing videos"
[08:38:13 CET] <thebombzen> or "capturing images"
[08:38:18 CET] <thebombzen> not "webms" and "pngs"
[08:39:01 CET] <dysfigured> well it's pretty picky about the formats, so it seems relevant
[08:40:34 CET] <thebombzen> well tbh you shouldn't be grabbing directly to GIFs
[08:40:41 CET] <thebombzen> you should be grabbing to video
[08:40:46 CET] <thebombzen> and then convert to GIF afterward
[08:40:53 CET] <thebombzen> given that the best way to do that in ffmpeg requires two passes
[08:41:20 CET] <dysfigured> i agree, it's just ffmpeg is a beast i'm not well acquainted with
[08:41:49 CET] <thebombzen> also what is "it"
[08:41:54 CET] <thebombzen> you said "it's pretty picky"
[08:41:57 CET] <yong> ^
[08:42:05 CET] <dysfigured> the script, i linked it above
[08:42:29 CET] <thebombzen> um
[08:42:30 CET] <yong> isnt that your script
[08:42:32 CET] <thebombzen> you write the script
[08:42:34 CET] <dysfigured> yes.
[08:42:37 CET] <thebombzen> you don't /have/ to make it picky
[08:43:09 CET] <dysfigured> the goal is to produce pngs or webms or gifs
[08:43:21 CET] <thebombzen> no the goal is to produce images or videos or gifs
[08:43:34 CET] <thebombzen> there's no reason the videos have to be webms
[08:43:40 CET] <thebombzen> that's a design decision on your part
[08:43:45 CET] <thebombzen> (and a poor one tbh)
[08:44:04 CET] <dysfigured> yes, that's the design decision i made, to only support those formats.
[08:44:43 CET] <thebombzen> well then you have to live with the fact that you've chosen to restrict yourself to inferior formats
[08:45:39 CET] <thebombzen> /especially/ since most websites will transcode any video you upload anyway
[08:45:51 CET] <thebombzen> like if you upload a webm to youtube, it'll re-encode it
[08:46:11 CET] <dysfigured> currently it's recording directly to webm, if it's better to record to a better container format and transcode afterwards, i'll throw in an option to not remove the original 'raw' footage
[08:47:39 CET] <yong> Well, the thing is that libx264 is the most efficient video encoder in existence by far, but webm doesn't support h264
[08:48:01 CET] <yong> So your script isn't gonna be very efficient if you want webm
[08:48:32 CET] <dysfigured> efficiency is a secondary goal to easy of use
[08:48:48 CET] <yong> If you dont mind waiting for a long transcode, then record to mp4, and transcode to vp9/webm
[08:48:59 CET] <dysfigured> i don't mind waiting for a longer transcode
[08:50:08 CET] <yong> Also, do you really want yuv444p? Seems odd in a webm
[08:50:33 CET] <dysfigured> i have no idea what that even is. like i say i'm pretty sure i just yoinked it from a SO thread
[08:51:04 CET] <dysfigured> or maybe it was ubuntu forums..
[08:51:53 CET] <yong> well, then after specifying the duration (line 178), for the recording you want "-c:v libx264 -crf 18 -preset ultrafast -r 60 -pix_fmt yuv420p -f mp4 "$file""
[08:52:05 CET] <yong> and then you transcode that to vp9
[08:54:20 CET] <dysfigured> so i'm gonna start a couple new functions, one that just records the screen in a high quality format, then a couple more for transcoding that into webm and gif..?
[08:55:02 CET] <yong> I guess
[08:57:54 CET] <yong> ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 1500k -keyint_min 150 -g 150 -f webm -dash 1 video.webm
[08:58:10 CET] <yong> That's probably the more or less correct way to encode a webm for DASH
[08:58:27 CET] <yong> What bitrate you want obviously depends on what the video consists of
[08:58:43 CET] <yong> http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-adaptive-webm-using-dash
[08:58:44 CET] <thebombzen> yong: don't record to mp4
[08:58:49 CET] <thebombzen> if the program crashes the file won't be readable
[08:58:56 CET] <thebombzen> I recommend recording to matroska instead
[08:59:08 CET] <thebombzen> -f matroska
[08:59:25 CET] <thebombzen> mp4 has a table of contents in the file that's written once it's done
[08:59:43 CET] <thebombzen> (that's the moov atom)
[08:59:49 CET] <yong> Or you just add -faststart
[08:59:54 CET] <yong> And it'll be at the start
[08:59:58 CET] <thebombzen> yong: not quite
[09:00:15 CET] <yong> That doesn't work?
[09:00:16 CET] <thebombzen> if you add -movflags +faststart it just performs a second pass over the file, once it's written
[09:00:27 CET] <yong> Hmm
[09:00:33 CET] <thebombzen> well it's a table of contents
[09:00:42 CET] <yong> Weird though, pretty sure vlc and ffmpeg can read it either way
[09:00:48 CET] <thebombzen> no they won't
[09:00:59 CET] <yong> For example, if you record with OBS and it crashes, the video file works fine
[09:01:25 CET] <yong> Is OBS just re-writing the moov atom every second?
[09:01:41 CET] <thebombzen> are you recording to mp4?
[09:01:45 CET] <yong> Yeah
[09:02:08 CET] <thebombzen> my guess is obs probably has a subprocess doing the recording
[09:02:10 CET] <thebombzen> to fix that
[09:02:33 CET] <kerio> half of #ffmpeg is getting people to stop using options that they don't understand
[09:02:40 CET] <thebombzen> lol
[09:02:44 CET] <thebombzen> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x564ceed10580] moov atom not found
[09:02:44 CET] <thebombzen> grab.mp4: Invalid data found when processing input
[09:02:54 CET] <ritsuka> you can write a fragmented mp4 to avoid that issue (I don't know how to make ffmpeg  do it but whatever)
[09:02:54 CET] <thebombzen> that's what'll happen if you try to read from the file after a crash
[09:03:15 CET] <kerio> another quarter is getting people to use x264 instead of whatever random codec they happened to copypaste
[09:03:25 CET] <yong> mkv has this weird fps thing that is annoying, the timestamp res is only 16.666 or something like that and tbn is 1000
[09:03:36 CET] <yong> So VLC shows 60.002400 fps
[09:03:42 CET] <thebombzen> ritsuka: I think it's -movflags +frag_keyframe
[09:03:43 CET] <yong> And my OCD kicks in every time I see that
[09:04:04 CET] <yong> Does .mov have the moov atom at the end as well?
[09:04:06 CET] <thebombzen> yong: what are you talking about
[09:04:11 CET] <thebombzen> mp4 is based on mov
[09:04:14 CET] <thebombzen> so yes
[09:04:15 CET] <yong> rip
[09:04:27 CET] <thebombzen> but yong what do you mean "mkv has this weird fps thing"
[09:04:46 CET] <thebombzen> if you're talking about the timebase, it's not limited to 1000
[09:05:07 CET] <yong> thebombzen: Try making a video from a picture with -loop 1 and -framerate 60, -libx264 test.mkv
[09:05:19 CET] <yong> and then open it with VLC and check the codec
[09:05:24 CET] <yong> it'll show 60.002400 fps
[09:12:53 CET] <dysfigured> daaaaamn this transcode process takes foreeeevvveeerrrr even for just a 2 second clip
[09:13:25 CET] <kerio> what's the obsession with webm again?
[09:13:42 CET] <dysfigured> all these image boards only support webm or gif uploads
[09:14:01 CET] <dysfigured> well, jpg and png too
[09:14:27 CET] <dysfigured> jpg is trash though, i can't stand those artifacts
[09:14:46 CET] <thebombzen> jpeg is not trash
[09:14:52 CET] <yong> dysfigured: You mean like imgur?
[09:14:58 CET] <dysfigured> it looks like trash to me
[09:15:14 CET] <dysfigured> if i'm being honest, i'm specifically talking about 4chan
[09:15:30 CET] <yong> Hm, no idea then. But imgur allows mp4 as well
[09:15:38 CET] <yong> Their rules are retarded though
[09:15:55 CET] <yong> They have a time limit on videos (15s I think?) but not on gifs
[09:15:56 CET] <dysfigured> content rules?
[09:16:18 CET] <dysfigured> ohh
[09:16:21 CET] <dysfigured> that's weird
[09:16:39 CET] <dysfigured> what thell his gifv then
[09:16:44 CET] <yong> So if you want to upload a 20 second video to imgur (because let's face it, gifs are dead, you want the .gifv)
[09:16:46 CET] <dysfigured> *what the hell
[09:16:55 CET] <yong> You have to convert from mp4 to gif
[09:17:03 CET] <yong> Which blows the file size way up and decreases quality
[09:17:11 CET] <thebombzen> https://0x0.st/WK2.jpg
[09:17:13 CET] <yong> Only so they can encode to "essentially mp4" (gifv) again
[09:17:16 CET] <thebombzen> "jpegs are trash"
[09:20:08 CET] <dysfigured> well played. doesn't look like trash at all.
[09:23:16 CET] <dysfigured> this script http://twily.info/s/scripts/screencast seems to take the same approach of record to mp4 and convert to webm afterwards... but the script itself is horrible. i've tried to just yoink what the ffmpeg options are but i can never seem to get them to work right..
[09:25:28 CET] <thebombzen> this jpeg was converted at 90% quality
[09:25:39 CET] <thebombzen> if you set it to 95 it's even harder to tell
[09:26:06 CET] <dysfigured> still, png is lossless right, why not just use that?
[09:26:18 CET] <thebombzen> file size
[09:26:28 CET] <dysfigured> optipng
[09:27:15 CET] <thebombzen> ?
[09:28:31 CET] <dysfigured> http://freecode.com/projects/optipng  should be in your repos
[09:30:01 CET] <yong> Hmmm, YouTube doesn't seem to like 709 color space
[09:30:27 CET] <yong> You'd think they'd use it... but apparently all their encoded videos are 601 too
[09:35:27 CET] <ritsuka> yong: mp4 or webm? I see some h.264 mp4 that are properly tagged
[09:36:23 CET] <thebombzen> dysfigured: didn't help much
[09:36:52 CET] <thebombzen> keep in mind I'm comparing a 200k jpeg to a 1.7M png
[09:37:05 CET] <thebombzen> that's a factor of 8.5
[09:37:24 CET] <dysfigured> interesting. what'd you grab the png with?
[09:38:17 CET] <thebombzen> ffmpeg -i input.mkv -frames 1 output.png
[09:38:33 CET] <thebombzen> after running optipng -o7 it reduced it to 1.4 M
[09:38:38 CET] <thebombzen> but that's still 7 times the filesize
[09:38:54 CET] <yong> ritsuka: I'm uploading mov because ffmpeg doesn't like including lossless audio in mp4 files, not even pcm_s16le and mov supports alac. Looking at it with ffprobe, the source mov is correctly tagged as 709, but the mov that ffmpeg put out (after re-encoding) doesn't have a color space tag. VLC plays it correctly, but maybe that's what getting YouTube confused? Ima try to upload a full range 709 test video
[09:40:39 CET] <thebombzen> yong: have you considered using matroska
[09:41:16 CET] <yong> thebombzen: As soon as I can get VLC to show 60 FPS for it, sure :p
[09:41:37 CET] <thebombzen> dysfigured: you can get reasonable file sizes with png if you're looking a screenshot of something in a toolkit window
[09:41:47 CET] <thebombzen> like a screenshot of some text
[09:41:50 CET] <yong> Hmmm the full range 709 recording looks way too dark already, weird
[09:41:59 CET] <thebombzen> but once it gets more complicated, pngs go into the megabyte range
[09:42:08 CET] <thebombzen> which is too much if you've got several of them
[09:42:19 CET] <thebombzen> (well, too much compared to jpg)
[09:42:32 CET] <thebombzen> jpegs are best in places where pngs suck anyway
[09:42:47 CET] <ritsuka> yong: for example this random youtube video https://www.youtube.com/watch?v=JGwWNGJdvx8 , mediainfo tells its BT.709
[09:44:59 CET] <dysfigured> you make a convincing argument, i'm adding jpg support
[09:45:43 CET] <dysfigured> maybe my gripe with jpeg isn't the format itself, just that image hosts love to compress the fuck out of it
[09:46:02 CET] <yong> ritsuka: Yeah it might be because the tag is missing - but why does ffmpeg remove it? Maybe I'll have to explicitly tell it the color space
[09:46:25 CET] <ritsuka> is your mov tagged at container level or in the h.264 stream?
[09:47:32 CET] <thebombzen> dysfigured: sometimes you can fool them tho
[09:47:43 CET] <thebombzen> like facebook sees png and goes "omg big" and will make it a reallyshit jpeg
[09:48:08 CET] <thebombzen> but sometimes if save is as jpg with 100% quality
[09:48:12 CET] <thebombzen> it won't convert it
[09:48:20 CET] <thebombzen> but I know what you mean
[09:48:29 CET] <thebombzen> but sometimes for an image like this one: https://0x0.st/WKf.png
[09:48:34 CET] <thebombzen> png is just terrible
[09:48:42 CET] <yong> ritsuka: The source mov is tagged at stream level, at least that's where ffprobe shows it "yuv420p(tv, bt709/unknown/unknown)"
[09:49:20 CET] <yong> The mov after encoding just shows "yuv420p"
[09:49:29 CET] <ritsuka> try to set all three, not just one piece of the tag
[09:50:21 CET] <thebombzen> oh wow it's almost 4 a.m.
[09:50:23 CET] <thebombzen> I should go to bed
[10:01:34 CET] <Franciman> Hi, is there a way to always correctly determine an audio stream's channel layout?
[10:30:56 CET] <yong> ritsuka: Hm, even if I tag the mov file with  -color_primaries bt709 -color_trc bt709 -colorspace bt709, and ffprobe tells me "yuv420p(tv, bt709)", youtube still gets the colors wrong
[10:54:49 CET] <ChocolateArmpits> yong, How are they wrong? Did you try downloading the encoded video using youtube-dl and comparing it directly with the original using a (software) waveform or vectorscope monitor ?
[11:07:17 CET] <yong> ChocolateArmpits: The file itself is actually fine, it's tagged correctly and it plays with all colors looking fine. I think it's chrome's video player
[11:08:05 CET] <ChocolateArmpits> yong, so it might be a hardware acceleration problem if your graphics drivers aren't set up correctly
[11:09:17 CET] <yong> ChocolateArmpits: I mean, VLC and MPC-HC are also using hw acceleration right?
[11:44:10 CET] <ChocolateArmpits> yong, depends how they are set up. There are different render engines. I can't really comment
[11:44:53 CET] <ChocolateArmpits> That's why unless you have a stable and tested setup I would advise a good old waveform check
[14:15:09 CET] <rodmacedo> hi all
[14:15:20 CET] <rodmacedo> I have a tricky question: does ffpmpeg support SMPTE 436M CC data information?
[14:15:48 CET] <rodmacedo> Is there a way to remap audio streams keeping the video and data untouched ?
[14:17:19 CET] <Franciman> rodmacedo, I think so
[14:17:27 CET] <Franciman> (for the second question)
[14:17:41 CET] <Franciman> you just manipulate the audio stream and leave alone the other streams
[14:17:49 CET] <Franciman> I think it'll work
[14:18:34 CET] <rodmacedo> unfortunately not.
[14:18:40 CET] <Franciman> why?
[14:19:58 CET] <rodmacedo> I dont know why, but I am sure I lose the cc information in the output file
[14:21:34 CET] <rodmacedo> this is the command I am using: ffmpeg -i input-file.mxf -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -map 0:5 -map 0:5 -map 0:5 -map 0:5 -map 0:7 -map 0:8 -c copy output-file.mxf
[14:21:35 CET] <Franciman> oh, I see
[14:22:29 CET] <rodmacedo> and the cc information present in the input-file is not present int the output
[14:22:46 CET] <rodmacedo> can you help me?
[14:23:27 CET] <Franciman> rodmacedo, I'll try, but I think I won't
[14:23:34 CET] <Franciman> can't*
[14:25:16 CET] <rodmacedo> sorry
[14:26:18 CET] <Franciman> rodmacedo, yeah, the output could help
[14:34:13 CET] <rodmacedo> Please
[14:34:29 CET] <rodmacedo> check the details here: http://pastebin.com/fXJcei9d
[14:36:03 CET] <rodmacedo> I dont even refer to the data inside the original file and it is lost in the output
[14:36:19 CET] <rodmacedo> I am doing the right way?
[14:51:01 CET] <rodmacedo> Franciman: did you see my code?
[14:55:38 CET] <durandal_170> rodmacedo: you need to copy data stream too
[15:09:42 CET] <rodmacedo> whats the command syntax?
[15:09:54 CET] <rodmacedo> somebody can help me?
[15:16:30 CET] <Franciman> rodmacedo, sorry, here I am. I'll look at it, now
[15:27:08 CET] <mape_> I'm trying to capture my screen and stream it using http://jsmpeg.com/ but regardless of what I try to set I can't seem to get more then around 20fps on 1440p and 30 on 1080p
[15:27:28 CET] <mape_> Am I missing some arguments? http://pastebin.com/XJLXw5Dn
[15:31:06 CET] <BtbN> why would you use mpeg1 and mp2 for video streaming?
[15:32:43 CET] <mape_> BtbN: jsmpeg gives me lower latency
[15:33:06 CET] <BtbN> than what?
[15:34:00 CET] <mape_> HLS
[15:34:25 CET] <BtbN> don't use HLS then
[15:39:01 CET] <mape_> BtbN: So what would you recommend I use instead if I want to get sub 100ms latency and not use a flash player in the browser to decode?
[15:40:35 CET] <BtbN> sub 100ms is not going to happen
[15:40:52 CET] <BtbN> encoder and decoder alone has more latency, plus network latency and everything
[15:41:14 CET] <mape_> BtbN: That is what I have currently with what I pasted
[15:42:21 CET] <BtbN> there is some botched mp4 format that can be streamed and most browsers understand
[15:43:31 CET] <kepstin> if you can do webrtc, that would get you pretty good latency...
[15:43:34 CET] <mape_> Sure, but have any idea why I'm getting low fps with the solution I'm currently using?
[15:44:14 CET] <BtbN> Because it's a JavaScript video decoder.
[15:44:31 CET] <BtbN> Those things aren't exactly fast
[15:44:41 CET] <mape_> The javascript decode has nothing to do with the ffmpeg encoding?
[15:45:11 CET] <kepstin> oh, you're using gdigrab? That's not exactly known for speed
[15:45:12 CET] <BtbN> is it still slow if you don't encode it and just output it to -f null?
[15:45:16 CET] <kepstin> if you're getting 20fps it's doing well
[15:45:28 CET] <BtbN> at 1440p even
[15:45:30 CET] <kepstin> limitations of windows api and graphics card drivers
[15:45:42 CET] <kepstin> if you want faster, you need to use a proper gpu based capture driver, try obs
[15:45:46 CET] <BtbN> Use OBS if you want performant desktop capture I guess
[15:50:59 CET] <mape_> Well if I just use gdigrab and put it into test.mpeg I get 60fps, if I instead put it into test.ts I get 20fps
[15:54:39 CET] <BtbN> even if you output the test.ts to the local file system instead?
[15:55:08 CET] <mape_> Yes
[15:55:25 CET] <mape_> So seems like some artificial fps cap
[15:59:07 CET] <BtbN> Or a super slow storage
[15:59:21 CET] <BtbN> there is no artificial fps cap anywhere, unless you enforce one somehow.
[16:00:13 CET] <kerio> hold on
[16:00:17 CET] <kerio> why does that jsmpeg thing talk about no patents
[16:00:19 CET] <kerio> when it's using mpegts
[16:00:41 CET] <BtbN> beause they have no idea there are patents on that as well
[16:00:47 CET] <mape_> Ok thanks for your help
[16:00:57 CET] <kerio> someone's mad
[16:54:10 CET] <jubalh> hi
[16:57:13 CET] <jubalh> i have several mp4 files. i would like to add all of them together into one video and have chapters for each of them. so i wondered: is there even a video format that has chapters? :) can ffmpeg help me acomplish what i try to do?
[16:59:26 CET] <c_14> It's possible, but not easy. You'd have to do the concatenation stuff and then also create an ffmetadata file that contains the chapter start and end points
[17:00:19 CET] <jubalh> the concatenation doesnt sound to hard does it?
[17:01:42 CET] <c_14> https://trac.ffmpeg.org/wiki/Concatenate
[17:04:26 CET] <jubalh> seems like baically its just listing all the files in a txt file
[17:04:35 CET] <jubalh> i am more confsued about the ffmetadata
[17:04:39 CET] <c_14> https://ffmpeg.org/ffmpeg-formats.html#Metadata-1
[17:05:42 CET] <c_14> What I'd do is concatenate the files, then use the first command listed there to generate an FFMETADATA file and then modify it in a text editor to add the chapters
[17:06:59 CET] <jubalh> whats a STREAM? i only need to concern myself with chapters, i guess?
[17:07:07 CET] <c_14> yeah
[17:07:17 CET] <c_14> all the other information will already be there because it's sourced from the concatenated file
[17:07:34 CET] <jubalh> ok very good
[17:07:36 CET] <jubalh> thanks c_14
[17:26:55 CET] <jubalh> that didnt work at all :/
[17:27:18 CET] <jubalh> the outputted video is 5 minutes but already the first of 7 part videos is 23 minutes
[17:27:38 CET] <jubalh> i used: ffmpeg -f concat -safe 0 -i files.txt -c copy output.mp4
[17:28:45 CET] <jubalh> though the outputted file is very big
[17:36:42 CET] <jubalh> c_14: any idea where something could have gone wrong?
[17:38:36 CET] <thebombzen> generally can't -c copy with concat input
[17:39:06 CET] <c_14> Are the files the same resolution, codec, pixel format...
[17:39:25 CET] <jubalh> thebombzen: isnt tha what https://trac.ffmpeg.org/wiki/Concatenate suggests?
[17:39:29 CET] <jubalh> c_14: i will check
[17:39:59 CET] <thebombzen> only works for some codecs, and everything has to be the same
[17:40:24 CET] <thebombzen> the general rule is if you do anything interesting to the stream, you can't copy it
[17:40:28 CET] <thebombzen> there are some exceptions
[17:41:20 CET] <jubalh> it seems the resolution of one video is different
[17:41:20 CET] <c_14> What you can try is to remux all the inputs to mpegts and then just cat those together
[17:42:01 CET] <jubalh> how to do that?
[17:42:23 CET] <c_14> ffmpeg -i file.mp4 -c copy -map 0 file.ts
[17:42:39 CET] <c_14> use your shell to loop that for all the files
[17:42:45 CET] <c_14> then just cat *.ts > new.ts
[17:42:55 CET] <c_14> (you have to cat them in the right order)
[18:55:12 CET] <thebombzen> huh, it appears libx264rgb doesn't like 10-bit input
[18:57:36 CET] <thebombzen> it does this http://0x0.st/WP1.jpg
[18:58:03 CET] <thebombzen> if I run: ffmpeg -f x11grab -video_size 1920x1080 -i :0.0 -c libx264rgb -qp 0 -preset ultrafast -y grab.mkv but instead I have  10bit x264 installed
[18:58:06 CET] <thebombzen> it creates this crap
[18:58:37 CET] <kerio> thebombzen: when you say 10
[18:58:42 CET] <kerio> you mean per channel?
[18:58:45 CET] <thebombzen> yea
[18:58:49 CET] <thebombzen> that's what 10bit means
[19:00:07 CET] <thebombzen> oh hey that's even worse
[19:00:11 CET] <thebombzen> if I add: -vf format=gbrp10le
[19:00:19 CET] <thebombzen> Segmentation fault (core dumped)
[19:01:59 CET] <durandal_1707> thebombzen: what version?
[19:03:26 CET] <thebombzen> N-62844-gb1e2192007
[19:03:30 CET] <thebombzen> I built it recently
[19:03:35 CET] <thebombzen> lemme rebuild from git master and try again
[19:06:32 CET] <furq> nice
[19:06:40 CET] <furq> i've got an old build with 10-bit x264 and it's totally screwed
[19:09:18 CET] <kerio> 10 bit is the devil's work anyway
[19:09:31 CET] <kerio> 4 bits are enough for everyone
[19:10:02 CET] <furq> thebombzen: what do you get from -h encoder=libx264rgb | grep pixel\ formats
[19:10:34 CET] <furq> is it full of lies
[19:11:00 CET] <thebombzen> furq: interestly, it lists bgr0 rgb24 and bgr24
[19:11:06 CET] <furq> yeah mine does the same
[19:11:21 CET] <furq> if i do -pix_fmt rgb24 it flags the output stream as rgb24, but it very much isn't
[19:11:53 CET] <furq> mpv detects it as gbrp10le and it all looks fucked
[19:12:52 CET] <thebombzen> I think it's an x264 error
[19:13:12 CET] <furq> maybe that path just hasn't been wired up properly in ffmpeg
[19:13:13 CET] <thebombzen> so I grabbed the bgr0 to ffv1-in-mkv
[19:13:23 CET] <furq> but yeah maybe x264rgb in 10-bit mode is just broken
[19:13:28 CET] <thebombzen> this works: ffmpeg -i grab.mkv -vf format=gbrp10le -c libx264rgb -qp 0 -preset fast -f null -
[19:13:47 CET] <thebombzen> this crashes: ffmpeg -i grab.mkv -vf format=gbrp10le -c libx264rgb -qp 0 -preset faster -f null -
[19:14:00 CET] <furq> lol what
[19:14:46 CET] <thebombzen> yea
[19:14:50 CET] <thebombzen> probably just a libx264 but
[19:15:04 CET] <thebombzen> I don't think it's ffmpeg's problem
[19:15:09 CET] <furq> http://vpaste.net/pSRT6
[19:15:10 CET] <thebombzen> also every preset faster than "faster" also crashes
[19:15:33 CET] <furq> does faster give correct output
[19:15:34 CET] <furq> it doesn't here
[19:16:28 CET] <thebombzen> -preset fast doesn't crash the encoder
[19:16:33 CET] <thebombzen> it just creates an invalid bitstream
[19:16:38 CET] <thebombzen> -preset faster will crash it
[19:16:45 CET] <furq> yeah i meant fast
[19:17:00 CET] <furq> looks like you're using ffv1 then
[19:17:03 CET] <thebombzen> but by invalid bitsream
[19:17:25 CET] <thebombzen> I mean decoder spits errors and outputs this: http://0x0.st/WP2.jpg
[19:17:34 CET] <furq> nice
[19:17:39 CET] <furq> i at least get something vaguely recognisable
[19:17:47 CET] <thebombzen> I do too
[19:17:56 CET] <thebombzen> you can see my quicklaunch bar at the top
[19:18:23 CET] <furq> http://i.imgur.com/gkR7ydJ.jpg
[19:18:45 CET] <thebombzen> oh look rgb
[19:18:46 CET] <thebombzen> hmmm
[19:21:08 CET] <thebombzen> none of the presets after "fast" produce anything better
[19:21:16 CET] <thebombzen> this is sort of the most I actually could do http://0x0.st/WPO.jpg
[20:52:39 CET] <kerio> is this the place to rant about awful codecs found in pirated movies
[20:53:44 CET] <durandal_1707> yes
[20:54:04 CET] <kerio> fuck divx
[20:57:47 CET] <furq> what about 3ivc
[20:57:49 CET] <furq> 3ivx
[20:59:33 CET] <JEEB> lol
[20:59:42 CET] <JEEB> you remind me of the times of nandub
[20:59:50 CET] <JEEB> when you had to manually do rate control for the encoders
[21:00:03 CET] <JEEB> times have become good 8)
[21:00:17 CET] <furq> at least it's not 1080p ffmpeg mpeg4
[21:00:28 CET] <furq> in 1-pass abr mode, of course
[21:00:57 CET] <ritsuka> and split in two 650 MB files so it fits on cd
[21:00:58 CET] <JEEB> hey, lavc mpeg-4 part 2 was supposedly good (in mpeg-4 part 2 space if and only if you went through the majestic effort of setting it up)
[21:01:17 CET] <kerio> rate control of what
[21:01:19 CET] <furq> it might not have been lavc mpeg4
[21:01:36 CET] <JEEB> I remember <redacted> using a university cluster to basically forcibly find his parameters of choice
[21:01:55 CET] <furq> but it definitely wasn't ASP
[21:02:08 CET] <JEEB> kerio: I think back then divx was pretty much the only thing, it was before Xvid
[21:02:26 CET] <JEEB> I came into the transcoding space before that
[21:02:30 CET] <furq> also you used the past tense there but i found this shining example a couple of months ago
[21:02:33 CET] <JEEB> s/before/after/
[21:03:11 CET] <JEEB> I think by the time I entered transcoding divx 4 was already a thing
[21:03:28 CET] <furq> the first thing i remember using is xvid with autogk
[21:03:41 CET] <JEEB> (before that you had the hacked MS mpeg-4 encoder as 'divx ;-)')
[21:03:49 CET] <furq> i think i still have some godawful rip i did with hardcoded black bars
[21:04:06 CET] <furq> it might have been divx 5 actually
[21:04:25 CET] <furq> i remember i put that in the filename because i thought it was a cool thing to do
[21:04:25 CET] <JEEB> flaskmpeg was the thing I did my first rips in like 2001 with
[21:04:43 CET] <JEEB> then later I poked gordian knot (not autogk)
[21:06:11 CET] <furq> i definitely still have a bunch of my autogk rips
[21:06:21 CET] <furq> all just under 700MB of course
[21:06:59 CET] <thebombzen> lol the shittiest file I have is probably from 1999
[21:07:06 CET] <thebombzen> ffmpeg forces the low_delay flag
[21:07:50 CET] <thebombzen> there was a noticeable improvement when this fansub group switched to H.264
[21:07:52 CET] <kerio> JEEB: this is a 2016 title
[21:07:54 CET] <furq> Bits/(Pixel*Frame)             : 0.096
[21:07:55 CET] <furq> nice.
[21:08:04 CET] <kerio> fucking 720x336
[21:08:23 CET] <thebombzen> that sounds like 720x480 but with black bars atop and below
[21:08:25 CET] <JEEB> kerio: well welcome to "scene"
[21:08:39 CET] <kerio> it doesn't even fit in a cd
[21:08:48 CET] <kerio> thebombzen: yeah
[21:08:49 CET] <kerio> but WHY
[21:08:58 CET] <thebombzen> because it's dvd-compatible
[21:09:01 CET] <thebombzen> microsoft loves that d.vd
[21:09:11 CET] <kerio> this is a dvdscr sure
[21:09:16 CET] <thebombzen> there you go
[21:09:20 CET] <thebombzen> gotta have my d.vd
[21:09:29 CET] <kerio> but why is the SAR 1:1
[21:09:33 CET] <thebombzen> oh
[21:09:33 CET] <JEEB> seems like my initial encode was in 2001. the music video DVD that came with Final Fantasy X
[21:09:36 CET] <thebombzen> 1:1 sar?
[21:09:37 CET] <thebombzen> lol
[21:09:39 CET] <thebombzen> wtf
[21:09:55 CET] <furq> thanks JEEB i feel less embarrassed about what i was doing in 2001 now
[21:09:55 CET] <thebombzen> oh I didn't encode this 1999 file
[21:09:58 CET] <thebombzen> it's K-F
[21:09:58 CET] <kerio> 1696 kb/s
[21:10:04 CET] <kerio> I HAVE SONGS WITH MORE BITRATE THAN THIS SHIT
[21:10:08 CET] <thebombzen> in 1999 I was 3 years old
[21:10:10 CET] <thebombzen> I wasn't encoding videos
[21:11:06 CET] <JEEB> anyways, MPEG-4 Part 2 to AVC was really a big switch because of CABAC and in-loop deblocking and some other fancy things that were not in the former
[21:11:37 CET] <furq> and no more 2-pass
[21:29:21 CET] <vans163> can anyone help me optimize my low latency endoder x264 settings? to lower cpu usage?
[21:29:33 CET] <vans163> rihgt now encoding 1080p im getting 90% of 1 core usage
[21:30:49 CET] <vans163> https://gist.github.com/anonymous/a20d30cad02683cc00a049da83cd48f8  this is what I have now  changing between 444 to 420 accounted for 3-5% cpu usage change
[21:31:14 CET] <vans163> im wondering if piping in a different pixel format then PPM will make a huge diff
[21:31:46 CET] <vans163> encoding 720p its 40% of 1 core
[21:34:12 CET] <furq> pass 1?
[21:34:55 CET] <furq> crf 20 and qp 26?
[21:49:42 CET] <vans163> furq: no idea I have NVEnc using qp26 by default from the guides tried it for ffmpeg.  pass 1 I think is faster?
[21:56:40 CET] <vans163> i want absolutely 0 buffer on the encode and decode size. so the frames are decoded as they come
[22:00:05 CET] <DHE> with nvenc your best hope is 'll' preset (low latency)
[22:00:19 CET] <DHE> but it's probably worst for image quality
[22:02:49 CET] <kerio> is software encoding not an option?
[22:02:53 CET] <kerio> x264 can do some fucking magic
[22:19:05 CET] <vans163> nono i am using software encoding
[22:19:18 CET] <vans163> I mean on another config I had on a different system, the hardware nvenc was set to 26 qp
[22:19:28 CET] <vans163> so i copied it to the software
[22:19:31 CET] <vans163> encoder config i pasted
[22:21:39 CET] <vans163> im thinking maybe my bitrate is really really low
[22:21:52 CET] <vans163> vbv-maxrate=3000:vbv-bufsize=100  does this mean anyting in terms of that?
[22:22:10 CET] <vans163> someone noted that setting these like so makes the encoder not precache frames
[22:33:45 CET] <vans163> anyone know if using pixels directly from the video card buffer would improve ffmpeg h264 encode perf? right now im converting those to ppm
[22:39:20 CET] <Mavrik> It would a bit, but burning a core for a fullHD encode isn't really strange
[22:39:46 CET] <vans163> Mavrik: I am quite happy with 50% right now, but I have not seen the quality yet
[22:39:59 CET] <vans163> ah thats 50% wiht 15 fps
[22:40:38 CET] <Mavrik> I guess you could switch to baseline profile if you need CPU that much :)
[22:40:41 CET] <DHE> x264 encoder can run as you describe with -preset zerolatency
[22:40:52 CET] <DHE> err, wait
[22:40:54 CET] <Mavrik> DHE, -tune and he has it :)
[22:40:56 CET] <DHE> -tune zerolatency
[22:41:00 CET] <DHE> yeah that
[22:43:39 CET] <Mavrik> Those settings will make video look like arse though. :/
[22:43:45 CET] <Mavrik> No idea what's the point of 1080p resolution there.
[22:44:18 CET] <vans163> Mavrik: would veryfast present fix the quality?
[22:44:25 CET] <vans163> (it takes almost 2-3x more cpu)
[22:44:40 CET] <DHE> zerolatency is meant for, say, video conferencing when you want fast reaction across the communication
[22:44:50 CET] <Mavrik> I don't know by heart, but AFAIK ultrafast locks video in baseline profile which is utterly fugly.
[22:45:07 CET] <Mavrik> vans163, if you drop resolution to 720p or so you'll get way more out of it
[22:45:26 CET] <vans163> Mavrik: yea 720p gets great mileage. half the cpu usage
[22:45:44 CET] <Mavrik> Yeah, since it's significantly less pixels to process for each frame
[22:46:06 CET] <Mavrik> I don't know what your use-case is, but ultra* profiles usually aren't something you actually want to use :/
[22:46:14 CET] <DHE> .
[22:46:18 CET] <vans163> usecase is to stream a desktop across local network
[22:46:22 CET] <DHE> indeed, ultrafast is a crutch at best
[22:46:35 CET] <vans163> i got get results with nvenc, but now I want to try a pure software encoder
[22:46:43 CET] <kerio> use skype :D
[22:47:00 CET] <vans163> *great results
[22:47:08 CET] <Mavrik> vans163, ah, yeah, HW encoding is your best bet for this
[22:47:09 CET] <DHE> reduce the framerate to maybe 10?
[22:47:25 CET] <vans163> kerio: heh i hate skype ever since microsfot bought it
[22:47:28 CET] <Mavrik> vans163, the other option is maybe switching to another format if you control the player
[22:47:51 CET] <vans163> Mavrik: Yea I control the player
[22:47:59 CET] <vans163> Mavrik: any idea whihc one would be good to try?
[22:49:23 CET] <Mavrik> I usually used huffyuv / ffv1 for their low CPU use when grabbing desktops.
[22:49:34 CET] <kerio> ffv1 is heavy as fuck tho
[22:49:34 CET] <Mavrik> They probably will be significantly worse bandwidth-wise tho.
[22:50:18 CET] <Mavrik> But without HW encoding... I guess what you have is about as good as it gets.
[22:52:18 CET] <vans163> Mavrik: do you think it would be under 50mbps for like 30fps 1080p low latency (under 50ms to encode and under 50 to decode)
[22:52:24 CET] <furq> does nvenc do intra-refresh
[22:52:54 CET] <Mavrik> I think there are profiles for that yes.
[22:53:04 CET] <DHE> I dont' see anything in the source
[22:53:04 CET] <furq> there's probably no point using x264 then
[22:53:07 CET] <Mavrik> At least I've seen it behave rather interestingly in the profiles meant for game streaming.
[22:53:26 CET] <Mavrik> But I'm not sure what is actually exposed in ffmpeg
[22:53:26 CET] <furq> if nvenc's latency is good enough then i doubt you'll get image quality improvements from x264
[22:53:38 CET] <furq> because you need to turn pretty much everything off to get minimum latency out of x264
[22:53:40 CET] <kerio> *at high bitrates
[22:53:48 CET] <DHE> not if you're cranking the preset down to ultrafast
[22:53:57 CET] <Mavrik> Yeah, nvenc units were built for zero-latency low CPU usage streaming of 3D games
[22:54:03 CET] <Mavrik> They're kinda optimized for that :)
[22:54:06 CET] <vans163> furq: nvenc takes me 4ms to encode a 1080p 444 frame, amazing
[22:54:24 CET] <furq> x264 is a better general-purpose encoder, but this is pretty much the thing nvenc was built for
[22:54:40 CET] <furq> as some guy said once
[22:55:08 CET] <vans163> furq: I am considering if itl make sense to buy a beefy business nvidia card like a P4 and do the encode on that
[22:55:26 CET] <furq> do you have a lot of concurrent streams
[22:55:32 CET] <vans163> yea planning on it
[22:55:55 CET] <furq> might be worth a look then
[22:56:04 CET] <furq> try qsv as well if you have a recent-ish intel cpu
[22:56:17 CET] <vans163> i checked out qsv but the thruput seems very low
[22:56:17 CET] <kerio> quadro p6000 :3
[22:56:25 CET] <vans163> (for many concurrent streams)
[22:56:38 CET] <vans163> didnt test it ofcourse, just from the docs available on it
[22:56:57 CET] <furq> the problem with using nvenc for this is that it seems to be impossible to find concrete specs of how much you can actually do with a given card
[22:57:09 CET] <vans163> i wish intel could release like a PCIE board filled with $20 atom chips, each has a hardware encoder/decoder
[22:57:15 CET] <furq> the best source i've found for simple questions like "how many 1080p30 streams can xyz run" is some guy on the nvidia forums
[22:57:16 CET] <vans163> kinda like a knights landing
[22:57:43 CET] <furq> and obviously there's another guy two posts down telling him he is dangerously wrong
[22:57:53 CET] <DHE> keep in mind that without a high-end quadro card, the nvidia driver will refuse to run more than 2 streams at a time. even with multiple cards
[22:58:17 CET] <DHE> (that said, there is no speed limit per-stream as long as the card has the capacity)
[22:58:17 CET] <furq> yeah iirc some quadros still have the 2-stream restriction
[22:58:26 CET] <furq> so make sure the card you buy is unrestricted
[22:58:28 CET] <kerio> furq: https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCPerf
[22:58:28 CET] <vans163> furq: the offical nvidia docs say things pretty promising, like.. i think 300 or 450frames of 1080p 444 low latency video is possible from the newest cards
[22:58:34 CET] <DHE> yeah, I have a low-end workstatino quadro that is limited to 2
[22:58:57 CET] <DHE> while I have nothing to back it up, I suspect that the minimum price tag is $1,000 for an unlimited card
[22:59:47 CET] <furq> anyway if you do want low latency with x264 then
[22:59:48 CET] <furq> http://archive.is/gUP7m
[22:59:52 CET] <kerio> looks like 35 1080p30 high performance low latency streams, on a P4
[22:59:57 CET] <furq> comment 8 is particularly useful
[23:00:32 CET] <furq> you can get 12-core haswell servers off ebay for way less than a single unrestricted quadro
[23:00:51 CET] <furq> i've seen them for like $350 with ram and disks, although usually disks destined for a bin
[23:01:30 CET] <vans163> furq: would those haswells have iGpus tho?
[23:01:42 CET] <furq> the xeons don't
[23:01:48 CET] <furq> doesn't really matter though
[23:01:56 CET] <DHE> there are some xeons that do, but the performance ones don't
[23:02:43 CET] <furq> obviously the power consumption of a dual-socket haswell server is going to be a bit worse than a quadro
[23:02:52 CET] <jkqxz> Quick Sync should somewhere close to 300fps of 1080p encode on any normal recent Intel CPU (mobile or desktop, Haswell+), a bit more on the ones with the extra GPU power.  Though that's 4:2:0-only, of course.
[23:03:13 CET] <DHE> you won't need a dual socket unless you're looking at 3+ GPUs in a single system
[23:03:18 CET] <vans163> jkqxz: that is much more promising then I recall reading from intel
[23:03:20 CET] <furq> i meant dual cpu socket
[23:03:44 CET] <vans163> jkqxz: there are some nicely priced 4:4 core e3 xeons with iris pros
[23:03:48 CET] <furq> if you want a lot of powerful cores on the cheap then there's a ton of dual socket servers on ebay
[23:04:36 CET] <furq> i've seen 12-core broadwell servers for like $150 all in
[23:05:04 CET] <furq> or $750 if you include your power bill for the quarter
[23:05:09 CET] <JEEB> that's quite new > broadwell
[23:05:18 CET] <furq> ere
[23:05:20 CET] <JEEB> I still remember sandy-e going for $60 lately a pop
[23:05:21 CET] <furq> i mean westmere
[23:05:30 CET] <JEEB> oh
[23:05:31 CET] <JEEB> :D
[23:05:32 CET] <vans163> JEEB: closer to 110$ now
[23:05:50 CET] <vans163> furq: ah westmere seem ancient these days, i think its ddr2
[23:05:54 CET] <furq> it's not
[23:06:14 CET] <furq> westmere is the upgrade from nehalem
[23:06:44 CET] <furq> aside from avx it's not far off the new stuff
[23:06:54 CET] <JEEB> E5-2670 seems to still be the thing on the refurb market
[23:06:57 CET] <furq> except in power consumption obviously
[23:07:01 CET] <vans163> damn.. even nehalhem is ddr3
[23:07:01 CET] <JEEB> well yeah
[23:07:12 CET] <jkqxz> That age of server is no longer economical to operate at full load compared to new servers because of the power consumption; that continues to be true if you run them rather than whatever people are dumping them on ebay.
[23:07:16 CET] <JEEB> yeah, they ditched ddr2 around the later core2s
[23:07:22 CET] <jkqxz> If you only want to use it some of the time, though, then sure.
[23:07:44 CET] <furq> depends how much you're paying for power really
[23:07:49 CET] <furq> at us power prices it's probably still a good deal
[23:08:04 CET] <vans163> jkqxz: I think its more due to large upgrades and dumps of servers
[23:08:07 CET] <furq> certainly if it's only one
[23:08:18 CET] <furq> i'd fork out for newer stuff if i was filling a rack
[23:08:21 CET] <vans163> then some people in the know gets dumps of 10-20 skids of 4 48u racks each
[23:09:42 CET] <vans163> because powerwise the costs are minor a 2x 2670v1 takes like.. 300w max at full load vs a newer gen would take 150w at full
[23:09:51 CET] <vans163> the cpus would cost 1.5k each new
[23:10:08 CET] <vans163> 150w == 0.8amp say in the DC at 208v
[23:10:16 CET] <vans163> with a 97% efficent psu
[23:10:53 CET] <furq> yeah at us power prices it's going to take a while for that to pay itself back
[23:11:55 CET] <vans163> i really cant see power being the factor,  but I could see things like general upgrading of infrastructure to last the next 4 yerars
[23:12:33 CET] <jkqxz> That isn't quite the right comparison.  The newer one also takes 300W, except it is one 2x18-core server doing just as much as five slower 2x6-core servers.
[23:14:50 CET] <jkqxz> Also aircon, and packing stuff in more densely.  Consuming less power to do the same work has a lot of other benefits to your server farm.
[23:14:55 CET] <vans163> jkqxz:  hum yea seems right  https://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@Server   not quite the 2x but look at the  Intel® Xeon® Processor E5-2680 v4
[23:14:55 CET] <vans163> (35M Cache, 2.40 GHz)
[23:15:26 CET] <vans163> 2.4ghz clock 14 phys cores 120w tpd 1.7k  vs  2670v1  8phys 120w tpd 1.5k
[23:15:33 CET] <vans163> 2.6GHZ
[23:16:07 CET] <vans163> so going from 1000 servers to 500 IMO is a huge upgrade
[23:16:49 CET] <DHE> wow that is a lot of machines...
[23:17:37 CET] <jkqxz> Faster by IPC (maybe 30% or so Westmere -> Broadwell, more if you can use AVX2 and stuff like that).  The clock speed has indeed not changed very much.
[23:18:08 CET] <vans163> jkqxz: AVX2 would sell me on the upgrade alone
[23:18:29 CET] <vans163> it reduces cpu usage of common SSL ciphers to insignicant
[23:18:48 CET] <vans163> srry i think its another extension
[23:18:55 CET] <kerio> that would be AESNI
[23:19:00 CET] <kerio> and yes it does
[23:19:01 CET] <vans163> AESNI ye
[23:19:20 CET] <kerio> but eeh, chacha20 is better :^)
[23:19:29 CET] <vans163> you need salsa
[23:19:33 CET] <vans163> to chacha
[23:19:33 CET] <DHE> AESNI has been available on virtually all CPUs in the last 5 years (short of the low-ends)
[23:20:11 CET] <vans163> we should move to UDP already with FEC
[23:20:12 CET] <jkqxz> What I'm really trying to say is: while the old servers on ebay look superficially attractive, you should actually calculate whether they are sane - other people are basically throwing them away, so unless you have a significantly different use-case to those people them they are unlikely to be a good idea.
[23:20:16 CET] <vans163> for the whole WWW
[23:21:49 CET] <furq> i expect most people buying servers off ebay have a different use case to the people who are selling 50 of them
[23:22:13 CET] <furq> unless they actually plan on buying all 50, in which case, stop it
[23:22:23 CET] <vans163> furq: yea it makes a great workstation
[23:22:36 CET] <vans163> 1 2670v1 + a refub mobo for like 150$
[23:22:46 CET] <vans163> its about the cost of a modern i7
[23:22:55 CET] <vans163> except youl get 2x the power and 2x the TPD
[23:23:07 CET] <Diag> "2x the power"
[23:23:09 CET] <vans163> unless you overclock the i7
[23:23:19 CET] <furq> you'd have to pay the K series premium for the i7 though
[23:23:34 CET] <furq> those ones definitely aren't $150
[23:23:49 CET] <Diag> 8 cores, 16 threads at 2.6ghz
[23:23:51 CET] <Diag> pff
[23:23:52 CET] <vans163> well 110 for the cpu + 150 for the mono 260.. even cheaper
[23:24:07 CET] <Diag> youd be better off with an i5 or something
[23:24:17 CET] <vans163> an atom would do the trick
[23:24:17 CET] <Diag> lots of shit isnt multithreaded so the low clock speed would cripple it
[23:24:26 CET] <furq> you can overclock those if your board has the right chipset
[23:24:30 CET] <furq> at least you can with most xeons
[23:24:32 CET] <Diag> the xeons?
[23:24:34 CET] <vans163> furq: no way!
[23:24:38 CET] <Diag> i dont believe it
[23:24:46 CET] <Diag> you might be able to adjust the baseclock
[23:24:50 CET] <furq> you can certainly overclock westmere xeons
[23:24:58 CET] <Diag> but thats not real "overclocking"
[23:24:58 CET] <vans163> Diag: for a workstation i beg to differ. Maybe running a single threaded old game
[23:25:00 CET] <furq> i've not paid attention to any newer xeons
[23:25:15 CET] <vans163> But for having a bunch of browsers, programs, chats open
[23:25:20 CET] <vans163> i rather have more threads and less ghz
[23:25:31 CET] <Diag> Ill stick to my 12 threads at 4.6ghz
[23:25:35 CET] <furq> how is changing the bclk not real overclocking
[23:25:42 CET] <Diag> because thats retarded
[23:25:55 CET] <Diag> youll scrape 50-150mhz out of it
[23:25:55 CET] <furq> an unlocked multi just makes it less annoying
[23:26:05 CET] <Diag> meanwhile you fuck over your pci bus
[23:26:14 CET] <vans163> Diag: that is a good balance, 12 threads at 4,6ghz il take that over 16 or even 32 at 2,6 I thought you were talkig about 4:4
[23:26:14 CET] <Diag> and other IO busses
[23:26:23 CET] <furq> either you suck at overclocking or intel have gone nuts lately
[23:26:27 CET] <Diag> vans163: well yes i did reference some i5
[23:26:35 CET] <vans163> No way an i5 has 6:6
[23:26:42 CET] <vans163> it dont even hyperthread and you cant dual cpu it
[23:26:44 CET] <Diag> no im saying yes
[23:26:55 CET] <Diag> > I thought you were talkig about 4:4
[23:27:01 CET] <Diag> >Diag> vans163: well yes i did reference some i5
[23:27:02 CET] <vans163> ohh
[23:27:20 CET] <Diag> if you could have an i5 at ~4.8 vs that at 2.6
[23:27:22 CET] <vans163> k yea i disagree on that, i would rather have 8:8 at 2.0 then 4 at 5ghz
[23:27:23 CET] <Diag> id take the i5
[23:27:38 CET] <Diag> uhh
[23:27:46 CET] <Diag> 8:8 at 2 vs 4:4 at 5
[23:27:57 CET] <Diag> you mean 8:16
[23:28:14 CET] <vans163> I was meaning 8phys 8hyper vs 4phys (i5)
[23:28:24 CET] <Diag> oh i see
[23:28:28 CET] <Diag> ehhhh
[23:28:36 CET] <Diag> too much shit is singlethreaded
[23:28:49 CET] <Diag> you referenced web browsers, each tab is a single thread
[23:28:56 CET] <Diag> soo the i5 would roast it
[23:29:26 CET] <Diag> most programs other than high end shit such as solidworks/adobe tools dont make use of more than 1 thread
[23:29:32 CET] <vans163> I think youd be right.. just something inner nature prefers 8:8
[23:29:37 CET] <Diag> Lol
[23:29:39 CET] <Diag> I get ya
[23:30:03 CET] <furq> 22:26:23 ( furq) either you suck at overclocking or intel have gone nuts lately
[23:30:06 CET] <furq> it turns out intel have gone nuts
[23:30:15 CET] <Diag> some stuff might be faster JUST BECAUSE it doesnt have to timeshare as much for each core
[23:30:29 CET] <Diag> but then that depends on your OS
[23:30:46 CET] <Diag> furq: yeah man, shits locked down
[23:30:46 CET] <furq> it's ok i'm sure there is a very valid justifiable reason for them to lock the pcie bus clock to the bclk
[23:30:50 CET] <furq> it can't possibly be "fuck you"
[23:30:53 CET] <furq> intel would never do that
[23:30:55 CET] <Diag> No its fuck you
[23:31:08 CET] <Diag> People buy non K chips, "overclock"
[23:31:12 CET] <furq> i don't believe you. intel are a fine and upstanding company who would never fuck shit up to make their customers pay more
[23:31:17 CET] <Diag> roast their pci cards and fuck their harddrives
[23:31:19 CET] <vans163> Diag: when I had VM heavy work pipeline, the 8:8 is really appealing
[23:31:19 CET] <furq> they have never done that
[23:31:35 CET] <Diag> furq: its a fuck you for your own protection
[23:31:44 CET] <furq> no it isn't
[23:31:47 CET] <vans163> Diag: but browsers, editors, chat, shells I think the higher Ghz would win
[23:32:13 CET] <furq> it's to make it so they can stop you overclocking by just locking the multi
[23:32:28 CET] <Diag> and thats not a fuck you?
[23:32:34 CET] <Diag> sounds like one to me
[23:32:36 CET] <furq> it's not for your own protection
[23:32:46 CET] <Diag> sure it is
[23:32:58 CET] <Diag> when theres an unlocked multi on the PCI/IO bus
[23:33:06 CET] <Diag> you can trash a graphics card or trash a harddrive
[23:33:12 CET] <Diag> people do the wrong shit
[23:33:14 CET] <kerio> binning tho?
[23:33:22 CET] <Diag> binning what
[23:33:30 CET] <furq> i never saw anyone do that before they pegged the bus clocks
[23:33:41 CET] <furq> and i stopped paying attention to this shit after that
[23:34:05 CET] <Diag> and still, you fuck up everything fucking with the baseclock
[23:34:12 CET] <Diag> all the sudden, 1066 isnt 1066 anymore
[23:34:17 CET] <Diag> so everythings off
[23:34:18 CET] <furq> that's what ram dividers are for
[23:34:24 CET] <furq> or did they get rid of those too
[23:34:35 CET] <Diag> you can still pick the freqs for the ram
[23:35:04 CET] <Diag> but if the baseclocks 150mhz, 1066 is gonna appear as 1066 but really be 1600
[23:35:17 CET] <Diag> my bios shows the differences
[23:35:20 CET] <furq> it's not going to appear as that on a board which doesn't suck
[23:35:41 CET] <Diag> good luck getting that in a workstation board
[23:35:52 CET] <furq> i said in a consumer board
[23:36:01 CET] <kerio> but why overclock
[23:36:02 CET] <Diag> where did you specify
[23:36:03 CET] <furq> but evidently that's no good for anything post sandy bridge
[23:36:05 CET] <Diag> I dont see it
[23:36:05 CET] <kerio> when it's got a clock already
[23:36:26 CET] <Diag> furq: you did not specify consumer board
[23:36:30 CET] <furq> 22:24:26 ( furq) you can overclock those if your board has the right chipset
[23:36:38 CET] <Diag> thats not  "consumer"
[23:36:44 CET] <furq> that includes consumer boards
[23:36:54 CET] <Diag> No thats a extremely general statement
[23:36:58 CET] <furq> yes
[23:37:00 CET] <kerio> ur a consumer board
[23:37:02 CET] <furq> which is why it includes consumer boards
[23:37:05 CET] <Diag> Yeah if you get the right socket 2011 board you can do X
[23:37:13 CET] <Diag> Well socket2011 includes a wide array of shit
[23:37:24 CET] <furq> one of the things it includes is consumer boards
[23:37:40 CET] <Diag> It sounds like someone who doesnt know what theyre talking about is making broad points
[23:37:44 CET] <Diag> so that they cant be wrong
[23:37:50 CET] <Diag> Just like this statement
[23:37:53 CET] <Diag> look at me not specifying
[23:37:54 CET] <Diag> lol
[23:37:59 CET] <Diag> it could be any one of you
[23:38:10 CET] <Diag> shit, it could even be someone in another channel
[23:39:07 CET] <furq> looks like it's time to buy zen
[23:39:18 CET] <Diag> heh im excited about amds new shit
[23:39:29 CET] <furq> new shit indeed
[23:40:19 CET] <Diag> they can call me when they outperform my 6850k
[23:40:27 CET] <Diag> otherwise ill stick to their graphics cards
[23:40:38 CET] <Diag> my cards are nearing 5 years old i think
[23:40:41 CET] <kerio> yea because those outperform the competition so well lmao
[23:41:01 CET] <vans163> Finally got the stream hooked up, quality is brutal going to try veryfast over ultrafast
[23:41:12 CET] <vans163> brutal meaning.. 2-4x better then regular VNC
[23:41:15 CET] <Diag> kerio: does AMD have anything faster than a 6850k?
[23:41:31 CET] <kerio> does AMD have anything faster than a 1070?
[23:41:51 CET] <Diag> Id say no
[23:42:07 CET] <vans163> AMD is making the new line of procs look at their stock price
[23:42:07 CET] <Diag> Is there anyone on the market still using the 500 series of nvidia cards?
[23:42:24 CET] <vans163> apparently they copied hyperthreading and other optimizations from intel
[23:42:39 CET] <Diag> kerio: what about 600 series
[23:42:45 CET] <Diag> do you know anyone with a 600 series card?
[23:42:50 CET] <kerio> no
[23:42:54 CET] <Diag> huh
[23:42:55 CET] <Diag> wonder why
[23:43:01 CET] <Diag> nvidia is make a quick buck and run
[23:43:04 CET] <kerio> my lappy has a 750m
[23:43:16 CET] <Diag> my 2 7970s are faster than a 1070
[23:43:28 CET] <Diag> and ive had them 5 years now (or going on it in a few months)
[23:43:38 CET] <Diag> Cant say that about any nvidia card
[23:43:50 CET] <Diag> AMD is in it for the long haul
[23:44:05 CET] <Diag> my cards still actively supported with specific shit coming out just for it still
[23:44:12 CET] <Diag> cant say that about the 600 series cards
[23:44:23 CET] <Diag> or even the 700 series cards really, or at least not often
[23:44:31 CET] <vans163> heh veryfast is less CPU usage then ultrafast, guessing this means ultrafast probably uses baseline
[23:44:31 CET] <Diag> nvidia can go suck a bigass dick
[23:44:39 CET] <vans163> 30% cpu vs 50% veryfast vs ultrafast
[23:45:11 CET] <vans163> oh no nm im a dummy i made the resolution lower x,x
[23:45:15 CET] <Diag> pff
[23:45:15 CET] <Diag> lol
[23:45:29 CET] <Diag> wait vans163 what proc you on now
[23:46:11 CET] <Diag> itsss
[23:46:13 CET] <Diag> a something
[23:46:15 CET] <vans163> actually.. veryfast vs ultrafast is the same for me... maybe veryfast is 1-2% less
[23:46:22 CET] <vans163> Diag: surprizingly a i5 2600
[23:46:26 CET] <vans163> ** i5 700
[23:46:31 CET] <Diag> mobile?
[23:46:48 CET] <vans163> sec.. no i5 750
[23:46:59 CET] <vans163> but i got some 2670v1's lying around I use to run most of my code
[23:47:17 CET] <Diag> Lol
[23:47:28 CET] <Diag> we should bench my c2q q8300 at 2.66 against that
[23:47:29 CET] <vans163> damn this thing is expensive to run..
[23:47:34 CET] <vans163> 95w tpd
[23:47:51 CET] <vans163> heh i can dedicate a thread to that let me know what to run
[23:48:25 CET] <Diag> id also like to bench that xeon against my 6850k
[23:48:49 CET] <vans163> oh your  q8300 willl get smoked if i dont turn off turbp
[23:48:53 CET] <Diag> lol
[23:49:31 CET] <vans163> hum the 6850k should win wow, thats a great price
[23:49:32 CET] <furq> a nehalem will kick fuck out of a core 2 quad
[23:49:52 CET] <Diag> ~600 bucks
[23:49:56 CET] <furq> especially at stock clocks
[23:50:07 CET] <Diag> i won the silicon lottery
[23:50:16 CET] <vans163> Diag: microcenter?
[23:50:21 CET] <Diag> no, newegg
[23:50:33 CET] <Diag> i took my 6850 to 4.9ghz
[23:50:46 CET] <vans163> microcenter always ontop  http://www.microcenter.com/product/463391/Core_i7-6850K_Broadwell_36_GHz_LGA_2011-3_Boxed_Processor
[23:50:46 CET] <Diag> but then felt bad because it was a fixed voltage of 1.375
[23:50:54 CET] <vans163> plus giving me 30$ off the mobo
[23:51:16 CET] <Diag> huh not bad
[23:51:26 CET] <vans163> Diag: yea limit 1 their great
[23:51:42 CET] <vans163> Diag: Does it overclock easy to stable clock? no voltage fuckery?
[23:51:48 CET] <vans163> like 4.4 or some
[23:51:59 CET] <Diag> vans163: well the 1.375 was stable at 4.9ghz
[23:52:03 CET] <Diag> but it was fixed
[23:52:11 CET] <vans163> that is insane
[23:52:12 CET] <vans163> wtf
[23:52:13 CET] <Diag> I backed it to 4.4 @ ~1.275
[23:52:18 CET] <Diag> but its variable
[23:52:22 CET] <Diag> it goes up and down with the clock
[23:52:28 CET] <vans163> how much did it take out the power socket at 4.9?
[23:52:36 CET] <Diag> i dont want to know
[23:53:16 CET] <Diag> im on an asrock x99 taichi board though
[23:53:27 CET] <Diag> seemed pretty beefy
[23:54:34 CET] <vans163> asrock has been making great boards lately
[23:54:43 CET] <vans163> all the nice pricepoints I find are from them
[23:54:49 CET] <Diag> i love this board
[23:54:53 CET] <Diag> i have an m2 drive in it
[23:55:00 CET] <kerio> sata or nvme?
[23:55:03 CET] <Diag> nvme
[23:55:07 CET] <kerio> sweeet
[23:55:15 CET] <Diag> samsung 950 pro 256gb
[23:55:18 CET] <Diag> 960 wasnt out yet
[23:55:33 CET] <Diag> its my boot and some programs drive
[23:55:40 CET] <Diag> tests around 2400MB/s
[23:57:56 CET] <furq> how does cool edit pro run on that bad boy
[23:58:06 CET] <vans163> 960 looks overkill, 950 was hard enough for me to get over
[23:58:12 CET] <vans163> 960 actually looks like an upgrade
[23:58:15 CET] <Diag> furq: fan fuckin tastic lol
[23:58:20 CET] <vans163> btw this is where im at now  https://gist.github.com/anonymous/c2a22dbfc0302665f300fa651be01e83
[23:58:24 CET] <vans163> I think i cant really expect more
[23:58:33 CET] <vans163> latency looks good as well as quality
[23:58:54 CET] <vans163> slice-max-size made a large difference
[23:59:02 CET] <furq> get rid of -qp 26
[23:59:13 CET] <furq> also get rid of -pass 1 -coder 0 -bf 0 -wpredp 0
[23:59:21 CET] <furq> pass 1 is just wrong and the others are taken care of by the preset and tune
[23:59:27 CET] <vans163> let me try..
[23:59:52 CET] <furq> this won't make it faster, those options are just wrong
[23:59:57 CET] <kerio> wtf is cool edit
[00:00:00 CET] --- Sun Feb  5 2017