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

[burek]

[00:12:50 CET] <nevcairiel> Eh why is Trac so dumb, if you write a comment while someone edits the post, it reverts the edit automatically
[00:14:05 CET] <BtbN> Probably to prevent a seemingly nonsensical reply?
[00:16:57 CET] <nevcairiel> Apparently it basically submits the state of the entire ticket instead of just adding a comment
[00:18:12 CET] <BtbN> hm, I'm 90% sure I have seen it reject comments from me, showing me a "changes were made since you started writing, review please".
[00:19:26 CET] <nevcairiel> I think it did that async right as I was pressing the button, so I basically "reviewed"
[00:21:55 CET] <jamrial> that's not a link failure. it's complaining about undeclared functions
[00:22:16 CET] <jamrial> all these are under a OPENSSL_VERSION_NUMBER >= 0x1010000fL check in tls_openssl.c
[00:22:25 CET] <jamrial> so i'd expect it should work...
[00:22:40 CET] <BtbN> I'd guess it's missing an include?
[00:23:22 CET] <jkqxz> Another slightly-incompatible openssl fork?
[00:23:29 CET] <nevcairiel> Perhaps it's using some unsupported version, maybe libressl shit again
[00:23:39 CET] <BtbN> Or they have a completely botched up their openssl, reporting 1.1 version string on a 1.0 one?
[00:24:07 CET] <BtbN> Aren't there various other openssl forks out in the wild?
[00:24:43 CET] <nevcairiel> I guess
[00:25:11 CET] <jamrial> it's windows, and the second pkg-config check succeeded
[00:27:08 CET] <nevcairiel> That build script he uses likely makes its own binaries, so it could still be anything
[00:27:33 CET] <BtbN> On a quick glance at those scripts I cannot see what openssl it uses and where it comes from
[00:42:38 CET] <nevcairiel> seems to use libressl
[00:47:44 CET] <jamrial> so libressl just sets the above define to whatever?
[00:47:57 CET] <BtbN> It just pretends to be OpenSSL
[00:47:59 CET] <BtbN> but isn't
[00:48:02 CET] <BtbN> really great design
[00:48:29 CET] <nevcairiel> even worse, it pretends to be like openssl 2.0 but is stuck with 1.0 API
[00:48:51 CET] <BtbN> Maybe we should add a check to configure to detect libressl, and error out if it's found?
[00:49:13 CET] <BtbN> Until someone feels like actually writing up support for it
[00:49:18 CET] <jamrial> it's a windows build, so just tell him to disable openssl in configure and use schannel
[00:49:32 CET] <jamrial> or to use an actual openssl library
[00:59:21 CET] <cone-470> ffmpeg 03Kaustubh Raste 07master:72dbc610be32: avcodec/mips: Improve avc avg mc 02, 12 and 32 msa functions
[00:59:21 CET] <cone-470> ffmpeg 03Kaustubh Raste 07master:48d77d5cd4ac: avcodec/mips: Improve hevc uni weighted hv mc msa functions
[00:59:21 CET] <cone-470> ffmpeg 03Michael Niedermayer 07master:cf5a6c754aa3: avcodec/gdv: Check compression before allocating frame
[01:00:56 CET] <nevcairiel> the last patch on the ML for adding libressl s upport basically ended with "deal with this in configure, not a jungle of #ifs in the code", and no follow up patches appeared
[01:58:25 CET] <cone-470> ffmpeg 03Luca Barbato 07master:c5c76370ae24: doc: Drop the legacy symlink to README
[01:58:26 CET] <cone-470> ffmpeg 03Memphiz 07master:a970f9de865c: aarch64: vp9: Fix assembling with Xcode 6.2 and older
[01:58:27 CET] <cone-470> ffmpeg 03John Stebbins 07master:713efb2c0d01: movenc: use correct tag list for AVOutputFormat.codec_tag
[01:58:28 CET] <cone-470> ffmpeg 03John Stebbins 07master:f6f86f432fe5: movenc: simplify codec_tag lookup
[01:58:29 CET] <cone-470> ffmpeg 03John Stebbins 07master:1c64bae648ee: movenc: move tags definitions to where they are used
[01:58:30 CET] <cone-470> ffmpeg 03John Stebbins 07master:1ea9b7fdf99b: movenc: write correct format hvcc when tag is hvc1
[01:58:31 CET] <cone-470> ffmpeg 03John Stebbins 07master:84ab1cc437fa: movenc: allow alternative hvc1 h.265 codec tag
[01:58:32 CET] <cone-470> ffmpeg 03James Almer 07master:90adafe6aab8: Merge commit '84ab1cc437fa47a00532f305b9fe15b5b66c8c5e'
[03:19:50 CET] <Zeranoe> There seems to be a growing interest in 10-bit x264/x265 builds. I'm curious if this is something that is justified. Is 10 bit encoding the future or something?
[03:21:18 CET] <atomnuker> yeah, to do HDR you need 10bits, so most HEVC decoders support 10bits
[03:21:37 CET] <jamrial> 10bit h264 is popular with anime. 10bit h265 is used by blu ray uhd and HDR movies
[03:21:50 CET] <atomnuker> yeah, 10bit x264 is only used by fansubbers and the broadcasting industry
[03:22:49 CET] <Zeranoe> Hm, so maybe I should do builds for that
[03:23:52 CET] <Zeranoe> Granted, that'd be five more builds to do. I wish this could be selected at runtime
[03:23:53 CET] <jamrial> x265 supposedly lets you compile 8, 10 and 12 bit support in a single library. x264 should also get that soon(tm)
[03:25:44 CET] <Zeranoe> x264 doesn't do 12-bit right
[03:35:24 CET] <cone-470> ffmpeg 03Martin Storsjö 07master:0671eb2346c1: tls_openssl: Readd support for nonblocking operation
[03:35:25 CET] <cone-470> ffmpeg 03James Almer 07master:eaa25b09e411: avformat/tls_openssl: move some functions up in the file
[03:35:26 CET] <cone-470> ffmpeg 03James Almer 07master:575fc7e80a1b: Merge commit '0671eb2346c17e8fb13784cf90ce416661fdea1c'
[03:43:48 CET] <cone-470> ffmpeg 03Martin Storsjö 07master:eb061ad6fd0e: tls_gnutls: Readd support for nonblocking operation
[03:43:49 CET] <cone-470> ffmpeg 03James Almer 07master:2805c8dcfc3b: Merge commit 'eb061ad6fd0e3cea7cf7cfbff0749bc90dd7d888'
[04:27:20 CET] <cone-470> ffmpeg 03Nicolas Frattaroli 07master:1c06a32cfa57: diracdec: fix deprecated API usage
[13:34:28 CET] <cone-789> ffmpeg 03Nicolas Frattaroli 07master:6a50a8f34016: snowenc: fix use of deprecated API
[15:10:23 CET] <BtbN> Did he seriously attach patches as rtf, or is that track messing up?
[15:10:29 CET] <nevcairiel> he did
[15:26:52 CET] <kierank> durandal_170: LOL
[15:27:57 CET] <durandal_170> kierank: ?
[15:28:04 CET] <kierank> "they don't have lives"
[15:36:43 CET] <gnafu> BtbN, nevcairiel: Haha, wow.
[17:42:42 CET] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/296859024#L588 is this new?
[17:43:35 CET] <nevcairiel> relatively new
[17:44:12 CET] <BtbN> It didn't break in yesterdays cov build
[17:44:19 CET] <BtbN> And the configure line didn't change in months
[17:46:42 CET] <nevcairiel> yeah you can only enable one of those now since some internal symbols otherwise collide
[17:46:49 CET] <nevcairiel> (and its really not useful to enable multiple anyway)
[17:47:06 CET] <BtbN> Well, that means from now on we can only statically analyze one of them
[17:47:28 CET] <nevcairiel> the code for those two is extremely minimal anyway
[17:48:23 CET] <BtbN> Guess openssl is the most widely used one
[18:11:37 CET] <jamrial> BtbN: the two didn't work at the same time even before the commit that made it abort during configure
[18:11:53 CET] <jamrial> configure would arbitrarily and silently disable one of them instead
[18:12:01 CET] <BtbN> Interesting.
[18:12:05 CET] <BtbN> Well, it's openssl now
[18:12:31 CET] <jamrial> ffmpeg would still link to both, but the tls module would just use one
[18:12:40 CET] <BtbN> Well, would both get compiled?
[18:12:54 CET] <jamrial> no
[18:20:16 CET] <BtbN> also, holy shit that android camera API
[18:27:37 CET] <kierank> michaelni: so in a packet with multiple NALs how does your approach find the length of each NAL?
[18:27:46 CET] <kierank> without doing what the google patch did
[18:36:13 CET] <michaelni> The length of a unescaped NAL is smaller or equal to the length of the input (escaped) NAL. The input packet length is the sum of all its escaped NALs, so the sum of all unescaped ones is smaller or equal. for a packet of n escaped NALs you can just allocate the packets length once and all unescaped NALs should fit in it
[18:36:30 CET] <kierank> not in this sample
[18:36:39 CET] <kierank> I do that an it fails
[18:36:47 CET] <kierank> and*
[18:37:17 CET] <kierank> but yes I agree in principle
[18:37:26 CET] <nevcairiel> how would that be, escaping only removes single bytes, never adds any
[18:38:27 CET] <BtbN> you mean unescaping?
[18:39:07 CET] <nevcairiel> yeah
[18:39:15 CET] <kierank> haven't checked the numbers but qualitiatively the packet has a bunch of small NALs and then a large one
[18:39:26 CET] <kierank> so it ends up allocating the entire buffer on each iteration and the blows the allocation
[18:40:10 CET] <kierank> by "allocating the buffer" I mean moves the pointer forward
[18:41:09 CET] <kierank> I guess I can move the pointer forward after the unescape
[18:49:52 CET] <kierank> ok have a possibly working patch, now to try fate
[18:57:51 CET] <kierank> how do I stop fate complaining about  Use of av_clip() where av_clip_intp2() could be used:
[18:57:58 CET] <kierank> not in my code
[18:59:25 CET] <jamrial> kierank: fixing what it complains about :p
[18:59:27 CET] <jamrial> what's the file?
[18:59:37 CET] <kierank> --- ./tests/ref/fate/source     2017-08-27 13:52:07.093928603 +0100
[18:59:37 CET] <kierank> +++ tests/data/fate/source      2017-11-03 17:59:25.365940793 +0000
[18:59:37 CET] <kierank> @@ -30,5 +30,8 @@
[18:59:37 CET] <kierank>  compat/float/float.h
[18:59:37 CET] <kierank>  compat/float/limits.h
[18:59:37 CET] <jamrial> i'll take a look
[18:59:38 CET] <kierank>  compat/nvenc/nvEncodeAPI.h
[18:59:38 CET] <kierank> +libavcodec/h264_mvpred.h
[18:59:39 CET] <kierank> +libavcodec/h264_parse.h
[18:59:39 CET] <kierank> +libavcodec/h264_ps.h
[18:59:40 CET] <kierank>  Use of av_clip() where av_clip_uintp2() could be used:
[18:59:40 CET] <kierank>  Use of av_clip() where av_clip_intp2() could be used:
[18:59:50 CET] <kierank> i don't even know what that means
[18:59:51 CET] <jamrial> that does sound like some change of yours
[19:00:19 CET] <kierank> I don't use clip
[19:00:27 CET] <jamrial> it means you're using av_clip with immediate values as clipping arguments
[19:00:42 CET] <kierank> obe at obe:~/ffmpeg$ git diff HEAD~1 | grep clip
[19:00:42 CET] <kierank> obe at obe:~/ffmpeg$
[19:02:57 CET] <kierank> might be because of my configure i guess
[19:03:01 CET] <jamrial> that's weird, those headers don't even use av_clip
[19:03:25 CET] <ubitux> it's unrelated to av_clip
[19:03:35 CET] <jkqxz> No, it means that those headers fail the test above.  The "Use of av_clip..." notes refer to the lists following them.
[19:03:37 CET] <ubitux> it's probably about the copyright or header protect
[19:03:52 CET] <jamrial> ah right
[19:05:19 CET] <kierank> is there something explaining the failure?
[19:05:46 CET] <jkqxz> Look at the header for the list in the output file.
[19:05:48 CET] <jamrial> as ubitux said, you probably changed the copyright header, or removed/didn't add preprocessor guards
[19:06:03 CET] <kierank> afaik not done anything like that
[19:06:25 CET] <kierank> but I had a slightly limited ./configure so let's see what happens now
[19:06:55 CET] <jamrial> then ignore the fate-source failure for now. it's not important for what you're trying to do and can be looked at once you send the patch
[19:13:50 CET] <kierank> I have hevc failures without my patch...
[19:14:45 CET] <JEEB> \o/
[19:15:16 CET] <jamrial> fate.ffmpeg.org looks clean with git head, so can't be
[19:16:28 CET] <kierank> hehe fate-source errors even on HEAD
[19:16:33 CET] <kierank> must be something related to windows
[19:16:38 CET] <kierank> and linux line endings
[19:17:06 CET] <jamrial> what are you using? msys2, cygwin?
[19:17:16 CET] <jamrial> msys2 works fine here
[19:17:42 CET] <kierank> linux x64
[19:17:47 CET] <kierank> but copying from my windows pc
[19:17:51 CET] <jamrial> ah
[19:18:22 CET] <jamrial> kierank: sed -i -e 's/\r//' file
[19:21:59 CET] <kierank> still random fate failures
[19:22:40 CET] <durandal_1707> how random?
[19:22:59 CET] <kierank> first hevc, now msvideo1
[19:23:11 CET] <kierank> gonna send patch anyway
[19:23:20 CET] <kierank> jamrial: and will send to libav even though I would usually not
[19:23:32 CET] <durandal_1707> msvideo1? lol
[19:35:15 CET] <jamrial> kierank: fate-h264 and fate-hevc pass with your patch here, with one and four threads, frame and slice
[19:44:50 CET] <BtbN> Hm, I'm tempted to build a tool that auto-converts mailinglist patches to github PRs...
[19:45:15 CET] <BtbN> There's tons of "free for open source" CI services. But all tied into Github
[19:49:28 CET] <JEEB> yea :/
[19:49:38 CET] <JEEB> or gitlab, but that's largely the same
[19:50:43 CET] <BtbN> I guess it's a better first step to setup a github repo where you can send PRs to, and have them tested
[19:51:52 CET] <BtbN> ffmpeg even already has a .travis.yml that seems to work
[19:52:39 CET] <BtbN> Should probably not do that on FFmpeg/FFmpeg. That would cause mass confusion
[19:53:12 CET] <BtbN> It would be by far the easiest though
[21:19:24 CET] <cone-789> ffmpeg 03Paul B Mahol 07master:1f24b33d9af8: avfilter/vf_tile: remove limit of max tile size
[00:00:00 CET] --- Sat Nov  4 2017