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

[burek]

[00:25:09 CEST] <cone-535> ffmpeg 03James Almer 07master:70a708713ad2: fate: fix hapqa-extract-nosnappy tests on small builds
[10:03:15 CEST] <durandal_1707> so anybody against adding .max_lowress = 3 to prores decoder?
[10:07:36 CEST] <atomnuker> what does that do?
[10:10:31 CEST] <durandal_1707> atomnuker: instruct idct to do 1/8, 1/4 or 1/2 decoding reduction
[10:11:15 CEST] <durandal_1707> for faster decoding of 8k on slow machine
[10:12:02 CEST] <atomnuker> at the loss of detail?
[10:13:56 CEST] <durandal_1707> loss of resolution
[10:14:05 CEST] <atomnuker> the api seems to be deprecated, so no one should be using that feature nowadays
[10:15:24 CEST] <atomnuker> I'd rather just make it do nothing until its dropped, I don't think such optimizations are a good idea
[10:15:43 CEST] <durandal_1707> atomnuker: stop beeing that bad boy
[10:16:10 CEST] <durandal_1707> lowres will stay, via API or via private option, doesn't matter
[10:16:21 CEST] <atomnuker> well no, it'll be gone in the next bump
[10:16:45 CEST] <durandal_1707> then consider it being an private option
[10:17:04 CEST] <atomnuker> no such thing as that
[10:17:29 CEST] <durandal_1707> atomnuker: no, it will not, you devs are extremely lazy
[10:17:42 CEST] <atomnuker> I can't care for now though since no one is using it, and it will be gone anyway
[10:17:50 CEST] <durandal_1707> and no codec that uses .max_lowres have been 'fixed'
[10:18:06 CEST] <durandal_1707> atomnuker: people do use it
[10:18:27 CEST] <atomnuker> and its not great, its incorrectly decoding
[10:20:24 CEST] <durandal_1707> atomnuker: jpeg2000 decoder uses private lowres option
[10:20:46 CEST] <durandal_1707> atomnuker: it is not incorrect decoding, what's wrong with you?
[10:21:30 CEST] <durandal_1707> there is special jpeg idct for doing scaled down idct
[10:24:30 CEST] <atomnuker> unless its explicitly given in the codec specs its not, its a hack
[10:57:28 CEST] <durandal_1707> atomnuker: stop this nonsense reasoning, you are stealing my lunch
[13:05:49 CEST] <LigH> Hi.
[13:05:58 CEST] <HappyPonyLand> heeeeey, buddy
[13:06:40 CEST] <LigH> :o
[13:07:41 CEST] <LigH> There is a patch for libav, to enable building with the current fdk-aac API. Do you know if ffmpeg already has a similar one?
[13:08:00 CEST] <LigH> https://git.libav.org/?p=libav.git;a=commitdiff;h=141c960e21d2860e354f9b90df136184dd00a9a8;hp=c8bca9fe466f810fd484e2c6db7ef7bc83b5a943
[13:08:59 CEST] <JEEB> it should come in as the merges get done
[13:09:37 CEST] <JEEB> IIRC there were some questions regarding a merge between that thing which is currently in review
[13:09:43 CEST] <JEEB> after that gets done that should get merged in as well
[13:10:42 CEST] <JEEB> if it seems like it's going to take too much time, feel free to post the patch on ffmpeg-devel (I think Derek mentioned the fdk-aac related patches #elsewhere yesterday)
[13:12:14 CEST] <LigH> Alright, so ... patience.
[13:14:18 CEST] <LigH> The configuration for libsrt works again, just needs to refresh the .pc files; only liblensfun is more tricky under MSYS2, may require meson to be rebuilt in relation to glib2 without gnulib ...
[13:16:50 CEST] <LigH> Bye
[13:21:53 CEST] <HappyPonyLand> I'm building libavutil (we're locked to an ancient fork) with MinGW and I'm having some linking trouble, is there any secret magic which symbols get exported?
[13:23:14 CEST] <HappyPonyLand> building _a DLL_, I meant to say
[13:23:36 CEST] <durandal_1707> maybe, maybe not, my crystal ball is shining
[13:34:22 CEST] <HappyPonyLand> apparently there is, tried adding a test function and it only got exported after I added an av_ prefix
[13:36:26 CEST] <durandal_1707> that is ugly solution...
[13:36:55 CEST] <BtbN> Don't use ancient stuff
[13:44:55 CEST] <HappyPonyLand> in the best of worlds...
[13:51:12 CEST] <wbs> not using ancient stuff doesn't matter, the fact that only av_* prefixed symbols are exported is intentional and a feature, have a look at lib{foo}/lib{foo}.v to see the patterns that are intended to be exported
[13:55:00 CEST] <HappyPonyLand> wbs: thanks, just what I was looking for
[13:55:58 CEST] <durandal_1707> now, watch how that internal version goes bersek
[13:57:40 CEST] <HappyPonyLand> what is this practice of .v files called? I have never seen it before
[13:57:53 CEST] <HappyPonyLand> (and googling "v files [gnu] [make]" doesn't turn up anything useful)
[14:02:01 CEST] <wbs> HappyPonyLand: https://sourceware.org/binutils/docs/ld/VERSION.html
[14:03:26 CEST] <wbs> and the --version-script part at https://sourceware.org/binutils/docs/ld/Options.html#Options
[14:04:13 CEST] <wbs> modern versions of ffmpeg don't use this feature of ld, but manually takes the .v file and the built object files and runs a manual script which filters out what symbols to actually include, creating a def file from that
[14:16:27 CEST] <durandal_1707> will push updated scpr3 patch in a momment
[14:20:47 CEST] <HappyPonyLand> interesting - I hope I don't need to mess with it anymore right now, but it's good to know it exists
[14:26:04 CEST] <January> How would I go about adding a fate API test which requires h264 dec and threads? (specifically wondering about the makefile)
[15:11:59 CEST] <cone-954> ffmpeg 03Paul B Mahol 07master:cc24665f4479: avcodec/scpr: make sure count and min are valid
[17:33:36 CEST] <jamrial> michaelni: i'm trying to upload something to the fate samples suite, but i get a "Broken pipe" error when connecting using ssh, no matter the command i use
[17:53:01 CEST] <michaelni> jamrial, just tried a --dry-run from my upload script and didnt see anything odd with that
[17:55:36 CEST] <jamrial> michaelni: this is what i get https://pastebin.com/raw/hecWBMwN
[18:21:55 CEST] <durandal_1707> ask michaelni to upload file for you, so then we will know if he have same problem
[18:26:02 CEST] <jamrial> he just did, so it's a problem on my end
[18:26:31 CEST] <durandal_1707> --dry-run does nothing i assume
[18:29:38 CEST] <jamrial> it can't connect, so the command i use is irrelevant
[18:50:11 CEST] <cone-954> ffmpeg 03Thomas Mundt 07master:f4438e387e03: avfilter/vf_interlace: fix numerical options
[19:31:45 CEST] <kurosu> durandal_1707, for lowres, you could also not store the coefficients that are unneeded, albeit determining this could be tricky, as you need to compute the position anyway
[19:33:59 CEST] <kurosu> also, I imagine this requires specific transform code? have you rewritten asm ones, or are you comparing lowres C to SSE2?
[19:34:49 CEST] <durandal_1707> kurosu: i only written 1/8 lowres for prores, there is no point for SIMD for 1/8
[19:37:13 CEST] <durandal_1707> i did it by guessing mostly, for 1/4 & 1/2 I will need more than guessing
[20:01:49 CEST] <atomnuker> yep, at 1/8 you'll only need the DCs
[20:08:17 CEST] <BtbN> philipl, hm, and opinion about the nvidia rotate filter? They originally submitted a transpose_npp one, that only rotated in fixed 90° angles. Now they renamed it to rotate_npp, but still only fixed angles. Not a fan of either approach. I'm tempted to fix their transpose filter to actually transpose, not rotate.
[20:09:18 CEST] <BtbN> I will also rip out the NV12->YUV420->NV12 transformation if possible
[20:09:31 CEST] <BtbN> not sure if it's actually normal yuv420p in between
[20:11:50 CEST] <kurosu> durandal_1707, ok, this mode must be particularly efficient as you don't even need to decode the acs
[20:25:41 CEST] <atomnuker> you do, you still need to parse them
[20:25:54 CEST] <BtbN> Should I rather make a new vf_deinterleave_npp filter that does NV12->YUV420 or equialent for 10/12 bit, or should I just let the scale filter do it?
[20:26:03 CEST] <BtbN> I guess swscale also does both
[20:27:56 CEST] <BtbN> hm, the scale filter already does it anyway
[20:31:52 CEST] <kurosu> atomnuker, with 1/8, you just need dcs, which are at the start the slice bitstream? acs follow, so you can just skip them?
[20:32:25 CEST] <atomnuker> you need to know how large the acs are
[20:37:02 CEST] <cone-954> ffmpeg 03Shiyou Yin 07master:9f60c5858680: avcodec/mips: [loongson] fix improper use of register constraints.
[20:37:03 CEST] <cone-954> ffmpeg 03Zhao Zhili 07master:b9d1f5bf6811: avcodec/h264dec: check number of SPS in is_extra
[20:37:04 CEST] <cone-954> ffmpeg 03Zhao Zhili 07master:037b3bd14a8d: avcodec/h264dec: remove unnecessary checks in h264_decode_frame
[21:46:26 CEST] <cone-954> ffmpeg 03Paul B Mahol 07master:c4cda4eb878a: avfilter: add lut1d filter
[00:00:00 CEST] --- Sat Sep  8 2018