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

[burek]

[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=packages/x265#n30
[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