[04:43:29 CET] <cone-875> ffmpeg 03Michael Niedermayer 07master:ddd851f7cbcb: avcodec: Document that init_static_data() is not intended for time consuming operations. [08:55:02 CET] <rcombs> tmm1: ping re: that videotoolbox sample [17:00:26 CET] <gagandeep__> hi, i am looking to contribute to cineform [17:01:11 CET] <gagandeep__> i would like to ask how shall i begin as i am looking to participate in gsoc and i came here from the ideas list of ffmpeg for 2018 [17:02:25 CET] <gagandeep__> since this will be my first time collaborating in an open source project, is this project comprehensible to a beginner such as me [17:03:38 CET] <gagandeep__> i have seen the required qualification tasks and to approach them i need help on to start to dive into the source code [17:10:37 CET] <kierank> gagandeep__: do you know C? [17:10:55 CET] <Zeranoe> This looks related to the recent multibitdepth in x265: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=5481 [17:12:16 CET] <sfan5> unless there were any changes, which depths x265 will encode depends entirely on how it was compiled [17:13:12 CET] <Zeranoe> To my understanding you can go to both within the same executable [17:13:54 CET] <sfan5> you can, yes [17:13:59 CET] <sfan5> x265 [info]: build info [Linux][GCC 7.2.1][64 bit] 8bit+10bit+12bit [17:14:04 CET] <sfan5> in there log there is x265 [info]: build info [Windows][GCC 7.2.0][64 bit] 10bit [17:14:12 CET] <sfan5> so x265 was not compiled with support for 8-bit [17:15:12 CET] <Zeranoe> sfan5: Ah, do you know what cmake option is used to get multiple? [17:15:44 CET] <sfan5> you need to build multiple times to get that [17:15:44 CET] <sfan5> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... [17:17:06 CET] <Zeranoe> weird, but alright [17:21:03 CET] <RiCON> Zeranoe: multidepth isn't really recent either, it's almost 3 years-old by now [17:28:00 CET] <gagandeep__> guys, i would like to understand cineform code, what guides should i follow [17:28:11 CET] <gagandeep__> i know c [17:29:48 CET] <kierank> gagandeep__: https://github.com/gopro/cineform-sdk/tree/master/docs [17:29:51 CET] <kierank> quite simple maths actually [17:31:55 CET] <gagandeep__> k [17:33:19 CET] <cone-346> ffmpeg 03James Almer 07master:cb97400f93ba: Revert "cmdutils: make use of new iteration APIs" [17:37:31 CET] <DHE> you mean x264? in december they added one-library-multiple-depths support [17:56:00 CET] <durandal_1707> jamrial: i expect you will add proper code for that one [17:57:25 CET] <jamrial> durandal_1707: no [17:57:52 CET] <durandal_1707> jamrial: than why you are acting like that? [17:58:35 CET] <jamrial> i suggested a revert for the one broken patch with (at the time) no proper fix. two people agreed with me, one was against, but ultimately accepted my arguments [17:58:48 CET] <jamrial> i was not going to revert it myself, but was asked to [17:59:22 CET] <durandal_1707> so we now have broken program/api well done [17:59:35 CET] <jamrial> how so? [18:00:43 CET] <durandal_1707> its really shame we need to listen to bikesheeds all way around [18:01:08 CET] <jamrial> the api is still in place, you know? [18:01:40 CET] <jamrial> the bikeshed is still ongoing, but now with the not-fully-working api in place [18:04:35 CET] <jamrial> i fixed three issues introduced by this patch. there are a couple remaining that the authors of this set should fix [18:04:46 CET] <jamrial> plus a working version of the commit i was asked to revert [18:06:44 CET] <jamrial> so i'm not in the mood to get shat on for helping to get the tree back in a working condition without the need for a full revert of all seven patches [20:40:07 CET] <durandal_1707> FFmpeg is dead, leave while you can [20:42:55 CET] <atomnuker> every time you say it it gets more and more alive [20:46:49 CET] <durandal_1707> atomnuker: no, see last drama, ffmpeg is semi broken now [20:47:10 CET] <wm4> what is broken [20:47:18 CET] <wm4> I don't know from all the bikeshedding noise [20:47:30 CET] <jamrial> caca demuxer it seems [20:48:05 CET] <jamrial> all the cmdutils related issues are gone after the revert [20:49:16 CET] <atomnuker> the caca demuxer is useless anyway [20:49:36 CET] <jamrial> doesn't matter [20:49:37 CET] <JEEB> caca *demuxer* ? [20:49:52 CET] <JEEB> so you input text and..? [20:49:56 CET] <jamrial> sorry, muxer [20:49:57 CET] Action: JEEB has his mind blown [20:50:00 CET] <JEEB> ah [20:50:11 CET] <JEEB> would have been rather fancy [20:50:50 CET] <wm4> well it might apply to all libavdevice outputs [20:51:03 CET] <jamrial> probably, yeah [20:51:04 CET] <wm4> of which decklink is the only one that isn't just a broken toy [20:51:12 CET] <durandal_1707> and what about soxr? [20:51:34 CET] <wm4> wasn't that due to the cmdutils thing [20:51:49 CET] <jamrial> that breakable is weird [20:52:28 CET] <atomnuker> the pulse and kms lavd things are also fine [20:52:36 CET] <jamrial> it doesn't really make much sense for this patchset to break linking for some swr stuff [20:55:09 CET] <jamrial> in any case, the api discussion is pretty much stalled at this point, so i guess iterate() is most likely going to stay at this rate [20:55:26 CET] <JEEB> yea [20:55:32 CET] <jamrial> might as well fix the remaining issues, reimplement the cmdutils stuff right, and move on [20:55:54 CET] <JEEB> I don't have any heavy feelings about the API, and not sure if the mentioned alternatives actually bring much extra to the table [20:56:56 CET] <wm4> lavd has a kms thing? jesus [20:57:12 CET] <wm4> lol at the API bikeshed [20:57:43 CET] <atomnuker> it has to in order to have kms capture [20:57:54 CET] <jamrial> why add iterate() at all? next() already exists. all we needed was removing the registration crap [20:58:17 CET] <JEEB> someone asked for renaming or something [20:58:27 CET] <jamrial> lovely precedent this one, for future developers. just push, knowing full well it will stick even if people disagreed [20:58:30 CET] <JEEB> it's in the threads [20:59:06 CET] <JEEB> hmm, someone posted a mpeg-2 video decoding fix? [20:59:10 CET] <BtbN> imo this should be reverted just because of the way it was pushed, and then maybe re-applied after proper discussion [20:59:32 CET] <BtbN> and seeing how it broke a ton of things, it's even more dubious [20:59:34 CET] <jamrial> that'd be ideal, but also make people even more bitter [20:59:37 CET] <atomnuker> jamrial: I think the reason for iterate over next was that next needs to store state somewhere [20:59:46 CET] <wm4> jamrial: because it's either slow, or requires mutating static data [20:59:48 CET] <Chloe> just revert it all [21:00:00 CET] <atomnuker> iterate moved the state storing to the api user iirc [21:00:10 CET] <jamrial> no, i don't want to revert it all. i want to move forward [21:00:14 CET] <Chloe> then you can design the API [21:00:31 CET] <wm4> like nicolas wants with memory allocation? no thanks [21:01:59 CET] <durandal_1707> that guy.... [21:02:17 CET] <Chloe> The reason for _iterate is to clarify on what the API does exactly, and the reason for the API being like it is the same as the reasoning for the newer BSF API [21:05:51 CET] <Chloe> And yes I know it was my bad with the cmdutils patch, sorry about that one. [21:09:58 CET] <jamrial> fate passed, so i understand why you would expect it was fine [21:10:02 CET] <jamrial> the major bump was the same [21:10:27 CET] <Chloe> I checked -formats but I completely forgot about -codecs (and friends) [21:11:29 CET] <Chloe> jamrial: do you think the last patch I posted on the ML (for cmdutils) was going in the right direction at least? [21:15:15 CET] <durandal_1707> michaelni: how utvideodec change fixes overread if it checks smaller number? [21:17:04 CET] <jamrial> Chloe: i don't know, i'm not familiar with that code [00:00:00 CET] --- Fri Feb 9 2018