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

[burek]

[00:03:37 CEST] <wm4> BtbN: except software
[00:03:48 CEST] <wm4> nvidia supports no wayland etc.
[00:04:09 CEST] <BtbN> So far I never felt an immediate need for Wayland, so I don't care.
[00:04:17 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:db869f4ea440: fate: Add build-only targets to FATE
[00:04:18 CEST] <cone-265> ffmpeg 03James Almer 07master:85e2fe628183: Merge commit 'db869f4ea4405fb8f9736e5ecdca70f77621a28e'
[00:05:01 CEST] <durandal_1707> nvidia added own stuff for wayland...
[00:05:31 CEST] <BtbN> Nvidia is working on a new API for Wayland initialization stuff
[00:05:32 CEST] <BtbN> slowly
[00:06:03 CEST] <atomnuker> not just nvidia
[00:06:18 CEST] <wm4> BtbN: which means?
[00:06:28 CEST] <BtbN> There eventuall will be Wayland
[00:06:56 CEST] <atomnuker> but by then nvidia would have paid the price and no one would be left to care
[00:07:05 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:5ff3b5cafcc6: build: Add pthreads to list of avutil extralibs
[00:07:06 CEST] <cone-265> ffmpeg 03James Almer 07master:7d2882bf52a6: Merge commit '5ff3b5cafcc685b6936d16602b0f80aa09a95870'
[00:08:08 CEST] <wm4> what's the planned API? is it better than the EGLstreams BS?
[00:08:59 CEST] <atomnuker> probably, this is the git repo: https://github.com/cubanismo/allocator
[00:09:08 CEST] <BtbN> nvidia and mesa are working on it
[00:09:18 CEST] <BtbN> GBM isn't exactly good either. It's just what is already there.
[00:10:23 CEST] <wm4> "Capabilities Set Math" oh god what
[00:11:06 CEST] <BtbN> well, you kind of need that black magic
[00:11:28 CEST] <TD-Linux> it's a C API rather than a kernel API which I have mixed feelings about
[00:11:51 CEST] <BtbN> But all that stuff is in userland?
[00:12:46 CEST] <TD-Linux> oh yeah nevermind, got it mixed up with something else
[00:33:55 CEST] <jamrial> ubitux: ping
[00:34:02 CEST] <ubitux> jamrial: pong
[00:34:11 CEST] <jamrial> your fate clients are failing
[00:34:35 CEST] <jamrial> ubitux: nevermind, i think i found why
[00:36:53 CEST] <ubitux> it's the null() thing?
[00:37:13 CEST] <ubitux> like, missing the concat close? :p
[00:37:41 CEST] <jamrial> yeah :p
[00:41:53 CEST] <cone-265> ffmpeg 03James Almer 07master:ef7766befde5: fate: add missing closing bracket
[00:46:18 CEST] <cone-265> ffmpeg 03Ganesh Ajjanagadde 07master:7bfda7d157eb: intmath: add faster clz support
[00:46:19 CEST] <cone-265> ffmpeg 03James Almer 07master:19d57ca62e71: libavutil: add av_mod_uintp2
[00:46:20 CEST] <cone-265> ffmpeg 03Paul B Mahol 07master:aba5b94859ef: Add Apple Pixlet decoder
[00:46:21 CEST] <cone-265> ffmpeg 03James Almer 07master:37caed777472: Merge commit 'aba5b94859ef1cb8f517dc64bce86a3021316ae8'
[00:48:47 CEST] <ubitux> jamrial: sources are different between libav pixlet and ours
[00:48:56 CEST] <jamrial> BtbN: what do you think of 3303f86467? (libav commit)
[00:49:07 CEST] <ubitux> it seems to be mostly random spaces as usual, but you may want to reduce the diff
[00:50:15 CEST] <jamrial> ubitux: ah ok. I usually just skip them when it's a port from ffmpeg, but you're right, better reduce diff if possible
[00:50:31 CEST] <ubitux> no, you really need to check everytime
[00:50:54 CEST] <ubitux> because they have a bad habit of shuffling the code all the time when cherry picking
[00:51:15 CEST] <ubitux> the other way around is less problematic since you can trust the person doing the port
[00:51:52 CEST] <jamrial> i see at first glance it uses the new bitstream reader
[00:52:10 CEST] <ubitux> there are type changes too
[00:52:11 CEST] <jamrial> gonna be a pain to find real changes
[00:52:23 CEST] <jamrial> size_t again
[00:53:40 CEST] <ubitux> one thing you have to be careful is that they sometimes cherry-pick the original commit but not the fixes that happened later
[00:53:53 CEST] <ubitux> so you have to be careful about not reverting changes we did... :p
[00:55:12 CEST] <jamrial> yeah, heh
[00:55:53 CEST] <jamrial> in this case they did squash all the fixes up to that point into the first commit
[01:02:43 CEST] <jamrial> they added a variale named cthulu
[01:03:20 CEST] <wm4> who is they
[01:03:24 CEST] <wm4> or do you mean THEM
[01:04:46 CEST] <jamrial> whoever cherry picked and changed parts of this decoder
[01:04:54 CEST] <jamrial> probably koda
[01:05:41 CEST] <wm4> you could probably ask koda
[01:08:44 CEST] <jamrial> it's a temp variable to hold a value. i just found the name funny
[01:29:37 CEST] <cone-265> ffmpeg 03Sasi Inguva 07master:2b006ccf8318: ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined.
[01:29:38 CEST] <cone-265> ffmpeg 03Ivan Kalvachev 07master:9054439bad33: Fix visual glitch with XvMC, caused by wrong idct permutation.
[03:26:21 CEST] <cone-265> ffmpeg 03James Almer 07master:734ed3893110: configure: fix dependencies for v4l2_indev
[03:30:46 CEST] <jamrial> ubitux: two bugs we didn't detect so far :p
[03:35:13 CEST] <atomnuker> BBB: why did vp9 have both SEG_LVL_SKIP and the mbmi skip flag to signal skipping?
[03:35:45 CEST] <BBB> some people thought itd be fun to skip at the segment level so it would take Even Less Bits
[03:36:07 CEST] <BBB> there was some data that it helped reduce bitrate of akiyo (240p) at 40ish dB PSNR by a few percent (to 20kbps or so)
[03:36:35 CEST] <atomnuker> but you always signal an mbmi->skip flag too
[03:36:38 CEST] <BBB> also static content
[03:36:54 CEST] <BBB> yes, but SEG_LVL_SKIP forces a reference, a motion vector (zeromv) and a skip flag
[03:36:58 CEST] <BBB> so it does everything at once
[03:37:20 CEST] <BBB> or actually, the reference is a separate feature
[03:37:22 CEST] <BBB> but still
[03:37:33 CEST] <atomnuker> yeah but you still code a skip flag
[03:37:43 CEST] <BBB> SEG_LVL_SKIP + SEG_LVL_REFERENCE would mean no coded flags in the block apart from the seg_id
[03:37:46 CEST] <BBB> nope
[03:38:00 CEST] <BBB> with these two seg features, you dont code any bits in the block data
[03:38:02 CEST] <BBB> nothing at all
[03:38:06 CEST] <BBB> its entirely static
[03:38:16 CEST] <BBB> but no coded bits in the block data (afaicr)
[03:38:45 CEST] <BBB> other than the seg id of course, which for static data would be update_map=0, which means even that isnt coded, which means its free
[03:38:47 CEST] <atomnuker> I guess things did change because in av1 you read a segment_id and then you immediately read the skip flag (always)
[03:39:02 CEST] <BBB> maybe that changed in av1; in vp9, its dependent on the seg feature
[03:39:18 CEST] <atomnuker> wow
[03:39:43 CEST] <jamrial> they used results from a test on a 240p sample at ~20kbps to agree on a feature for a codec meant for 2k and 4k video?
[03:40:13 CEST] <atomnuker> ...all their internal test samples were low res
[03:41:32 CEST] <BBB> vp9block.c:143
[03:41:34 CEST] <BBB>     b->skip = s->s.h.segmentation.enabled &&
[03:41:35 CEST] <BBB>         s->s.h.segmentation.feat[b->seg_id].skip_enabled;
[03:41:37 CEST] <BBB>     if (!b->skip) {
[03:41:37 CEST] <BBB>         int c = td->left_skip_ctx[row7] + s->above_skip_ctx[col];
[03:41:38 CEST] <BBB>         b->skip = vp56_rac_get_prob(td->c, s->prob.p.skip[c]);
[03:41:41 CEST] <BBB> so it looks like that changed in av1
[03:42:38 CEST] <atomnuker> yeah, that's definitely changed
[03:42:48 CEST] <atomnuker> did vp9 have temporal segid prediction too?
[03:42:55 CEST] <BBB> yes
[03:43:04 CEST] <BBB> please fix that, I want spatial prediction in av1
[03:43:13 CEST] <BBB> I would like*
[03:44:10 CEST] <atomnuker> patch is for review on gerrit, removes temporal prediction but still needs some code management crap
[03:44:26 CEST] <BBB> ok, cool
[03:44:43 CEST] <atomnuker> and to figure out what to do not to signal a segment id on skipped blocks
[03:45:01 CEST] <BBB> what about loopfilter delta?
[03:45:10 CEST] <atomnuker> (it works, but blocks get blurred, looks like the encoder still uses a segment id for something so there's a desync)
[03:45:32 CEST] <BBB> probably loopfilter delta
[03:45:55 CEST] <atomnuker> yeah, I meant skip a segment id if none of the segments contain anything but seg_lvl_alt_q
[03:46:12 CEST] <BBB> ah ok
[03:46:28 CEST] <BBB> that seems a weird case to optimize for TBH
[03:46:36 CEST] <BBB> in most cases you want lf lvl to adjust along with q
[03:46:49 CEST] <BBB> but if you have a use case for it, go ahead, of course
[03:47:03 CEST] <atomnuker> not really
[03:47:53 CEST] <atomnuker> derf's idea was to use another block's q (non-skipped) or use some default value
[03:48:21 CEST] <BBB> sounds like its worth trying at least, sure
[03:52:17 CEST] <atomnuker> I am/was considering starting to write an av1 encoder myself but I'm not happy with what it settled for (it lacks exotic things)
[03:52:47 CEST] <atomnuker> well, except obmc, it has that though its limited afaik
[03:53:29 CEST] <atomnuker> I'd rather do ffv2 with full on exotic things
[03:54:41 CEST] <atomnuker> so lapping, stockwell transforms instead of dcts, obmc, pvq, dering and whatever else I could think of
[03:56:03 CEST] <atomnuker> using stockwell transforms would have solved daala's NP hard problem of block size selection with lapping because you could use a fixed block size and instead subdivided
[03:57:24 CEST] <atomnuker> (since they're partly spatial/frequency domain yet are cheap-ish to compute..ish)
[04:31:44 CEST] <djfk> hello
[04:32:10 CEST] <djfk> how to simulate client request different video stream?
[09:06:59 CEST] <Zeranoe> A commit in the last day seems to have broken building for macOS. Trying to find what exactly buy bisect isn't working.
[09:09:27 CEST] <Zeranoe> 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 perhaps
[09:17:38 CEST] <Zeranoe> Yeah something in 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 that's a huge commit too
[10:02:40 CEST] <nevcairiel> Zeranoe: you'll need to be more specific, i did a ./configure && make just now, and it finished fine
[10:04:09 CEST] <Zeranoe> nevcairiel: It's with gnutls, before that commit the frameworks were included: -framework CoreServices -framework CoreGraphics -framework VideoToolbox -framework CoreImage -framework AVFoundation -framework AudioToolbox -framework AppKit
[10:04:39 CEST] <Zeranoe> It looks like gnutls needs at least CoreServices
[10:06:59 CEST] <BtbN> jamrial, 3303f86467 is a no-op. NV_ENC_PARAMS_RC_2_PASS_VBR is a deprecated rc mode(http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h=c3a829421282d5f22f82fc285723f13eb660f053;hb=HEAD#l268).
[10:07:14 CEST] <BtbN> And the first hunk with qmin/qmax was applied to ffmpeg quite a while ago already.
[10:07:49 CEST] <BtbN> In a slightly different fashion, but with the same effect
[10:07:58 CEST] <BtbN> Came as a patch from nvidia iirc
[10:09:14 CEST] <nevcairiel> Zeranoe: all of those services are still included here
[10:10:06 CEST] <nevcairiel> please open a trac ticket with full log output and everything, and a minimal configure commandline to reproduce it
[10:10:16 CEST] <Zeranoe> nevcairiel: do you have extralibs ?
[10:13:52 CEST] <Zeranoe> It doesn't look like that matters anyway. You're seeing the frameworks during configure at the gnutls check (check_gnutls_global_init) ?
[10:14:04 CEST] <nevcairiel> additionally, gnutls is included through pkg-config, if it needs anything special, its .pc file should include that
[10:14:46 CEST] <Zeranoe> I agree, but it seems to be confused with what it needs
[10:18:01 CEST] <nevcairiel> I also cannot find any reference to gnutls needing that on the web
[10:19:02 CEST] <Zeranoe> Not sure, but my configure fails without extralibs="-framework CoreServices" at gnutls
[10:20:00 CEST] <Zeranoe> https://paste.ubuntu.com/25723363/
[10:23:47 CEST] <nevcairiel> what does the .pc file for gnutls look like, exactly?
[10:26:17 CEST] <Zeranoe> https://paste.ubuntu.com/25724985/
[10:27:28 CEST] <BtbN> jamrial is not even here...
[10:30:42 CEST] <nevcairiel> should definitely open a ticket with gnutls if they require linkage to something but the .pc doesnt specify it
[10:33:11 CEST] <nevcairiel> the osx keychain support in gnutls is "relatively" new (only 6 months, only in 3.5.x and above)
[10:36:35 CEST] <Zeranoe> Getting https://paste.ubuntu.com/25725030/ now nevcairiel 
[12:44:17 CEST] <cone-612> ffmpeg 03Carl Eugen Hoyos 07master:ce508f0bcc37: lavc/proresdec2: Do not mix variable declaration and statement.
[12:47:47 CEST] <wm4> is libavutil missing a dep on opencl?
[13:07:12 CEST] <funman> it's missing a dep on all the hw stuff afaik
[13:10:56 CEST] <wm4> supposedly it regressed with 6dfcbd80ad446ff163b47f2bf432bbf706436ea8
[13:28:04 CEST] Action: JEEB thinks about adding a flag to the mpegts demuxer to "handle the timestamp funkiness for me, thank you"
[13:28:19 CEST] <JEEB> handling it in each darn client just seems like duplicated effort :|
[13:29:45 CEST] <wm4> like what?
[13:29:59 CEST] <JEEB> timestamps can go backwards and libavformat will just export those timestamps as-is
[13:30:27 CEST] <JEEB> there's the usual round-going which is normal because of the 33bit int
[13:30:36 CEST] <JEEB> and then there's just stuff going backwards etc
[13:31:03 CEST] <JEEB> this is why upipe exports multiple timestamps
[13:31:14 CEST] <JEEB> one for those who want the original coded timestamp of input
[13:31:31 CEST] <JEEB> one for those who just want the timestamp after de-MPEG-TS'ization
[13:31:43 CEST] <JEEB> which would be constantly rising properly and all that jazz
[13:31:55 CEST] <JEEB> and then one for the reception time stamp
[13:57:53 CEST] <nevcairiel> i might use such a mode if it existed and is reliable
[16:00:58 CEST] <jamrial> BtbN: saw your reply in the logs, thanks
[16:03:53 CEST] <jamrial> wm4: ping
[16:03:59 CEST] <wm4> jamrial: pong
[16:05:43 CEST] <jamrial> wm4: does https://pastebin.com/cy8s8zn3 fix the opencl on avutil thing you mentioned?
[16:06:14 CEST] <wm4> haven't tested it myself, can do later
[16:06:19 CEST] <wm4> isn't that missing vdpau
[16:06:38 CEST] <wm4> hm maybe that's dlopened
[16:07:09 CEST] <jamrial> wm4: no, it's using vdpau_x11 though
[16:08:18 CEST] <wm4> I remember some murky problems with this (months/years long before)
[16:33:12 CEST] <jamrial> nevcairiel: can you post a sample config.mak from a default macos build?
[16:33:12 CEST] <wm4> ok, as expected I can't reproduce the issue
[16:34:15 CEST] <jamrial> wm4: what issue?
[16:36:09 CEST] <BBB> atomnuker: regarding SEG_LVL_SKIP
[16:36:15 CEST] <wm4> the one I mentioned before (user report is here https://github.com/mpv-player/mpv/issues/4977)
[16:36:17 CEST] <BBB> static int write_skip(const AV1_COMMON *cm, const MACROBLOCKD *xd,
[16:36:18 CEST] <BBB>                       int segment_id, const MODE_INFO *mi, aom_writer *w) {
[16:36:19 CEST] <BBB>   if (segfeature_active(&cm->seg, segment_id, SEG_LVL_SKIP)) {
[16:36:20 CEST] <BBB>     return 1;
[16:36:26 CEST] <BBB> atomnuker: doesnt that suggest av1 still has the behaviour vp9 had also?
[16:37:01 CEST] <wm4> jamrial: the test program fails with "err: /usr/lib/libavutil.so.55: undefined reference to `clEnqueueUnmapMemObject'"
[16:37:23 CEST] <wm4> (and a bunch of other missing cl* refs)
[16:37:42 CEST] <jamrial> does the change i posted above fix it? or you mean you can't evne reproduce the failure anymore?
[16:42:50 CEST] <atomnuker> BBB: no, look in e.g. read_intra_frame_mode_info() in av1/decoder/decodemv.c
[16:43:16 CEST] <atomnuker> first it reads mbmi->segment_id and then mbmi->skip
[16:43:55 CEST] <wm4> jamrial: I can't reproduce the failure without the patch
[16:44:24 CEST] <jamrial> are you enabling opencl? it's afaik not autodetected
[16:44:29 CEST] <wm4> asked the user to try the patch
[16:44:30 CEST] <wm4> no
[16:44:41 CEST] <wm4> this is just a basic linking test
[16:44:51 CEST] <wm4> #include <libavcodec/version.h>
[16:44:51 CEST] <wm4> int main(int argc, char **argv)
[16:44:51 CEST] <wm4> { int x[LIBAVCODEC_VERSION_MICRO >= 100 ? 1 : -1]; return 0; }
[16:45:03 CEST] <wm4> + using the .pc file cflags/libs
[16:45:13 CEST] <jamrial> ah, so the user must have a build with opencl enabled
[16:45:18 CEST] <wm4> probably
[16:47:20 CEST] <BBB> atomnuker: see code for read_skip
[16:47:22 CEST] <BBB> static int read_skip(AV1_COMMON *cm, const MACROBLOCKD *xd, int segment_id,
[16:47:23 CEST] <BBB>                      aom_reader *r) {
[16:47:24 CEST] <BBB>   if (segfeature_active(&cm->seg, segment_id, SEG_LVL_SKIP)) {
[16:47:25 CEST] <BBB>     return 1;
[16:47:33 CEST] <BBB> so it doesnt actually read any bits from the bitstream if the seg feature is active
[16:47:38 CEST] <BBB> afaics
[16:58:44 CEST] <atomnuker> oh, didn't notice that
[16:59:11 CEST] <atomnuker> still I don't like it because its niche, isn't it?
[17:05:26 CEST] <wm4> jamrial: oh, it actually uses libavcodec.pc only
[17:13:34 CEST] <wm4> jamrial: ok, I can reproduce, and your patch doesn't fix it
[17:13:56 CEST] <wm4> jamrial: the bug is when linking something that uses libavcodec only with libavcodec's .pc file, if opengl is enabled in ffmpeg
[17:15:33 CEST] <wm4> I don't see an opencl lib anywhere in the .pc files or in the .so's
[17:16:28 CEST] <wm4> oh, make clean + rebuild and your patch fixes it
[17:18:05 CEST] <wm4> jamrial: yeah, it adds opencl as dependency to the avutil .so, so push it
[17:23:20 CEST] <jamrial> wm4: yeah, opencl is libavfilter and libavutil only for now. i missed the latter
[17:23:22 CEST] <jamrial> will push, thanks
[17:24:48 CEST] <wm4> Libs.private still doesn't have opencl in it, not sure if that's an issue (and I didn't try a static build)
[17:29:40 CEST] <cone-361> ffmpeg 03James Almer 07master:25bd2f4f368a: configure: add missing OpenCL dependency to libavutil
[17:47:45 CEST] <wm4> jamrial: user reports some more issues, with a set of switches https://github.com/mpv-player/mpv/issues/4977#issuecomment-336173090
[17:47:59 CEST] <wm4> could be similar issues
[18:01:33 CEST] <jamrial> wm4: the user just confirmed the opencl fix solved it
[18:01:51 CEST] <jamrial> which is great, because the example configure line he posted enables a shitload of things
[18:02:04 CEST] <jamrial> meaning all those are alledgedly working as intended
[18:02:49 CEST] <wm4> jamrial: yeah, apparently now everyting is fixed
[18:03:05 CEST] <wm4> I thought the user had these problems after your fix, but that was not the case
[18:07:49 CEST] <jamrial> curious, though. that configure example enables libxavs and that one is supposedly failing
[18:08:04 CEST] <jamrial> haven't pushed the fix for that yet since michaelni hasn't confirmed if it works for him
[18:38:22 CEST] <nevcairiel> Maybe his xavs is without pthreads on a platform which doesn't require explicit libm
[18:38:54 CEST] <jamrial> could be
[18:40:58 CEST] <nevcairiel> That people still bother with xavs however
[18:41:11 CEST] <cone-361> ffmpeg 03Ganapathy Kasi 07master:3303f86467ef: nvenc: Remove qmin and qmax constraints for nvenc vbr
[18:41:12 CEST] <cone-361> ffmpeg 03James Almer 07master:65c11f1bbac6: Merge commit '3303f86467efa99f23c670707f5be094cc9ce547'
[18:41:28 CEST] <nevcairiel> It's a cheap knockoff of h264, and the encoder is probably half x264 as well
[18:43:46 CEST] <jamrial> the library hasn't been updated since like 2011 as well
[18:44:38 CEST] <jamrial> the latest news in the website is "ffmpeg supports libxavs", even. it's like they made it in and said job done :p
[18:44:52 CEST] <wm4> are there any files using it in the wild
[19:02:13 CEST] <jamrial> nevcairiel: what i asked above, can you post an example config.mak from macos?
[19:08:43 CEST] <jkqxz> wm4:  A lot of China.  Chinese kit all has it in hardware, too - Allwinner and Rockchip SoCs support it, say.
[19:09:16 CEST] <jkqxz> No idea about encoders for it, though.
[19:10:30 CEST] <wm4> https://0x0.st/CBu.jpg
[19:15:06 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:6eef263aca28: x86: Merge align directives into SECTION_RODATA declarations where possible
[19:15:07 CEST] <cone-361> ffmpeg 03James Almer 07master:b78bb51a7cdd: Merge commit '6eef263aca281fb582e1fa3d841ac20ef747a252'
[19:21:02 CEST] <cone-361> ffmpeg 03James Almer 07master:6fb580e7d3c4: configure: fix libxavs check
[20:00:37 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:808ef43597b1: build: Explicitly set 32-bit/64-bit object formats for nasm/yasm
[20:00:38 CEST] <cone-361> ffmpeg 03James Almer 07master:e4ad3e6f6449: Merge commit '808ef43597b1e3d6e69a5b9abe2237c8ddb97b44'
[20:05:15 CEST] <cone-361> ffmpeg 03Vittorio Giovara 07master:b44bd7ee7f7d: pixlet: Fix architecture-dependent code and values
[20:05:16 CEST] <cone-361> ffmpeg 03James Almer 07master:c54431354a36: Merge commit 'b44bd7ee7f7d834c1e22b5f33674393e5c0267c5'
[20:46:08 CEST] <ubitux> durandal_1707: http://b.pkh.me/0001-lavc-pixlet-reduce-diff-with-Libav-cosmetics-only.patch
[20:46:22 CEST] <ubitux> there are a bunch of other changes you may or may not want to pick
[20:46:33 CEST] <ubitux> such as free/reinit code
[20:46:48 CEST] <ubitux> pict_type/color_range/key_frame setting earlier
[20:47:01 CEST] <ubitux> sorry, later* (might be a local change they didn't pick)
[20:47:08 CEST] <ubitux> various type changes
[20:47:20 CEST] <ubitux> hardcoding NB_LEVELS everywhere instead of using a variable
[20:47:46 CEST] <ubitux> and aside from the bitstream api, that should be all
[20:50:23 CEST] <jamrial> ubitux: unexpected fallout of the extralibs merge: people using custom --extra-ldflags that worked purely by chance because global extralibs added things said custom extra-ldflags were missing
[20:51:26 CEST] <jamrial> this merge is revealing a lot of poorly planned configure lines, haha
[20:51:41 CEST] <wm4> is it even possible to properly "plan" configure lines
[20:51:59 CEST] <jamrial> wm4: not adding random --extra-ldflags for components already detected by configure is a good start
[20:52:08 CEST] <wm4> most time I have to do this I can come up with some BS that just barely works and that reviewers are content with
[20:52:27 CEST] <wm4> oh you mean configure user invocation?
[20:52:30 CEST] <jamrial> yeah
[20:52:49 CEST] <ubitux> jamrial: yeah, i think that's a good thing
[20:54:17 CEST] <jamrial> ubitux: sure, but please help me explain that to the guy in the ml without him having go mad because the script that worked until now is not working anymore because it probably wasn't correct :P
[20:54:33 CEST] <ubitux> tessarek ?
[20:55:08 CEST] <jamrial> yeah. he seems to run mac nightlies
[20:55:17 CEST] <jamrial> wm4: ^
[20:55:26 CEST] <jamrial> he kinda needs to use git master
[20:58:06 CEST] <wm4> seems silly to get mad about occasional instability in git master, and also to use git master for something that should "just work"
[21:06:07 CEST] <jamrial> mmh, it appears libbluray does use freetype2 if configured as such
[21:07:35 CEST] <jamrial> so if the check is not including bzip2 and zlib for him (both freetype2 deps) then it means pkg-config was not called with --static, or maybe that he lacks a .so for freetype2
[21:08:35 CEST] <ubitux> isn't pkg-config supposed to raise all the static flags if only the static .a is available?
[21:09:07 CEST] <wbs> ubitux: there's no such rule, but some projects (like libav/ffmpeg) try to produce such pkg-config files
[21:09:08 CEST] <jamrial> i have no idea
[21:09:32 CEST] <wbs> there's the pkg-config flag --static as well, which includes those parts; but as a user of pkg-config you can't know if only static libraries are available or not
[21:09:58 CEST] <ubitux> but pkg-config knows, so it should raise the --static ones, no?
[21:10:06 CEST] <wbs> no, pkg-config doesn't know anything
[21:10:24 CEST] <wbs> it's up to the build system of the library that produces the .pc file
[21:10:54 CEST] <wbs> whether they even knew and/or cared to promote the .private parts into the public part, if only installing static libs
[21:10:56 CEST] <ubitux> mmh, right, so if the project is built with static only it should generate the proper .pc
[21:11:04 CEST] <wbs> exactly
[21:11:13 CEST] <ubitux> yeah right, i remember figuring that out a while ago
[21:11:27 CEST] <wbs> since not all libs do this correctly, in vlc they've got a script which you can run on pkg-config files that fixes this, if you know you've got a static-only build
[21:12:19 CEST] <jamrial> so, at least on msys2's package, libbluray.pc has "-lfreetype" as Libs.private instead of having freetype as a package depencency
[21:12:43 CEST] <wbs> jamrial: that doesn't really make much of a difference
[21:13:04 CEST] <wbs> normally they would put such dependencies into the Depends.private, or what you call it
[21:13:08 CEST] <jamrial> even if freetype2 depends on things loke bzip2?
[21:13:18 CEST] <wbs> ah, right
[21:13:24 CEST] <jamrial> s/loke/like
[21:13:47 CEST] <wbs> yes, using package dependecies is better if that dependency also is a potentially static library with further recursive deps
[21:14:07 CEST] <ubitux> shouldn't we do that as well for our deps?
[21:14:47 CEST] <jamrial> i'm guessing tessarek is missing .so files for some libraries
[22:30:57 CEST] <Rathann> hi
[22:31:31 CEST] <jamrial> hi
[22:37:55 CEST] <cone-361> ffmpeg 03James Almer 07master:4226c57b2b1f: configure: add missing libfontconfig and libfreetype dependencies to showcqt filter
[22:41:14 CEST] <jamrial> ubitux: thanks btw for the pixlet cosmetics
[22:54:23 CEST] <ubitux> np, it was the easy part
[22:56:42 CEST] <jamrial> what did you do wiht the av_clip?
[22:56:44 CEST] <jamrial> skipped it?
[22:57:17 CEST] <ubitux> what about it?
[22:58:45 CEST] <jamrial> their version added an av_clip in a function that we don't have
[22:59:06 CEST] <jamrial> i guess you skipped it since it was not a cosmetic change?
[22:59:20 CEST] <ubitux> didn't notice anything related to av_clip
[23:00:30 CEST] <jamrial> look in line_add_sat_s16() in their version, which was split off lowpass_prediction()
[23:03:35 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:003124ebf4a0: build: Fix logic of clock_gettime() check
[23:03:36 CEST] <cone-361> ffmpeg 03James Almer 07master:583003670f24: Merge commit '003124ebf4a05f1347c74104216887ddd2e5aad4'
[23:04:17 CEST] <ubitux> ah that, yeah it's functionnal changes
[23:04:20 CEST] <ubitux> i didn't include that
[23:09:36 CEST] <ubitux> i'm still waiting for comments from durandal_1707, and he will probably take over it for the functionnal part
[23:10:11 CEST] <durandal_1707> i dont like these cosmetic changes
[23:12:02 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:51411eb7ffba: build: Special-case handling of SDL CFLAGS
[23:12:03 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:f54037da8af2: build: Make x86 assembler commandline-selectable
[23:12:04 CEST] <cone-361> ffmpeg 03Diego Biurrun 07master:57b753b445e2: build: Prefer NASM assembler over YASM
[23:12:05 CEST] <cone-361> ffmpeg 03James Almer 07master:fb934f23e1b7: Merge commit '57b753b445e23363c997a8ec1c556e0b0f6e9da3'
[23:12:44 CEST] <durandal_1707> mostly because they are pointless
[23:13:24 CEST] <jamrial> ubitux: i'd not bother renaming the get_bits variables from b to bc. those lines will still differ from libav since they use the new bitstream reader
[23:13:32 CEST] <jamrial> durandal_1707: they help with merges
[23:15:53 CEST] <cone-361> ffmpeg 03Carl Eugen Hoyos 07master:c87bb9c04af8: lavc/ppc/fft_init: Fix compilation on ppc64le with --disable-vsx.
[23:24:10 CEST] <Rathann> w00t, it looks like FDK AAC is now almost free: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F64JBJI2IZFT2A5QDXGHNMPALCQIVJAX/
[23:25:24 CEST] <jamrial> Rathann: can we remove the nonfree dep then?
[23:25:30 CEST] <durandal_1707> no
[23:25:39 CEST] <jkqxz> What licence does this version have?
[23:25:56 CEST] <Rathann> the forked source with SBR, TNS and some other stuff stripped is considered free by RH legal
[23:27:00 CEST] <kierank> Rathann: what BS
[23:27:07 CEST] <atomnuker> " No other AAC implementations (regardless of copyright license) are permitted in Fedora at this time." <- pricks
[23:29:15 CEST] <Rathann> jkqxz: not any of the standard ones
[23:30:17 CEST] <Rathann> however, the problematic clause (that the (copyright) license only covers compliant AAC implementations, a use case restriction) appears to have been removed from the original FDK AAC license
[23:32:23 CEST] <durandal_1707> lets sue them!
[23:32:57 CEST] <Rathann> durandal_1707: huh? what for?
[23:33:20 CEST] <kierank> Rathann: the problem is "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
[23:33:21 CEST] <kierank> by appropriate patent licenses."
[23:33:40 CEST] <kierank> i guess if redhat legal think the stuff isn't patented then perhaps fine
[23:35:57 CEST] <Rathann> kierank: yes, apparently they do think so now
[23:36:46 CEST] <kierank> maybe we should do the same
[23:36:53 CEST] <kierank> have a special --enable-heaac build
[23:37:32 CEST] <Rathann> your call, I'm just here to give the news ;)
[23:38:06 CEST] <Rathann> and working on reviewing the package to get it into Fedora
[23:38:26 CEST] <atomnuker> kierank: wouldn't help, redhat want the source code to not contain patents _too_
[23:38:39 CEST] <atomnuker> they go to great lengths for that
[23:38:52 CEST] <kierank> the source code?
[23:38:53 CEST] <kierank> huh
[23:38:59 CEST] <kierank> oh
[23:39:01 CEST] <kierank> blimey
[23:39:04 CEST] <kierank> that's dumb
[23:39:13 CEST] <Rathann> atomnuker: this is about the fork at https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=stripped2
[23:39:18 CEST] <Rathann> not the original fdk-aac
[23:39:54 CEST] <Rathann> as I said earlier, some stuff is stripped (probably the parts RH legal thinks are covered by some unexpired patents)
[23:41:20 CEST] <Rathann> kierank: remember RH is US-based, so they're subject to dumb US patent law and courts
[23:41:46 CEST] <Rathann> so they don't want to distribute anything that's patented
[23:41:54 CEST] <Rathann> including source code
[23:43:23 CEST] <jkqxz> michaelni:  Ping cbs patchset again?  (Or shall I resend the full set?)
[23:43:54 CEST] <wm4> distributing source code that contains patented algorithms is legally no problem
[23:44:23 CEST] <wm4> (other than the hysteric fact that algorithms can't be patented even in the US)
[23:52:37 CEST] <TD-Linux> US patent law (along with the EU I believe) makes no distinction between source code and binaries
[23:53:00 CEST] <ubitux> durandal_1707: it's to help you figuring out the remaining functionnal changes
[23:53:22 CEST] <ubitux> durandal_1707: as you can see there are a bunch of stuff that may be interesting to us
[23:53:33 CEST] <durandal_1707> i dont care
[23:53:49 CEST] <ubitux> k
[23:54:17 CEST] <ubitux> well then, patch dismiss, do as you please
[23:54:52 CEST] <durandal_1707> ubitux: no you can apply it im not dictator
[23:55:06 CEST] <ubitux> it's your code and you're maintaining it
[23:55:14 CEST] <ubitux> no?
[23:55:47 CEST] <durandal_1707> no, i dont care for cosmetics ., just dont break decoder
[23:56:22 CEST] <ubitux> i only imported the cosmetics so you can care about the functionnal changes
[23:56:31 CEST] <ubitux> i'm not qualified to make functionnal changes to that code, so i won't
[23:57:33 CEST] <durandal_1707> whatever, i picked what was usefull already
[23:59:09 CEST] <ubitux> http://b.pkh.me/pixletdiff.html
[23:59:14 CEST] <ubitux> this is the diff post cosmetics
[00:00:00 CEST] --- Fri Oct 13 2017