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

[burek]

[00:01:39 CET] <atomnuker> wm4: did you see the new edit list patch from savi on the ml?
[02:10:28 CET] <FishPencil> Is there a replacement for --enable-verbose-build ?
[02:16:08 CET] <FishPencil> I guess make V=1 works
[03:21:42 CET] <cone-729> ffmpeg 03Michael Niedermayer 07master:25d9643f1172: avcodec/mjpegdec: Check for rgb before flipping
[03:58:28 CET] <Zeranoe> Is there a reason $(SRC_PATH) is used here https://github.com/FFmpeg/FFmpeg/blob/master/configure#L6415 and not just "src/compact/.."? 
[04:30:34 CET] <Zeranoe> I guess that goes for everything, why isn't $source_path being set to "src" instead of the absolute path
[05:23:16 CET] <Compn> Zeranoe : someone remarked that hevc decoding was slower on your 32bit v 64bit builds... JEEB says this is just because of a lack of 32bit simd. do you have any comment ?
[05:23:48 CET] <Zeranoe> Compn: How much slower we talking?
[05:24:17 CET] <Compn> [04:18] <fritsch> we found that the x64 bit version of ffmpeg (zerone build) is roughly 2 times faster when doing hevc decoding
[05:24:40 CET] <Compn> pretty sure "zerone" is you , but i could be wrong :D
[05:25:45 CET] <Compn> 2x slower sounds like problem to me though
[05:26:11 CET] <Zeranoe> Compn: Did they mention their testing methods?
[05:26:30 CET] <Compn> [04:20] <fritsch> download zerone's 32 bit build and his 64 bit build
[05:26:30 CET] <Compn> [04:20] <fritsch> take this sample:
[05:26:30 CET] <Compn> [04:20] <fritsch> http://fritsch.fruehberger.net/samples/future-live-tv-hevc-10bit.ts
[05:26:30 CET] <Compn> [04:20] <fritsch> and run:
[05:26:35 CET] <Compn> [04:21] <fritsch> ffmpeg -i future-live-tv-hevc-10bit.ts -f null -
[05:26:55 CET] <Compn> [04:23] <nevcairiel> for h264, which is more thoroughly simd'ed even on 32-bit, the difference is around 10%
[05:27:53 CET] <Compn> just wondering if you could test with an old build to make sure its not a regression or something
[05:28:28 CET] <Zeranoe> Compn: I'm going to test on 32 and 64-bit linux's first
[05:28:36 CET] <Compn> no problem
[05:29:52 CET] <Compn> its probable that what nevcairiel and JEEB were saying at the time is correct. that the simd was written in 64bit arch, and no one bothered with x86, and that is the only difference in speed
[05:30:50 CET] <Zeranoe> I can't fault that though, if you're going to focus on one thing make it 64-bit instead of 32
[05:30:57 CET] <Compn> right
[05:31:07 CET] <Compn> im not saying its wrong or anything. just want to verify not a regression 
[05:31:15 CET] <Compn> and fritsch is the kodi person , so its kind of important for users to know 32bit limitations
[05:32:57 CET] <Compn> millions of users :D
[07:05:54 CET] <Zeranoe> Compn: I haven't run the numbers yet, but I'm seeing an almost double framerate processing speed between 32-bit and 64-bit
[10:13:24 CET] <wm4> atomnuker: no
[12:08:51 CET] <cone-304> ffmpeg 03Carl Eugen Hoyos 07master:5ff6e8790a2c: doc/filters: Slightly improve the smartblur documentation.
[13:04:32 CET] <cone-304> ffmpeg 03Clément BSsch 07master:771b3a956e0c: lavfi/selectivecolor: rename adjust_range to scale
[13:13:03 CET] <cone-304> ffmpeg 03Michael Niedermayer 07master:af7a75cb5171: configure: Check build with some header not just preprocessing for testing --std=c11
[15:00:04 CET] <Compn> Zeranoe : ok thanks for testing. then its not your builds fault :D
[15:07:39 CET] <Compn> if you do make a benchmark, any chance for making a trac for it? there maybe some crazy people out there who want to create some x86 simd for hevc...
[15:08:00 CET] <Compn> at least there are still quite a few people running 32bit OS ;P
[15:09:54 CET] <JEEB> mostly windows
[15:10:17 CET] <JEEB> but yeah, it should have been pretty obvious that we just have less SIMD for 32bit x86
[15:10:27 CET] <JEEB> so I dunno why you were requesting a test or something (?)
[15:10:50 CET] <JEEB> but sure, if someone cares about it an issue can be made so someone who cares might make SIMD
[15:11:32 CET] <Compn> just making sure it wasnt a regression or a problem with Zeranoe's builds. 2x slower is a big deal to people :P
[15:13:14 CET] <Compn> no harm in testing... or spreading the word that 32bit hevc is slower at the moment
[15:16:14 CET] <Compn> Zeranoe provides support for his builds on his support forum. so its also good if he knows the limitations of the decoder
[15:17:22 CET] <JEEB> given that it's been the case since like ~2013-4 or so and nevcairiel's fork's stuff is probably one of the most used things around places I thought it was pretty much common knowledge at this point :P
[15:18:07 CET] <Compn> the original reporter was the kodi dev, so no, it wasnt common knowledge (or we all forgot)
[15:18:35 CET] <Compn> how is downstream to know our common knowledge? :D
[15:18:50 CET] Action: Compn wants to write index page entry about hevc decoder :P
[15:19:32 CET] <JEEB> with the downstream it's even more apparent due to the openhevc SIMD
[15:19:34 CET] <JEEB> methinks
[15:20:38 CET] <Compn> does ffmpeg have openhevc wrapper ?
[15:21:31 CET] <JEEB> openhevc is lavc
[15:21:44 CET] <JEEB> they just have their intrinsics which will never get put into FFmpeg
[15:21:59 CET] <JEEB> nev just applies some of the user intrinsics they have
[15:22:20 CET] <Compn> ok, i dont remember nev's fork
[15:22:39 CET] <Compn> or what its called or where it is :P
[15:22:40 CET] <JEEB> http://git.1f0.de/gitweb?p=ffmpeg.git;a=shortlog;js=1
[15:22:45 CET] <JEEB> it's used in LAV Filters
[15:22:52 CET] <Compn> yea i know he runs lav filters
[15:22:54 CET] <JEEB> which is pretty widely used on the most used 32bit env :P
[15:24:04 CET] <JEEB> the hevc: port ones
[15:24:12 CET] <JEEB> intra pred and IDCT
[15:24:56 CET] <Compn> ok thanks
[15:26:20 CET] <Compn> https://haasn.xyz/posts/2016-11-08-ffmpeg-hevc-decoding-benchmarks.html
[15:26:27 CET] <Compn> hehe haasn
[15:26:33 CET] Action: Compn afk
[16:17:29 CET] <BBB> haasn: the reason intra pred simd doesnt help is b/c most intra pred is dc, and dc is very trivial in c or simd
[16:17:39 CET] <BBB> haasn: runtime of dc C vs. idct C is like 1:10 or so
[16:17:57 CET] <BBB> haasn: directional intra pred is more complicated, but runs sparsely
[16:18:22 CET] <BBB> (from my memory)
[16:52:11 CET] <haasn> BBB: I did a `perf` and the most time was spent in that hevc_cabac function
[16:52:12 CET] <haasn> or w/e
[16:55:49 CET] <BBB> haasn: yeah thats residual decoding, that is normal
[16:55:57 CET] <BBB> haasn: unfortunately not really simd'able
[16:56:03 CET] <BBB> I guess you can try simding the bypass function
[16:56:06 CET] <BBB> but thats hard
[16:56:10 CET] <BBB> and I Dont care about hevc ;)
[16:56:48 CET] <durandal_170> write simd for some filters
[16:56:58 CET] <haasn> also kyaa, stop cyberstalking me Compn
[16:57:38 CET] <durandal_170> Compn is ultimate stalker
[17:20:20 CET] <cone-304> ffmpeg 03Thomas Turner 07master:11b7cad3dc17: avutil/tests/audio_fifo.c: use av_malloc() family of functions
[17:20:21 CET] <cone-304> ffmpeg 03Thomas Turner 07master:1bfb4587a2e5: avutil/tests/audio_fifo.c: Memory leak and tab space fixes
[17:20:22 CET] <cone-304> ffmpeg 03Moritz Barsnick 07master:6c442e158459: lavc/libmp3lame: add support for cutoff
[17:20:23 CET] <cone-304> ffmpeg 03Moritz Barsnick 07master:5dbce5120b4e: doc: document cutoff option to ac3 and adjust the option's global documentation
[17:20:24 CET] <cone-304> ffmpeg 03Michael Niedermayer 07master:7525517593df: libavutil/random_seed: Ensure that get_generic_seed() spends at least 1/32 sec gathering entropy
[17:47:08 CET] <Zeranoe> Any thoughts on why $source_path is not being set to src instead of the absolute path? I'm thinking about writing a patch to switch this, but there might be a reason.
[17:48:09 CET] <BtbN> because out-of-tree builds exist I guess
[17:48:28 CET] <Zeranoe> BtbN: But src is a symbolic link to the actual source
[17:48:48 CET] <BtbN> And what happens on systems that don't support symbolic links?
[17:49:11 CET] <Zeranoe> BtbN: The current system would fail
[17:49:53 CET] <Zeranoe> BtbN: Also, what systems don't support symbolic links
[17:50:28 CET] <BtbN> Windows for instance
[17:50:54 CET] <BtbN> And there are some more exotic ones ffmpeg supports, like OS/"
[17:50:55 CET] <Zeranoe> BtbN: Complication is broken with MSVC right now because it's using the absolute path :)
[17:52:23 CET] <Zeranoe> I was able to build within the source with Cygwin, but not outside
[19:47:30 CET] <Compn> windows ntfs has some links , called junctions
[19:47:33 CET] Action: Compn runs
[20:00:50 CET] <nevcairiel> Msvc builds work fine for me
[20:01:16 CET] <nevcairiel> But I use msys, not broken cygwin
[20:02:23 CET] <nevcairiel> My fate boxes test it all the time after all, out of tree as well
[20:06:02 CET] <JEEB> it's usually cygwin vs windows full paths I guess
[20:06:17 CET] <nevcairiel> And windows does in fact not support symlinks, not in the Linux sense
[20:06:29 CET] <nevcairiel> Although cygwin might emulate them badly
[20:06:42 CET] <JEEB> cygwin tends to not try to convert the paths in certain cases where msys does
[20:06:53 CET] <JEEB> (the logic of either is something I have no idea of)
[20:06:54 CET] <nevcairiel> Cygwin is really designed to work inside itself, not call out to windows apps
[20:06:57 CET] <JEEB> yes
[20:13:47 CET] <Compn> do we even support cygwin ?
[20:14:52 CET] <JEEB> cygwin builds should work. but it's an environment, and building for something else within it is up to the user to make sure it works :P
[20:17:50 CET] <Compn> yeah i just meant cygwin itself with the cygwin1.dll
[20:17:56 CET] <Compn> not mingw in cyg
[20:43:03 CET] <jamrial> Compn: afaik yes, we support targetting cygwin's gcc
[20:43:51 CET] <jamrial> although i remember it being a pita since it didn't define _WIN32 or some such
[23:41:14 CET] <Gaming4JC> Hey guys, since AVStream.codec is deprecated what is the new replacement for FF_CODEC_PROPERTY_CLOSED_CAPTIONS? And/or have any bugs been open about already?
[23:41:30 CET] <Gaming4JC> it's a very useful feature for the hearing impared.
[23:41:49 CET] <Gaming4JC> about it *
[00:00:00 CET] --- Sun Jan  1 2017