[00:39:30 CEST] <Gramner> BtbN: rdtsc doesn't count core clock cycles any more, no. it has it's own clock that's not synchronized in relation to the core clock [00:43:49 CEST] <Gramner> also rdtsc by itself doesn't serialize, so out-of-order execution will happily run things wildly out of order so you have no idea what you're actually measuring. rdtscp or lfence;rdtsc fixes that though (at least on intel cpus, no idea about amd) [00:54:03 CEST] <J_Darnley> fortunately the timer macro does use a fence [00:55:38 CEST] <jamrial> on x86_32 that only happens if you target sse2 or higher, which doesn't happen in most configuration scenarios [00:57:32 CEST] <Gramner> yes, I added that a few years ago. if you want to actually measure clock cycles though you probably have to use performance monitoring counters [00:58:02 CEST] <Gramner> unrelated, but why isn't SSE2 the default anyway? [00:58:28 CEST] <Gramner> even steam hw survey has SSE2 supported by 100.00% of users [00:58:56 CEST] <J_Darnley> Because none of us have put in the work to make sse2 the default minimum. [00:59:21 CEST] <rcombs> our product requires SSE2 out of sheer convenience [00:59:27 CEST] <rcombs> afaik nobody has ever complained [01:00:05 CEST] <nevcairiel> i build my 32-bit libraries without sse2 because the compiler starts assuming 16-byte aligned arguments then, and ffmpeg doesnt build w ith incoming-stack-boundary :( [01:00:11 CEST] <J_Darnley> I expect the Steam survey to not be very accurate for all computers woldwide [01:00:44 CEST] <J_Darnley> XP is still a significant portion. [01:00:45 CEST] <Gramner> i don't expect all ancient legacy computers worldwide to do multimedia processing though [01:01:08 CEST] <J_Darnley> So equally old CPUs must be around [01:02:21 CEST] <Gramner> xp support ended 2014. sse2 has been around since 2001. quite a difference [01:03:23 CEST] <nevcairiel> everytime I mentioned requiring sse2 there is some random lusers coming out of the wood work whining for their old Athlon XP [01:04:08 CEST] <J_Darnley> :) [01:04:14 CEST] <nevcairiel> or pentum3, or w hatever [01:05:08 CEST] <Gramner> a good reason for them to upgrade then ;) [01:05:28 CEST] <jamrial> i'm amazed there are still working pentium 3 or old athlon rigs out there. by now I'd expect every single one of them having failed in some way or another [01:06:03 CEST] <nevcairiel> i used a k6-2 as a router for way more years then one might think it would be good for [01:06:42 CEST] <jamrial> those ran super hot, so i'd expect a fan with a bit of dust should be enough to cook one [01:07:19 CEST] <Gramner> a modern budget system would probably save money in power consumption alone compared to using old stuff forever [01:07:50 CEST] <jamrial> don't recall if it was my thunderbird or thorougbread that ran at like 80c idle when the fan started to misbehave [01:10:19 CEST] <nevcairiel> you could probably pick up a recemt Pi and rival the processing speed of a Pentium3 [01:10:29 CEST] <nevcairiel> i wonder if anyone did benchmarks of such a nature =p [01:12:43 CEST] <Gramner> I'd guess the p3 would be significantly faster [01:15:18 CEST] <Gramner> oh, or the recent ones. yeah they would probably win, I was thinking about the original one which was kinda slow [01:16:07 CEST] <nevcairiel> yeah the original was slow [01:17:05 CEST] <Gramner> "performance is similar to a 300 MHz Pentium II" for the 1st gen according to wikipedia [01:18:04 CEST] <alevinsn> Since you are talking about processors, remember Itanium? A new (and supposedly last) Itanium processor was released yesterday. [01:18:15 CEST] <Gramner> "new" [01:18:19 CEST] <nevcairiel> they still make those? [01:18:33 CEST] <alevinsn> Intel is contractually obligated as a result of its deal with HP [01:18:38 CEST] <alevinsn> HP still uses Itanium [01:18:50 CEST] <Gramner> they bumped the clock a bit and called it a new product. the only reason they do so is because they're required to [01:19:03 CEST] <alevinsn> I don't think Windows supports Itanium anymore, probably just HP-UX and maybe Linux [01:19:04 CEST] <Gramner> contracts etc [01:19:14 CEST] <Gramner> it's still 32nm too [01:19:22 CEST] <alevinsn> http://www.anandtech.com/show/11372/intels-itanium-takes-one-last-breath-970... [01:20:42 CEST] <alevinsn> It used to be known as "Itanic" :-) [01:20:50 CEST] <alevinsn> in some circles [01:20:58 CEST] <nevcairiel> Microsoft dropped support for itanium years ago [01:21:31 CEST] <Gramner> everyone who wasn't legally required to support it dropped it ages ago [01:21:34 CEST] <nevcairiel> and HP would likely prefer to kill it as well, but they are also bound in contracts with their customers [01:33:21 CEST] <J_Darnley> Well that ^ problem obviously comes from cmd [01:33:51 CEST] <J_Darnley> I wonder what it might do with %string% ??? [01:34:14 CEST] <alevinsn> cmd as in cmd.exe on Windows? [01:37:13 CEST] <J_Darnley> yes [01:54:01 CEST] <alevinsn> J_Darnley: you might find this useful: https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en... [01:54:21 CEST] <J_Darnley> *I* don't need it [01:54:41 CEST] <J_Darnley> *I* know %string% is environment variable substitution [02:12:08 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:5ac17f187ae6: avcodec/cavsdec: Fix runtime error: signed integer overflow: 31 + 2147483640 cannot be represented in type 'int' [02:12:09 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:e66488252335: avcodec/hq_hqadsp: Fix runtime error: signed integer overflow: 80359 * 30274 cannot be represented in type 'int' [02:12:10 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:0158b405a71f: avcodec/fmvc: Check nb_blocks [02:12:11 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:934572c5c359: avcodec/rscc: Check pixel_size for overflow [02:12:12 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:afb4632cc30e: avcodec/dds: Fix runtime error: left shift of 210 by 24 places cannot be represented in type 'int' [02:12:13 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:96cbaaa5481b: avcodec/rangecoder: Fix range coder corner case handling [02:33:11 CEST] <J_Darnley> > Analyzed by developer set [02:33:13 CEST] <J_Darnley> top kek [02:34:34 CEST] <J_Darnley> *sigh* did I ever register there? [02:35:14 CEST] <J_Darnley> no [02:47:09 CEST] <jamrial> nevcairiel: http://fate.ffmpeg.org/log.cgi?time=20170512222049&log=test&slot=x86_64-msvc15-windows-native [02:47:17 CEST] <jamrial> your vm ran out of space [04:37:37 CEST] <cone-423> ffmpeg 03James Almer 07master:0fbc7a2169af: x86/float_dsp: remove usage of integer instructions [10:15:52 CEST] <atomnuker> what am I doing wrong such that swr_next_pts() is giving me batshit crazy timestamps? [10:16:47 CEST] <atomnuker> I'm just resampling 44100->48000 and whatever I feed it in I get something like -3740160 [10:20:15 CEST] <atomnuker> couldn't we just expose some code to make timestamps up? [10:26:05 CEST] <mateo`> tmm1: I'm not working on MediaCodec encoders atm, the biggest blocker I see is how to handle properly the surface input (I haven't spend a lot of times thinking about it though). I'm not too interested in buffers input as it would require a ton of workarounds to handle the different alignments, formats (plus some proprietary ones) depending on the device. Plus, it's slow compared to surface input. [10:35:40 CEST] <durandal_1707> atomnuker: show the code? [10:54:59 CEST] <atomnuker> durandal_1707: https://github.com/atomnuker/cyanrip/blob/master/src/cyanrip_encode.c#L273 [10:59:22 CEST] <nevcairiel> the pts argument requires a specific timebase [11:02:21 CEST] <atomnuker> a specific timebase? [11:02:36 CEST] <nevcairiel> its documented in the doxy of the next_pts function [11:02:46 CEST] <nevcairiel> timestamps are in 1/(in_sample_rate * out_sample_rate) units. [11:08:28 CEST] <durandal_1707> look at libavfilter/af_aresample.c [11:09:07 CEST] <atomnuker> feeding it av_rescale(frame->pts, 1, (44100 * cfmt->rate)) is still spitting out junk [11:09:59 CEST] <nevcairiel> that rescale command is wrong [11:10:14 CEST] <nevcairiel> your previous timebase was unlikely to be 1 [11:10:24 CEST] <atomnuker> but rescale just does a*b/c [11:11:28 CEST] <atomnuker> (the problem with all examples is that everyone has access to some timestamps, here there are none to work with) [11:11:48 CEST] <nevcairiel> making new timestamps for audio is not exactly hard [11:12:06 CEST] <atomnuker> it is if you don't know what you're doing [11:12:39 CEST] <wm4> choose the sample rate as timebase, and sample number as timestamp [11:12:48 CEST] <wm4> I never understood those swr functions though [11:12:49 CEST] <nevcairiel> for clarity I would recommend to use av_rescale_q, that way you can just pass in both timebases and not guess at the values [11:13:05 CEST] <wm4> I'm simply using swr_get_delay() [11:13:25 CEST] <nevcairiel> ie. av_rescale_q(pts, {1, 44100}, {1, 44100 * dstrate}) [11:15:43 CEST] <nevcairiel> or simplified by removing the common 44100: av_rescale_q(pts, cfmt->rate, 1); [11:15:49 CEST] <nevcairiel> eh, no _q anymore [11:16:13 CEST] <nevcairiel> (or in this case, pts = pts * cfmt->rate) [11:23:19 CEST] <atomnuker> its not giving negative numbers now but decoding spams "Invalid audio PTS: 348138.053500 -> 349980.033500" [11:23:57 CEST] <atomnuker> (just using av_rescale_q(pts, {1, 44100}, {1, 44100 * dstrate}) as input to swr_next_pts) [11:24:19 CEST] <nevcairiel> you'll have to convert the returned number back into whatever value you expect as well [11:24:21 CEST] <atomnuker> using the sample number as input in this case [11:29:10 CEST] <atomnuker> ok, scaling the values I still get "Invalid audio PTS: 12.410250 -> 12.906375", though only once or twice a second now [11:29:26 CEST] <atomnuker> is my input timestamp junk? I'm just using the current sample number [11:41:11 CEST] <cone-697> ffmpeg 03Paul B Mahol 07master:ed93ed5ee320: avfilter: don't anonymously typedef structs [12:59:28 CEST] <atomnuker> (btw got my issues fixed, I was incorrectly accounting planar->non planar sample count) [15:55:53 CEST] <cone-240> ffmpeg 03Michael Niedermayer 07master:74dc728a2c2c: avcodec/mlp: Fix multiple runtime error: left shift of negative value -1 [15:55:53 CEST] <cone-240> ffmpeg 03Michael Niedermayer 07master:54e1b62ee28f: avcodec/h264_cavlc: Fix runtime error: index -1 out of bounds for type 'VLC [15] [15:55:53 CEST] <cone-240> ffmpeg 03Michael Niedermayer 07master:2171dfae8c06: avcodec/scpr: Fix multiple runtime error: index 256 out of bounds for type 'unsigned int [256]' [17:07:44 CEST] <philipl> BtbN: cuda scale stuff looks mechanically reasonable to me. I did not attempt to understand the actual scaling. [18:16:01 CEST] <BtbN> philipl, there are still a few things in the filter C code I'd like to change, but will do so after to fact, to keep proper patch attribution [21:38:30 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:48f775774956: avcodec/wavpack: Fix runtime error: signed integer overflow: 2147483642 + 512 cannot be represented in type 'int' [21:38:30 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:87b08ee6d2a3: avcodec/aacsbr_template: Do not change bs_num_env before its checked [21:38:30 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:26227d91865d: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1 [21:38:30 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:a3508cc3fe64: avcodec/webp: Add missing input padding [21:38:30 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:9351a156de72: avcodec/ac3dec: Keep track of band structure [23:43:50 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:e3e51f8c14d2: avcodec/mlpdec: Check that there is enough data for headers [23:43:51 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:86b1b0d33dd7: avcodec/svq3: Fix runtime error: signed integer overflow: 169 * 12717677 cannot be represented in type 'int' [23:43:52 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:8c5cd1c9d33b: avcodec/webp: Fix signedness in prefix_code check [23:43:53 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:8630b2cd36c5: avcodec/ffv1dec: Fix runtime error: signed integer overflow: 1550964438 + 1550964438 cannot be represented in type 'int' [00:00:00 CEST] --- Sun May 14 2017