[00:00:57 CEST] <philipl> "working" is a probabilistic statement [00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:315f51128a95: avcodec/prores_kostya: increase bits usage when alpha is used [00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:4bd4fc56abf9: avcodec/proresenc_kostya: use frame metadata instead of avctx [01:07:29 CEST] <cone-547> ffmpeg 03Michael Niedermayer 07master:7d317d4706b4: avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in priv_data [01:07:49 CEST] <michaelni> durandal_170, should be fixed [02:03:10 CEST] <iive> atomnuker: what asm did you use for the tests? [02:04:24 CEST] <atomnuker> nasm [02:04:40 CEST] <iive> version? [02:05:21 CEST] <atomnuker> 2.13 [02:05:30 CEST] <atomnuker> 2.13.01 [02:05:47 CEST] <iive> ok, i have the same nasm version. [02:12:40 CEST] <iive> atomnuker: btw, I do not have complete benchmarks from you. some defines were missing the the file. have you done them? [02:14:18 CEST] <iive> if you haven't, don't do them now, i'll be leaving in a moment [02:15:42 CEST] <atomnuker> no, not yet, what should I do? [02:15:46 CEST] <atomnuker> *what else [02:19:33 CEST] <iive> stall_write_forwarding, short_syy_update, [02:19:50 CEST] <iive> const_in_x64_reg_is_faster [02:20:06 CEST] <iive> and the blends... [02:30:28 CEST] <iive> see ya [03:19:40 CEST] <kierank> atomnuker: no it was fork drama at the time [03:19:44 CEST] <kierank> iirc [04:01:37 CEST] <atomnuker> ? [08:41:35 CEST] <rcombs> atomnuker: the prores stuff, presumably [09:14:00 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading [09:56:00 CEST] <cone-442> ffmpeg 03Matthieu Bouron 07master:db5bf64b214d: lavc/x86: clear r2 higher bits in ff_sbr_sum_square [12:56:28 CEST] <TMM> good afternoon all! [13:07:50 CEST] <wm4> it's not good, it's too hot [13:14:15 CEST] <durandal_1707> michaelni: have you looked at #5405, its about ffv1? [13:30:03 CEST] <TMM> wm4, it finally cooled down here a bit, it was way too hot lately though [13:35:24 CEST] <kierank> J_Darnley: ask atomnuker here if you have questions please [15:27:48 CEST] <BBB> gh0st__: Ill probably push your patch sometime today [15:27:54 CEST] <BBB> gh0st__: unless people have review comments [15:28:10 CEST] <gh0st__> BBB:Sure [15:28:41 CEST] <BBB> next& threading? [15:29:03 CEST] <kierank> durandal_1707: holy crap you are [15:29:04 CEST] <kierank> ][';/./# [15:29:04 CEST] <kierank> ][=] [15:29:08 CEST] <kierank> shit [15:29:52 CEST] <durandal_1707> kierank: what? [15:30:13 CEST] <kierank> finally getting rid of prores dupes [15:30:38 CEST] <BBB> \o/ [15:30:40 CEST] <BBB> hurray [15:32:34 CEST] <gh0st__> BBB: Yes, I'll do one or two more avx2 versions of the directional intra predictions, by then I'll settle all my business with my university, and we can do tile threading. =) [15:32:45 CEST] <BBB> ok [15:35:42 CEST] <BBB> which one is next? I guess one of the hu/hd or vl/vr ones? [15:35:54 CEST] <BBB> hu/vl are probably easier since they only use one edge [15:36:08 CEST] <BBB> hd/vr are like ddr, they use both edges so a little more complicated [15:37:59 CEST] <gh0st__> Yeah, I'll do vl and vr they are pretty simple indeed. [15:38:50 CEST] <atomnuker> what about loopfilter avx2? [15:39:26 CEST] <gh0st__> atomnuker: I will do that too. [15:41:21 CEST] <atomnuker> BBB: do you know if youtube enable tile threaded decoding on any encodes they do? [15:41:37 CEST] <BBB> I believe it is, yes [15:41:56 CEST] <BBB> atomnuker: 10-bit will be done; 8-bit is in the planning but also very hard so cant guarantee well get to it [15:44:56 CEST] <atomnuker> odd, on a 4k video ripped from youtube I'm getting 1 row and 8 cols (s->s.h.tiling.tile_cols) [15:45:09 CEST] <atomnuker> on an 8k I'm getting 1 row and 16 cols [15:46:14 CEST] <nevcairiel> twice the width, twice the cols? :) [15:46:27 CEST] <atomnuker> yes, but 1 row? [15:51:48 CEST] <BBB> rows affect latency, not threading [15:52:03 CEST] <BBB> they have rows-mt also but apparently youtube isnt using it [15:52:16 CEST] <BBB> its a bitstream thing [15:52:22 CEST] <BBB> rows are different than cols in dependency handling [15:52:43 CEST] <BBB> so threading for cols is more independent than rows [15:55:33 CEST] <J_Darnley> atomnuker: So kierank has asked me to add sliced threading to the VC-2 encoder. Do you have any suggestions on where to start? [15:57:02 CEST] <atomnuker> J_Darnley: start with small 128x128 yuv444p samples, set -slice_width 128 and -slice_height 128 [16:01:45 CEST] <atomnuker> that way you can reorder stuff knowing quickly whether it works [16:01:53 CEST] <atomnuker> also -wavelet_depth 1 [16:02:12 CEST] <atomnuker> then add support for multiple wavelet levels [16:02:19 CEST] <atomnuker> then add support for more than 1 slice [16:03:06 CEST] <atomnuker> for now bodge the function which calculates slice sizes to output the worst case scenario [16:03:45 CEST] <J_Darnley> kierank said I should forget about rate control and just use const quant. [16:04:18 CEST] <J_Darnley> I guess bodging would have a similar effect [16:04:39 CEST] <atomnuker> if you have a constant quant you'll still need to calculate the worst case scenario [16:04:58 CEST] <atomnuker> (its one and the same, of course you need to fix the quantizer) [16:05:26 CEST] <atomnuker> and do keep in mind the worst case scenario in dirac is very very bad in terms of size [16:06:17 CEST] <atomnuker> and even the best scenario with a high quantizer will still give you a grey output and a large amount of bits spent encoding just gray [16:07:31 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:449cdfa687f7: avcodec/ffv1: Increase the maximum number of slices to 1024 [16:07:32 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:4147bb905346: avcodec/ffv1enc: Try to choose slice count so that slice packet sizes are within the supported size [16:07:33 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:ea5366670e26: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [16:07:34 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:3c7025178064: avcodec/jpeg2000dwt: Fix integer overflows in sr_1d97_int() [16:31:04 CEST] <atomnuker> durandal_1707: which decoder do you plan on leaving? [16:32:00 CEST] <JEEB> ffmpeg Paul B Mahol master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading <- based on this the kostya one? [16:32:24 CEST] <JEEB> because I'd be surprised if he improved an encoder if he was going to drop it [16:32:27 CEST] <JEEB> &32 [16:32:38 CEST] <kierank> atomnuker: constant quant to experiment [16:32:48 CEST] <kierank> J_Darnley: no it's not slice threading [16:33:25 CEST] <atomnuker> JEEB: I said decoder, not encoder [16:33:38 CEST] <kierank> J_Darnley: it's slice-by-slice encoding [16:34:11 CEST] <BBB> durandal_1707: \o/ [16:35:40 CEST] <JEEB> atomnuker: ah right [16:35:47 CEST] <JEEB> didn't remember we had multiple *decoders* [16:36:04 CEST] <BBB> we should get rid of the gpl one [16:36:07 CEST] <BBB> this is so ridiculous [16:36:15 CEST] <BBB> arent they both the same anyway? [16:36:29 CEST] <BBB> (or maybe theyre now both lgpl; still, get rid of the one that is not in libav) [16:46:02 CEST] <JEEB> 734 [16:50:05 CEST] <durandal_1707> BBB: libav one is slightly slower [16:50:34 CEST] <BBB> then delete the other [16:50:42 CEST] <cone-442> ffmpeg 03Kyle Swanson 07master:c11ca6105e69: avcodec/g722enc: force mono channel layout [16:51:30 CEST] <durandal_1707> BBB: but the other one is less nice looking code [16:51:36 CEST] <BBB> are you plannign to address decoder duplication also? [16:51:49 CEST] <durandal_1707> will try [16:52:06 CEST] <BBB> \o/ [16:52:08 CEST] <BBB> hero [16:53:00 CEST] <atomnuker> durandal_1707: here performance > code quality, this isn't some hypercomplicated codec, its jpeg, you can always fix code if you don't like it [16:54:58 CEST] <kierank> it's an encoder [16:55:03 CEST] <kierank> surely the best quality is best [16:58:49 CEST] <atomnuker> DEcoder [16:59:04 CEST] <atomnuker> both decoders are lgpl [17:13:23 CEST] <durandal_1707> the elvis one was initially gpl for some reason [17:41:20 CEST] <BBB> hehe the sizeof_mismatch isnt doing its job in coverity [17:55:04 CEST] <ubitux> durandal_1707: feel free to update the "Collateral damage" section in doc/libav-merge.txt [17:55:13 CEST] <ubitux> (when you're done) [17:56:26 CEST] <durandal_1707> only when kierank posts dolby-e decoder [18:04:47 CEST] <durandal_1707> kierank: could you at least improve dolby-e description in wiki? [19:44:33 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:e9510dc03284: avfilter: remove usage of empty header [19:52:20 CEST] <JEEB> durandal_1707: cool stuff with utvideodec [19:52:29 CEST] <JEEB> funny how everyone forgot aboug planar RGB [19:52:50 CEST] <JEEB> even though, indeed, that is the native format [19:53:29 CEST] <BBB> did that exist when the native decoder was written? [19:53:41 CEST] <BBB> (planar rgb pix_fmt) [19:54:00 CEST] <JEEB> I don't exactly remember [19:54:10 CEST] <JEEB> I think it was circa 2011 or so [19:54:37 CEST] <JEEB> I then started poking around the encoder in 2012, and I even was a hard-headed SIMD "student" for you at one point :) [19:54:51 CEST] <BBB> oct 2011 [19:56:47 CEST] <BBB> aaaa [19:56:48 CEST] <BBB> and [19:56:53 CEST] <BBB> I added planar RGB (really!) [19:56:54 CEST] <BBB> in nov 2011 [19:56:55 CEST] <BBB> bd97b2e1ce713a4886d909f71b6f1f5403446f53 [19:57:07 CEST] <BBB> I dont even remember that [19:57:18 CEST] <JEEB> :D [19:57:20 CEST] <BBB> so yes, it wasnt around back then ;) [19:57:30 CEST] <JEEB> just like I don't remember adding high bit depth y4m into x264cli [19:57:47 CEST] <BBB> hbd y4m is a hack anyway :-p the original y4m software doesnt support it [19:57:53 CEST] <JEEB> true that [19:57:59 CEST] <JEEB> but it was simpler than adding NUT [19:58:13 CEST] <JEEB> and FFmpeg already supported it [19:58:17 CEST] <BBB> indeed [19:58:28 CEST] <BBB> wasnt that the point of y4m? to be an interop format between different tools? [19:58:38 CEST] <BBB> I thought it originated in mjpegtools but maybe Im way off [19:58:45 CEST] <JEEB> yea, it originated around there [19:59:52 CEST] <BBB> (I originate from mjpegtools also :-p) [20:00:05 CEST] <wm4> BBB is deprecated! [20:00:14 CEST] <BBB> its about time [20:00:35 CEST] <BBB> /shutdown -h now [20:04:44 CEST] <BBB> is anyone here attending VDD? [20:04:46 CEST] <BBB> err [20:04:47 CEST] <BBB> I mean [20:04:48 CEST] <BBB> demuxed [20:06:02 CEST] <Compn> what country is demuxed in ? [20:06:09 CEST] <BBB> us, san fransisco [20:06:29 CEST] <Compn> october 5th [20:07:03 CEST] <wm4> lol traveling to the US [20:07:18 CEST] <kierank> BBB: if my submission is accepted [20:08:07 CEST] <JEEB> wm4: no laptops and reset your phone before you go [20:08:15 CEST] <BBB> Im wondering if I should talk about stuff [20:08:38 CEST] <JEEB> wm4: actually this seems to be pretty solid advice https://mricon.com/i/travel-laptop-setup.html [20:08:47 CEST] <JEEB> even if not going to china [20:09:00 CEST] <Compn> bring usb drive? then just buy cheap netbook when you get to the states ? [20:09:15 CEST] <JEEB> Compn: or bring over a basic laptop with a pure install that isn't encrypted [20:09:21 CEST] <BBB> the easiest solution is to live in the US [20:09:22 CEST] <JEEB> just so you can boot it up and connect to wifi [20:09:26 CEST] <BBB> then you dont have to worry about bring stuff in [20:09:37 CEST] <JEEB> I would probably never fit into the US [20:09:46 CEST] <nevcairiel> BBB: as long as you never leave =p [20:09:49 CEST] <JEEB> I like government help and pay 40% taxes [20:10:02 CEST] <BBB> JEEB: depends on the state [20:10:29 CEST] <kierank> JEEB: yes but you don't have a space programme [20:10:33 CEST] <kierank> which is the best part of usa [20:10:45 CEST] <JEEB> yes, and I like the fact that the private enterprises are doing that now [20:10:48 CEST] <wm4> doesn't russia have a better one [20:10:49 CEST] <JEEB> I mean, not lockheed etc [20:10:53 CEST] <nevcairiel> at this state i dont even want to visit the US, never mind living there [20:11:25 CEST] <Compn> now would probably be a good time to visit [20:11:32 CEST] <Compn> as long as you arent muslim... [20:17:15 CEST] <BBB> kierank: what are you talking about again? [20:17:25 CEST] <kierank> Uncompressed video over IP [20:17:53 CEST] <kierank> and the simd & zero copy stuff around that [20:48:02 CEST] <kierank> JEEB: any idea who filler56789 is? [20:48:23 CEST] <JEEB> nope [20:49:12 CEST] <nevcairiel> i've seen the name around doom9 in places [20:59:05 CEST] <TD-Linux> nevcairiel, speaking of, do you know how I can get my posts on doom9 approved? [21:02:40 CEST] <JEEB> TD-Linux: huh, yours are still in mod queue? [21:08:50 CEST] <TD-Linux> JEEB, yes [21:09:24 CEST] <shincodex> "buffer_size", "Send/Receive buffer size (in bytes)", [21:09:31 CEST] <shincodex> but this only applies to udp [21:09:32 CEST] <shincodex> yet [21:09:39 CEST] <shincodex> the wording is lies [21:09:46 CEST] <shincodex> "buffer_size", "Underlying protocol send/receive buffer size", [21:09:56 CEST] <shincodex> the rtsp buffer_size does not control [21:10:12 CEST] <shincodex> "send_buffer_size", [21:10:13 CEST] <shincodex> for tcp [21:10:15 CEST] <shincodex> why? [21:21:22 CEST] <BBB> I dont know. do you want it to? [21:29:15 CEST] <shincodex> hmmm [21:29:34 CEST] <shincodex> better business bureau? [21:33:28 CEST] <kierank> lol [22:04:15 CEST] <BBB> still waiting for j_darnleys glorious push [22:04:17 CEST] <BBB> where is it? [22:05:58 CEST] <feliwir> hey, how do i synchronise two seperate files with libav for playback? E.g. i have a video file (vp6) and an audio file that is the audiostream for that video (mp3) [22:09:41 CEST] <shincodex> So [22:09:51 CEST] <shincodex> send_buffer_size or recv_buffer_size [22:09:58 CEST] <shincodex> are in options list but are ignored for tcp.c [22:10:05 CEST] <shincodex> does that sound right to you? [22:10:39 CEST] <shincodex> coming from RTSP [22:12:05 CEST] <BBB> feliwir: https://ffmpeg.org/faq.html#How-can-I-join-video-files_003f [22:12:17 CEST] <BBB> feliwir: and I think this probably belongs in #ffmpeg, not here [22:12:36 CEST] <BBB> shincodex: like I just said, not necessarily. if youd like it to be different, submit a patch? :) [22:12:57 CEST] <shincodex> Why is it like a giant guess with this whole framework [22:13:10 CEST] <shincodex> I really wish i was just using it wrong [22:13:31 CEST] <shincodex> sprintf(tempBuff, "%lld", tcpOptions.sendBufferSize); av_dict_set(&options, "send_buffer_size", tempBuff, 0); [22:13:35 CEST] <shincodex> int err = avformat_open_input(&formatContext, openPath.c_str(), inputFormat, &options); [22:13:38 CEST] <shincodex> its in there somewhere [22:17:38 CEST] <shincodex> oh... this really might be unfinished code [22:24:56 CEST] <feliwir> BBB, i want to do it in libav [22:24:56 CEST] <feliwir> not ffmpeg [22:25:21 CEST] <BBB> maybe ask in #libav-devel then or so? [22:26:01 CEST] <rcombs> I'm in London; anybody wanna hang out? [22:26:41 CEST] <rcombs> kierank? [22:26:57 CEST] <wm4> BBB: I think he means via the ffmpeg libraries and C API [22:27:08 CEST] <BBB> oh I see [22:27:15 CEST] <BBB> feliwir: you mean libavcodec/format etc.? [22:27:52 CEST] <kierank> rcombs: where in london [22:28:29 CEST] <kierank> If you are near the river I might end up seeing you anyhow [22:28:50 CEST] <rcombs> Holland Park Station [22:29:04 CEST] <rcombs> I'll be around until Friday [22:29:44 CEST] Action: kierank is running round the thames [22:30:14 CEST] <wm4> why are you in Britain anyway? [22:30:53 CEST] <kierank> Place to be [22:31:13 CEST] <rcombs> vacation [22:32:16 CEST] <wm4> strange choice [23:14:23 CEST] <atomnuker> iive: I'll do the tests in an hour or so, haven't forgotten [23:21:30 CEST] <iive> np [23:29:13 CEST] <BtbN> Why does the ocr filter have no way to dump out what it's recognizing? Getting out the frame metadata is hard. [23:29:24 CEST] <BtbN> I ended up just hacking file dumping into there [23:36:17 CEST] <rcombs> BtbN: because lavfi doesn't do subtitles yet [23:36:29 CEST] <BtbN> I don't want it as subtitle [23:36:36 CEST] <BtbN> I just want it as plain text [23:36:56 CEST] <BtbN> just log it for all I care, I can grep that out of the output [23:38:05 CEST] <BtbN> I just put something in that fopens a file, and writes every scanned line into a text file [23:38:21 CEST] <BtbN> it works surprisingly well [23:40:47 CEST] Action: wm4 can't wait for the trainwreck that will be subtitles [23:40:52 CEST] <wm4> it can barely do audio/video [23:41:35 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:3594788b713e: avcodec/utvideodec: decode to GBR(A)P [23:45:50 CEST] <BtbN> Well, I want it to parse a 140x60 image for a 2 or 3 digit number. It does that reliably. [00:00:00 CEST] --- Tue Jun 27 2017