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

[burek]

[00:02:09 CEST] <BtbN> also, are there no a53 cc samples on samples.ffmpeg.org?
[00:07:45 CEST] <jkqxz> BtbN:  <http://ixia.jkqxz.net/~mrt/ffmpeg/sei-test.h264>
[00:07:45 CEST] <jkqxz> (I just happened to be contriving a ridiculous SEI test to add to FATE.  The captions should name the numbers in the video.)
[00:09:04 CEST] <BtbN> ok, so it seems like a53 in nvenc works
[00:09:13 CEST] <BtbN> at least transcoding this gives me a file with a subtitle track in vlc
[00:10:06 CEST] <jkqxz> Is it right?
[00:10:15 CEST] <BtbN> In what sense right?
[00:10:32 CEST] <nevcairiel> CCs often arent a "track" as such, but i have no clue how vlc works
[00:10:43 CEST] <jkqxz> Well, are the captions in the right order.
[00:11:45 CEST] <BtbN> I can't see them for that sample at all, probably because VLC is bad and renders them black on black?
[00:12:06 CEST] <BtbN> They are there, according to ffprobe though
[00:13:43 CEST] <BtbN> found some other sample on track, and it's just fine there
[00:16:10 CEST] <cone-914> ffmpeg 03Timo Rothenpieler 07master:7d4e1f7cfb66: avcodec/nvenc: make hw_frames_ctx fully optional
[00:16:11 CEST] <cone-914> ffmpeg 03Miroslav SlugeH 07master:952421cd20ac: avcodec/nvenc: support dynamic aspect ratio change
[00:16:12 CEST] <cone-914> ffmpeg 03pkviet 07master:155375123c1f: avcodec/nvenc: support dynamic bitrate changes
[00:16:13 CEST] <cone-914> ffmpeg 03Roman Arzumanyan 07master:5a88e8c36581: avcodec/nvenc: add A53CC support
[00:16:14 CEST] <cone-914> ffmpeg 03Timo Rothenpieler 07master:fdbb4b9a7866: avcodec/nvenc: move reconfig_encoder call inside of push/pop ctx
[00:18:58 CEST] <jkqxz> If anyone would like to suggest any other SEI things (or other metadata) to add to that file I would add them.
[00:28:39 CEST] <jamrial> jkqxz: that files gives an "Assertion n == subs" error with trace_headers
[00:29:14 CEST] <jkqxz> Yes, I'm fixing that.
[00:29:33 CEST] <jamrial> ok
[00:29:35 CEST] <jkqxz> The "other" SEI support doesn't really work properly.
[00:30:18 CEST] <jkqxz> (It doesn't write the correct size either.)
[00:38:04 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:c2fd69ba6239: avfilter/vf_colorbalance: add 16bit depth support
[00:54:02 CEST] <tmm1> rcombs: this is super hacky but fixes decoding https://github.com/tmm1/FFmpeg/commit/44b1612000
[00:54:17 CEST] <tmm1> i can't figure out why some frames are missing hw_frames_ctx.. its not getting copied somewhere
[00:54:23 CEST] <tmm1> maybe wm4 has some idea
[01:43:33 CEST] <rcombs> tmm1: well what code path would call alloc_frame but not end_frame?
[01:47:28 CEST] <rcombs> maybe the `!avpkt->size` case in hevc_decode_frame()?
[02:18:25 CEST] <tmm1> nope that would only be on EOF
[02:18:49 CEST] <tmm1> its something weird inside the hevc dec, maybe this HEVC_FRAME_FLAG_BUMPING business
[02:18:54 CEST] <tmm1> causing frames to be reused
[03:03:40 CEST] <tmm1> the decoder copies and moves frames all over the place, so i can't make any sense of what's going on
[03:25:27 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:84e03db9a334: avcodec/videotoolbox: improve logging of decoder errors
[03:25:28 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:bcff983dc340: avcodec/videotoolbox: fix kVTCouldNotFindVideoDecoderErr trying to decode HEVC on iOS
[03:38:03 CEST] <Compn> hanna : i didnt see any good mails in queue , only spam
[03:38:16 CEST] <Compn> so either lou or someone else approved them, or they didnt come
[04:51:32 CEST] <hanna> maybe my registering to the ML automatically approved it
[04:51:38 CEST] <hanna> (retroactively)
[05:45:22 CEST] <philipl> BtbN: Not a real problem but the define you're using in nv-codec-headers to detect 64bit windows is ffmpeg specific.
[05:45:25 CEST] <philipl> https://github.com/jb-alvarado/media-autobuild_suite/pull/832
[05:45:34 CEST] <philipl> Presumably there's a windows define you can check instead.
[05:45:53 CEST] <philipl> In practice mpv doesn't care as it doesn't try to load any nvenc symbols.
[12:27:11 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:4cd4aa08a689: avfilter/vf_convolution: use already available dstride
[12:27:12 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:db8777cef092: avfilter/vf_colorbalance: add planar rgb support
[12:52:31 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:0ef7a4519745: avfilter/vf_colorbalance: add slice threading
[15:49:06 CEST] <BtbN> philipl, fixed, just missed that one
[16:08:58 CEST] <ubitux> i'm going to repeat myself but the aarch64 simd asm is really damn nice
[16:09:20 CEST] <ubitux> almost done with the nlmeans simd
[16:09:45 CEST] <ubitux> not sure it will make much of a difference, but it will at least act as a reference for x86
[16:09:54 CEST] <JEEB> nice
[16:10:21 CEST] <JEEB> I've got rpi3 running in aarch64 mode but I seem to have one of those that dies after ~3 days of running
[16:11:25 CEST] <durandal_1707> ubitux: i looked at that already,  and it doesnt help much for cif resolutions
[16:30:41 CEST] <ubitux> durandal_1707: yeah but you don't need nlmeans for cif resolutions
[16:30:57 CEST] <ubitux> and even if you do, you don't need simd since it's already small & fast :p
[16:40:45 CEST] <durandal_1707> ubitux: it is not realtime even for cif
[16:45:10 CEST] <atomnuker> JEEB: I put archlinux aarch64 on mine, 100 days of uptime
[16:45:31 CEST] <atomnuker> and it did reset and had compiler errors and ram errors all the time with raspbian
[16:46:09 CEST] <atomnuker> ubitux: yeah but no x86 addressing
[16:46:56 CEST] <BtbN> interesting. Twitch plays their HLS stuff with sub 1 second delay now
[16:47:09 CEST] <BtbN> Their playlists have the next two segments in a #EXT-X-TWITCH-PREFETCH: thing
[16:47:27 CEST] <BtbN> as in, the next two that don't even exist yet
[16:49:41 CEST] <wm4> can libavformat play this
[16:51:28 CEST] <BtbN> it will just ignore the EXT- elements and play it like normal HLS with more delay
[16:52:07 CEST] <BtbN> But a live stream with less than a second delay, over a CDN and Server-Side remuxing and even transcoding if enabled...
[16:52:13 CEST] <BtbN> That's pretty impressive, even without HLS.
[16:53:14 CEST] <BtbN> It's Chrome-Only for some reason
[16:53:38 CEST] <wm4> yeah sometimes stupid things are impressive
[16:53:57 CEST] <atomnuker> is that what peloverde is up to nowadays
[16:54:08 CEST] <cone-295> ffmpeg 03Michael Niedermayer 07master:15a2e35e9e74: avcodec/flac_parser: Fix infinite loop
[16:54:16 CEST] <JEEB> BtbN: I think they just generate the initial PMT/PAT first, then keep the chunked thing waiting
[16:54:21 CEST] <JEEB> something like that
[16:54:29 CEST] <JEEB> atomnuker: I hear this is just a hardware thing
[16:54:38 CEST] <JEEB> some rpi3s seemingly die after ~3 days
[16:55:27 CEST] <BtbN> JEEB, can confirm. When I used an rpi3 for something semi-important, I had to cronjob-reboot it every night, otherwise it would die after random times
[16:56:12 CEST] <wm4> reboot? so it's a software problem?
[16:56:45 CEST] <JEEB> well reboot probably reset some hw
[17:02:50 CEST] <atomnuker> JEEB: don't know, mine got fixed after I reinstalled
[17:03:05 CEST] <JEEB> oh well
[17:03:22 CEST] <JEEB> I wish I cared more about it; right now I am lazy enough that it's still powered on dead
[17:07:24 CEST] <atomnuker> same issue and situation as one of my odroid c2s
[17:08:23 CEST] <atomnuker> rock solid for months until you run something even remotely intensive like cloning the kernel git, then you need to physically unplug and plug it again
[17:08:38 CEST] <BtbN> I eventuelly replaced the RPi with a NUC. No issues anymore since.
[17:09:12 CEST] <hanna> ^
[17:09:49 CEST] <JEEB> yea
[17:09:59 CEST] <JEEB> I would never put the rpi for anything serious
[17:10:07 CEST] <JEEB> for me it was mostly about "how far do I get in aarch64 mode"
[17:10:15 CEST] <JEEB> the answer to which was "surprisingly far"
[17:10:18 CEST] <Compn> rpi people are fun, they come into #mplayer because there is no rpi support or forum or distro
[17:10:35 CEST] <JEEB> because I got as far as opengl with the open source driver
[17:10:41 CEST] <JEEB> with the 4.16.x kernel
[17:10:44 CEST] <JEEB> and mesa, I guess?
[17:39:32 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:d1e18724187d: avfilter/vf_colorchannelmixer: add slice threading
[17:39:33 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:2017b4b1c25b: avfilter/vf_colorbalance: fix off by one overflow
[17:39:34 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:931e2c4541e0: avfilter/vf_colorchannelmixer: refactor code
[17:39:35 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:0f4ca420bca4: avfilter/vf_colorchannelmixer: add planar rgb support
[18:04:15 CEST] <BtbN> https://cgit.freedesktop.org/gstreamer/gst-libav/commit/?id=15a17f3f8d2282005e746507f833e68947e736e3 interesting. It really should just work?
[18:06:57 CEST] <wm4> yes
[18:07:25 CEST] <wm4> maybe they're using the API incorrectly, like always expecting yuv420p or so?
[18:07:27 CEST] <wm4> who knows
[18:07:38 CEST] <philipl> Maybe because it wasn't written by a libav dev...
[18:08:03 CEST] <BtbN> Or they didn't even test it, and just disabled it like every hwenc
[18:08:15 CEST] <JEEB> yea, that is more likely
[18:08:20 CEST] <JEEB> "just disable things just in case"
[18:08:22 CEST] <philipl> But the yuv420p wouldn't surprise me. When I did that firefox experiment with it, I had to mess around with a bunch of stuff to get nv12 working
[18:09:21 CEST] <philipl> BtbN: there's also a native nvdec gst plugin. Bare minimum functionality though.
[18:10:28 CEST] <philipl> but it has GL interop
[18:10:49 CEST] <ubitux> ssd_integral_image_c: 360618.5
[18:10:51 CEST] <ubitux> ssd_integral_image_neon: 212887.2
[18:10:54 CEST] <ubitux> not crazy but still good
[18:10:58 CEST] <BtbN> latest gst-plugins-libav does not build with ffmpeg-4 anyway
[18:11:43 CEST] <wm4> why not
[18:11:58 CEST] <BtbN> Using a bunch of deprecated defines that got removed
[18:12:08 CEST] <BtbN> ones without AV_ prefix
[18:12:17 CEST] <wm4> wow they only had a decade to fix this
[18:12:26 CEST] <BtbN> And a lot of other stuff
[18:12:38 CEST] <durandal_1707> atomnuker: see ml, there is crash in dcaenc
[18:13:36 CEST] <ubitux> https://github.com/ubitux/FFmpeg/blob/nlmeans-dsp/libavfilter/aarch64/vf_nlmeans_neon.S
[18:13:45 CEST] <ubitux> suggestions for acc_sum_store welcome
[18:14:01 CEST] <ubitux> i could probably make use of random other registers to help with pairing
[18:14:16 CEST] <durandal_1707> i think C code is very slow, there are better implementations
[18:14:49 CEST] <durandal_1707> or defaults are simply too strong...
[18:15:18 CEST] <ubitux> i made a faster C version
[18:15:42 CEST] <ubitux> but simd is still much faster
[18:16:14 CEST] <ubitux> https://github.com/ubitux/FFmpeg/blob/nlmeans-dsp/libavfilter/aarch64/vf_nlmeans_init.c#L72
[18:16:23 CEST] <ubitux> this one is relatively faster than current naive C
[18:16:43 CEST] <ubitux> (unrolled but mainly a different algorithm, typically what i do in simd)
[18:16:54 CEST] <ubitux> (except 16 instead of 8)
[18:17:24 CEST] <durandal_1707> how much faster?
[18:20:18 CEST] <ubitux> 49317.0 old c, 46343.0 new c, 28219.5 neon
[18:20:38 CEST] <ubitux> (sorry not the same magnitude as previously, i forgot what settings i was testing)
[18:22:15 CEST] <jamrial> BtbN: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gst-libav&id=e3b49f937a40df4a5861fb96c38a86bfebdb3b97 Arch gst-libav maintainer just said "fuck it, no system libraries"
[18:22:31 CEST] <jamrial> probably because it wasn't fixed by gst-libav itself
[18:23:40 CEST] <ubitux> durandal_1707: found back previous settings: 360552.5 old c, 340711.0 new c, 213613.2 neon
[18:26:04 CEST] <durandal_1707> ubitux: well, i got several milliions cycles in antother part of code
[18:26:34 CEST] <ubitux> yeah that's not surprising
[18:26:55 CEST] <ubitux> it's not meant for real time
[18:42:43 CEST] <durandal_1707> ubitux: others nlmeans filters are realtime, even purce C versions
[18:53:52 CEST] <durandal_1707> what about colorize filter, this one would colorize gray images, with set hue, saturation, lightness?
[19:27:55 CEST] <ubitux> durandal_1707: are you saying the ffmpeg nlmeans is much slower than other implementations?
[19:28:16 CEST] <ubitux> (can you provide numbers?)
[19:28:47 CEST] <atomnuker> durandal_1707: -devel? I don't see it
[19:29:27 CEST] <durandal_1707> atomnuker: -user
[19:29:41 CEST] <durandal_1707> ubitux: the old handbrake filter
[19:32:42 CEST] <ubitux> with+without its asm disabled and comparable settings?
[19:34:33 CEST] <durandal_1707> i tried it long ago, and was pretty fast
[19:35:36 CEST] <ubitux> the settings have a large influence on the speed
[19:36:08 CEST] <ubitux> changing the research window and patch size can be night & day
[19:36:46 CEST] <ubitux> i've followed the ipol suggestions, they may not be the most appropriate settings
[20:13:34 CEST] <durandal_1707> ubitux: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=4883 it is 5x times slower
[20:14:03 CEST] <ubitux> interesting
[20:14:18 CEST] <ubitux> any idea how i can test handbrake?
[20:14:30 CEST] <ubitux> i mean, bench
[20:17:15 CEST] <durandal_1707> you could build ffmpeg with this one: https://github.com/farindk/ffmpeg/blob/master/libavfilter/vf_nlmeans.c
[20:20:10 CEST] <ubitux> ffmpeg from 2014? yeah nah, i'll pass
[20:20:26 CEST] <ubitux> anyway, i'll just work on making it faster
[20:21:14 CEST] <ubitux> maybe i'm doing something stupid but i can't see how it could be significantly slower with comparable settings
[20:21:25 CEST] <ubitux> maybe the threading i did wasn't smart, dunno
[20:23:14 CEST] <ubitux> i'll make the unsafe version faster
[20:23:27 CEST] <ubitux> the integral in simd will help also
[20:24:00 CEST] <ubitux> then 65% of the time seems spent in nlmeans_slice
[20:26:43 CEST] <durandal_1707> ubitux: also the noise is not removed as good as other filter
[20:27:28 CEST] <durandal_1707> with same settings, range, and patch size, and different strength
[20:33:03 CEST] <ubitux> ah? maybe there is a bug?
[20:35:43 CEST] <durandal_1707> ubitux: i have downloaded orig pngs
[20:37:49 CEST] <jamrial> jkqxz: ping
[20:43:02 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:a1c6fc773f94: mpegvideo: remove support for libxvid's RC system
[20:43:03 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:c1b282dc74d8: dcaenc: fix segfault when attempting to encode with invalid samplerate
[20:48:45 CEST] <JEEB> what's the way to add pkg-config checks for check_lib things?
[20:48:56 CEST] <JEEB> because it seems like require_pkg_config does die?
[20:49:35 CEST] <JEEB> because I'm getting kind of tired of having to add extra-cflags/ldflags for my (say) mingw-w64 prefix just because the zlib pc file isn't being utilized
[20:49:55 CEST] <JEEB> (yes, zlib comes with a seemingly working pc file, for the horror)
[20:52:00 CEST] <JEEB> I guess I'll just try and see how it goes
[20:52:58 CEST] <jamrial> JEEB: check_pkg_config
[20:53:44 CEST] <JEEB> wonder how I missed that
[20:53:52 CEST] <ubitux> durandal_1707: https://paste.ee/p/f4oaU
[20:53:57 CEST] <JEEB> oh, and I had just copy-pasted it from the fdk-aac check
[20:53:58 CEST] <JEEB> lal
[20:53:59 CEST] <ubitux> stupid shit like this seems to improve performance for me
[20:54:53 CEST] <ubitux> i'll make a few other speedups and send a patchset maybe tomorrow
[20:55:00 CEST] <durandal_1707> ubitux: yes, but by how much? compilers are dumb
[20:55:36 CEST] <durandal_1707> actually i can not reproduce quality stuff, because he uploaded jpgs
[20:55:44 CEST] <ubitux> it went from about 62% to 59.9% time spent in that function
[21:00:56 CEST] <ubitux> i'
[21:01:05 CEST] <ubitux> i'm curious how x86 simd will help here
[21:01:23 CEST] <ubitux> pretty sure it will be more efficient than on these shitty board
[21:01:41 CEST] <ubitux> where it's probable the memory bus is saturated
[21:04:02 CEST] <jamrial> atomnuker: you forgot to add the deprecated avoption flag as i told you
[21:04:58 CEST] <durandal_1707> ubitux: the other nlmeans filter is about 30% faster than yours, with just C, looks like slice threading doesnt help much
[21:06:13 CEST] <ubitux> with same settings?
[21:06:20 CEST] <durandal_1707> yes
[21:06:27 CEST] <ubitux> is it processing the same pixel format as input?
[21:06:32 CEST] <durandal_1707> yes
[21:06:48 CEST] <ubitux> well, if you can figure out why&
[21:07:02 CEST] <durandal_1707> try nlmeans=threads=X and you will see no big gain
[21:07:14 CEST] <ubitux> ok
[21:09:01 CEST] <ubitux> speed=0.612x vs speed=0.451x here with threads=1 vs threads=8
[21:09:14 CEST] <ubitux> (./ffmpeg -lavfi testsrc2=d=5,nlmeans=threads=X -f null -)
[21:09:19 CEST] <ubitux> not the best comparison
[21:09:26 CEST] <ubitux> but it seems to help a little
[21:09:53 CEST] <ubitux> (i inverted the results, threads=8 is the fastest ofc)
[21:10:32 CEST] <JEEB> yayifications, got my mingw-w64 build to work without manual cflags/ldflags
[21:10:43 CEST] <JEEB> first of course forgot the ;
[21:10:49 CEST] <JEEB> and got my shell derping at myself
[21:12:54 CEST] <JEEB> aand sent
[21:13:36 CEST] <nevcairiel> why did you need special cflags before
[21:14:12 CEST] <JEEB> if your cross-prefix is not your sysroot
[21:14:27 CEST] <JEEB> if you f.ex. use the distro toolchain
[21:14:49 CEST] <JEEB> so I have the toolchain and CRT etc under /usr/something_or_another
[21:14:54 CEST] <nevcairiel> oh stupid cross-compilation
[21:15:04 CEST] <JEEB> and then I have my own stuff including zlib under /home/jeeb/blah
[21:15:14 CEST] <JEEB> because I don't want to mix that stuff up, of course
[21:16:47 CEST] <JEEB> I hope that stupid cross-compilation didn't mean my way of keeping my own things and sysroot separate is dumb?
[21:17:01 CEST] <nevcairiel> no just that i find cross-compilation dumb :p
[21:17:02 CEST] <JEEB> because I just like to have those two separate
[21:17:05 CEST] <cone-295> ffmpeg 03Rostislav Pehlivanov 07master:d05c3b9ceeb9: mpegvideo: add deprecated flags to the rc_strategy option
[21:17:08 CEST] <JEEB> heh
[21:17:10 CEST] <atomnuker> jamrial: sorry, I forgot
[21:21:47 CEST] <JEEB> nevcairiel: let's just say I disliked the waiting times before, and I dislike them even more now
[21:22:10 CEST] <wm4> does mingw use dash?
[21:22:16 CEST] <JEEB> you can use it
[21:22:19 CEST] <JEEB> msys comes with it
[21:22:23 CEST] <JEEB> or mingw, whichever it was
[21:22:35 CEST] <nevcairiel> it helps the time, but doesnt eliminate the huge waits from the mess that is configure
[21:22:37 CEST] <JEEB> msys is the environment, mingw has native tools
[21:23:02 CEST] <wm4> lately someone mentioned that dash helps a lot even on linux
[21:23:05 CEST] <JEEB> yea, that's why I just do cross from my fedora VM these days
[21:23:07 CEST] <wm4> (over bash)
[21:23:24 CEST] <JEEB> leads to "oh, my configure is done already? yay"
[21:23:30 CEST] <JEEB> instead of "let me go grab my coffee mug"
[21:24:57 CEST] <jamrial> i have been manually adding shit to config.h/mak lately to avoid having to run configure for 15 min just to add one define for a new filter
[21:25:42 CEST] <jamrial> wish windows 10 would get its shit together and go back to pre CU build process spawn performance
[21:26:09 CEST] <JEEB> I think at that point you might have luck just using WSL and a zipballed MSVC in wine if you were using MSVC
[21:26:10 CEST] <jamrial> maybe this April release that came out last tuesday is the one...
[21:26:16 CEST] <JEEB> I haven't tried yet
[21:26:22 CEST] Action: JEEB did install it on Monday
[21:27:39 CEST] <jamrial> i'm waiting for a stable/whql driver from amd before i install it (they had a beta ready the same day this win10 update came out, but i always skip those)
[21:27:51 CEST] <JEEB> ah
[21:34:29 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:ac86011b1fa7: avfilter/af_amerge: port to activate API
[21:34:30 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:20a3c4f606e7: avfilter: forward status back in some filters that missed it
[21:53:42 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:aef93c6aa572: avutil: add gray14 pixel format
[21:53:43 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:b9dd058f7a9d: swscale: add gray14 support
[21:53:44 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:41ebbae9dd65: avfilter/vf_extractplanes: add support for extracting planes with 14 depth
[21:53:45 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:72b29c02f4ba: avfilter/drawutils: support gray14
[22:04:06 CEST] <durandal_1707> shit, all code convoluted, managed to break fate again
[22:06:02 CEST] <JEEB> congratulations. sounds like we need something like oracle if you don't have space/cpu time to run FATE yourself
[22:06:13 CEST] <JEEB> so you can push your WIP branch there
[22:07:12 CEST] <atomnuker> fate runs as quick as configure here
[22:07:42 CEST] <atomnuker> well, maybe 3x slowr, still not much, just a few minutes
[22:07:45 CEST] <cone-295> ffmpeg 03Paul B Mahol 07master:a26367493c13: fate: update pad pixfmt test
[22:28:25 CEST] <jamrial> nevcairiel: do you know if access() is available in msvc?
[22:31:42 CEST] <jamrial> mmh, we seem to check for access() in configure
[23:25:16 CEST] <JEEB> michaelni: for you the numbers you add up for those checks might be obvious, but I'd recommend adding the actual ideas behind them as a comment or so
[23:40:36 CEST] <michaelni> JEEB, ok, will fix that
[23:40:51 CEST] <JEEB> cheers
[23:45:53 CEST] <wm4> in general it seems better to put a comment instead of a log message
[00:00:00 CEST] --- Sun May  6 2018