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

[burek]

[00:01:23 CEST] <de-facto> its the -t "${DURATION}" argument, -t 120 works, -t 30 kills OOM
[00:01:59 CEST] <de-facto> what does -t mean?
[00:02:28 CEST] <durandal_1707> man ffmpeg
[00:19:21 CEST] <de-facto> ok i found the cause of the memory peak, but it does not make any sense to me: -t 30 gets killed (regardless of d=30 or d=120, -t 120 works: https://dpaste.de/5XDs
[00:20:20 CEST] <de-facto> it seems like ffmpeg can't write moov atom for 30s video without more than 16 GB of memory. I have seen it working on 64GB machines today...
[00:21:13 CEST] <durandal_1707> try another container to be sure
[00:22:05 CEST] <furq> de-facto: the moov atom thing is just because ffmpeg is crashing
[00:22:17 CEST] <furq> it doesn't write that until it's done muxing
[00:22:37 CEST] <furq> or not crashing, getting oom killed
[00:39:34 CEST] <de-facto> my internet service provider is causing problems, bad luck day... cant surf too much over mobile :/
[00:41:14 CEST] <de-facto> any idea why 120 seconds is fine but 30 seconds gets OOM killed?
[00:42:29 CEST] <durandal_1707> de-facto: 120 seconds is enough to get back frames
[00:42:39 CEST] <de-facto> they behave the same until ~28.5s encoding, i guess then the finalizing for the 30s video begins and it requests too much memory for some reason (in contrast 120 seconds it would not do that even at the end of 120s)
[00:43:09 CEST] <durandal_1707> PTS-(3*DURATION)
[00:43:20 CEST] <durandal_1707> 0-(3*30)
[00:43:27 CEST] <durandal_1707> =-90
[00:43:53 CEST] <de-facto> PTS-(3*${DURATION})/(4*TB)
[00:44:40 CEST] <de-facto> so it should be 3/4*30=22.5
[00:45:57 CEST] <de-facto> but yeah i have to tweak that anyhow, just wanted to find out the reason before
[00:46:45 CEST] <furq> some filter's buffer is going nuts
[00:46:49 CEST] <furq> i couldn't tell you for sure which one or why
[00:47:01 CEST] <furq> probably one of the overlays
[00:47:17 CEST] <furq> if it was loop/setpts then i'd expect increasing the pts offset would make the problem worse
[00:47:49 CEST] <furq> i guess maybe try using pad and xstack instead of overlay
[00:53:08 CEST] <durandal_1707> furq: xstack does not need pad
[00:54:40 CEST] <furq> the videos are all the same size and he's putting one in each corner with gaps
[00:54:52 CEST] <furq> so either i'm reading the filter docs wrong or he needs to pad them
[00:57:29 CEST] <durandal_1707> furq: no padding is  needed for xstack if colorspace is rgb
[00:57:35 CEST] <de-facto> its like a "cross" around the background (1600x1200) center: four VGA videos rotated (0, 90, 180, 270 degree)
[01:02:09 CEST] <de-facto> i cant surf right now, my internet is broken :/
[01:09:57 CEST] <de-facto> loop=1 makes it kinda work with 30s, there is still a little memory peak at the end but its much better
[01:43:37 CEST] <snap1> i just learned something today:  did you know intel system does not support  high-density ram:  where AMD system does
[01:44:54 CEST] <BtbN> Are you talking Registered vs. Non-Registered?
[01:45:05 CEST] <BtbN> Never heard the term high density before.
[01:47:08 CEST] <snap1> non registered
[01:47:50 CEST] <BtbN> Single vs. Dual Rank then?
[01:48:24 CEST] <snap1> no
[02:15:49 CEST] <de-facto> ok cropping and scaling was easy, ffmpeg is awesome :)
[02:17:34 CEST] <de-facto> is there a filter to mathematically transform/project videos with complex functions? just was thinking: the glass pyramid reflection is not perfect since viewed from an edge always allows two paths of sight on the object
[02:19:07 CEST] <de-facto> maybe a cone (or rotational symmetric body) would be better, yet it would require to distort the video in a complex way on the monitor to compensate the effect of a curved reflection
[02:20:11 CEST] <de-facto> probably a task suitable for mathematica et al
[02:20:46 CEST] <DHE> the list of filters is here: https://ffmpeg.org/ffmpeg-filters.html
[02:21:55 CEST] <snap1> everybody:   did you know that intel system does not support  high-density ram:  where AMD system does
[02:22:17 CEST] <DHE> you mean 8-channel memory from AMD vs intel's 6?
[02:22:24 CEST] <de-facto> whats high density ram? do you have a link?
[02:23:24 CEST] <snap1> DHE no
[02:23:37 CEST] <snap1> do you have a RAM in front of you
[02:23:43 CEST] <snap1> then ican explain better
[02:24:01 CEST] <snap1> find a ram and look at it in front of you
[02:24:51 CEST] <snap1> then ican explain better
[02:26:39 CEST] <de-facto> you mean the storage per chip on a dimm?
[02:27:00 CEST] <DHE> or number of chips (ie. vertically tall memory sticks)
[02:30:48 CEST] <snap1> de-facto yes
[02:31:03 CEST] <snap1> sometimes you see 4 chips per side or 8 chips
[02:31:56 CEST] <DHE> 9 if you have ECC. :)
[02:32:56 CEST] <snap1> ecc rams have 9 chips? didn't know that
[02:33:03 CEST] <de-facto> interessting, i thought thats what JEDEC conformity is meant for, no clue if there are different levels of standard conformity though
[02:33:39 CEST] <de-facto> ECC = 72bit (e.g. 9 chips) vs non-ECC = 64bit (e.g. 8 chips) per rank
[02:34:09 CEST] <snap1> is it possible to have more than 9 chips  per side?
[02:34:09 CEST] <de-facto> or something like that
[02:34:20 CEST] <snap1> so 20 chips total ?
[02:35:48 CEST] <de-facto> no clue, i guess its a sum of powers of two or such
[02:36:26 CEST] <de-facto> maybe the guys in #hardware know more?
[02:56:23 CEST] <koz_> I keep getting this error message when trying to recode some videos: Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height
[02:56:58 CEST] <koz_> I have no idea what I have to tell it. According to mediainfo, the original audio has 6 channels with layout C L R Ls Rs LFE.
[02:59:27 CEST] <furq> koz_: pastebin the command line and output
[03:01:39 CEST] <koz_> furq: http://paste.debian.net/1080145/
[03:06:49 CEST] <furq> https://trac.ffmpeg.org/ticket/5718
[03:07:05 CEST] <furq> looks like there's a workaround at least
[03:07:35 CEST] <koz_> furq: Yup, that seems to work. Thanks!
[03:21:25 CEST] <de-facto> How can i match pure black only? chromakey=black:0.01:0.0 also takes some dark gray, but i want to match ONLY pure (binary) black. Is there a filter without similarity?
[03:34:30 CEST] <de-facto> nice it seems lumakey=16:0:0 comes pretty close to that
[04:18:39 CEST] <de-facto> According to the raspberrypi.org guys the VideoCore iV in all Pis is the same. ... "The chip was originally designed for 1080P30 encode and decode with VideoCore running at 250MHz. In reality the Pi is almost universally able to overclock the VideoCore blocks to 400MHz, to the extent that that is done automatically on "complex" H264 streams.
[04:18:39 CEST] <de-facto> Decode is dependent on the exact bitstream. It will manage almost all 1080P60 streams, but it does depend on the bitrates involved. You have no come back should you find a stream that it can't play that exceeds 1080P30." ...
[04:18:59 CEST] <de-facto> does that mean H264 High at 4.1?
[04:20:07 CEST] <DHE> most likely
[04:20:52 CEST] <de-facto> H264 1080p30 is 4.1-ish right?
[04:21:40 CEST] <DHE> it's a bit more complicated than that, but most likely
[04:23:32 CEST] <de-facto> they dont really provide detailed info (at least i couldnt find it). if they claim guarenteed H264 high at 1080p30 i understand high at 4.1-ish and if they say probably most high at 1080p60 i read high at 4.2-ish at least as estimate
[04:24:51 CEST] <DHE> officially there are additional restrictions like number of reference frames according to the spec, but I don't see that being a major issue.
[04:28:10 CEST] <de-facto> i will just try to encode 1600x1200 at 60fps on H264 high at 4.1 with ~2.7Mbit and see if that plays back on Raspi 2 when I have access again on monday
[04:32:51 CEST] <furq> de-facto: you can clamp reference frames to the maximum allowed for 4.1 with -level 41
[04:34:00 CEST] <DHE> are you encoding or decoding?
[04:34:01 CEST] <de-facto> oh i was using -profile:v high -level:v 4.1 , is that wrong syntax?
[04:34:05 CEST] <de-facto> decoding
[04:34:26 CEST] <de-facto> with openelec
[04:34:49 CEST] <DHE> that's right for encoding. whatever options you give it will be adjusted to meet the constraints of the profile/level
[04:36:36 CEST] <furq> i think 1600*1200 @ 60fps needs 4.2
[04:37:06 CEST] <furq> setting -level can only clamp refs
[04:39:13 CEST] <de-facto> ok then i try -level:v 4.2 and see if that plays back
[04:39:44 CEST] <furq> you usually don't need to set -level, it picks the right one automatically
[04:40:43 CEST] <de-facto> thats really efficient, the source.webm is 11.5MB (VGA), the target.mp4 is 10MB :)
[04:41:30 CEST] <de-facto> oh I didnt know that, so only  -profile:v high is sufficient already then?
[04:41:38 CEST] <furq> you don't need that either
[04:44:29 CEST] <de-facto> interessting, indeed it gives me the exact same size in bytes :)
[04:44:55 CEST] <de-facto> without either profile nor level as you said
[04:46:21 CEST] <furq> 1152x864 should be level 4.1 at 60fps
[04:46:26 CEST] <furq> i think that's as high as you can go
[04:46:46 CEST] <furq> apparently the pi might work with 4.2 if it's overclocked, but 1600x1200 is way over the max data rate for 4.1
[04:46:55 CEST] <furq> so i'd probably have a backup prepared
[04:47:23 CEST] <furq> alternatively you could drop to 30fps but i'm guessing that's not going to work
[04:49:52 CEST] <de-facto> well if it would not work I could try to drop to 30fps indeed, 60fps was just chosen before for some reason i am not aware of, i guess to match the refresh rate or such
[04:50:15 CEST] <furq> if it's a physical effect then it's probably just to look smoother
[04:50:58 CEST] <de-facto> yeah i guess something like that
[04:51:32 CEST] <de-facto> the video they had before was around 20 Mbps and it wasnt really smooth
[04:52:27 CEST] <de-facto> but that also could have been for other reasons, i guess they didnt really think too much about it
[04:59:56 CEST] <de-facto> I am going with this now and see if it plays back, it stays below 5GB on encode with a small memory peak at the end, lumakey and scaling made it much slower, but cropping compensated a bit: https://dpaste.de/6Jdt
[05:03:24 CEST] <de-facto> cool thing is overlay would allow for lumakey so i could scale them together much closer without dealing with overlappings
[13:59:28 CEST] <kubast2> hey, how can I capture a pulse audio application output and make it an input device?
[14:01:04 CEST] <kubast2> Rn I'm recording my microphone, putting a filter on it for kicks, and output it to pulseaudio, does pulseaudio allow me to create a dummy input device?
[14:13:45 CEST] <kubast2> okay
[14:13:47 CEST] <kubast2> I done it
[14:14:26 CEST] <kubast2> I found someone who needed an output device for voice chat and a game
[14:14:30 CEST] <kubast2> to be seperate for obs
[14:14:36 CEST] <kubast2> allowing me to what I wanted
[22:46:02 CEST] <Jolein> hi
[22:47:12 CEST] <Jolein> is there a way to use these 2 things (-vf scale=1280:720 and -filter:v "minterpolate='mi....) at the same time ?
[22:47:48 CEST] <durandal_1707> yes
[22:48:12 CEST] <Jolein> it gives a strange error with me
[22:48:23 CEST] <durandal_1707> because you use it wrong
[22:48:33 CEST] <Jolein> well obviously xD
[22:48:38 CEST] <Jolein> else it would be working :p
[22:48:59 CEST] <Jolein> trying to find the error back
[22:49:21 CEST] <durandal_1707> http://ffmpeg.org/ffmpeg-filters.html#Filtering-Introduction
[22:50:43 CEST] <Jolein> so it would be just (-vf scale=1280:720,filter:v "minter...) ?
[22:51:05 CEST] <durandal_1707> no
[22:51:50 CEST] <durandal_1707> -vf is same as -filter:v
[22:52:39 CEST] <Jolein> -vf scale=1280:720,minter..?
[22:52:49 CEST] <durandal_1707> yes
[22:52:55 CEST] <Jolein> ah
[22:53:03 CEST] <Jolein> easy info that i couldnt find for some reason >.>
[22:53:12 CEST] <Jolein> ty :D
[23:08:46 CEST] <nitrxgen> <3 ffmpeg
[23:28:07 CEST] <Jolein> would anyone be willing to help me get open_cl to work ?
[23:48:22 CEST] <__Shepherd> furq: you've posted this setpts=PTS-22.5/TB mid-week
[23:48:40 CEST] <__Shepherd> that offsets the input -22.5s seconds back
[23:49:25 CEST] <__Shepherd> can you offer an explanation on how that works
[00:00:00 CEST] --- Sun Apr 28 2019