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

[burek]

[00:00:29 CEST] <nevcairiel> isnt value 13 sRGB (AVCOL_TRC_IEC61966_2_1) - IEC 61966-2-1 (sRGB or sYCC)
[00:03:29 CEST] <durandal_1707> srgb is supported already
[00:04:51 CEST] <wm4> nevcairiel: hm right
[00:04:56 CEST] <wm4> we use that too
[00:05:09 CEST] <wm4> could use a nicer alias I guess
[00:17:22 CEST] <nevcairiel> for that matter, that one is already hooked up in vf_zscale
[00:18:28 CEST] <thebombzen> I had no idea that sRGB was IEC 61966-2-1
[00:18:42 CEST] <thebombzen> maybe srgb as an alias, or at least add that to the documentation
[00:21:22 CEST] <nevcairiel> technically it is in the docs, at least the header and the doxygen
[00:32:32 CEST] <llogan> thebombzen: feel free to mention it in filters.texi if you like
[00:32:49 CEST] <thebombzen> yea tha'ts what I meant.
[00:33:16 CEST] <thebombzen> I'll patch filters.texi to say "note: iec61966-2-1 is another name for sRGB."
[00:33:40 CEST] <thebombzen> unless it's actually added as an alias
[00:34:20 CEST] <nevcairiel> that seems weird and non-standard, should just write "IEC 61966-2-1 (sRGB or sYCC)" in there like in the header file and the 23001-8 spec
[00:39:48 CEST] <thebombzen> that works, although the filters don't have descriptions
[00:41:59 CEST] <llogan> an alias doesn't seem like a bad idea to me
[01:11:48 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e38f280fece3: avcodec/mpeg4videodec: Use 64 bit intermediates for sprite delta
[01:11:50 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:127a362630e1: avcodec/mpeg_er: Clear mcsel in mpeg_er_decode_mb()
[01:11:50 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:bdee75a4e750: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_53iL0()
[01:11:51 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:c20f4fcb74da: avcodec/ffv1dec: Fix out of array read in slice counting
[01:11:52 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:56822b074b50: avcodec/mips: preload data in hevc sao edge 135 degree filter msa functions
[01:11:54 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:af9433b1d687: avcodec/mips: Improve avc bi-weighted mc msa functions
[01:11:54 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:b59323cb72c5: avcodec/mips: Improve avc chroma hv mc msa functions
[01:11:55 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:662234a9a22f: avcodec/mips: Improve avc put mc 21, 23 and 02 msa functions
[01:11:56 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:eadb91164324: avcodec/mips: Improve hevc uni-w horiz mc msa functions
[01:11:57 CEST] <cone-629> ffmpeg 03Kaustubh Raste 07master:ff53f4dc2dd8: avcodec/mips: Improve avc uni copy mc msa functions
[01:11:58 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:832fc05a9bc7: avutil/frame: Fix project name
[01:11:59 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:ed8ff608b2b4: doc/APIchanges: Update
[02:43:37 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e1de9eab3a43: Bump minor versions for branching 3.4
[02:43:38 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:92ae4ab56d0d: doc/APIchanges: Add 3.4 cut point
[02:43:39 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:74d2bbb70dbe: avcodec/opusenc_psy: Fix mixed declaration and statement
[02:43:40 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:7bec3f78da25: avcodec/rkmppdec: check wether typo
[02:44:25 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07release/3.4:HEAD: avcodec/rkmppdec: check wether typo
[02:54:38 CEST] <Zeranoe> What is the primary FFmpeg source repo? http://git.videolan.org/?p=ffmpeg.git https://git.ffmpeg.org/ffmpeg ? The videolan one looks slightly newer
[02:56:02 CEST] <Zeranoe> Actually they look the same now
[03:01:00 CEST] <jamrial> Zeranoe: both are "official", and are always in sync (maybe with a bit of a delay)
[03:02:56 CEST] <Zeranoe> Alright... If I was to pick one which would it be?
[03:03:44 CEST] <michaelni> best to pick what is on our download page
[03:06:23 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:80154b1b3a0a: Bump version for master after 3.4 branchpoint
[03:06:24 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07master:e4d5310a507d: RELEASE: update for git after 3.4 branchpoint
[03:44:07 CEST] <atomnuker> michaelni: what name is 3.4 going to have?
[03:51:12 CEST] <cone-629> ffmpeg 03Michael Niedermayer 07release/3.4:b1ec41a64f2d: add release notes based on release 3.3
[03:52:19 CEST] <michaelni> atomnuker, the one that was suggested (cantor) 
[03:54:45 CEST] <atomnuker> cool
[15:31:28 CEST] <jamrial> ubitux: did you have time to test the merge?
[15:32:07 CEST] <jamrial> i'm mainly interested in being sure the macos stuff still works, but general testing with assorted external libraries would also be nice
[15:41:31 CEST] <ubitux> jamrial: check_apple_framework VideoToolbox "-framework CoreFoundation -framework CoreMedia -framework CoreVideo"
[15:41:34 CEST] <ubitux> this looks weird
[15:41:51 CEST] <ubitux> those are extralibs for the decoder (or encoder), not for the framework itself
[15:42:30 CEST] <ubitux> i can't really test as i won't have access to a macos for about 2 wks
[15:42:49 CEST] <jamrial> ubitux: they are currently set as videotoolbox_extralibs
[15:43:04 CEST] <jamrial> that's why i moved them to the check
[15:43:48 CEST] <jamrial> i can make them extralibs for the decoder/encoder if you prefer. that'll be cleaner as well
[15:43:58 CEST] <jamrial> what about CoreImage?
[15:44:23 CEST] <ubitux> ah indeed that's probably a mistake then
[15:44:56 CEST] <ubitux> jamrial: every framework/dependency is supposed to be independent from each other
[15:45:06 CEST] <jamrial> ok, will make them extralibs for the modules then
[15:45:11 CEST] <ubitux> but our codecs/filters may require more of them
[15:46:12 CEST] <ubitux> what is this libfreetype change?
[15:46:57 CEST] <ubitux> ah actually you're fixing a bunch of inconsistencies
[15:47:19 CEST] <jamrial> the first argument for require/check/use_pkg_config needs to be the same name as the configure module
[15:47:26 CEST] <jamrial> yeah
[15:48:35 CEST] <jamrial> ubitux: there are a lot of videotoolbox modules. hwaccels, encoders... do you know which extralib is for which?
[15:49:10 CEST] <ubitux> you should probably keep the current behaviour, we can fix it later
[15:49:16 CEST] <ubitux> i didn't realize it was already kinda wrong
[15:49:27 CEST] <jamrial> ok
[15:50:15 CEST] <ubitux> --disable-autodetect --enable-libxcb
[15:50:20 CEST] <ubitux> grep LIBXCB config.h
[15:50:23 CEST] <ubitux> is this on purpose ^ ?
[15:50:39 CEST] <ubitux> http://sprunge.us/fAgE
[15:50:54 CEST] <ubitux> maybe that's because of your recent change
[15:51:29 CEST] <ubitux> LIBXCB_{SHM,SHAPE,XFIXES} to 1 doesn't matter if LIBXCB is 0
[15:51:42 CEST] <ubitux> but the other way around is kinda problematic
[15:52:15 CEST] <jamrial> what's the expected behavior of that command line?
[15:52:49 CEST] <ubitux> LIBXCB{,_SHM,_SHAPE,_XFIXES} to 1
[15:52:54 CEST] <jamrial> and wouldn't xcb will compile if those three are 0 but libxcb 1? they are not listed as dependencies of libxcb
[15:53:40 CEST] <ubitux> i would say that you want either libxcb and all its sub deps, or none of them
[15:53:48 CEST] <ubitux> but not a custom subset
[15:54:00 CEST] <ubitux> (unless you don't have them on your system ofc)
[15:54:47 CEST] <ubitux> we should probably hide libxcb-{shm,shape,xfixes} but well
[15:54:50 CEST] <jamrial> ubitux: disable autodetec does a disable_weak on every autodeted module. and every libxcb check is done only after an enabled libxcb_* check
[15:55:27 CEST] <ubitux> it's just kinda weird to have to do enable every libxcb component when you actually want it 
[15:55:40 CEST] <ubitux> anyway, can be changed later, i guess
[15:56:11 CEST] <jamrial> did this change recently? i don't think i altered how these were detected
[15:57:20 CEST] <ubitux> i this shm/shape/xfixes were at 1 with --disable-autodetect --enable-libxcb
[15:57:23 CEST] <ubitux> i think*
[15:58:13 CEST] <ubitux> i'm going to do a few more test
[15:58:15 CEST] <ubitux> +s
[15:58:41 CEST] <ubitux> did you test lavfi with its optionnal deps?
[16:00:14 CEST] <jamrial> which ones? external libraries?
[16:00:49 CEST] <ubitux> if you have filters like afir, lavfi will depend on lavc
[16:01:21 CEST] <ubitux> look for the bunch of prepend avfilter_deps ... in the configure
[16:02:21 CEST] <ubitux> i think these are supposed to show up at some point, somewhere in the build... i don't remember the details
[16:02:29 CEST] <ubitux> maybe in the .pc?
[16:02:44 CEST] <jamrial> in config.mak, avfilter_FFLIBS
[16:03:05 CEST] <jamrial> and yeah, looks like prepend() still adds the library deps just fine
[16:04:02 CEST] <ubitux> they're not supposed to show up in the pc file?
[16:06:09 CEST] <jamrial> yes, they also show up there
[16:07:05 CEST] <ubitux> as Libs?
[16:07:43 CEST] <jamrial> in the requires: line
[16:08:04 CEST] <jamrial> with minimum required version and such
[16:08:55 CEST] <ubitux> but aren't you supposed to have them in the link as well?
[16:10:03 CEST] <ubitux> like, ok you require the other libraries to be installed, but when linking against libavfilter, if it depends on libavcodec for some filter you will also have to raise that flag
[16:10:15 CEST] <ubitux> maybe that's not the case currently though..
[16:13:05 CEST] <ubitux> seems pkg-config understands the current state
[16:13:08 CEST] <jamrial> the .pc file looks the same as before except it now lists only the avfilter extralibs (the point of this patch, basically)
[16:13:09 CEST] <ubitux> you can ignore my comment
[16:13:10 CEST] <jamrial> but since it mentions dependency on the other libraries, linking by using pkg-config should still work the same
[16:13:58 CEST] <ubitux> yeah i tried pkg-config --static --libs libavfilter and it works pretty much fine after post merge
[16:14:06 CEST] <ubitux> anyway
[16:14:10 CEST] <ubitux> i don't see any obvious problem
[16:17:04 CEST] <ubitux> jamrial: you are waiting to apply this after the release?
[16:17:12 CEST] <ubitux> or the release is already branched out?
[16:17:32 CEST] <jamrial> yeah, it's branched out so there's nothing holding this merge
[16:17:46 CEST] <jamrial> other than making sure it works :p
[16:18:11 CEST] <ubitux> yeah i'm not sure about the macos stuff, but i can't test
[18:00:50 CEST] <jamrial> ubitux: pushed a version that's a bit cleaner with the macos stuff
[19:36:26 CEST] <jamrial> ubitux: why is there a videotoolbox_encoder module in configure? it's not used anywhere in the tree and it seems to just add indirection to the whole dep checking process for h264_videotoolbox_encoder
[19:38:37 CEST] <ubitux> jamrial: yeah it's an indirection; but typically you for hevc_videotoolbox_encoder you would depend on it too
[19:38:38 CEST] <wm4> is it for when other codecs might be added?
[19:38:51 CEST] <ubitux> and that would prevent from expliciting again all the deps of the common vt enc code
[19:39:05 CEST] <jamrial> ah, yeah, that's true
[19:39:16 CEST] <ubitux> (that is, currently, dep on vt framework and its encode function)
[19:39:36 CEST] <ubitux> btw, what are these suggest thing?
[19:39:38 CEST] <ubitux> :D
[19:40:21 CEST] <jamrial> "add it to my list of things i use/depend on if it's enabled, but don't if it's not", or something like that
[19:40:36 CEST] <ubitux> mmh. ok
[19:42:17 CEST] <jamrial> so, since coregraphics, applicationservices and coreservices are all optional and check_lib() doesn't add everything to global extralibs anymore, i need to state what modules have use for them
[19:53:59 CEST] <thebombzen> re: earlier sRGB alias. Is there a way to add option aliases easily, or would I just do something like this? https://0x0.st/CbJ.log
[19:54:18 CEST] <thebombzen> (+ appropriate filters.texi documentation, of course)
[20:49:34 CEST] <durandal_1707> thebombzen: just add entry with same option but different name
[20:49:53 CEST] <thebombzen> so in other words exactly what I posted in my 0x0.st log?
[21:25:16 CEST] <atomnuker> jamrial: vega really doesn't look bad here - http://www.guru3d.com/articles_pages/asus_radeon_rog_rx_vega_64_strix_8gb_review,20.html
[21:25:28 CEST] <atomnuker> its around 200 quid cheaper than a 1080ti here too
[21:34:52 CEST] <nevcairiel> its also quite a bit slower then a 1080ti, its more inline with a 1080
[21:35:17 CEST] <nevcairiel> (looking at a benchmark at 1080p thats likely CPU bound is not very useful, fwiw)
[21:36:28 CEST] <atomnuker> a 1080 is around 70 quid less expensive, I'd say that's a small price to pay for good linux support
[21:36:54 CEST] <atomnuker> (also it has 4x4 sad instructions!)
[21:37:22 CEST] <atomnuker> (though you'll likely need to write raw asm to get to those)
[21:38:45 CEST] <wm4> asm on GPUs? wut
[21:38:53 CEST] <wm4> even spir-v is way way higher level
[21:39:13 CEST] <wm4> so you'd need to write driver-specific code using driver-specific APIs
[21:42:34 CEST] <TD-Linux> nvidia has PTX, their """raw""" asm
[21:42:54 CEST] <nevcairiel> amd calls it "AMDGCN assembly"
[21:43:29 CEST] <TD-Linux> AMD's is a bit different in that they actually define the binary format that the GPU executes
[21:50:08 CEST] <atomnuker> there's llvm support for compiling instinsic-like code to opencl kernels though
[21:51:29 CEST] <atomnuker> its a matter of time before spriv is extended to support arbitrary raw instructions though
[21:54:22 CEST] <Compn> why cpu faster at computing than the cpu haha
[21:54:27 CEST] <Compn> er gpu faster*
[21:54:28 CEST] Action: Compn runs
[22:49:56 CEST] <cone-265> ffmpeg 03Marton Balint 07master:58143b15adda: configure: remove libdl dependency from libndi_newtek
[22:53:12 CEST] <cone-265> ffmpeg 03Marton Balint 07release/3.4:c8642473e0b3: configure: remove libdl dependency from libndi_newtek
[22:58:26 CEST] <jkqxz> michaelni:  Do you have any more comments on the cbs series?
[23:16:30 CEST] <jamrial> michaelni: all your openbsd fate clients are failing with "ffmpeg: cannot execute - Permission denied"
[23:20:51 CEST] <jamrial> maybe ff6de6b180 is at fault
[23:23:22 CEST] <jkqxz> strip there doesn't mark the target as executable?
[23:25:04 CEST] <jamrial> could be. cp+strip does, but strip alone does not
[23:26:27 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:7cb1d9e2dbbe: build: Fine-grained link-time dependency settings
[23:26:28 CEST] <cone-265> ffmpeg 03James Almer 07master:6dfcbd80ad44: Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'
[23:30:10 CEST] <durandal_1707> haha Compn haha
[23:33:38 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:fde7ee8710e9: x86: hevc: Add missing colons after assembly labels
[23:33:39 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:58407b4d74c9: configure: Fix typo in objcc default setting
[23:33:40 CEST] <cone-265> ffmpeg 03James Almer 07master:9244524177b5: Merge commit '58407b4d74c99e30dbd40fe468c69dbd25ea4255'
[23:35:37 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:4d1f7e8bc751: build: Skip generating .version files when cleaning
[23:35:38 CEST] <cone-265> ffmpeg 03James Almer 07master:f6a959adff30: Merge commit '4d1f7e8bc7516e6b7b15f754af4a665b3f8af79e'
[23:38:56 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:d1d6230ea3dd: build: Add "build" shorthand target that depends on all compile targets
[23:38:57 CEST] <cone-265> ffmpeg 03James Almer 07master:5adc1f14f91b: Merge commit 'd1d6230ea3dd2c34bcd121f958706f3177f8d8c5'
[23:41:54 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:39e208f4d475: build: Generalize yasm/nasm-related variable names
[23:41:55 CEST] <cone-265> ffmpeg 03Diego Biurrun 07master:3c0efbd03349: build: Allow generating dependencies as a side-effect of assembling
[23:41:56 CEST] <cone-265> ffmpeg 03James Almer 07master:9908eac21866: Merge commit '3c0efbd03349ae68d3a25a082222652a102e3fd4'
[23:46:09 CEST] <BtbN> The Vega64 uses like 150-200W more, for the same performance as a 1080. That's a big "no thanks" right there.
[23:47:10 CEST] <atomnuker> now now its clearly faster than a 1080
[23:47:59 CEST] <BtbN> it's slightly faster, in some benchmarks
[23:48:05 CEST] <BtbN> And uses a lot more power, in all of them
[23:48:30 CEST] <BtbN> It even uses a lot more power than a 1080Ti, which is significantly faster than the Vega
[23:49:18 CEST] <BtbN> And the price difference between the Vega64 and a 1080Ti is just 100¬
[23:50:06 CEST] <BtbN> The only reason I could possibly think about buying a Vega GPU is to support AMD. But in every technical aspect it looses to nvidia.
[23:51:14 CEST] <jamrial> or if you're a miner
[23:53:16 CEST] <BtbN> even then I doubt the extreme power consumption of those cards makes them worth it
[23:55:09 CEST] <atomnuker> its not *that* bad, the vega still pulls ahead in some benchmarks
[00:00:00 CEST] --- Thu Oct 12 2017