[00:02:05 CEST] <durandal_1707> convolve_add ? [00:02:51 CEST] <durandal_1707> if its used by single filter i can not move it to lavu? [00:05:07 CEST] <kierank> durandal_1707: what does it do exactly the function? [00:06:18 CEST] <durandal_1707> it multiplies two complex numbers and sum it to accumulator [00:06:52 CEST] <durandal_1707> accumulator is also complex number [00:08:34 CEST] <kierank> scalarproduct_complex [00:08:48 CEST] <kierank> or just scalarproduct if you want [00:09:13 CEST] <jamrial> the former [00:10:10 CEST] <nevcairiel> if it does the same as scalarproduct_float just on complex numbers, then scalarproduct_complex is what it should be called [03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:80a3227be624: ffprobe: make function replacement macros behave correctly [03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:3c3d4ce4fda1: doc: fix bistream typo [03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:8b1f66cf5c2e: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int' [03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:3a4d387195a5: avcodec/ffv1dec: Fix copying planes of paletted formats [03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:5f928c5201c0: avcodec/rangecoder: Test for invalid corner case [05:52:28 CEST] <atomnuker> rcombs: ping [05:52:32 CEST] <rcombs> hi [05:52:53 CEST] <atomnuker> solved flac problems? [05:53:05 CEST] <rcombs> oh yeah, would probably help if I rebased and resent, wouldn't it [05:53:40 CEST] <atomnuker> yep, very much so [06:39:55 CEST] <rcombs> atomnuker: there you go [06:47:19 CEST] <atomnuker> cool [06:47:26 CEST] <atomnuker> I've send my librsvg patches too [06:54:54 CEST] <jamrial> rcombs: ideally, you'd make flac_write_picture() shared in its own file (or in flac_picture.c) [06:55:11 CEST] <jamrial> so it can be used by the ogg muxer [06:55:12 CEST] <rcombs> oh, is that something other code would want to do? [06:55:14 CEST] <rcombs> ahh [06:55:47 CEST] <rcombs> flac_picture.c sounds good [06:57:10 CEST] <jamrial> that file has the decode picture function, so i'm not sure if the encode one should go there [06:57:17 CEST] <jamrial> maybe flacenc_picture.c instead [06:57:22 CEST] <cone-370> ffmpeg 03Daniil Cherednik 07master:b8c2b9c39279: avcodec/dcaenc: Initial implementation of ADPCM encoding for DCA encoder [06:59:01 CEST] <rcombs> maybe flac_picture_enc.c? [06:59:17 CEST] <rcombs> (does it really matter?) [07:01:59 CEST] <jamrial> I prefer flacenc_picture.c [07:03:31 CEST] <atomnuker> yeah, would be nice to be able to embed pictures inside ogg files too [07:17:54 CEST] <atomnuker> rcombs: what does the segment muxer do? [07:18:12 CEST] <rcombs> like, in general? [07:18:25 CEST] <atomnuker> yeah [07:19:22 CEST] <rcombs> writes output to multiple segment files, using some underlying muxer [07:19:55 CEST] <atomnuker> is it used by the flac muxer? [07:20:26 CEST] <atomnuker> wait, multiple segment files? [07:20:29 CEST] <rcombs> you can use whatever underlying muxer you like [07:20:34 CEST] <atomnuker> it writes to multiple files? [07:20:38 CEST] <rcombs> yes [07:21:17 CEST] <rcombs> it can either reopen the underlying muxer for each file, or keep the muxer open and reopen the AVIOContext [07:21:47 CEST] <rcombs> in this case, I'm using it to split cue/flac pairs [07:22:22 CEST] <rcombs> the cue demuxer outputs the cue sheet's contents as chapters, and the flac file's contents as streams and packets [07:22:37 CEST] <atomnuker> damn, I didn't know this was possible [07:22:39 CEST] <rcombs> I configure the segment muxer to split each chapter into a separate .flac file [07:22:59 CEST] <rcombs> with the filenames based on the chapter metadata [07:23:14 CEST] <rcombs> the primary disadvantage is that it only gives packet-level granularity, rather than sample-level [07:26:09 CEST] <wm4> such a hack [07:26:51 CEST] <rcombs> you're not wrong [07:27:48 CEST] <rcombs> atomnuker: if you come up with something better for this use-case (small C wrapper around lavf+lavc, I'd imagine?), I'd be happy to use that instead [07:29:30 CEST] <atomnuker> rcombs: no, to split cue to stuff I have a lua script which decodes to a wav and lets shnsplit do [07:29:44 CEST] <atomnuker> *do the splitting and encoding [07:30:10 CEST] <rcombs> I'm not sure if that's better or not [07:30:17 CEST] <atomnuker> shnsplit doesn't support tta [07:31:13 CEST] <atomnuker> its alright, cue files don't offer sample precise offsets [07:31:44 CEST] <atomnuker> so however you split them they'll be imprecise [07:32:05 CEST] <rcombs> frame-precise, though (588 samples) [07:32:17 CEST] <rcombs> and it's as precise as the CD itself gets, right? [07:32:53 CEST] <atomnuker> well CD tracks are segmented into frames of 2100ish bytes [07:33:23 CEST] <rcombs> 75 frames per second [07:33:23 CEST] <atomnuker> I guess that's actually more precise than CD frames themselves [07:33:35 CEST] <atomnuker> or less, no idea [08:11:26 CEST] <atomnuker> rcombs: got any idea how to test your patches? [08:12:57 CEST] <atomnuker> I'm writing an image packet with a separate stream index with the lavf API but nothing seems to happen [08:14:43 CEST] <rcombs> specifically trying to test the FLAC attachment support, then? [08:15:00 CEST] <atomnuker> https://github.com/atomnuker/cyanrip/blob/master/src/cyanrip_encode.c#L226 [08:15:14 CEST] <atomnuker> yep [08:16:05 CEST] <rcombs> pkt->stream_index = 0; <-- don't you want 1? [08:16:47 CEST] <rcombs> also, fmt->video_codec is meant to be immutable [08:16:49 CEST] <atomnuker> (btw the cue demuxer seems to work fine) [08:17:07 CEST] <rcombs> you should configure st_img->codecpar instead [08:17:26 CEST] <atomnuker> but that would mean configuring an encoder as well, no? [08:17:33 CEST] <atomnuker> (I don't want to encode, just mux) [08:17:49 CEST] <rcombs> no [08:18:03 CEST] <rcombs> codecpar is independent from actual encoders [08:18:30 CEST] <rcombs> and I _think_ what you want to do here is set st_img->attached_pic before calling write_header [08:18:57 CEST] <rcombs> rather than calling av_interleaved_write_frame for the attachment yourself [08:19:02 CEST] <rcombs> lavf will do it for you [08:19:10 CEST] <rcombs> make sure to set the stream disposition as well [08:19:33 CEST] <rcombs> welp [08:20:09 CEST] <rcombs> atomnuker: what was the last line you caught of that [08:20:25 CEST] <atomnuker> "rcombs | codecpar is independent from actual encoders" [08:20:35 CEST] <rcombs> <rcombs> and I _think_ what you want to do here is set st_img->attached_pic before calling write_header [08:20:35 CEST] <rcombs> <rcombs> rather than calling av_interleaved_write_frame for the attachment yourself [08:20:35 CEST] <rcombs> <rcombs> lavf will do it for you [08:20:35 CEST] <rcombs> <rcombs> make sure to set the stream disposition as well [08:21:52 CEST] <atomnuker> but for encoding attached_pic in AVStream is listed as unused [08:22:08 CEST] <atomnuker> I also checked and its not used anywhere thoughout the muxers [08:22:20 CEST] <atomnuker> (or does your patch change that?) [08:22:26 CEST] <rcombs> oh derp, you're right [08:22:36 CEST] <rcombs> yeah, I was looking at the wrong code [08:22:56 CEST] <atomnuker> how do I initialize codecpar? [08:23:15 CEST] <rcombs> st_img->codecpar->codec_id = <&> [08:23:19 CEST] <rcombs> that might be all you need [08:23:43 CEST] <rcombs> then set the disposition and make sure you get the stream index right [08:26:26 CEST] <atomnuker> nope, not getting a thing [08:27:01 CEST] <atomnuker> I don't think st_img is registered properly if there's such a thing [08:28:04 CEST] <rcombs> nothing in the log? [08:28:39 CEST] <rcombs> also, you don't need to set nb_streams; avformat_new_stream does that [08:28:44 CEST] <atomnuker> av_dump_format doesn't print anything to suggest there's another stream [08:29:44 CEST] <rcombs> oh, and you should set codecpar->codec_type = AVMEDIA_TYPE_VIDEO [08:31:33 CEST] <rcombs> you can do ffmpeg -i input.flac -c copy output.flac and see it works [08:31:42 CEST] <rcombs> (for an input file with an attached picture) [08:32:13 CEST] <atomnuker> that's odd, dumping stream index 1 prints the same as stream index 0 (audio, flac, etc.) [08:33:02 CEST] <atomnuker> yep, that works [08:33:16 CEST] <rcombs> hmm? dumping a particular stream? [08:33:30 CEST] <rcombs> afaik there's no public function for that [08:33:32 CEST] <atomnuker> av_dump_format(avf, 1, filename, 1); instead of av_dump_format(avf, 0, filename, 1); [08:33:56 CEST] <rcombs> the second arg is a file index, not a stream index [08:34:01 CEST] <rcombs> it's just used in the string output [08:34:17 CEST] <rcombs> for things like "#<file index>:<stream index>" [08:37:28 CEST] <atomnuker> updated the file [08:40:50 CEST] <atomnuker> when using ffmpeg.c and copying stream index 0 on the input is audio but on the output stream index 0 is video [08:43:53 CEST] <atomnuker> swapping the stream indices here though causes "Invalid packet stream index: 1" to be printed [08:55:41 CEST] <atomnuker> rcombs: what's also odd is writing to st->metadata doesn't write anything at all on the output [09:36:13 CEST] <trapp> Hi! Just wantes to push a patch but SSH reports a changed RSA host key for source.ffmpeg.org . Can someone confirm that this is to be expected? [09:36:13 CEST] <trapp> The fingerprint for the new RSA key is SHA256:KVBtJbvfrNcF+McexrkKdLtPNr+37PXjOUnRuGcqwJo. [09:40:22 CEST] <wm4> I know it changed a few days or weeks before and it was expected [09:48:00 CEST] <JEEB> weeks, but yea. if you want to double-check with someone I think thresh from #videolan is the one maintaining those boxes [10:05:24 CEST] <trapp> Yes, it's been some weeks since my last commit. Thanks. [10:09:48 CEST] <cone-453> ffmpeg 03Tobias Rapp 07master:78f51ecb7411: tests/fate/fifo-muxer: update fifo-muxer dependencies [10:54:56 CEST] <ubitux> http://boxbase.org/entries/2017/may/8/optimizing_lever_png/ [10:59:15 CEST] <wm4> ubitux: "the fuck" [10:59:34 CEST] <kierank> wm4: +1 [11:00:03 CEST] <wm4> also it's missing a conclusion [11:00:08 CEST] <wm4> how fast did he get it? [11:00:19 CEST] <thardin> nice glitch [11:04:31 CEST] <thardin> vectorizing png decoding sounds a bit tricky [11:08:44 CEST] <ubitux> i learned one thing: "layout asm" in gdb [11:08:59 CEST] <ubitux> i'll be sure to use it next time [12:35:37 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:1e42736b9506: avcodec/cdxl: Check format for BGR24 [12:35:38 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:279420b5a63b: avcodec/cavsdec: Check sym_factor [12:35:39 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:5d5118f81bd5: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col() [12:35:40 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:8824b7370a9f: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int' [12:59:01 CEST] <kierank> BBB: J_Darnley is going to be working on mpeg-2 asm conversion over the next few weeks [13:23:21 CEST] <wm4> inline asm -> yasm? [13:23:24 CEST] <wm4> or nasm [13:23:29 CEST] <wm4> since yasm is dead [13:24:55 CEST] <JEEB> yea, nasm changed license and yasm-ng isn't gonna become reality [13:25:09 CEST] <JEEB> so, uh, yasm effectively accomplished its mission [13:25:16 CEST] <JEEB> by becoming unneeded [13:25:40 CEST] <nevcairiel> its practically the same syntax anyway [13:33:47 CEST] <iive> isn't yasm a fork of nasm? [13:36:26 CEST] <nevcairiel> its a rewrite [13:37:43 CEST] <BBB> kierank: thats amazing [13:38:02 CEST] <kierank> wm4: yes [13:38:07 CEST] <BBB> vp8dsp? [13:38:11 CEST] <kierank> BBB: are you able to help J_Darnley from time to time [13:38:14 CEST] <BBB> michaelni: is that patch on the ML? [13:38:17 CEST] <BBB> kierank: of course [13:38:46 CEST] <BBB> michaelni: please send patches to vp8 to the ML, I still maintain and review that [13:42:26 CEST] <michaelni> BBB do you also want to review webp ? (as its using vp8) [13:42:46 CEST] <BBB> I can look, but I dont necessarily care for it as much ;) [13:50:30 CEST] <BBB> michaelni: the above patch looks OK, I think C is clunky there but what can you do [14:22:10 CEST] <J_Darnley> I will start with the functions in simple_idct.c [14:24:11 CEST] <kierank> ok [14:27:42 CEST] <J_Darnley> I think I can get the syntax all turned around today and have a nasm mmx version working tomorrow [14:28:05 CEST] <kierank> nice [14:30:31 CEST] <wm4> so we will untangle mpegvideo? [14:30:38 CEST] <wm4> or is it just asm [14:30:55 CEST] <J_Darnley> Just asm, inline -> nasm right now [14:32:08 CEST] <Compn> untangle mpegvideo? it will only become angry... [14:32:09 CEST] <Compn> ehe [14:32:12 CEST] <BBB> J_Darnley: Ive looked at some of that stuff [14:32:30 CEST] <BBB> J_Darnley: I think if you simply convert without adding anything new (so ignore sse2 etc. for now), you should be OK [14:32:42 CEST] <BBB> J_Darnley: if you want to make it pretty, you will cry [14:32:47 CEST] <J_Darnley> :) [14:32:51 CEST] <BBB> J_Darnley: but thanks so much for doing this [14:33:11 CEST] <BBB> I think weve had multiple people work on aspects of inline->nasm conversion and its nice to see someone picking it up again [14:33:20 CEST] <J_Darnley> Hey, I'd sell my organs for money [14:33:24 CEST] <BBB> ... [14:33:26 CEST] <BBB> dont do that [14:33:35 CEST] <Compn> i'd buy your brain, $15 [14:34:04 CEST] <nevcairiel> what other major components are still inline asm? [14:37:03 CEST] <J_Darnley> A quick glance at `git grep HAVE_INLINE_ASM -- libavcodec/x86` suggests: old video stuff (mpeg), obscure video stuff (lossless and now), h264 cabac, vc1, vp 5 6 [14:37:25 CEST] <J_Darnley> *lossless and _snow_ [14:37:52 CEST] <J_Darnley> There's more inline assembly on other platforms [14:38:02 CEST] <nevcairiel> cabac is actual inline asm [14:38:30 CEST] <nevcairiel> ie. its mixed with C code all over [14:39:47 CEST] <J_Darnley> yeah, I don't think it is a candidate for being moved to nasm. [14:39:54 CEST] <J_Darnley> ever [14:41:16 CEST] <nevcairiel> someone should totally write much faster cabac code [14:44:03 CEST] <BBB> I think mpegvideo and vc1/vp56 are the interesting ones [14:44:13 CEST] <BBB> obscure video isnt very interesting [14:44:17 CEST] <BBB> (IMO) [14:46:15 CEST] <iive> nevcairiel: is it possible to be faster? [14:46:26 CEST] <BBB> oh vp56 is also arithmetic coding [14:46:29 CEST] <BBB> so ignore that one also [14:46:39 CEST] <BBB> its just the vc1 subpel MC and old mpegvideo stuff [14:46:48 CEST] <BBB> the vc1 isnt terribly interesting but would be nice to convert [14:47:04 CEST] <BBB> the mpegvideo is the only remaining one, but I think most people stopped caring because mpegvideo is old [14:47:22 CEST] <BBB> (it was interesting before the h264/mpeg split, but after that people lost interest, at least I did) [14:52:16 CEST] <kierank> faster cabac would be interesting but hard i guess [14:52:48 CEST] <nevcairiel> cabac isnt simd, so from an optimization stand-point it requires quite a different approach then what we usually do with asm [15:02:01 CEST] <wm4> ubitux: what's the deprecated "srt" decoder for?= [15:02:58 CEST] <ubitux> it's the format where you have timestamps in the packet payload [15:03:16 CEST] <nevcairiel> speaking of entropy coding, did av1 officially adopt the ANS entropy coding in favor of vp9s entropy coder? [15:04:22 CEST] <BBB> oh [15:04:31 CEST] <BBB> J_Darnley: snowdsp also (it doesnt use INLINE_MMX/etc. macros) [15:06:56 CEST] <BBB> (and fdct, cavs) [15:08:40 CEST] <atomnuker> nevcairiel: nope, the daala one was accepted [15:09:09 CEST] <nevcairiel> which one was that? [15:09:39 CEST] <atomnuker> the opus one which forgoes integer division and uses shifts [15:09:43 CEST] <wm4> ubitux: yeah, but the decoder is obviously not different [15:10:22 CEST] <ubitux> wm4: the decoder only supports SUBRIP now [15:10:32 CEST] <ubitux> it's just a legacy to have an alias srt/subrip [15:10:50 CEST] <ubitux> but CODEC_ID_SRT is no longer supported yes [15:11:13 CEST] <ubitux> srt could be dropped i suppose [15:11:15 CEST] <J_Darnley> BBB: I might have missed others because I only searched for HAVE_INLINE_ASM [15:15:38 CEST] <j-b> BtbN: everything is back to normal, accoridng to the graphs [15:17:47 CEST] <j-b> BtbN: but we have a weird attack on another server [15:18:12 CEST] <BtbN> weird, so is it actually trying to do a small scale DDoS or something? [15:18:33 CEST] <j-b> BtbN: I cannot say yet. [15:20:10 CEST] <j-b> BtbN: but I'm happy about our security and splitting each service in a lxc [16:06:42 CEST] <J_Darnley> Memeory arguments in __asm__ blocks all have byte offsets, right? [16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:0075d9eced22: avcodec/dvbsubdec: check region dimensions [16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:ea59ef0c031b: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int' [16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:29692023b2f1: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int' [16:17:49 CEST] <Tomaz^W> Quick question, is there an issue with the ffmpeg configure script and using openssl-1.1.0c? [16:18:22 CEST] <J_Darnley> quick answer: no idea [16:18:26 CEST] <Tomaz^W> Since there is no SSL_library_init anymore in 1.1.0_ [16:22:22 CEST] <nevcairiel> configure should support both 1.0 and 1.1, using 1.1 will likely make using pkg-config mandatory though [16:22:23 CEST] <jamrial> it's first checking for OPENSSL_init_ssl [16:22:45 CEST] <BtbN> openssl 1.1 compat was merged last year [16:22:52 CEST] <BtbN> if you're using some old release, it's time to update. [16:23:37 CEST] <BtbN> nevcairiel, to me configure looks like pkg-config alreads is mandatory for OpenSSL 1.1 [16:23:57 CEST] <Tomaz^W> Using 3.3 [16:23:57 CEST] <BtbN> all the non-pkg-config checks look for the old symbol [16:25:08 CEST] <BtbN> 3.3 has that. [16:25:18 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/n3.3/configure#L5918 [16:25:35 CEST] <Tomaz^W> Am using non-pkg-config tho [16:25:44 CEST] <nevcairiel> time to use pkg-config [16:25:47 CEST] <BtbN> pkg-config is mandatory for 1.1 [16:25:56 CEST] <cone-705> ffmpeg 03James Almer 07master:74fee9760f7a: configure: add missing lpc dependency to mlp and truehd encoders [16:49:31 CEST] <cone-705> ffmpeg 03James Almer 07master:2cb656ad1197: avcodec/mjpegenc: move ff_mjpeg_encode_picture_frame to mjpegenc_common [17:03:42 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:aaeec1c654a2: avcodec/wavpack: Fix signed integer overflow: 1285114081 * 2 cannot be represented in type 'int' [17:03:43 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:f4ae3cce64bd: avcodec/htmlsubtitles: Check for string truncation and return error [17:03:44 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:983e3fbcc5c9: avcodec/samidec: Check ff_htmlmarkup_to_ass() return code [17:03:45 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:7b94df232a4b: avcodec/srtdec: Check ff_htmlmarkup_to_ass() return code [17:03:46 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:8ef2c791c99e: doc/build_system: Document how to build decoder fuzzer [17:50:10 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/commits/mergework [17:50:28 CEST] <ubitux> ooh [17:50:37 CEST] <jamrial> h264 didn't merge cleanly, as usual, but it passes fate [17:50:49 CEST] <jamrial> i changed size_t to unsigned. not sure if wm4 will agree :p [17:50:50 CEST] <ubitux> did you figure out a way of rebasing all the merges? [17:51:20 CEST] <jamrial> no, i just reapply them when i need to rebase [17:51:40 CEST] <ubitux> how do you deal with the conflicts? [17:51:54 CEST] <nevcairiel> in many cases rerere can do magic [17:53:19 CEST] <jamrial> ubitux: when i first merge something i solve the conflicts the usual way. then if i need to rebase, i remerge with -s ours then apply the already cleaned changes i stashed somewhere else [17:53:27 CEST] <jamrial> kinda archaic, but works :p [17:53:34 CEST] <jamrial> i thought you had a script to rebase merges [17:54:14 CEST] <ubitux> it's a semi scripts, but it doesn't work well with delete/moves [17:54:39 CEST] <ubitux> nevcairiel: i should probably learn how to use that [17:54:46 CEST] <ubitux> anyway. [17:55:07 CEST] <ubitux> jamrial: which commits/merge are the sensible ones? [17:55:44 CEST] <jamrial> the h264 ones, since those didn't apply cleanly. then we need to decide if we keep the fields as size_t like libav, of make them unsigned like i did there [17:59:18 CEST] <wm4> jamrial: the crop params? well as I wrote in those mailing list discussions, I think it'd be better not to have such differences to Libav [18:00:02 CEST] <jamrial> wm4: size_t then? pity you couldn't convince them to switch to unsigned [18:00:36 CEST] <jamrial> size_t is kinda silly when they make sure all the calculated values are < INT_MAX, but whatever [18:00:49 CEST] <wm4> yeah, I agree [18:01:36 CEST] <wm4> they probably plan on changing other size quantities to size_t or similar too, so we'll get years of inconsistencies [18:02:45 CEST] <jamrial> i don't get the whole "they are sizes, so use size_t" [18:02:56 CEST] <jamrial> they are video dimensions, and are not system dependant [18:04:29 CEST] <wm4> indeed [18:05:22 CEST] <j-b> size_t is for the stuff that can be returned by sizeof, not for every size that exists in real life... [18:05:27 CEST] <wm4> even in theory int is pretty sufficient, because an image using INT_MAX dimensions would require a memory allocation near INT64_MAX size [18:06:36 CEST] <wm4> what I'd rather see would be removing the image size restriction of ~16000x16000 (or whatever it was) [18:06:47 CEST] <wm4> which actually triggers in real life [18:07:05 CEST] <wm4> but for crop dimensions, especially if width/height are still int, it seems ridiculous to me [18:11:26 CEST] <ubitux> if you want a portable code between the two projects you can still always cast to int [18:12:34 CEST] <ubitux> size_t for this doesn't make much sense [18:15:12 CEST] <BBB> wm4: wasnt that limit introduced so michaelnis fuzzing experiments go faster? [18:15:53 CEST] <wm4> BBB: AFAIK not? the image size limit is merely supposed to avoid int overflows when addressing pixels [18:16:04 CEST] <BBB> hm... [18:16:18 CEST] <BBB> but 1<<31 is much bigger than 16kx16k? [18:16:46 CEST] <wm4> I'm referring to av_image_check_size [18:19:09 CEST] <wm4> so when you do e.g. AVFrame.data[0] + AVFrame.linesize[0] * (int)x you could get an overflow if x and linesize are large [18:19:19 CEST] <wm4> err that would be y, but whatever [18:21:15 CEST] <nevcairiel> it like accounts for the worst possible cases [18:21:24 CEST] <nevcairiel> like, 8 byte per pixel and whatnot [18:21:29 CEST] <nevcairiel> or even more these days [18:21:48 CEST] <ubitux> jamrial: you kept offsets[] in size_t? [18:21:55 CEST] <BtbN> so nvenc on Linux gained OpenGL texture input support [18:23:50 CEST] <wm4> BtbN: seems odd [18:24:13 CEST] <wm4> given that opengl is pretty useless for image processing and icky as an API [18:24:27 CEST] <BtbN> Probably aimed at live-encoding games and stuff [18:24:41 CEST] <wm4> that on the other hand makes sense [18:24:41 CEST] <nevcairiel> likely [18:24:55 CEST] <wm4> but wouldn't they normally use cuda/opencl interop instead? [18:25:10 CEST] <BtbN> Well, they don't need to anymore now [18:25:25 CEST] <BtbN> Maybe they'll actually add OpenGL texture output support to nvdec, then it'd suddenly be a vdpau replacement candidate. [18:25:47 CEST] <wm4> nvdec=cuvid? [18:25:51 CEST] <BtbN> yes [18:25:55 CEST] <nevcairiel> yeah they renamed it [18:26:03 CEST] <wm4> doesn't that work already (just a bit awkward) [18:26:16 CEST] <BtbN> By using tons of non-free cuda functions, yes [18:26:29 CEST] <nevcairiel> 5) Decode capability API [18:26:30 CEST] <nevcairiel> 6) Decode latency reduction [18:26:34 CEST] <nevcairiel> i wonder what that means [18:26:42 CEST] <nevcairiel> i should diff the headers later [18:26:45 CEST] <BtbN> similar capability API like nvenc has [18:27:11 CEST] <wm4> I wonder of Libav's attempt of using cuvid as hwaccel will result in anything [18:29:33 CEST] <jamrial> ubitux: ah yeah, missed that [18:30:22 CEST] <jamrial> in any case, i'll change the fields back to size_t, so that should be ok [18:30:52 CEST] <jamrial> want me to force push that change to my repo? [18:31:39 CEST] <ubitux> i was just curious [18:35:45 CEST] <ubitux> i hope the cropping checks are sane [18:36:11 CEST] <ubitux> especially given the unsigned property of the cropping values often mismatching with the signdness of width/height [18:36:45 CEST] <ubitux> i suppose you checked that we didn't have more advanced checks on these [18:37:13 CEST] <jamrial> we did in h264's case i think [18:38:43 CEST] <jamrial> no, it was hevc. a cast to int64_t which i replaced with the new code in the merge [18:49:15 CEST] <ubitux> i don't see anything special to comment on [18:50:32 CEST] <BtbN> nevcairiel, pushed the updated headers to my github clone. [18:51:01 CEST] <nevcairiel> BtbN: i'm signed up for designworks or whatever one needed anyway [18:51:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/3d273dded7789318bbbe08462694322f4ddd5b... this looks interesting. I have no clue what a CUstream is, but a raw_output_dptr looks primising. Might save the extra memcpy? [18:52:27 CEST] <nevcairiel> they always had some incomplete API for processing raw YUV images through the nvdec processing pipeline, but it was never really functional [18:52:30 CEST] <nevcairiel> maybe they fixed it [18:52:45 CEST] <BtbN> it's at least no longer documented as "do not use" [18:53:08 CEST] <BtbN> but I have a hard time finding documentation for that API [18:53:30 CEST] <BtbN> Decoding capability API, "NVDECODE API to query hardware capabilities" [18:53:37 CEST] <BtbN> Nowhere to be found in the updated headers though? [18:53:51 CEST] <nevcairiel> tcuvidGetDecoderCaps ? [18:53:54 CEST] <nevcairiel> seems to be there [18:54:07 CEST] <BtbN> oh, indeed. blind [18:54:33 CEST] <BtbN> that should be able to resolve that horrible "try to create a dummy decoder to see if it works" hack [18:54:57 CEST] <wm4> how do you get a diff from the github patch view [18:55:16 CEST] <wm4> because it only shows a dumb loading animation instead of all the changes [18:55:18 CEST] <jamrial> wm4: append .patch to the url of the commit you're viewing [18:55:24 CEST] <wm4> jamrial: does nothing [18:55:41 CEST] <nevcairiel> https://github.com/BtbN/FFmpeg/commit/3d273dded7789318bbbe08462694322f4ddd5b... ? works for me [18:55:44 CEST] <jamrial> it does for me, gives me a raw text patch [18:55:57 CEST] <nevcairiel> have to strip out the anchor link [18:56:04 CEST] <wm4> opening this link worked [18:56:14 CEST] <wm4> appending it to the address in firefox didn't [18:56:16 CEST] <wm4> wtf [18:56:34 CEST] <BtbN> .patch or .diff [18:56:35 CEST] <wm4> I should leave tech and start gardening or so [18:56:39 CEST] <BtbN> .diff is more human readable iirc [18:56:58 CEST] <wm4> nevcairiel: ah, maybe it was the anchor [18:57:11 CEST] <jamrial> mmh, weird, for merge commits it gives me the libav commit instead of the merge commit [18:57:19 CEST] <jamrial> see for example https://github.com/jamrial/FFmpeg/commit/1d530860afa1c4e2ff59e7081ab418c68eb... [18:57:23 CEST] <BtbN> github is kinda broken with merges [18:57:30 CEST] <nevcairiel> for merges its kinda useless [18:57:44 CEST] <jamrial> yeah [18:57:48 CEST] <nevcairiel> lets see if the new headers work out of the box in my code [18:57:57 CEST] <nevcairiel> been a while since i touched cuvid code [18:58:17 CEST] <BtbN> The ffmpeg header copies are slightly modified [18:58:22 CEST] <BtbN> I think I got the update right though [18:59:18 CEST] <nevcairiel> only had to remove some include line that doesnt exist for the d3d9 interop [18:59:36 CEST] <BtbN> huh? That was never there in the first place for me [18:59:41 CEST] <nevcairiel> d3dx is deprecated, someone tell nvidia =p [18:59:42 CEST] <BtbN> which header? [18:59:47 CEST] <nevcairiel> dynlink_cuda_d3d.h [18:59:59 CEST] <BtbN> ah, yeah, not using those [19:00:09 CEST] <jamrial> think you can fix the LOAD_SYMBOL warning spam from compat/cuda/dynlink_loader.h while at it? [19:00:19 CEST] <BtbN> jamrial, I tried, it's MSVC being dumb [19:00:28 CEST] <BtbN> gcc is perfectly happy with that. [19:00:32 CEST] <jamrial> i'm getting it with mingw-w64 [19:00:37 CEST] <BtbN> really? [19:00:43 CEST] <BtbN> I'll look at it again [19:00:51 CEST] <jamrial> yeah [19:01:09 CEST] <jamrial> i define _WIN32_WINNT=0x0602 when compiling, though [19:01:19 CEST] <jamrial> maybe that's related [19:04:37 CEST] <BtbN> I'll try a normal x86_64-w64-mingw32-gcc build [19:05:34 CEST] <jamrial> i'm using the one provided by msys2 package manager. didn't try one of nevcairiel's builds or one of my own [19:06:20 CEST] <BtbN> I'm using the one cygwin installed for me [19:06:22 CEST] <BtbN> gcc 5.4 [19:06:40 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170508104153&log=compile&slot=x86_64-mingw-w64-windows-native nevcairiel's also show this [19:08:10 CEST] <BtbN> I like how configure takes longer than actually building [19:08:36 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170506184511&log=compile&slot=x86_64-debian-mingw32-gcc-4.6 this old version as well, but is much less spammy about it [19:09:36 CEST] <BtbN> Can I just cast the destination and source pointer to void*, and be done? [19:10:32 CEST] <BtbN> This would be easy in C++, but no clue how to solve this in C [19:26:08 CEST] <BtbN> gnu c has typeof() [19:26:10 CEST] <BtbN> but MSVC doesn'T [19:26:16 CEST] <BtbN> so manually enumerating all types it is... [19:26:37 CEST] <jamrial> try __typeof__ [19:26:48 CEST] <jamrial> no wait, nevermind [19:27:13 CEST] <BtbN> It should work on all compilers [19:30:16 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/a455fa1f2345118e4c91b289137b0912333cd7... that should silence them [19:30:30 CEST] <BtbN> not pretty, but I can't think of any other solution [19:36:25 CEST] <jamrial> ubitux: pushed a version using size_t to my repo [19:39:01 CEST] <jamrial> michaelni: want to look at https://github.com/jamrial/FFmpeg/commits/mergework ? h264/hevc/theora custom cropping code replaced by generic code in decode.c using new avframe fields [19:40:59 CEST] <uau> jamrial: why does gcc warn about assignment from void *? [19:41:17 CEST] <jamrial> if you mean cuda, i don't know [19:42:49 CEST] <durandal_1707> what is instruction to load every 2nd float in m0? [19:43:05 CEST] <uau> does it warn about mixing void * and function types on windows? or is that not void * on windows? [19:43:17 CEST] <durandal_1707> im writting simd for afir complex multiplication and add [19:43:49 CEST] <BtbN> uau, FARPROC is not a void*, and can't be assigned to a function pointer without cast [19:43:55 CEST] <BtbN> at least not without a warning [19:45:09 CEST] <uau> is that what dlsym returns on windows? [19:45:40 CEST] <BtbN> It's what GetProcAddress returns [19:45:52 CEST] <BtbN> dlsym is just a convenience rename [19:46:27 CEST] <jamrial> durandal_1707: what do you mean load every 2nd float? and from memory to m0, or from m0 to something else? [19:47:14 CEST] <durandal_1707> from memory and do the reverse [19:47:53 CEST] <durandal_1707> real component is every 2nd element in an array [19:48:34 CEST] <durandal_1707> imaginary is 2 *n +1 [19:49:14 CEST] <jamrial> mmh, with avx2/avx512 you have gather/scatter, but with older sets you'll have to load everything and do shuffles i think [19:51:49 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg can you give this a test? Works on both my nvidia boxes. [19:57:50 CEST] <philipl> I'll test tonight. [20:02:25 CEST] <philipl> BtbN: GetDecoderCaps. How nice [20:02:53 CEST] <BtbN> Haven't adapted to the new API yet, only removed some deprecated fields from nvenc [20:02:59 CEST] <BtbN> They also deprecated all the old preset names [20:03:06 CEST] <BtbN> they are not calling it twopass anymore [20:03:16 CEST] <BtbN> *rc mode names [20:09:37 CEST] <BtbN> haha, the nvidia ffmpeg usage guide already has an entry for ffmpeg 3.4 using Video Codec SDK 8.0 [20:10:07 CEST] <BBB> michaelni: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.htm... you should apply for one of these prizes [20:21:04 CEST] <michaelni> BBB, IIUC we already received the initial price on ffmpeg-spi. Do we qualify already for more ? [20:21:35 CEST] <BBB> michaelni: no idea, Im not keeping track, just saying you did a lot of work on that and it looks like some of these conditions were met, but not sure [20:21:39 CEST] <nevcairiel> i wonder if i should use getdecodercaps, i basically just create a decoder anyway and keep using that decoder instance as appropriate, not sure it would make my live that much better [20:23:29 CEST] <michaelni> jamrial, can you post this to the ML so everyone can comment ? [20:25:57 CEST] <jamrial> michaelni: alright [20:37:44 CEST] <durandal_1707> jamrial: what to use fo shuffle then? [20:38:58 CEST] <atomnuker> some unpacking/packing instruction (pshufb is slower compared to them) [20:39:48 CEST] <jamrial> shufps, unpck[lh]ps, and/or vpermps with avx2 [20:40:57 CEST] <BtbN> nevcairiel, it doesn't seem overly useful for ffmpeg as well, as we basically don't know things like the bit depth until it's way too late anyway [20:44:17 CEST] <philipl> BtbN: So they remain completely vague on which GPUs can decode vp9 10/12bit, but I assume it'll turn out to be GP107 (1050) only. [20:44:20 CEST] <philipl> Sad. [20:44:27 CEST] <philipl> And apparently they threw out vp8 after GP104 [20:44:57 CEST] <durandal_1707> jamrial: what to use for last arg? [20:45:14 CEST] <BtbN> I just ordered a 1050 [20:45:17 CEST] <BtbN> so I'll see [20:45:26 CEST] <BtbN> Also curious what the 1030 will be able to do [20:45:29 CEST] <philipl> If it turns out to be 1050 only I'll probably get one too - they're cheap enough [20:45:32 CEST] <philipl> Is 1030 announced? [20:45:35 CEST] <BtbN> yes [20:45:57 CEST] <philipl> Then I'll get one of those. Only want it for vp9 testing [20:46:17 CEST] <BtbN> The difference in price is like 30¬, so I didn't bother waiting for it [20:47:12 CEST] <cone-705> ffmpeg 03Anton Khirnov 07master:52627248e49e: frame: add a cropping rectangle to AVFrame [20:47:13 CEST] <cone-705> ffmpeg 03Anton Khirnov 07master:019ab88a95cb: lavc: add an option for exporting cropping information to the caller [20:47:14 CEST] <cone-705> ffmpeg 03James Almer 07master:a47bd5d77e3f: Merge commit '52627248e49e58eb4b78e4fcda90a64f4c476ea3' [20:47:15 CEST] <cone-705> ffmpeg 03James Almer 07master:f089e02fa2b7: Merge commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5' [20:47:26 CEST] <philipl> Fair. Well, first I need to check with the latest drivers and sdk and see what GetDecoderCaps says for my 1080 [20:47:41 CEST] <philipl> but I fully expect disappointment. [20:51:16 CEST] <BtbN> philipl, the new caps thing seems completely useless. You have to specify the bit depth as input parameter [20:51:20 CEST] <nevcairiel> vp9 10bit no worky on my 1080 or 1060, too bad, nvidia rep once said that a 1060 might be able to [20:51:24 CEST] <BtbN> so you basically have to call it 3 times to query all of them [20:51:43 CEST] <philipl> fun [20:53:19 CEST] <BtbN> Or do the container parsers give you information about that? [20:53:51 CEST] <nevcairiel> they can, but there is no guarantee [20:58:48 CEST] <michaelni> jamrial, i meant the API changes shoud be posted to the ML, i doubt theres much interrest in the implementation changes [20:59:13 CEST] <jamrial> michaelni: i posted the patches that could introduce regressions in h264/hevc [20:59:54 CEST] <jamrial> that's what i said i would in the ml thread a week or so ago [21:08:13 CEST] <philipl> BtbN: ffmpeg -y -vsync 0 -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -c:a [21:08:13 CEST] <philipl> copy -c:v h264_nvenc -preset slow -profile high -b:v 5M -bufsize 5M - [21:08:13 CEST] <philipl> maxrate 10M -qmin 0 -g 250 -bf 2 -temporal-aq 1 -rc-lookahead 20 - [21:08:13 CEST] <philipl> i_qfactor 0.75 -b_qfactor 1.1 output.mp4 [21:08:23 CEST] <philipl> Maybe they fixed the b-frames bug in the driver [21:08:31 CEST] <BtbN> nope [21:08:32 CEST] <philipl> That's their example usage [21:08:37 CEST] <BtbN> Doesn't work for me [21:08:40 CEST] <philipl> hah. [21:09:05 CEST] <BtbN> they don't specify -bf, so it's not using bframes to begin with [21:11:21 CEST] <philipl> It's on that command line [21:54:16 CEST] <BtbN> dafuq, after updating the cuvid headers, msvc just hogs all available RAM(So, 32GB), and never finishes building cuvid.c [21:54:29 CEST] <BtbN> cl.exe to be precise [23:01:07 CEST] <philipl> BtbN: shit's special. [23:02:12 CEST] <BtbN> Only happened once, builts fine now [23:50:49 CEST] <alevinsn> jkqxz: are you planning to apply the two qsv patches I submitted? I took the patches you had on your Web site [23:51:07 CEST] <alevinsn> applied them, and then I generated new patches with altered text--code wasn't changed at all [00:00:00 CEST] --- Tue May 9 2017