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

[burek]

[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/3d273dded7789318bbbe08462694322f4ddd5b21#diff-0823f17b4e015a61e2f7e962c15abe23R728 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/3d273dded7789318bbbe08462694322f4ddd5b21.patch ? 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/1d530860afa1c4e2ff59e7081ab418c68ebf5d10.patch
[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/a455fa1f2345118e4c91b289137b0912333cd702 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.html 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