[00:00:46 CEST] <de-facto> can I set the source background (black) as transparent somehow ? [00:09:36 CEST] <de-facto> btw furq, your version works as well like this: http://vpaste.net/nX4GM [00:10:29 CEST] <Numline1> furq hi :) I just wanted to let you know, I played with your Go code a bit. I don't think it's working for me, the splitter doesn't split the y4m a single time. I'm going to debug it on my own of course, I was just wondering if you could show me the ffmpeg command or file or somethign you used to test it [00:10:34 CEST] <Numline1> I don't want to bother you with this too much [00:15:14 CEST] <furq> Numline1: ffmpeg -i foo.mp4 -f mjpeg - | ./foo [00:17:39 CEST] <furq> i feel like you've got mjpeg and y4m mixed up here [00:18:06 CEST] <Numline1> furq well that might be possible, I'm using this for output - -pix_fmt yuv420p -f yuv4mpegpipe [00:18:16 CEST] <Numline1> the outfile is y4m, so I guess that's something different? [00:18:19 CEST] <furq> yeah [00:18:26 CEST] <Numline1> heh, that explains a lot [00:18:34 CEST] <furq> the point was that you're uploading these images to some web service as jpeg anyway [00:18:40 CEST] <Numline1> yes sir [00:18:45 CEST] <furq> so you might as well have ffmpeg convert it to mjpeg [00:18:49 CEST] <furq> which is just a bunch of concatenated jpegs [00:19:18 CEST] <Numline1> absolutely. I just had no idea it existed tbh, I was using an advice I got yesterday from fellow friends in here [00:19:24 CEST] <Numline1> furq I'll try that, thank you [00:20:06 CEST] <Numline1> furq btw just out of curiosity, does y4m have any sort of similar delimiters like mjpeg or is it just a newline that's not reliable anyway? [00:20:51 CEST] <furq> y4m is file header, newline, frame header, newline, known-size frame data that can contain newlines, newline [00:21:27 CEST] <furq> so you can read everything other than the frame data line-by-line [00:21:37 CEST] <furq> also https://clbin.com/uJFry [00:21:44 CEST] <furq> it won't make any difference but i figured i should fix that bug [00:23:48 CEST] <Numline1> furq hah thanks :) same but a bit fancier [00:23:56 CEST] <Numline1> furq can I buy you a coffee for your help? [00:26:47 CEST] <de-facto> furq do you know if i can set the black background color of the source video sprites transparent prior to putting them on the canvas? [02:43:39 CEST] <irwiss> are there muxers/codecs/others which may be changing the format mid-stream? e.g. can i get a 320x240 YUV420P frame from a specific AVStream, and then the stream will resize into some other size or pixel format without a restart? or with audio are there scenarios where audio format changes without restarting the stream? i'm trying to figure out what [02:43:39 CEST] <irwiss> kind of stuff i need to handle w.r.t. buffer allocations [09:33:45 CEST] <dilm_> hi, i'm searching where i can find if my camera is compatible with ffmpeg to have a device in /dev/video* [09:34:27 CEST] <dilm_> Bus 001 Device 043: ID 04e8:138b Samsung Electronics Co., Ltd [09:34:36 CEST] <dilm_> WB250F [15:32:31 CEST] <mozzarella> guys help [22:07:00 CEST] <de-facto> why does crop filter require over 16 GB of memory for 320x320 video? [22:16:18 CEST] <durandal_1707> de-facto: post full command line [22:17:01 CEST] <de-facto> its not the crop filter, but after some time ffmpeg just tries to allocate memory like crazy and gets killed [22:18:29 CEST] <durandal_1707> de-facto: post full command line [22:22:07 CEST] <de-facto> durandal_1707, https://dpaste.de/gzEb [22:23:01 CEST] <de-facto> encodes a while with ~4.5 GB RAM then stops and allocates until it gets killed at ~16GB [22:23:56 CEST] <de-facto> i know it works on linux/windows with more memory (e.g. 64 GB) [22:26:42 CEST] <durandal_1707> de-facto: if it caches lots of frames than it will need more RAM, setpts could do that [22:27:43 CEST] <durandal_1707> so try without setpts filter and does it still need so many RAM? [22:31:30 CEST] <de-facto> durandal_1707, it reduces a lot of ram (1.2 GB), but at the end there still is a BIG peak, yet slightly below 16 GB for now [22:31:59 CEST] <de-facto> thats crazy, why would it need such enormous amounts of ram just to finish writing the file out to disk? [22:33:17 CEST] <durandal_1707> you could also use xstack instead of overlay [22:38:15 CEST] <de-facto> would that reduce the memory peak? [22:38:22 CEST] <durandal_1707> de-facto: look at graphmonitor filter, it can show number of cached frames in filter links [22:38:52 CEST] <durandal_1707> de-facto: if you just tile videos into grid, its also much faster [22:39:10 CEST] <de-facto> i need specific positions, not just a grid [22:40:14 CEST] <durandal_1707> de-facto: does not look like from graph, you just put videos into 2x2 tile [22:40:26 CEST] <durandal_1707> xstack can do that [22:41:20 CEST] <de-facto> its a "cross" of videos from the center with each video rotated by an additional 90 degree [22:43:44 CEST] <de-facto> from the docs it seems that xstack is meant for tight grids (e.g. by rows/cols by source w/h) [22:44:58 CEST] <durandal_1707> de-facto: not really, it allows any combination, even overlap, overlay filter is for transparency masking [22:48:36 CEST] <de-facto> hmm then i dont understand the documentation of xstack [22:49:06 CEST] <BtbN> I also don't see any sign of rotation in there, or cropping. [22:49:24 CEST] <furq> BtbN: transpose [22:49:36 CEST] <BtbN> ah [22:50:18 CEST] <de-facto> i removed the cropping i tried as a test, that is not the cause [22:50:51 CEST] <durandal_1707> bunch of overlays and setpst timeline changing needs RAM [22:50:56 CEST] <de-facto> it seems it encodes stable at constant memory and just before it finishes there is a crazy memory peak [22:51:17 CEST] <durandal_1707> to prove this, just attach graphmonitor at end and watch its output [22:51:39 CEST] <BtbN> The progress indicator also doesn't mean much when messing around with setpts [22:51:45 CEST] <BtbN> "the end" could be just it starting [22:51:58 CEST] <durandal_1707> yea [22:52:04 CEST] <de-facto> i just looked at the system monitor, but yeah maybe i need to use graph monitor [22:52:16 CEST] <durandal_1707> graphmonitor is filter [22:52:40 CEST] <durandal_1707> it shows issues with filtergraphs [22:52:47 CEST] <BtbN> I don't understand those setpts lines. Are they supposed to queue the 4 videos one after the other? [22:53:30 CEST] <furq> it's supposed to offset each one by 7.5 seconds [22:54:35 CEST] <durandal_1707> that will cause big cache of frames, which needs RAM [22:54:56 CEST] <de-facto> maybe my version 3.4.4-0ubuntu0.18.04.1 is too old? [22:55:12 CEST] <furq> they're small-ish frames and the source video is only 30 seconds long [22:55:18 CEST] <furq> so i wouldn't have thought it'd be that bad [22:55:29 CEST] <furq> but yeah graphmonitor will tell you for sure [22:55:43 CEST] <de-facto> im just not sure how to use that [22:55:44 CEST] <furq> de-facto: https://www.johnvansickle.com/ffmpeg/ [22:56:01 CEST] <furq> graphmonitor is new in 4.1 [22:58:55 CEST] <de-facto> yup i thought that already [22:59:22 CEST] <de-facto> weird thing is it encodes happily until 28 seconds in the video, then stalls and just allocates memory until its killed [22:59:52 CEST] <de-facto> same with the 4.1.3 static build [23:02:33 CEST] <furq> is it actually writing anything to the file [23:03:56 CEST] <de-facto> yes i think a little bit, but its unplayable [23:08:22 CEST] <de-facto> maybe its level and profile? [23:13:09 CEST] <durandal_1707> nope, that is tipical for mp4 [23:15:03 CEST] <de-facto> i think its something with the DURATION=30 and -t "${DURATION}" [23:17:27 CEST] <de-facto> i dont understand it, have to experiment for a while [23:23:37 CEST] <de-facto> what does this line mean? -i "color=r=60:c=black:s=1600x1200:d=120" [23:26:47 CEST] <kepstin> de-facto: ` -f lavfi -i "<some stuff>" ` means "run the filters listed in <some stuff> and use their output as an input to ffmpeg" [23:27:40 CEST] <de-facto> ok its a black 1600x1200 60 fps video i guess [23:27:53 CEST] <kepstin> de-facto: so in this case, the "color" filter just generates a blank video to use as an input to composite the other stuff over [23:29:35 CEST] <de-facto> kepstin, ok but i dont understand "color=r=60" and also not "d=120" [23:30:56 CEST] <kepstin> de-facto: https://www.ffmpeg.org/ffmpeg-filters.html#Filtergraph-description [23:31:35 CEST] <kepstin> de-facto: basically, you have a filter name, then an equals sign, then a list of options for the filter separated with : [23:32:40 CEST] <durandal_1707> http://ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_002c-color_002c-hal... [23:33:31 CEST] <de-facto> yeah i am already trying to read that [23:36:18 CEST] <de-facto> so its the color source with color=... with the options separated by : e.g. r=60:c=black:s=1600x1200:d=120 trying to find documentation of those specifically d=120 i guess its duration? [00:00:00 CEST] --- Sat Apr 27 2019