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

[burek]

[02:01:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07master:13f266b50cc7: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range
[02:01:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07master:0869ff7e9d17: avcodec/utils: Check bits_per_raw_sample on video encoder open
[03:31:31 CET] <doublebackslash> hello! Got what I hope to be a quick question about audio filters and audio sync
[03:32:12 CET] <doublebackslash> I'm working on a filter, my first one, and when I use it the audio is randomly out of sync. Always late relative to video. It does take multiple audio streams
[03:32:49 CET] <doublebackslash> I suspect that I'm doing something horrible with the pts but I'm not sure what. I attempted to mimick the af_mix filter, but I may have missed something
[03:33:12 CET] <doublebackslash> Not sure where would be a good place to look. Any thoughts would be appeciated
[05:40:27 CET] <cone-717> ffmpeg 03Ganesh Ajjanagadde 07master:369b161d8e6d: ffmpeg: replace log2 by av_log2
[10:00:43 CET] <cone-150> ffmpeg 03Paul B Mahol 07master:9f17d4ae7e83: avfilter/formats: fix leak of formats on error
[10:46:26 CET] <wm4> why is everyone suddenly so interested in closec captions?
[10:47:04 CET] <wm4> also lol at #5057
[10:57:53 CET] <rcombs> heh, what a saga
[10:58:30 CET] <rcombs> maybe do what every other piece of software does and actually build against a major version
[10:58:45 CET] <rcombs> this is how library dependencies work
[11:02:14 CET] <wm4> they're dynamically loading - maybe to run on systems that don't have libavcodec installed?
[11:03:42 CET] <wm4> oh, and of course they want to work with Libav too
[11:11:59 CET] <nevcairiel> they want to provide binary distributions in the fragmented linux world
[11:12:02 CET] <nevcairiel> no wonder thats painful
[11:14:43 CET] <wm4> not as painful as on windows
[11:14:59 CET] <wm4> where you need to depend on a 20 year old unmaintained dll
[11:18:18 CET] <nevcairiel> nah on windows you just distribute the things you need yourself
[11:19:25 CET] <nevcairiel> and if you are referring to msvcrt.dll, thats actually not true, thats the same DLL the entire OS uses as the C runtime, how old it is depends on how old your OS is
[11:29:10 CET] <wm4> well it's not like firefox couldn't just redistribute libavcodec
[11:29:22 CET] <nevcairiel> apparently they dont want to
[11:29:39 CET] <nevcairiel> they go through this big hack crap to avoid just that
[11:29:59 CET] <nevcairiel> noone would want to build binary compat with a wide range of versions if it can be avoided, its just painful
[11:42:35 CET] <rcombs> either vendor it or build for the distro's shipping version
[11:42:56 CET] <rcombs> (Chrome vendors it)
[11:43:24 CET] <nevcairiel> apparently its a common use-case for people to just download a firefox binary of the website, and they dont want to offer 100 versions, which is understandable
[11:43:37 CET] <nevcairiel> but then trying to support system libraries on 100 distributions is just crazy :D
[11:47:25 CET] <rcombs> do they only do this for ffmpeg
[11:47:30 CET] <rcombs> oh, I bet it's some patent bullshit
[11:48:02 CET] <nevcairiel> no idea
[11:48:12 CET] <nevcairiel> many other libraries are much more stable in their interface
[11:48:21 CET] <nevcairiel> mostly because they just dont change anymore
[11:48:45 CET] <rcombs> lav*'s interface instability is in part because its interface is large
[12:04:32 CET] <wm4> nevcairiel: what's the status of HEVC main 10 dxva?
[12:04:58 CET] <wm4> doesn't seem to be in yet?
[12:05:09 CET] <wm4> there was also some sort of API problem?
[12:05:59 CET] <nevcairiel> there is no "problem" as such, I am just undecided what to do about the issue with naive user code that might break when its pushed
[12:06:23 CET] <wm4> well I'd say just let the downstreams deal with the regression
[12:07:12 CET] <nevcairiel> i should push some of the preparation patches, like p010 for lavu and sws
[12:07:21 CET] Action: nevcairiel goes to send them
[12:07:44 CET] <wm4> there's no p010 yet? huh
[12:11:38 CET] <nevcairiel> there, senbd
[12:12:01 CET] <nevcairiel> -b
[12:14:33 CET] <nevcairiel> if someone really wants to use the sws p010 support, someone should probably SIMD it based on the nv12 simd
[12:14:37 CET] <nevcairiel> otherwise its crawling slow
[12:16:55 CET] <wm4> is there a way to actually test these pixdesc things?
[12:17:25 CET] <nevcairiel> i tested it by 10-bit decoding, no idea otherwise :D
[12:19:27 CET] <nevcairiel> there is some basic test in fate for the pixdescs, but no clue what it really tests for
[12:19:43 CET] <nevcairiel> there is an automated test if a pixfmt supports input and output in sws
[12:19:51 CET] <nevcairiel> but since p010 doesnt support output yet, thats not used
[12:20:05 CET] <nevcairiel> (writing output support in sws is far harder than input <.<)
[12:21:38 CET] <wm4> even though it's just 16 bit nv12 (which we support?) with a shift applied
[13:53:41 CET] <atomnuker> BBB: thanks for the review
[13:53:54 CET] <atomnuker> yeah, there's still some float logic left in the PVQ system
[13:54:11 CET] <atomnuker> but the overhead should be minimal
[13:54:39 CET] <atomnuker> the casting to (uint8_t) when calling anything in the dsp is because nothing's been templated already
[13:56:06 CET] <atomnuker> the output of the dequantizer is 8 bits or 8 bits + 4 bits (coeff_shift) in case of FPR
[13:56:17 CET] <atomnuker> so yeah, 16 bit wide integers should be enough
[13:59:04 CET] <atomnuker> for the coefficients that is, with 32 bits for intermediaries in the iDCT
[14:38:00 CET] <BBB> atomnuker: thats what I thought
[14:38:08 CET] <BBB> atomnuker: so, 16bits will have huge advantages when writing simd
[14:38:24 CET] <BBB> atomnuker: and I fully udnerstand that for 10/12bpp, youll probably need 32bit coeffs, but the templating logic should help with that
[14:39:04 CET] <BBB> atomnuker: did you find the libavcodec/bit_depth_template.c macros helpful? or not at all?
[14:39:20 CET] <BBB> atomnuker: and for floats, is it intended to disappear in daala sometime soon?
[14:39:31 CET] <BBB> atomnuker: I particularly find the log/sqrt/pow/& stuff kind of strange
[14:39:36 CET] Action: Daemon404 wonders if nevcairiel is planning to add w3fdif to lav
[14:39:39 CET] <BBB> but thats probably daala, not you
[14:39:45 CET] <atomnuker> BBB: I would have used them but they lacked a RENAME function
[14:39:55 CET] <atomnuker> yeah, that's Daala, though I did remove a few
[14:40:12 CET] <BBB> FUNC()?
[14:40:22 CET] <BBB> or FUNCC() for _c suffix
[14:40:39 CET] <atomnuker> ah, missed those
[14:40:49 CET] <BBB> \o/
[14:47:12 CET] <wm4> I have to say pixdesc doesn't make too much sense to me
[14:47:37 CET] <wm4> for example, AV_PIX_FMT_MONOWHITE has the component shift field set to 7
[14:48:14 CET] <wm4> why? because it'd expand it to 8 bit? but why 8 bit? what about properly setting the lower bits, instead of just shifting in zeros for the MSBs? but this makes no sense either way...
[14:49:51 CET] <wm4> nevermind, that's not what it's supposed to do
[14:50:34 CET] <Daemon404> every time i read pixdesc i need to stare at it for an hour
[14:50:40 CET] <Daemon404> then i forget how it works immediately
[14:52:04 CET] <wm4> yeah, and I was also stupid enough to extract major bits of information out of pixdesc in my code
[14:52:24 CET] <nevcairiel> i wondered about using it, but i never bothered
[14:52:33 CET] <nevcairiel> i have a long list to map av pixfmts to my internal ones instead =p
[15:01:47 CET] <Daemon404> thats mroe tedious but probably saner
[15:04:02 CET] <nevcairiel> and yes Daemon404, its definitely a consideration, it seems faster and better or higher quality than yadif
[15:04:35 CET] <durandal_1707> it all looks same to me
[15:19:14 CET] <wm4> kierank: do you have anything that decodes to NV20?
[15:20:09 CET] <kierank> It is x264s native format for 8-bit 422
[15:20:52 CET] <wm4> isn't NV20 10 bit per component? well maybe I'm reading pixdesc wrong again
[15:20:56 CET] <nevcairiel> wouldnt that be NV16
[15:21:13 CET] <nevcairiel> 8bit 422 has 16bit per  pixel
[15:21:27 CET] <wm4> NV16 is 8 bit per component, 4:2:2
[15:22:11 CET] <wm4> NV20 looks like the same but 2 bytes per component, with padding in the MSB
[15:22:35 CET] <nevcairiel> and 10 bit data?
[15:22:39 CET] <wm4> yeah
[15:22:51 CET] <nevcairiel> odd format
[15:23:03 CET] <wm4> kierank added it
[15:23:32 CET] <kierank> Sorry 10-bit
[15:23:48 CET] <wm4> so how can I test it?
[15:32:46 CET] <kierank> can't remember how I tested it
[15:32:49 CET] <kierank> but iirc I fed a file into x264
[16:11:12 CET] <kierank> I will be writing a v210 to nv20 converter in the next weeks
[16:31:39 CET] <kierank> poor nevcairiel having to work on swscale
[16:32:17 CET] <nevcairiel> input support wasnt too bad, output support l ooked like crazy magic, hence not done =p
[16:33:43 CET] <kierank> yeah
[16:39:33 CET] <wm4> wasn't libswscale recently refactored to make this kind of thing easier?
[16:49:00 CET] <durandal_1707> nope, wait for avscale
[16:52:51 CET] <JEEB> why not zscale?
[16:53:37 CET] <durandal_1707> its in c++ IIRC
[17:54:21 CET] <atomnuker> (BBB) how does using uint8_t cause random odd side effects and slowdowns
[17:54:30 CET] <atomnuker> are compilers messing it up or?
[17:54:46 CET] <BBB> uint8_t gives guarantees about the data range in a register
[17:54:52 CET] <BBB> so it ands 255 the value at every call
[17:54:56 CET] <BBB> just so its C compliant
[17:55:10 CET] <BBB> (not at the call, but at the position where a function call occurs in the C code)
[17:55:57 CET] <atomnuker> also what did you mean by using "fastdiv"?
[17:57:07 CET] <atomnuker> as in the macro?
[18:09:47 CET] <jamrial> BBB: is the av_clip patch ok to push? 
[18:12:00 CET] <BBB> yes
[18:12:07 CET] <BBB> atomnuker: yes
[18:12:07 CET] <kierank> wm4: hmm i was wrong I'm going to write a v210 to uyvy422 (10-bit) decoder
[18:12:11 CET] <kierank> so that won't go into ffmpeg
[18:12:14 CET] <BBB> jamrial: yes
[18:13:10 CET] Action: wm4 mumbles something about useless pixel formats
[18:14:04 CET] <kierank> but yeah nv20 is a bit useless
[18:26:18 CET] <Daemon404> depends if you define useful as actually useful or "useful to hardware developers"
[18:26:24 CET] <cone-715> ffmpeg 03James Almer 07master:f4c1a4848378: x86/intmath: add sse optimized av_clipf and av_clipd
[22:09:38 CET] Action: Daemon404 sees ganesh suggesting gnulib
[22:09:47 CET] Action: Daemon404 prepares to launch tactical nuclear missile
[22:09:49 CET] <JEEB> iä iä
[22:10:05 CET] <wm4> lol
[22:10:09 CET] <Daemon404> to fix an "issue"
[22:10:29 CET] <wm4> the fclose thing?
[22:10:35 CET] <Daemon404> yes
[22:11:32 CET] <Daemon404> oh the slides he linked are from the maintainer of gnulib.
[22:13:47 CET] <J_Darnley> What?  If there's errors using standard streams how will anything else work?
[22:20:40 CET] <cone-715> ffmpeg 03Clément BSsch 07master:84a967df034b: lavu/common: fix FF_CEIL_RSHIFT() range comment
[22:32:51 CET] <rcombs> Daemon404: bahahaha
[22:34:48 CET] <cone-715> ffmpeg 03Clément BSsch 07master:90cd02059b6f: lavfi/deshake: use FF_CEIL_RSHIFT()
[22:34:49 CET] <cone-715> ffmpeg 03Clément BSsch 07master:5fbe57c027d0: lavf/uncodedframecrcenc: use FF_CEIL_RSHIFT()
[22:34:50 CET] <cone-715> ffmpeg 03Clément BSsch 07master:04826b7ff02f: lavu/common: add an explanation to FF_CEIL_RSHIFT()
[22:34:56 CET] <Daemon404> gnulib contibuters go to the special hell
[22:34:57 CET] <Daemon404> a la firefly
[22:36:40 CET] <rcombs> pls add more giant monolithic dependencies
[22:37:10 CET] <TD-Linux> please it's 2016, they are "frameworks"
[22:37:17 CET] <wm4> gnulib is awesome, it's intended to make programs more portable, but actually makes them less portable
[22:37:23 CET] <wm4> it does so by being an ifdef hell
[22:37:29 CET] <durandal_1707> so where to contribute?
[22:37:37 CET] <wm4> and accessing the internals of obscure libcs etc.
[22:38:42 CET] <nevcairiel> speaking of special hell, sometimes these days I feel like it might be worthwhile to discuss merging of the libav changes again (or stopping of the same), the quality of their commits has gone down quite a bit IMHO, and more often than not its just fixes that we already have in a different shape or form, so maybe it might be worth it thinking about cherry-picking the interesting parts instead
[22:39:25 CET] <wm4> cherry-picking sounds kind of cleaner
[22:39:46 CET] <wm4> and I'm wondering if git really provides any advantages in our case with merges
[22:40:04 CET] <nevcairiel> cherry picking would work equally well
[22:41:02 CET] <nevcairiel> except you cant easily track anymore which commits are merged and which are not
[22:41:06 CET] <durandal_1707> I mentioned that years ago
[22:44:49 CET] <wm4> publicly reviewing the ported commits would be a big advantage over just having someone push "something" directly to git master
[22:45:31 CET] <cone-715> ffmpeg 03Clément BSsch 07master:d64fe951c2ee: lavc/ccaption_dec: fix always true condition
[22:47:13 CET] <durandal_1707> I even opened bug for that one
[22:49:33 CET] <kierank> Daemon404: 
[22:49:34 CET] <kierank> https://github.com/Netflix/vp9-dash/blob/master/Downloads/VPCodecISOMediaFileFormatBinding.pdf
[22:49:35 CET] <kierank> hahahahaha
[22:50:09 CET] <nevcairiel> vp9 in isom?
[22:50:59 CET] <TD-Linux> yup!
[22:50:59 CET] <kierank> yeah
[22:51:24 CET] <J_Darnley> Are they just making stuff up now?
[22:52:00 CET] <TD-Linux> a lot of people wanted a vp9 in mp4 mapping
[22:52:09 CET] <nevcairiel> wtf is MPEG VCB
[22:52:20 CET] <cone-715> ffmpeg 03Clément BSsch 07master:2ce29d17656f: lavu: add ff_parity()
[22:52:21 CET] <cone-715> ffmpeg 03Clément BSsch 07master:00e96613f3e0: lavc/ccaption_dec: use ff_parity()
[22:52:22 CET] <cone-715> ffmpeg 03Clément BSsch 07master:a1136ca973e3: lavc/g729dec: use ff_parity()
[22:54:04 CET] <kierank> it's a good iea
[22:54:08 CET] <kierank> mkv sucks
[22:54:19 CET] <TD-Linux> nevcairiel, MPEG's standardization of vp8
[22:54:46 CET] <wm4> at least mkv can be actually streamed
[22:54:53 CET] <wm4> instead of using stupid web hacks
[22:54:58 CET] <nevcairiel> honestly all containers suck to some degree
[22:55:08 CET] <wm4> without doubt
[22:55:41 CET] <nevcairiel> mkv is underspecified and overimplemented with crazy features for anime people =p
[22:56:04 CET] <TD-Linux> CELLAR is now trying to fix that
[22:56:27 CET] <J_Darnley> nevcairiel: no better people!
[22:56:44 CET] <kierank> wm4: true
[22:56:52 CET] <kierank> but inaccurate timestamps, no DTS
[22:56:53 CET] <kierank> ...
[22:56:53 CET] <nevcairiel> I wonder if they are really going to try to offer a clean documentation of the codec mappings to any useful degree in CELLAR
[22:56:54 CET] <rcombs> the biggest actual complaint I've seen about the MKV format (as opposed to other [reasonable] complaints about it being underspecified or having dumb anime features) is that timestamps aren't precise enough
[22:57:18 CET] <wm4> kierank: I really hate the inaccurate timestamps, but they happen in "good" containers too
[22:57:21 CET] <nevcairiel> you can nanosecond precision, its just that most muxers dont write them
[22:57:23 CET] <TD-Linux> nevcairiel, well mappings for ffv1 and flac are clearly within the charter. I don't know about any others
[22:57:43 CET] <TD-Linux> nanosecond precision is part of the problem
[22:57:53 CET] <nevcairiel> TD-Linux: i was thinking more about mainstream use, not their archival codecs :D
[22:57:53 CET] <wm4> nevcairiel: I doubt it, likely they'll only map ffv1 and raw video
[22:58:07 CET] <kierank> nevcairiel: again not good enough
[22:58:22 CET] <wm4> kierank: doesn't mpegts use 90khz
[22:58:23 CET] <kierank> a / b
[22:58:32 CET] <kierank> didn't say mpegts was a good container
[22:58:40 CET] <wm4> but it's used for TV
[22:58:51 CET] <kierank> exactly and TV is a 100 year of hacks
[22:58:55 CET] <nevcairiel> isom probably has timebase-based timestamps
[22:59:02 CET] <kierank> yup
[22:59:20 CET] <TD-Linux> I think other codec mappings could fall under CELLAR, someone would just have to do them.
[22:59:58 CET] <nevcairiel> and then there is the wide range of arcane mkv features that are not documented at all and if anyone asks the usual answer is "implement them so they work like Haali" =p
[23:01:37 CET] <TD-Linux> anyway, mp4 is royalty free, and if mapping royalty free codecs into it increases their adoption, I'm all for it
[23:01:56 CET] <nevcairiel> no mpeg patents on mp4/isom?
[23:02:08 CET] <kierank> probably are
[23:03:07 CET] <TD-Linux> nevcairiel, well it's hard to ever know for sure, but that seems to be the generally accepted view
[23:03:47 CET] <nevcairiel> patents in software world are so silly
[23:03:53 CET] <TD-Linux> DASH was also supposed to be royalty free and that's why it's based around MP4 and not ts
[23:04:22 CET] <nevcairiel> you can never be actually "safe", even if you lock yourself in a room and write everything entirely from scratch, chance is you will use some concept someone patented before =p
[23:04:44 CET] <fritsch> that's only an issue in the us
[23:04:45 CET] <fritsch> then
[23:04:46 CET] <TD-Linux> yup. but you can certainly make an effort to be safer
[23:05:06 CET] <durandal_1707> what happened with nut standardization?
[23:05:10 CET] <fritsch> where someone has patented: " way to connect to mysql with php" ...
[23:05:11 CET] <TD-Linux> fritsch, no, go look at one of MPEG-LA's list of patents and the countries they are issued in...
[23:05:19 CET] <wm4> sw patents are nothing but legal racketeering
[23:05:29 CET] <fritsch> and invalid in germany
[23:06:02 CET] <wm4> maybe the problem is simply that judges and law makers don't understand software
[23:06:33 CET] <nevcairiel> the problem is that the big companies have money to pay lobbyists and the free developers like us do not
[23:07:00 CET] <nevcairiel> company interests always win in this world
[23:07:20 CET] <durandal_1707> Dolby may sue
[23:07:32 CET] <fritsch> if they start in google play store ...
[23:07:36 CET] <fritsch> nothing will be left :-(
[23:07:46 CET] <fritsch> there are a lot applictions with ac3 decoders
[23:08:05 CET] <fritsch> sort mediaplayers by download and sue those with > 3 million users :-)
[23:08:22 CET] <philipl_> fritsch: DTS did this very aggressively.
[23:08:40 CET] <nevcairiel> dont they get enough money from encoders and hardware licenses, they should be happy if people can play content in their format, it might make it more popular
[23:09:19 CET] <fritsch> nevcairiel: do such people ever get _enough_ money?
[23:09:41 CET] <fritsch> hehe at least vlc / kodi / some others also do ac3 transcoding :-)
[23:10:15 CET] <philipl> fritsch: I'm actually surprised that DTS hasn't come after Kodi in the android store.
[23:10:29 CET] <fritsch> philipl: as long as vlc has twice the number of downloads :-)
[23:10:32 CET] <fritsch> we are safe, hehe
[23:10:34 CET] <fritsch> at least for now
[23:10:47 CET] <fritsch> but i am also very surprised
[23:10:54 CET] <TD-Linux> nevcairiel, well H.264 was pretty loosely enforced, so apparently some had that idea
[23:11:03 CET] <fritsch> and in fact we are working on a "free" version of kodi in playstore
[23:11:07 CET] <fritsch> free as in: plays nothing
[23:11:09 CET] <fritsch> :-(
[23:11:12 CET] <wm4> maybe they're still trying to sort out who to sue
[23:11:23 CET] <wm4> lol
[23:11:26 CET] <philipl> fritsch: theora/ogg is all you need
[23:11:30 CET] <fritsch> we try to use mediacodec itself
[23:11:32 CET] <nevcairiel> TD-Linux: sure, but dolby and dts seem to be more aggressive about that
[23:11:34 CET] <fritsch> in the future
[23:11:41 CET] <fritsch> so that we can decode what the "box vendor" bought for
[23:11:56 CET] <philipl> wm4: Funnily, when DTS first started going after people, there was no way to licence DTS decoding from them.
[23:12:10 CET] <philipl> It was a couple of years before they had a licence you could buy
[23:12:18 CET] <TD-Linux> nevcairiel, yup. and being in the position of "people can sue me but haven't because I don't have enough money yet" isn't so great either
[23:12:25 CET] <fritsch> i think as long as kodi does not cost a single cent - they perhaps won't do anything
[23:12:41 CET] <fritsch> but the very moment someone charges "one dollar" (not planned at all)
[23:12:48 CET] <fritsch> or someone screams: we got .... donations
[23:12:55 CET] <fritsch> i think they are highly interested
[23:13:14 CET] <nevcairiel> TD-Linux: yeah ... it makes opensource projects somewhat safe, I mean, who is going to sue me and my little project, i dont make a single cent with it, but for companies trying to develop a small player based on open-source decoders ... not so much fun
[23:13:26 CET] <TD-Linux> fritsch, well also someone using kodi might then not need to buy a bitstreaming receiver with dolby decoder
[23:13:54 CET] <fritsch> TD-Linux: that's fully right - yes
[23:14:12 CET] <nevcairiel> screw those HDMI devices, they have caused me nothing but trouble
[23:14:19 CET] Action: nevcairiel switched to an external USB DAC
[23:14:31 CET] <TD-Linux> also for some reason the audio camp in general seems to be much more intense about enforcement
[23:14:53 CET] <TD-Linux> traditionally many audio codecs have been trade secrets. you had to buy a hardware dongle to encode/decode them
[23:15:03 CET] <jamrial> ubitux: i thought you were going to use a generic c version of ff_parity instead of using av_popcount with non gnu compilers
[23:15:13 CET] <jamrial> ubitux: as i said, you really don't need the configure check
[23:16:00 CET] <ubitux> ah, my bad
[23:16:08 CET] <jamrial> just an AV_GCC_VERSION_AT_LEAST check for the builtin version, and ideally a generic c version instead of popcount&1 for anything else
[23:17:10 CET] <ubitux> well, i didn't know when gcc added it, and where it was efficient
[23:17:53 CET] <ubitux> i thought it was better to give the opportunity to all compiler supporting the builtin to provide asm they consider good
[23:18:19 CET] <ubitux> about the generic c, it can be done now, but given its limited usage it didn't look like a priority
[23:18:33 CET] <ubitux> i couldn't use my generic c code bc u8 only :p
[23:22:18 CET] <jamrial> ah, i see
[23:22:55 CET] <jamrial> ubitux: anyway, looks like since gcc 3.4, so better remove the configure check and check for that version instead
[23:23:09 CET] <ubitux> how did you get that gcc 3.4 info?
[23:23:14 CET] <jamrial> google :p
[23:23:22 CET] <ubitux> it wasn't documented in the builtin gcc page :(
[23:23:55 CET] <jamrial> yeah, no mention of what version introduced anything there
[23:24:15 CET] <jamrial> i see a lot of checks for 3.4 in our tree, so seems like a version where tons of builtins were added
[23:25:22 CET] <ubitux> ok, well, feel free to change, but it might be relevant to add a smart c version
[23:25:32 CET] <ubitux> because if clang ends up being not so dumb, it will be penalized
[23:26:01 CET] <ubitux> also, it makes all other potential compilers aside
[23:26:13 CET] <ubitux> not sure if any other relevant one uses __builtin_xxx
[23:26:20 CET] <jamrial> icc
[23:26:58 CET] <jamrial> anything that defines __GNU__ basically, so clang, gcc and icc
[23:37:02 CET] <jamrial> ubitux: looks like av_popcount may not be defined at all in intmath.h if you don't include through common.h
[23:37:14 CET] <jamrial> since av_popcount_c is in common.h
[23:38:13 CET] <ubitux> fuck
[23:38:36 CET] <ubitux> safe to include common.h from here?
[23:39:03 CET] <jamrial> don't think so
[23:39:52 CET] <ubitux> dammit
[23:39:58 CET] <jamrial> how about moving this to common.h, renaming it to av_parity and making it work like av_popcount and many others?
[23:40:56 CET] <jamrial> or just find a way to add a proper generic c version instead of using av_popcount :p
[23:41:59 CET] <ubitux> could do both
[23:43:40 CET] <jamrial> if we can add a generic c version then there's no need to move it to common.h
[23:43:47 CET] <jamrial> otherwise yeah, probably no other way
[23:44:21 CET] <ubitux> jamrial: http://b.pkh.me/0001-lavu-rename-and-move-ff_parity-to-av_parity.patch
[23:44:23 CET] <ubitux> opinion?
[23:47:51 CET] <ubitux> going to apply soon
[23:48:10 CET] <jamrial> you can remove the configure check and add the builtin from intmath.h under a gcc check
[23:48:48 CET] <ubitux> and do what for when it's not avail?
[23:49:15 CET] <ubitux> i mean i'm ok to remove the configure check later, i'm just not comfortable doing it before we provide a nicer c impl
[23:49:22 CET] <jamrial> something like http://pastebin.com/ezeSat6u
[23:50:05 CET] <jamrial> the builtin will be used in the same cases as with the configure check
[23:51:30 CET] <ubitux> but if icc or clang tmr provides a nicer parity, they won't be used
[23:51:49 CET] <jamrial> AV_GCC_VERSION_AT_LEAST checks __GNU__, which clang, gcc and icc define. no other compiler defines it or use any __builitin_* afaik
[23:52:07 CET] <jamrial> clang an icc will use it
[23:52:11 CET] <ubitux> ah
[23:52:13 CET] <ubitux> ok
[23:52:21 CET] <ubitux> well then sure ok, fine with me
[23:52:58 CET] <ubitux> do you want to do that on top of the fix i suggested?
[23:53:07 CET] <ubitux> or you want to do altogether?
[23:53:33 CET] <ubitux> (i'm going afk in a few minutes)
[23:53:35 CET] <jamrial> i'll do it altogether
[23:53:51 CET] <ubitux> ok, well feel free to push soon :p
[23:54:06 CET] <ubitux> i don't like to let my shit broken like this
[23:54:10 CET] <jamrial> sure :p
[00:00:00 CET] --- Fri Jan  8 2016