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

[burek]

[00:02:09 CET] <jkqxz> Hardware codecs are the best.  (Recently in wtf hardware codec bugs: <https://github.com/01org/intel-vaapi-driver/issues/87>.)
[00:04:24 CET] <philipl> 8bit signed wrap around anyone?
[00:04:35 CET] <philipl> 120fps should be enough for everyone, right?
[00:05:57 CET] <jkqxz> Looks like all their testing thought so.
[00:37:51 CET] <cone-255> ffmpeg 03Steven Liu 07master:e90ad882819c: avformat/hlsenc: fix duration wrong when no pkt duration
[09:06:38 CET] <matkatmusic> howdy.  I'm browsing the API and i'm wondering if it's possible to specify which frame number an image should be placed at, along with for how many frames. 
[09:07:32 CET] <deepak> Hello..I am deepak aggarwal. I am trying to fix http://trac.ffmpeg.org/ticket/5943#no1
[09:07:44 CET] <deepak> I have produced the error
[09:13:13 CET] <matkatmusic> or perhaps the ability to read a text file as input that specifies images and frame-ranges per image per line and turn it into a video
[09:19:04 CET] <matkatmusic> like, ffmpeg -i file.txt -r 24 where file.txt is File001.jpg 0 4, File002.jpg 5 12, meaning File001 is the image for frames 0 thru 4, File 002 is the image for frames 5 thru 12, etc..
[09:41:38 CET] <ubitux> what's the politic wrt color_range? avctx or frame or both?
[09:42:56 CET] <atomnuker> I'd expect it to be always flagged everywhere
[09:43:40 CET] <ubitux> so if the information is only in the frame
[09:43:47 CET] <ubitux> at each frame decode we set it to the avctx?
[09:44:48 CET] <ubitux> reason i'm asking: i'm trying to merge the next vpx commit; we are currently setting avctx color_range at every frame (libav doesn't), and the current change from libav set its into the frame instead (which makes more sense, IMO)
[09:45:09 CET] <ubitux> so i'm now wondering about keeping the avctx color range set
[09:45:15 CET] <nevcairiel> should probably update avctx as well so it doesnt desync and cause funnyness
[09:45:49 CET] <ubitux> ok
[09:46:21 CET] <ubitux> now second question: our code looks currently unsafe in case libvpx add more color ranges
[09:46:43 CET] <ubitux> it's simpler that a switch case though
[09:46:46 CET] <ubitux> what do we prefer?
[09:59:17 CET] <atomnuker> there can't be more than 2 color ranges
[10:00:31 CET] <ubitux> yeah well we use the same method for color spaces
[10:00:52 CET] <ubitux> (i'm refering to libvpxdec.c:set_pix_fmt())
[10:01:10 CET] <nevcairiel> you would think that, but the microsoft color format specification also specifies 48-208 for some reason, whats to stop someone else from also d oing  such weird things  =p
[10:01:24 CET] <atomnuker> what
[10:02:00 CET] <nevcairiel> https://msdn.microsoft.com/en-us/library/windows/desktop/ms705659(v=vs.85).aspx
[10:02:21 CET] <ubitux> btw, looking at lavc/utils, it seems we are setting the frame color_range based on the avctx value
[10:02:32 CET] <ubitux> so the commit might be noop-able altogether
[10:02:39 CET] <nevcairiel> if its unset in the frame i believe yes
[10:02:51 CET] <ubitux> (at least for decoding)
[10:04:04 CET] <atomnuker> I'm sure that its all for filters
[10:04:14 CET] <atomnuker> they can't keep cutting precision down and getting away with it
[10:05:12 CET] <nevcairiel> not that i have ever seen either of the  narrower ones used anywhere
[10:57:01 CET] <cone-541> ffmpeg 03Matthieu Bouron 07master:1ade4d87bae8: lavc/h264dec: use OFFSET macro
[12:30:09 CET] <cone-541> ffmpeg 03Luca Barbato 07master:b183abfb5b63: vpx: Support color range
[12:30:10 CET] <cone-541> ffmpeg 03Clément BSsch 07master:89a032634b6e: Merge commit 'b183abfb5b6366b177cf44f244c66156257a6fd6'
[12:32:58 CET] <cone-541> ffmpeg 03Luca Barbato 07master:40ad05bab206: checkasm: Cast unsigned to signed
[12:32:59 CET] <cone-541> ffmpeg 03Clément BSsch 07master:8b13492c9ecf: Merge commit '40ad05bab206c932a32171d45581080c914b06ec'
[12:34:27 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:48b80f8393d4: hpeldsp: Explain why put_no_rnd_pixels_tab is larger than necessary
[12:34:28 CET] <cone-541> ffmpeg 03Clément BSsch 07master:6426c58b1cb9: Merge commit '48b80f8393d418ad35d73f5a36f5011de1928f3c'
[12:38:03 CET] <ubitux> wbs: i suppose 56af0bc10 should also include strtoull?
[12:41:26 CET] <michaelni> ubitux, http://coverage.ffmpeg.org/ is not working
[12:41:29 CET] <wbs> ubitux: yes
[12:41:44 CET] <ubitux> wbs: ok thanks
[12:41:53 CET] <ubitux> michaelni: will fix
[12:44:05 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:56af0bc10f49: configure: Check for strtoll and redirect to _strtoi64 in the msvcrt block
[12:44:06 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:79fb0692992c: configure: Move defines for controlling MSVCRT headers to the CRT detection section
[12:44:07 CET] <cone-541> ffmpeg 03Clément BSsch 07master:132523448ba4: Merge commit '56af0bc10f49654b5b5f3efe82c69a13bf15fc8b'
[12:44:08 CET] <cone-541> ffmpeg 03Clément BSsch 07master:50d303a66ad0: Merge commit '79fb0692992c74214c6cf8e81350fc93eeffc5ec'
[12:52:28 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:100fb0ddfda9: configure: Allow detecting and using LLVM lld-link as linker for windows
[12:52:29 CET] <cone-541> ffmpeg 03Clément BSsch 07master:67e2ba36ec50: Merge commit '100fb0ddfda958da70f98feac81f924c02483789'
[13:05:58 CET] <ubitux> michaelni: i'm going to have to switch boxes, this box is dying; it will stay down for maybe 2 days
[13:28:51 CET] <michaelni> ubitux, ok, ill tell thomas, he is using it to decide/check were to add self test
[13:29:14 CET] <ubitux> it can be run locally
[13:29:33 CET] <ubitux> spoiler alert: lavfi needs more testing
[13:29:57 CET] <ubitux> but many filter are not bitexact so improvements needed in that area
[13:30:02 CET] <nevcairiel> testing lavfi more is probably more meaningful then adding yet more algorithmic tests for lavu =p
[13:30:24 CET] <michaelni> ill tell thomas about lavfi, i think he knows that coverage can be run locally
[13:30:59 CET] <ubitux> basically any filter that uses float should use a new test mechanism which needs to be added badly
[13:31:14 CET] <ubitux> i'm happy to add tests to my filters if such thing were present
[13:31:43 CET] <ubitux> (i have way too many float based filters)
[13:43:41 CET] <michaelni> ubitux, ok, just suggested thomas to look into a mechanism for non bitexact filter testing
[13:44:22 CET] <ubitux> thanks!
[14:04:21 CET] <temp> hello 
[14:05:44 CET] <temp> i build ffmpeg source encounter problem 
[14:06:13 CET] <temp> error like : libavcodec/ffjni.c:23:10: fatal error: jni.h: No such file or directory #include <jni.h>         ^~~~~~~
[14:10:33 CET] <ubitux> didn't you just --enable-jni for a non-android system?
[14:10:41 CET] <ubitux> this is probably a #ffmpeg question
[14:10:41 CET] <temp> yes
[14:10:56 CET] <ubitux> well, why?
[14:11:08 CET] <temp> ok, thanks for notice
[14:11:47 CET] <temp> i don't know, just try use --enable-jni 
[14:12:25 CET] <ubitux> it's java native stuff for android
[14:13:24 CET] <temp> ok, is it cannot for other java native program?
[14:15:00 CET] <mateo`> in theory it can enable the jni helpers on desktop too, but it's not tested and you should not be able to enable jni on a platform other than the android one in the first place
[14:15:42 CET] <temp> oh, thank your help 
[14:17:42 CET] <temp> and what's --enable-mediacodec for , why it need --enable-jni
[14:18:15 CET] <BtbN> Because it's an Android API.
[14:18:30 CET] <temp> ok
[14:18:44 CET] <temp> thanks so much 
[14:18:55 CET] <mateo`> I'll patch the configure asap to error out when needed
[14:21:25 CET] <BBB> durandal_170: do you have more libavfilter qualification tasks? Ive got another 3 vmaf students that need a new, fresh qualification task
[14:22:11 CET] <BBB> (I didnt think this qualification task thing throug very well)
[14:22:31 CET] <atomnuker> ask if anyone wants to work on audio encoders
[14:25:33 CET] <durandal_170> BBB: port some filters from mlt/frei0r/vapoursynth/avisynth
[14:26:58 CET] <durandal_170> add gray planar  >8 with alpha to swscale
[14:28:32 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:e46a6fb7732a: avconv: Check that muxing_queue exists before reading from it
[14:28:33 CET] <cone-541> ffmpeg 03Clément BSsch 07master:a283665693e1: Merge commit 'e46a6fb7732a7caef97a916a4f765ec0f779d195'
[14:32:24 CET] <jamrial> BBB: port the vf_noise asm from inline to yasm
[14:32:48 CET] <BBB> jamrial: thats not very appropriate for vmaf, I dont think it includes a lot of assembly, more basic filtering stuff and algorithms
[14:33:01 CET] <BBB> jamrial: that would work for vp9 qual task though (since thats a ton of avx2)
[14:33:14 CET] <jamrial> fair enough
[14:34:50 CET] <mateo`> ubitux seems to love cosmetic merges :D
[14:35:08 CET] <ubitux> grrr
[14:35:57 CET] <BBB> durandal_170: Im unfortunately not very familiar with mlt/frei0r/vapour/avisynth
[14:38:08 CET] <temp> libavcodec/libopusenc.c: In function libopus_encode_init:libavcodec/libopusenc.c:337:15: error: implicit declaration of function opus_multistream_surround_encoder_create; did you mean opus_multistream_decoder_create? [-Werror=implicit-function-declaration]         enc = opus_multistream_surround_encoder_create(
[14:38:09 CET] <temp>                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[14:38:09 CET] <temp>                opus_multistream_decoder_create
[14:38:09 CET] <temp> libavcodec/libopusenc.c:337:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
[14:38:10 CET] <temp>          enc = opus_multistream_surround_encoder_create(             ^
[14:38:27 CET] <temp> what's this mean
[14:39:05 CET] <cone-541> ffmpeg 03Steven Liu 07master:0052f3f527c4: avcodec/videotoolboxenc: add rc_max_bitrate control into videotoolbox
[14:40:09 CET] <durandal_170> BBB: port defish0r plugin from frei0r
[14:40:24 CET] <mateo`> temp: please ask on #ffmpeg, this channel is dedicated to ffmpeg development
[14:42:14 CET] <temp>  there no answer, sorry for trouble, i'll go and wait :P
[14:42:42 CET] <BBB> durandal_170: okiedokie, tnx& Ill suggest that as first qual task to the student
[15:16:08 CET] <ubitux> any reason libnpp is treated differently than libfdk_aac and openssl?
[15:18:38 CET] <BtbN> it is?
[15:18:49 CET] <ubitux> sorry, wrt licenses in configure
[15:19:06 CET] <BtbN> It's nonfree, unless someone accidentially changed that
[15:19:20 CET] <nevcairiel> so are the two ubitux listed
[15:19:38 CET] <ubitux> i'm asking about the gpl incompat bit
[15:19:40 CET] <nevcairiel> although people argue  about openssls system library exception all the time
[15:20:13 CET] <BtbN> Well, libnpp is a closed source non-system-library that's under a definitely not GPL compatible license.
[15:20:20 CET] <BtbN> I don't see how it could ever be not nonfree
[15:21:21 CET] <ubitux> so it should be treated the same as the other two?
[15:21:27 CET] <BtbN> It is?
[15:21:40 CET] <ubitux> it isn't, should it?
[15:21:56 CET] Action: ubitux wonders if he's failing at english again
[15:22:30 CET] <RiCON> fdk/openssl only fail if --enable-gpl is used without --enable-nonfree
[15:22:39 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=d486cfde37e43411a21753f7d62b01402972973c;hb=HEAD#l5166
[15:22:39 CET] <RiCON> libnpp fails even with lgpl
[15:22:52 CET] <nevcairiel> why would lgpl allow linking to a nonfree library
[15:23:20 CET] <nevcairiel> distributing it would still be nonfree
[15:23:29 CET] <BtbN> openssl and libfdk also require gpl instead of lgpl. The libnpp code in ffmpeg is LGPL
[15:23:37 CET] <BtbN> Maybe that's the difference you mean?
[15:24:11 CET] <ubitux> (side node: "enabled gpl &&" could be in die_license_disabled_gpl)
[15:24:27 CET] <BBB> nevcairiel: assuming the library is distributed separately, there is no issue, right?
[15:24:38 CET] <BtbN> it seems weird though. Indeed loks like fdk/openssl are only nonfree in GPL mode?
[15:24:55 CET] <BtbN> BBB, only if it's a system library
[15:24:56 CET] <BBB> nevcairiel: e.g. assume you link against nvidia drivers .so, if nvidia lets you download the .so and some rpm repo lets you download a ffmpeg build that links to it& everyones happy, right?
[15:24:59 CET] <BtbN> which npp is clearly not
[15:25:08 CET] <BBB> thats gpl
[15:25:11 CET] <nevcairiel> BBB: depends who you ask, some peole argue even having code t hat uses a nonfree library is therefore nonfree
[15:25:15 CET] <BBB> he asked lgpl
[15:25:42 CET] <BBB> puretards are entitled to their opinion too, indeed
[15:26:37 CET] <nevcairiel> also the license of the header matters, i guess
[15:26:38 CET] <RiCON> also, cdio/cdio-paranoia probably should require --enable-version3?
[15:26:39 CET] <BBB> nevcairiel: the lgpl says nothing of that sort in my reading ;)
[15:26:51 CET] <RiCON> or is it not about the libs license but the FFmpeg code using them?
[15:27:13 CET] <BBB> nevcairiel: but its indeed possible the nonfree part doesnt allow it, but you cant make blanket statements about that since each nonfree modules license is different
[15:27:53 CET] <BtbN> also the entire nvidia/cuda license stuff was deemed too fucked up and confusing, so making it nonfree was the safest thing to go for
[15:28:21 CET] <BtbN> libnpp is not part of any nvidia driver, they expect you to bundle the DLLs with your application.
[15:39:59 CET] <ubitux> http://sprunge.us/dRWf so& any objection?
[15:40:23 CET] <nevcairiel> libnpp should also fail when you try to use it with lgpl
[15:40:36 CET] <nevcairiel> without nonfree
[15:41:59 CET] <ubitux> but not the others?
[15:42:18 CET] <ubitux> i'm trying to make these check consistent for the next merge :(
[15:42:20 CET] <BtbN> it should always fail trying to build it without nonfree
[15:42:39 CET] <BtbN> So basically like it is right now from my understanding.
[15:43:45 CET] <nevcairiel> i have no clue why lgpl would allow linking against an incompatible library in the first place
[15:43:59 CET] <nevcairiel> libav certainly doesnt have it like that
[15:46:41 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f997ac1c8bc2124c4c6bf33ad17bc6f6cca0f84e .. maybe it applies to openssl and its apache license specifically
[15:47:30 CET] <nevcairiel> but libnpp is a propietary license, both on the binary and the headers used
[15:59:20 CET] <ubitux> so i should deal with the current behaviour?
[16:03:21 CET] <BBB> nevcairiel: its possible that apache/ssl are specifically lgpl-incompatible
[16:03:27 CET] <BBB> nevcairiel: i.e. lgpl+ssl = gpl
[16:03:38 CET] <BBB> or lgplv3 or whatever
[16:03:40 CET] <BBB> I dont remember
[16:12:30 CET] <J_Darnley> Dammit.  Why doesn't movh as a macro default parameter work?  Is it because it is another macro?
[16:19:09 CET] <BBB> J_Darnley: gramner would probably know that
[16:19:27 CET] <BBB> J_Darnley: but Ive always just done some integer parameter to the macro and then assin/define movtmp to movh/mova inside the macro
[16:19:31 CET] <jamrial> J_Darnley: if you're writing ymm code then it wont work
[16:19:35 CET] <BBB> depending on the integer constant
[16:19:40 CET] <BBB> and yes, movh in ymm doesnt exist
[16:19:41 CET] <jamrial> movh is not defined for that
[16:19:52 CET] <J_Darnley> Wait, I try again and it works?  Did I not save the correct changes before?
[16:19:58 CET] <J_Darnley> jamrial: I know
[16:19:59 CET] <Gramner> macro expansion rules probably
[16:19:59 CET] <BBB> lol
[16:20:28 CET] <J_Darnley> Clearly it is just user error
[16:48:02 CET] <kierank> atomnuker: bought dell laptop like yours
[16:48:11 CET] <kierank> did you get the thunderbolt to ethernet or usb3 to ethernet
[16:52:24 CET] <durandal_170> i have dell to
[16:54:02 CET] <kierank> i bought usb-c to thernet
[16:54:09 CET] <kierank> wasn't sure the apple one was gfoing to work
[16:59:56 CET] <atomnuker> kierank: I got a usb-c to ethernet, though it really doesn't matter
[17:00:08 CET] <atomnuker> they all have the same realtek chipset in them
[17:00:31 CET] <atomnuker> its pretty decent too in terms of offloading capabilities
[17:00:59 CET] <atomnuker> I recommend staying away from usb-c hubs though
[17:01:34 CET] <kierank> I read that the apple one doesn't hotplug on windows
[17:01:38 CET] <atomnuker> all use the same messed up chipset which for some reason breaks compatibility with usb 2 devices if you turn the usb connector 1 way
[17:02:28 CET] <atomnuker> even though its usb-c and it shouldn't matter, it does with that chipset
[17:38:56 CET] <wm4> does thunderbolt work yet in Linux
[17:39:12 CET] <wm4> couldn't ever get apple's thunderbolt ethernet adapter to work on my macbook (with Linux)
[18:47:21 CET] <tmm1> how can i add a file to fate?
[18:47:29 CET] <tmm1> and what are the guidelines for file size for samples
[18:59:39 CET] <nevcairiel> as small as possible for the task at hand
[19:09:19 CET] <J_Darnley> BBB jamrial Gramner: I know REP_RET should be used when it is a jump target but does the return from a function call count as one?
[19:11:27 CET] <jamrial> J_Darnley: i think you don't need to use REP_RET anymore
[19:12:23 CET] <jamrial> RET is enough for all cases
[19:12:30 CET] <J_Darnley> RET knows when the previous instruction was a jump but not if it is a target/label.  Or did you mean somethign else?
[19:14:53 CET] <Gramner> I don't remember if ret counts as a branch as far as that issue goes, but the cpu:s affected by it (old amd ones) are getting kinda rare nowadays so it doesn't really matter. I usually don't bother with REP_RET anymore
[19:15:40 CET] <J_Darnley> yeah, the comments say that ssse3 is enough to know
[19:33:43 CET] <J_Darnley> Gah!  I don't suppose people would let me add a dedicated file for avx functions.
[19:35:17 CET] <JEEB> why not?
[19:36:48 CET] <J_Darnley> Not sure.  Some would dislike the duplication I'm doing in it.
[19:37:22 CET] <BBB> the duplication is still there if its in a separate file
[19:37:23 CET] <J_Darnley> Nesecary in my opinion because many of these macros are written with mm registers in mind.
[19:37:38 CET] <BBB> and I think its fine to duplicate code if de-dup requires ugliness
[19:37:44 CET] <BBB> the h264 simd code is sometimes very very old
[19:37:47 CET] <BBB> h264 is old :-p
[19:39:12 CET] <Gramner> or just nuke mmx code from orbit when there's sse2 implementation :>
[19:40:34 CET] <J_Darnley> Some of it would be ugly if I add conditionals to the macros, sometimes not.
[19:41:47 CET] <BBB> J_Darnley: youre smart enough to be able to make a decision yourself on when its worth it and when not ;)
[19:41:54 CET] <BBB> J_Darnley: dont forget youre the main person touching h264 simd right now
[19:42:09 CET] <BBB> so if youre ok with it, &
[19:42:47 CET] <JEEB> aye
[19:42:58 CET] <Gramner> duplicating is better than an unreadable mess of a template that tries to be compatible with everything under the sun
[19:43:04 CET] <JEEB> ^this
[19:43:41 CET] <wm4> <tmm1> how can i add a file to fate? <- contact someone who has access
[19:43:46 CET] <BBB> %macro INC 17
[19:43:53 CET] <wm4> (might be a couple of people, but I only know michaelni)
[19:44:11 CET] <BBB> %if %0 == 1 inc %2 %elif .. add %2, %3 &
[19:44:19 CET] <J_Darnley> :D
[19:44:40 CET] <J_Darnley> Ouch my face is a little distorted with this font
[19:44:41 CET] <BBB> I believe at some point I could add files, but I forgot how it works
[21:08:23 CET] <kierank> J_Darnley: what function are you working on
[21:16:33 CET] <atana> michaelni, ping
[21:17:22 CET] <atana> I have updated the peakspoint2 repo. Now it has 8 failures
[21:20:06 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:ae90119c6701: configure: Simplify license incompatibility check
[21:20:07 CET] <cone-541> ffmpeg 03Clément BSsch 07master:9f28db47accb: Merge commit 'ae90119c6701fa09ff747cca35238e36b2d2ab2f'
[21:25:34 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:a115eb9e7505: mimic: do not release the newly obsolete reference at the end of decoding
[21:25:35 CET] <cone-541> ffmpeg 03Clément BSsch 07master:e40fd81809ea: Merge commit 'a115eb9e750543f1d8bf951414d291069bf396c2'
[21:29:30 CET] Action: michaelni sees a ping from atana and 7min later "atana has quit (Ping timeout: 240 seconds)"
[21:30:35 CET] <cone-541> ffmpeg 03Luca Barbato 07master:2ac00d2d1d51: mov: Validate the ID number
[21:30:36 CET] <cone-541> ffmpeg 03Clément BSsch 07master:8636ccb5c0ff: Merge commit '2ac00d2d1d51047c6ce69d5fbe1a08392d142658'
[21:45:29 CET] <cone-541> ffmpeg 03Luca Barbato 07master:a5ebe5d12179: ac3dec: Split spx-specific code from decode_audio_block()
[21:45:30 CET] <cone-541> ffmpeg 03Clément BSsch 07master:7c4dbd1df985: Merge commit 'a5ebe5d1217942238c641c83b24ef1106e53934a'
[21:57:12 CET] <cone-541> ffmpeg 03Luca Barbato 07master:f0ccc65bc9ab: ac3dec: Split coupling-specific code from decode_audio_block()
[21:57:13 CET] <cone-541> ffmpeg 03Clément BSsch 07master:2e3221c30320: Merge commit 'f0ccc65bc9ab9ddf1366066395564c71bcc825ee'
[21:58:35 CET] <cone-541> ffmpeg 03Luca Barbato 07master:3db51bf671de: ac3dec: Simplify skipping
[21:58:36 CET] <cone-541> ffmpeg 03Luca Barbato 07master:8495d84f0101: ac3dec: Add some inline hints
[21:58:37 CET] <cone-541> ffmpeg 03Clément BSsch 07master:151b5e4a53c2: Merge commit '3db51bf671defd47f2ec5ab67b11fb7730fb5e5a'
[21:58:38 CET] <cone-541> ffmpeg 03Clément BSsch 07master:4ac44520e526: Merge commit '8495d84f0101464b15517860db33e8605586d87e'
[22:00:40 CET] <ubitux> next merge might get me killed
[22:02:11 CET] <iive> hum?
[22:02:32 CET] <jamrial> iive: remove x11grab
[22:03:07 CET] <iive> is there any replacement/alternative?
[22:03:24 CET] <JEEB> xdg?
[22:03:30 CET] <ubitux> xcb
[22:03:35 CET] <jamrial> there's a replacement already, but people may still bitch. i guess that's what ubitux is talking about :p
[22:03:39 CET] <JEEB> right, xcb
[22:04:28 CET] <iive> isn't xcb just another lib that talks to xorg ?
[22:04:50 CET] <nevcairiel> yes
[22:05:22 CET] <nevcairiel> which is why having 2 is silly, and xcb is more modern
[22:05:54 CET] <iive> does it have any benefit compared to x11 one?
[22:06:22 CET] <JEEB> if it works better
[22:06:25 CET] <JEEB> does that count?
[22:06:40 CET] <iive> this is a big if
[22:06:56 CET] <wm4> ubitux: what is it?
[22:06:59 CET] <JEEB> as far as I know the xcb one was added due to the x11 one sucking
[22:07:25 CET] <iive> i mean, is there any measurable and demonstratable way to prove that it works better?
[22:08:42 CET] <nevcairiel> even if they work equally well, having two is  still silly if they serve the exact same purpose
[22:08:45 CET] <ubitux> wm4: the old gpl-version using old-style x11 api to grab the screen
[22:09:04 CET] <wm4> oh ok
[22:09:14 CET] <iive> nevcairiel: if they work equally well, then the one that works on more systems should be preffered
[22:09:18 CET] <wm4> oh so license is the issue with x11 vs. xcb?
[22:09:27 CET] <ubitux> it's one of them
[22:09:42 CET] <JEEB> oh, and the license thing :V
[22:10:04 CET] <iive> gah, licenses.
[22:10:17 CET] <ubitux> but xcb is definitely the modern way
[22:10:50 CET] <iive> ubitux: something been modern doesn't mean it is better.
[22:11:09 CET] <nevcairiel> xcb is also rather old already
[22:11:20 CET] <nevcairiel> in xorg terms, everything is old
[22:11:45 CET] <iive> the X protocol is much older ;)
[22:12:39 CET] <iive> libx11 uses xcb to talk to the server
[22:13:11 CET] <iive> so unless the new code exploits some of the locking improvements that xcb offers, it should run the same.
[22:14:20 CET] <jkqxz> Using XCB makes error handling possible - X11 offers little more than "oh noes, abort".
[22:14:24 CET] <uau> the xcb version is shorter, so it's probably better code
[22:14:28 CET] <TD-Linux> libx11 on modern systems is emulated using libxcb
[22:14:34 CET] <wm4> jkqxz: true
[22:14:44 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:4fef648d10bf: Remove the legacy X11 screen grabber
[22:14:45 CET] <cone-541> ffmpeg 03Clément BSsch 07master:4a9c5f6bc5a8: Merge commit '4fef648d10bf3bcfd4b8fa5755c1128966a2427c'
[22:14:49 CET] <iive> TD-Linux: that's what i said above too.
[22:14:50 CET] <wm4> to be honest, there are many libx11 things that could just have been fixed
[22:15:32 CET] <JEEB> I'm gonna poke #ffmpeg so that they update their olden tutorials on the wiki
[22:15:44 CET] <JEEB> since it seems like a lot of that stuff still points towards x11grab
[22:15:55 CET] <wm4> so the x11 one was dropped?
[22:16:03 CET] Action: JEEB points at the commit in the log
[22:16:18 CET] <wm4> ah
[22:16:41 CET] <wm4> to be honest a deprecation period wouldn't have hurt
[22:17:07 CET] <jamrial> there's no way to deprecate modules like this afaik
[22:17:36 CET] <jamrial> aside from an av_log() saying "stop using this"
[22:17:37 CET] <uau> are there any practical API/usage differences?
[22:17:55 CET] <uau> so could you just have an alias as a deprecation mechanism?
[22:18:09 CET] <JEEB> most of the options seemed to similar
[22:18:11 CET] <ubitux> -f x11grab is kept
[22:18:14 CET] <JEEB> ah
[22:18:17 CET] <JEEB> ok
[22:18:45 CET] <ubitux> compil' flags change; you don't need --enable-gpl anymore, and it's autodetected anyway
[22:19:35 CET] <ubitux> i'm going to fix a few remaining references after next commit
[22:21:11 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:5ed4644d6de7: x11grab: Rename internal component to "xcbgrab"
[22:21:12 CET] <cone-541> ffmpeg 03Clément BSsch 07master:f6d61eb6f95a: Merge commit '5ed4644d6de7f6112431dc2d9a5cfe9a0a75a688'
[22:21:19 CET] <uau> ubitux: if it's just disabling the older implementation of the same API, i don't see why you thought it'd be particularly controversial
[22:21:36 CET] <ubitux> because removing anything in ffmpeg is taboo
[22:21:52 CET] <ubitux> especially if it belongs in a museum
[22:22:15 CET] <nevcairiel> if common commandlines still work etc, then i d ont see  any reason to not do it
[22:22:45 CET] <nevcairiel> but its done already now anyway .)
[22:23:14 CET] <cone-541> ffmpeg 03Clément BSsch 07master:2f6661c94016: doc: remove remaining legacy x11grab references
[22:24:38 CET] <debianuser> ubitux: Last time I checked x11grab was providing higher fps than xcbgrab. I.e. 60fps grab was with some additional hacks possible with x11grab but not possible with xcbgrab.
[22:25:16 CET] <ubitux> did you test after 0bd1be65e88d6a4f367e698d7a2b105424eb1905 ?
[22:26:36 CET] <debianuser> No. I haven't tested it for about a year.
[22:27:04 CET] <ubitux> you should :)
[22:27:45 CET] <debianuser> You think it's os-dependent? I mean does xcbgrab gives higher fps to you?
[22:28:19 CET] <debianuser> (I'll definitely retest again, by the way, thank you!)
[22:33:06 CET] <wm4> <jamrial> aside from an av_log() saying "stop using this" <- good enough
[22:33:24 CET] <wm4> <ubitux> -f x11grab is kept <- oh, could be fine then
[22:42:44 CET] <iive> is it possible to create x11grab alias, that uses xcbgrab?
[22:42:59 CET] <JEEB> iive: that was already added
[22:43:02 CET] <iive> oh, it does this already
[22:53:31 CET] <ubitux> debianuser: the commit i'm pointing out is a huge optimization
[23:01:45 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:5ebef79abecc: Fix instances of broken indentation found by gcc 6
[23:01:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:dd0abace3ec7: Merge commit '5ebef79abecc3ffcc4ab0d46e203d13b068107c9'
[23:21:11 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:ed1cd8107643: flac demuxer: improve probing
[23:21:12 CET] <cone-541> ffmpeg 03Clément BSsch 07master:e887d685f741: Merge commit 'ed1cd81076434b76f37576d4d806973476a8e96c'
[23:23:45 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:e328178da90f: qsvdec: only access hwaccel_context is the pixel format is QSV
[23:23:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:aabe525734aa: Merge commit 'e328178da90f44690e0076f4dbfd16da9175f441'
[23:26:33 CET] <RiCON> ubitux: does 9f28db47a mean libnpp no longer needs --enable-nonfree for lgpl?
[23:28:45 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:7ebdffc353f3: dxv: Check to make sure we don't overrun buffers on corrupt inputs
[23:28:46 CET] <cone-541> ffmpeg 03Clément BSsch 07master:d96f6df3a649: Merge commit '7ebdffc353f3f0827864e8e3461fdc00cc243b14'
[23:29:13 CET] <ubitux> RiCON: ah, erm mmh... i will fix this tomorrow until someone does, i need to test it properly
[23:29:34 CET] <jamrial> ubitux: you can probably noop the next two commits, btw. they are reverted a few commits ahead
[23:29:35 CET] <RiCON> i thought that's what was discussed earlier
[23:29:46 CET] <ubitux> jamrial: yep, i will
[23:30:03 CET] <ubitux> RiCON: yeah i'm sorry
[23:30:22 CET] <ubitux> RiCON: any clean solution welcome btw
[23:30:32 CET] <ubitux> maybe another list is needed
[23:31:22 CET] <RiCON> isn't libnpp already in a separate list?
[23:31:31 CET] <ubitux> http://sprunge.us/LDKj
[23:31:48 CET] <RiCON> yeah, that's what i'd suggest too
[23:31:49 CET] <ubitux> RiCON: yeah but... the name isn't license-behaviour related
[23:32:13 CET] <RiCON> yeah, but the issue is with fdk/openssl being nonfree only with gpl
[23:32:27 CET] <ubitux> feel free to commit, it's late for me, i'll likely make a mistake
[23:32:32 CET] <ubitux> i'll go back to merges tmr
[23:32:46 CET] <RiCON> i don't have push :)
[23:33:29 CET] <ubitux> ask jamrial :°
[23:33:32 CET] Action: ubitux running away
[23:34:18 CET] <jamrial> RiCON: should i push that diff?
[23:46:19 CET] <RiCON> jamrial: wait, the error configure shows is wrong
[23:47:16 CET] <jamrial> RiCON: ok
[23:47:27 CET] <RiCON> jamrial: http://sprunge.us/XGIP
[23:47:54 CET] <jamrial> RiCON: give me a commit message for this :P
[23:51:19 CET] <RiCON> jamrial: http://sprunge.us/FZFe good enough?
[23:51:37 CET] <jamrial> RiCON: yes, thanks
[23:52:57 CET] <nevcairiel> imho openssl and possibly fdk should rather be special cased
[23:53:05 CET] <nevcairiel> they are those with a nonfree-but-not-really license
[23:53:30 CET] <kierank> dunno about openssl but why fdk
[23:53:50 CET] <BtbN> The FDK license is weird
[23:53:52 CET] <BtbN> but not nonfree
[23:54:00 CET] <kierank> the nonfree part is that it forces you to get a patent licence
[23:54:11 CET] <kierank> even if you don't want one
[23:54:25 CET] <BtbN> Not even, the nonfree part according to some FSF guy I asked is the part where it forces you how to name your derived work.
[23:54:50 CET] <kierank> you mean the bit where you can't mention fraunhofer?
[23:55:12 CET] <BtbN> They have a part where they very specifically describe how a derived work should be named
[23:56:20 CET] <cone-541> ffmpeg 03Ricardo Constantino 07master:b409d8d4a276: configure: libnpp is always nonfree, even with LGPL
[23:56:26 CET] <kierank> amazing that wbs is still fixing crashes to this day
[00:00:00 CET] --- Thu Mar 16 2017