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

[burek]

[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-9700-series-released
[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-us/ntcmds_shelloverview.mspx?mfr=true
[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