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

[burek]

[01:38:47 CEST] <TD-Linux> atomnuker, could you perhaps contain your hate for other open source projects that happily accept patches?
[02:03:51 CEST] <atomnuker> okay, I guess I'm wrong, they do use an external project for mp4 parsing
[02:07:23 CEST] <atomnuker> still, submitting a patch that affects 2 departments (decoding/rendering) would be an incredible amount of work
[02:08:39 CEST] <atomnuker> the plan to use libplacebo for eventual hdr/tonemapping seems like a pipe dream
[02:23:47 CEST] <TD-Linux> it would be difficult, just because there are so many compositors. You'd either have to pick one compositor to start with, or have libplacebo render to a texture
[02:26:21 CEST] <cone-398> ffmpeg 03Shiyou Yin 07master:2b646dac78d4: avcodec/mips: [loongson] refine ff_vc1_inv_trans_8x8_mmi.
[02:26:21 CEST] <cone-398> ffmpeg 03Michael Niedermayer 07master:3d201b83cda0: avcodec/zmbv: Update decomp_len in raw frames
[02:26:21 CEST] <cone-398> ffmpeg 03Michael Niedermayer 07master:e33b28cc79d1: avcodec/zmbv: Check that the decompressed data size is correct
[07:40:47 CEST] <Yagiza> Do I have to create an issue about inability to use SRTP with custom I/O? Or it considered not a bug?
[07:42:39 CEST] <nevcairiel> its not really a bug
[07:43:33 CEST] <nevcairiel> custom IO expects clear data. if you want decryption, either do that on your side, or use the proper protocols in avformat that handle that, instead of replacing them
[07:43:57 CEST] <Yagiza> nevcairiel, well
[07:44:18 CEST] <Yagiza> nevcairiel, I need using custom I/O in my project.
[07:44:29 CEST] <nevcairiel> then you need to perform decryption on the data yourself.
[07:45:12 CEST] <nevcairiel> you could open a ticket, but its a feature request, not a bug, and one that would require huge architectural changes, so at the end of the day you'll have to figure out something with the current situation anyway
[07:46:02 CEST] <Yagiza> nevcairiel, but FFMpeg libraries do have code for SRTP encryptions/decryption. And I can't use that code just because of FFMpeg ogranization flaws.
[07:47:07 CEST] <Yagiza> nevcairiel, so, creating of an issue is encouraged anyway?
[16:05:26 CEST] <BtbN> Nvidia claims that nvenc on turing has a better snr than x264 fast preset, at the same bitrate.
[16:10:48 CEST] <gnafu> But does it /look/ better?
[16:12:03 CEST] <BtbN> Give me a Turing card and I'll tell you :P
[16:19:13 CEST] <gnafu> Hehe.
[18:08:22 CEST] <cone-641> ffmpeg 03Carl Eugen Hoyos 07master:26902f2ef0dc: lavf/webvttenc: Always write hours in the timestamp with two characters.
[18:15:11 CEST] <cone-641> ffmpeg 03Carl Eugen Hoyos 07master:1ba32a3c464a: lavd/dshow: Interpret negative height as bottom-down frame.
[18:15:12 CEST] <cone-641> ffmpeg 03Carl Eugen Hoyos 07master:076558a9f403: Cosmetics: Reindent after last commit.
[18:21:58 CEST] <cone-641> ffmpeg 03Zhao Zhili 07master:0d7a75e848c3: avfilter/vf_sr: fix read out of bounds
[18:21:59 CEST] <cone-641> ffmpeg 03Zhao Zhili 07master:5dad51437916: avfilter/dnn_backend_native: fix invalid free
[18:22:00 CEST] <cone-641> ffmpeg 03Zhao Zhili 07master:cd732ac47280: avfilter/dnn_backend_native: fix memleak
[18:51:00 CEST] Action: durandal_1707 waits 5 minuts for eclipse to open project file
[18:52:52 CEST] <cone-641> ffmpeg 03Shiyou Yin 07master:ba175578d14e: avcodec: [loongson] optimize get_cabac_inline.
[19:00:33 CEST] <kierank> durandal_1707: eclipse?
[19:00:36 CEST] <kierank> are you on drugs?
[19:03:03 CEST] <durandal_1707> kierank: i'm officially now java developer
[19:03:26 CEST] <kierank> ok
[19:06:15 CEST] <atomnuker> VDD 2018 - Internet: Please bring your own internet.
[19:06:19 CEST] <atomnuker> Eh?
[19:07:14 CEST] <gnafu> atomnuker: Yeah, you know.  Pick one up at your local supermarket before you come if you expect to need it.
[19:07:17 CEST] <gnafu> ;-)
[19:07:51 CEST] <jamrial> atomnuker: aka, hope your cellphone plan has roaming data plan outside your country i guess :p
[19:07:57 CEST] <atomnuker> I'll bring an rj45 cable to jack into any system I feel like
[19:08:22 CEST] <atomnuker> jamrial: haha, not a problem for me, EU has had no roaming for a few years now
[19:08:41 CEST] <atomnuker> doesn't help non-business UK data plans are burning a hole in your wallet
[19:20:24 CEST] <nevcairiel> until we k ick the UK out of all such arrangements =p
[19:22:56 CEST] <kierank> nevcairiel: we kick ourselves out of these arrangements it seems
[22:02:06 CEST] <JEEB> NDK R18 is out and GCC is removed
[22:05:23 CEST] <gnafu> Interesting.  What are the implications there?  How big of a deal is that going to be for the average Android developer?
[22:06:58 CEST] <JEEB> not sure, they haven't updated their GCC in ages, so effectively if you never tried clang it's "too bad"
[22:07:28 CEST] <JEEB> I've been using the NDK clang for quite a while and it didn't seem any worse
[22:08:47 CEST] <jamrial> the average android dev probably doesn't even use the NDK
[22:09:14 CEST] <gnafu> Aah.
[22:09:24 CEST] <kierank> durandal_1707: will you RE Blackmagic RAW
[22:19:43 CEST] <durandal_1707> kierank: yes, you gave me 10k eur, almost finished it
[22:37:10 CEST] <durandal_1707> kierank: which codecs you will put in nttw3 slides?
[22:38:08 CEST] <kierank> Cineform, mpeg4 sstp and my memory card RE project
[22:38:17 CEST] <kierank> But dunno about other codecs
[22:40:47 CEST] <BtbN> The fun part is that many android devices still compile their kernel with gcc and explode when using clang.
[22:45:01 CEST] <JEEB> did the android kernel ever work with clang?
[22:45:03 CEST] <JEEB> OOTB
[22:45:39 CEST] <durandal_1707> kierank: put my codecs too
[22:47:15 CEST] <TD-Linux> firefox constantly exposes crashes in the ndk clang, enough that I think we use our own clang now
[22:53:05 CEST] <wbs> TD-Linux: doing a nightly build of clang (with asserts enabled) and building firefox with it probably would be good to keep that from regressing
[22:55:08 CEST] <TD-Linux> in fact I think that's already done
[22:57:15 CEST] <wbs> ok, good, good. with the build times of llvm (30-40 min on my build machine) combined with the rate of change (there are multiple changes every day that trigger rebuilding most of it), making bisecting rather painful (scripting it with git bisect is pretty much mandatory, and takes half a day to complete for me unless the range is on the level of a few days)
[22:58:59 CEST] <TD-Linux> I'll have to try ndk 18 with firefox, 15b works but 16 and 17 were both broken for different reasons
[23:00:17 CEST] <wbs> at work we struck a super funny bug in clang in the NDK; it miscompiled code for arm64, but only if you crosscompiled _from_ windows. not from linux/macos
[23:00:29 CEST] <JEEB> funky
[23:00:40 CEST] <JEEB> so the win64 binaries had something funky in the code generation?
[23:00:49 CEST] <wbs> it took a day of bisecting, but I finally found something that had slip in a "long" for something that should be int64_t
[23:00:57 CEST] <durandal_1707> atomnuker: do you want to try afftdnoiz?
[23:01:03 CEST] <JEEB> wbs: classic :)
[23:02:36 CEST] <wbs> https://github.com/llvm-project/llvm/commit/623692ec9cd5fd1dd90ef0fb66846430134111f9
[23:13:13 CEST] <atomnuker> durandal_1707: sure, push it somewhere
[23:14:59 CEST] <durandal_1707> atomnuker: its on github
[23:36:50 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:86e76762fc73: avcodec/av1_parse: Fix bistream typo
[23:36:50 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:7ed8d5cfd94a: avcodec/pcx: Check for end of input in pcx_rle_decode() and propagate error
[23:36:50 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:fb7b0347b331: avcodec/mpeg4videodec: Check rice_prefix_code
[23:36:50 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:c88afa44c482: avcodec/mpeg4videodec: Fix undefined shift in get_amv()
[23:36:50 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:e7b023e1db9f: avcodec/dvdsubdec: Sanity check len in decode_rle()
[23:37:29 CEST] <kierank> michaelni: surely that's a bug or lack of clarity in get_unary doc
[23:37:32 CEST] <kierank> docs
[23:51:01 CEST] <michaelni> kierank, ill post a patch to improve get_unary() docs
[00:00:00 CEST] --- Thu Sep 20 2018