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

[burek]

[00:00:26 CEST] <atomnuker> TD-Linux: apparently not in the EU, https://ffii.org/Frequently%20Asked%20Questions%20about%20software%20patents
[00:00:40 CEST] <atomnuker> (under "source code privilege")
[00:01:13 CEST] <atomnuker> nvm, that's for a draft, idk then
[00:01:15 CEST] <ubitux> (wtf @ cthulu)
[00:02:23 CEST] <BtbN> cthulu?
[00:02:55 CEST] <ubitux> libav didn't know how to name a variable
[00:03:09 CEST] <ubitux> cthulu = (a >= 0) + (a ^ (a >> 31)) - (a >> 31);
[00:04:02 CEST] <ubitux> (i wouldn't either, but that's a strange name neverless)
[00:04:22 CEST] <ubitux> though it looks like a pattern i already saw
[00:04:34 CEST] <BtbN> Well, some of the code at work has various colors of magic all over the code
[00:05:52 CEST] <BtbN> (a ^ (a >> 31)) - (a >> 31) certainly looks familiar. But I have no idea what it does. Some proper variable name would have been nice
[00:07:07 CEST] <durandal_1707> yes, dont_rename_me
[00:08:32 CEST] <BtbN> Does it just count the 1 bits?
[00:09:23 CEST] <durandal_1707> also its unneeded because michaelni simplified it abd they didnt pick our change as usual
[00:10:07 CEST] <ubitux> what about the reconfiguration part?
[00:10:37 CEST] <ubitux> and NB_LEVELS?
[00:11:00 CEST] <durandal_1707> size_t change is pointless
[00:11:25 CEST] <ubitux> "reinit should dimensions change"
[00:11:29 CEST] <ubitux> i'm not sure what that mean
[00:11:36 CEST] <ubitux> but that part may have some value?
[00:11:57 CEST] <ubitux> (missing "handle" probably)
[00:13:34 CEST] <durandal_1707> nb levels is fine
[00:13:44 CEST] <cone-361> ffmpeg 03Ivan Kalvachev 07master:3a6ded7cfcb3: Fix crash if av_vdpau_bind_context() is not used.
[00:13:46 CEST] <durandal_1707> change*
[00:15:10 CEST] <cone-361> ffmpeg 03Ivan Kalvachev 07release/3.4:7fb85ad3607a: Fix crash if av_vdpau_bind_context() is not used.
[00:16:46 CEST] <cone-361> ffmpeg 03James Almer 07master:4b175913bed8: build: fix builds configured with a suffix
[00:19:24 CEST] <ubitux> k, so i'll push that in a moment
[00:20:34 CEST] <ubitux> jamrial: are you in the middle of a merge?
[00:20:50 CEST] <jamrial> ubitux: no, i'm fixing shit from the extralibs merge :p
[00:21:05 CEST] <jamrial> been doing that all day
[00:25:46 CEST] <cone-361> ffmpeg 03Clément BSsch 07master:368fb74831c0: lavc/pixlet: reduce diff with Libav (cosmetics only)
[00:25:47 CEST] <cone-361> ffmpeg 03Clément BSsch 07master:d1aef7d08a06: lavc/pixlet: remove unecessary intermediate nb_levels variable
[00:25:57 CEST] <nevcairiel> I can make you a Mac config.mak in a bit if you still need it. Been out all evening and only on the phone
[00:26:07 CEST] <ubitux> jamrial: you have all my sympathy.
[00:26:19 CEST] <jamrial> nevcairiel: ok, thanks
[00:26:39 CEST] <jamrial> and yeah, i'm curious about what extralibs get added to each library
[00:27:06 CEST] <ubitux> durandal_1707: no opinion on the explicit i16 sat jamrial mentioned?
[00:27:24 CEST] <ubitux> (line_add_sat_s16)
[00:27:49 CEST] <ubitux> anyway, my job is done here
[00:28:17 CEST] <durandal_1707> ubitux: well i dont think its same thing
[00:28:30 CEST] <ubitux> it probably isn't yes
[00:28:36 CEST] <ubitux> which one is correct?
[00:29:05 CEST] <durandal_1707> maybe it will work better but its not what was in binary
[00:29:46 CEST] <durandal_1707> better not merge that clip thing
[00:51:56 CEST] <dylanmach1_> hello, i am having trouble compiling and making a static bin of ffmpeg on macOS from the git
[00:57:51 CEST] <jamrial> dylanmach1_: can you open a ticket in https://trac.ffmpeg.org/ detailing what's wrong?
[00:58:12 CEST] <dylanmach1_> sorry, sure i will try
[01:01:50 CEST] <nevcairiel> jamrial: http://termbin.com/7iff1 working ./configure --enable-shared on osx
[01:02:32 CEST] <jamrial> nevcairiel: you're not getting issues with avutil's hwcontext_videotoolbox module?
[01:02:58 CEST] <nevcairiel> no it build fine
[01:03:06 CEST] <nevcairiel> avutil also has -framework VideoToolbox
[01:03:29 CEST] <nevcairiel> let me make sure and just do it again
[01:03:44 CEST] <jamrial> yeah, but afaik it should also have corevideo
[01:03:54 CEST] <jamrial> if anything because it's set as a dep for videotoolbox
[01:05:56 CEST] <nevcairiel> i have no idea how the dep resolver works
[01:06:30 CEST] <nevcairiel> avutil_extralibs includes all sorts of vaapi and vdpau stuff, but no entry for videotoolbox, maybe it should?
[01:07:07 CEST] <cone-361> ffmpeg 03James Almer 07master:9c0279bc2c7b: configure: fix CoreGraphics module name
[01:07:17 CEST] <jamrial> nevcairiel: no, look at avutil_suggest
[01:07:19 CEST] <wm4> it definitely uses corevideo functions, though strangely no Vt ones
[01:07:28 CEST] <nevcairiel> jamrial: that also includes vaapi again
[01:07:33 CEST] <nevcairiel> so still not clear
[01:07:33 CEST] <nevcairiel> :D
[01:08:04 CEST] <jamrial> no, _extralibs includes vaapi_x11 and vaapi_drm :p
[01:08:15 CEST] <jamrial> it's a mess of internal modules
[01:09:21 CEST] <jamrial> avutil_suggest includes videotoolbox, videotoolbox_deps includes corevideo, coremedia and corefoundation, but they are not showing up in avutil in the end
[01:09:39 CEST] <jamrial> it's like avutil is resolved first, then videotoolbox, point where it's already late
[01:10:06 CEST] <nevcairiel> from what i can tell, the vdpau x11 functions for example are the only thing it actually links to
[01:10:12 CEST] <nevcairiel> it doesnt link to any normal vdpau
[01:10:13 CEST] <jamrial> i can just say fuck it and add corevideo, coremedia and corefoundation to avutil_suggest, but you're not getting build failures and it's weird
[01:10:16 CEST] <nevcairiel> lets check vaapi
[01:10:52 CEST] <jamrial> zeranoe had a build failure because avutil was not adding corevideo
[01:11:05 CEST] <nevcairiel> maybe it just should be in extralibs
[01:11:45 CEST] <nevcairiel> vaapi_drm_extralibs for example always includes -lva as well, so it would never be missing
[01:13:34 CEST] <jamrial> nevcairiel: doing bar_suggest="foo" is the same as doing bar_extralibs="foo_extralibs"
[01:14:07 CEST] <nevcairiel> apparently configure disagrees with you
[01:14:14 CEST] <jamrial> really?
[01:14:20 CEST] <nevcairiel> well its not doing that, is it? :D
[01:14:51 CEST] <nevcairiel> also i actually finished the shared build and it fails as well, i might have done a static build earlier
[01:15:02 CEST] <wm4> looking forward to the day ffmpeg uses a real build system
[01:15:12 CEST] <nevcairiel> as if any of those are any better
[01:15:43 CEST] <jamrial> nevcairiel: try adding corevideo coremedia and corefoundation to avutil_suggest
[01:16:19 CEST] <jamrial> or their _extralibs to avutil_extralibs. both should be the same
[01:16:20 CEST] <nevcairiel> apparently its not doign recursive lookups, or well, maybe its doing that in the wrong order
[01:16:37 CEST] <jamrial> yeah, as i said, probably it's resolving avutil first, then videotoolbox
[01:16:40 CEST] <jamrial> but it shouldn't
[01:17:46 CEST] <jamrial> i'll just add those three to avutil for now, if you confirm it fixes it
[01:18:25 CEST] <wm4> nevcairiel: can't be worse than trying to write recursive graph resolver algorithms in shell (which is what configure does, including emulating a stack)
[01:26:07 CEST] <cone-361> ffmpeg 03James Almer 07master:4440bcf6a0cf: configure: fix pthread_cancel check
[01:29:01 CEST] <cone-361> ffmpeg 03Luca Barbato 07master:abb5efca263d: configure: Fix sem_timedwait probe
[01:34:24 CEST] <jamrial> jkqxz: regarding hwcontext_videotoolbox, does it really need videotoolbox? or would corevideo suffice for it?
[01:34:39 CEST] <nevcairiel> jamrial: the order of expansions seems fine, but for some reason its not actually expanding the extralibs inside videotoolbox, ie it remains "videotoolbox_extralibs: -framework VideoToolbox corefoundation_extralibs coremedia_extralibs corevideo_extralibs coreservices_extralibs"
[01:35:35 CEST] <jamrial> huh
[01:35:39 CEST] <wm4> jamrial: corevideo is enough AFAIK
[01:35:50 CEST] <wm4> only libavcodec actually calls into VT
[01:36:44 CEST] <jamrial> wm4: it's currently including videotoolbox.h, so to make it corevideo only it needs a couple changes at least
[01:37:21 CEST] <jamrial> nevcairiel: ah, guess those three should have an entry in some of the lists
[01:37:30 CEST] <wm4> oh right
[01:37:39 CEST] <wm4> that include is unnecessary, but there, d'oh
[01:37:54 CEST] <nevcairiel> jamrial: it appears the final resolver doesnt support endless indirection, it seems to only do 2 levels
[01:38:02 CEST] <jamrial> ah
[01:38:06 CEST] <jamrial> well damn
[01:38:15 CEST] <wm4> LOL
[01:38:17 CEST] <wm4> why 2
[01:38:19 CEST] <jamrial> anyway, if it can be simplified to only use corevideo that would be much better
[01:38:21 CEST] <nevcairiel> unless i read this wrong
[01:38:38 CEST] <wm4> jamrial: I mean, it's part of the API, so it's fucked
[01:38:43 CEST] <wm4> (not sure why I did this crap)
[01:38:57 CEST] <jamrial> wm4: can't it be made include corevideo.h?
[01:39:14 CEST] <wm4> jamrial: hwcontext_videotoolbox.h also includes it, and it's a public header
[01:40:14 CEST] <jamrial> mmh, in makefile the file is listed under CONFIG_VIDEOTOOLBOX
[01:40:41 CEST] <nevcairiel> lets see where this entry goes missing
[01:40:41 CEST] <jamrial> so, can we just make it corevideo, or will it "break" the API?
[01:41:06 CEST] <wm4> jamrial: it will "break" it, yes
[01:41:19 CEST] <wm4> in theory
[01:41:41 CEST] <wm4> personally I'd say the user shouldn't rely on such recursive includes
[01:41:44 CEST] <wm4> *API user
[01:42:16 CEST] <nevcairiel> yeah for some reason flatten_extralibs doesnt copy all the entries over for avutil, odd
[01:42:50 CEST] <wm4> (also I should fix that the hwcontext_videotoolbox.h functions are missing if videotoolbox is disabled at compile time)
[01:43:06 CEST] <wm4> (also I should fix that videotoolbox fucking blows up if threads are enabled in lavc)
[01:44:29 CEST] <jamrial> just make it corevideo. if the user has videotoolbox, they have corevideo. it's apparently dep of the former after all
[01:44:53 CEST] <wm4> definitely
[01:48:47 CEST] <nevcairiel> i think i figured out whats wrong, after it processed a _extralibs entry once, it resolves one level of nesting and then removes any remaining _extralibs entries from it, because it thinks it should have already resolved those
[01:48:53 CEST] <nevcairiel> and woosh it goes missing
[01:49:40 CEST] <jamrial> how to fix it?
[01:50:18 CEST] <nevcairiel> unclear
[01:52:12 CEST] <jamrial> ok, do i add those three modules to avutil in the meantime? even if wm4 makes it use only corevideo later and if we fix flatten_extralibs
[01:52:28 CEST] <jamrial> we really need to get macos shared build back up asap
[01:53:49 CEST] <nevcairiel> the issue is in the flatten_extralibs function anyway, for future reference
[01:54:19 CEST] <nevcairiel> perhaps it should recurse in the loop or something
[01:54:55 CEST] <jamrial> sort of like check_deps does
[01:55:12 CEST] <wm4> jamrial: you mean add the corevideo libs etc. directly? sure why not
[01:56:17 CEST] <jamrial> wm4: configure currently adds videotoobox to avutil extralibs. i'll make it add all three deps for videotoolbox as well since those are not beign resolved because of a bug in flatten_extralibs
[01:56:18 CEST] <nevcairiel> perhaps the eval assignment in the loop should just be removed, thats what clears it out
[01:56:36 CEST] <nevcairiel> or hm maybe not
[01:56:37 CEST] <jamrial> wm4: but after that, you could make it corevideo only
[01:57:52 CEST] <nevcairiel> on second thought, the eval assignment does seem a bit fishy, maybe its trying to speed up lookups or something, but by messing with the extralibs like that, if two things reference the same _extralibs thing, they would not see the same thing
[01:58:00 CEST] <wm4> jamrial: that requires a 2 year deprecation period, if going by the book
[01:58:08 CEST] <wm4> how do you deprecate include statements
[01:58:19 CEST] <jamrial> do they need to be deprecated?
[01:58:24 CEST] <nevcairiel> just do it with th e major  bump
[01:58:34 CEST] <jamrial> i mean, if videotoolbox.h exists, corevideo.h will also exist
[01:58:40 CEST] <jamrial> it's not like it will break anything
[01:58:49 CEST] <wm4> it all depends whether we consider it part of the API or ABI or anything
[02:00:54 CEST] <jamrial> nevcairiel: i'll apply https://pastebin.com/sNQMA1Vq for now, is that ok?
[02:01:06 CEST] <nevcairiel> probably?
[02:01:35 CEST] <wm4> if it works it's ok
[02:02:00 CEST] <jamrial> unless flatten_extralibs can be fixed soon. otherwise mac users will start reporitng en masse :P
[02:02:31 CEST] <nevcairiel> its weird diego shell code, who knows what exactly its there for
[02:03:03 CEST] <nevcairiel> it definitely seems fishy to mess with the existing entries in such a way though
[02:03:51 CEST] <nevcairiel> anyway let me test a build  with that changed
[02:06:20 CEST] <nevcairiel> yeah builds now
[02:07:03 CEST] <jamrial> ok
[02:07:06 CEST] <nevcairiel> its fascinating that videotoolbox would be the only component with double nested components which is used in more then one library
[02:07:08 CEST] <winegums_> what are the common flags you use for static building?
[02:07:21 CEST] <nevcairiel> and apparently libav doesnt have VT yet, so they didnt run into this issue?
[02:07:32 CEST] <winegums_> i enabled static, disabled shared, and used the pkg config flag for static
[02:07:38 CEST] <cone-361> ffmpeg 03James Almer 07master:34dbee9f601f: configure: explicitly list videotoolbox deps for avutil
[02:08:21 CEST] <wm4> Libav still have VDA, but who still builds VDA these days
[02:08:32 CEST] <nevcairiel> but no vda in avutil
[02:09:36 CEST] <wm4> oh, true
[02:10:13 CEST] <nevcairiel> the problem only comes up if two libraries reference the same component, and that component has two levels of nested libraries
[02:10:26 CEST] <nevcairiel> nested extralibs*
[02:16:28 CEST] <nevcairiel> .. and hardware stuff is probably the only things that are even shared between any libraries
[02:16:56 CEST] <jamrial> nevcairiel: videotoolbox is that way because i made it that way to simplify some checks. good to know it revealed a bug :p
[02:18:08 CEST] <jamrial> wm4: we also have vda, but it's going to be removed after the bump
[02:18:29 CEST] <wm4> good
[03:20:46 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:27a0a8388082: avcodec/mips: Improve avc chroma avg horiz mc msa functions
[03:20:47 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e549933a270d: avcodec/mips: Improve avc put mc 12, 32 and 22 msa functions
[03:20:48 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e63758468c64: avcodec/mips: Improve hevc bi copy mc msa functions
[03:20:49 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:6ca821a3e775: avcodec/mips: Improve hevc uni horiz mc msa functions
[03:20:50 CEST] <cone-361> ffmpeg 03Kaustubh Raste 07master:e5439e272ed1: avcodec/mips: Improve hevc uni weighted vert mc msa functions
[03:20:51 CEST] <cone-361> ffmpeg 03Gyan Doshi 07master:147c1e008a7b: doc/filters: correct typo and incomplete desc.
[09:39:57 CEST] <thebombzen> I think the vf_zscale wrapper is segfaulting for alignment reasons
[09:40:14 CEST] <thebombzen> https://0x0.st/CQx.log
[15:31:30 CEST] <cone-189> ffmpeg 03James Almer 07master:15dc897582ad: configure: list libv4l2 as an optional library for v4l2
[16:24:48 CEST] <cone-189> ffmpeg 03James Almer 07master:6b52c0b583b8: configure: add missing zlib extralibs to the libmysofa check
[17:20:53 CEST] <jamrial> nevcairiel: what do you think about 81bffae368? (libav commit)
[17:22:50 CEST] <wm4> so what should we do to get an actually working maintainer system
[17:24:08 CEST] <jamrial> wm4: you mean the wtv patch just pinged on the ml?
[17:24:21 CEST] <cone-189> ffmpeg 03Daniel Kucera 07master:feed201849b8: libavformat/wtvdec: return AVERROR_EOF on EOF
[17:24:21 CEST] <wm4> I just pushed that
[17:24:25 CEST] <wm4> but yes
[17:24:36 CEST] <jamrial> is Peter Ross still around?
[17:24:37 CEST] <wm4> in this case, the maintainer's agreement isn't even necessary
[17:24:48 CEST] <wm4> last patch by him was mid 2016
[17:25:25 CEST] <jamrial> guess he didn't see the patch, then everyone else (including nicolas who reviewed it) forgot about it
[17:25:50 CEST] <wm4> there's certainly no reason to wait 4 months to apply such a small fix
[17:26:05 CEST] <wm4> that only frustrates drive-by contributors
[17:26:23 CEST] <jamrial> true
[17:27:12 CEST] <jamrial> nicolas could have pushed it himself after a bit. or someone else could have noticed it was such a small change that it didn't need the maintainer to chime in
[17:28:01 CEST] <jamrial> but it didn't happen, and it got buried. it sucks, but it happens
[17:28:07 CEST] <jamrial> the author could have also pinged much earlier, as well
[17:28:15 CEST] <wm4> I interpret that as smug "not my problem"
[17:28:26 CEST] <jamrial> no, i mean shit happens
[17:28:34 CEST] <jamrial> it's one of the reasons we added patchwork afaik
[17:28:36 CEST] <wm4> that too, additonally
[17:28:40 CEST] <wm4> *additionally
[17:28:44 CEST] <wm4> does anyone use patchwork?
[17:28:47 CEST] <jamrial> since patches on the ml get buried often
[17:28:54 CEST] <jamrial> almost nobody, and that's the problem
[17:29:06 CEST] <wm4> clearly we should switch all development to github
[17:29:23 CEST] <BtbN> so we burry issues and pullrequests instead of mails?
[17:30:31 CEST] <wm4> yes (also that was sarcasm)
[17:30:43 CEST] <wm4> personally I don#t think github would work for ffmpeg
[17:31:31 CEST] <BtbN> It would fail because a bunch of people would refuse to work with it.
[17:31:40 CEST] <jamrial> what about gerrit?
[17:31:53 CEST] <BtbN> So you combine the pain of github and a mailinglist?
[17:31:57 CEST] <wm4> the only time I tried gerrit I wanted to die
[17:32:19 CEST] <jamrial> BtbN: everyone gets both what they want and what they hate that way :D
[17:32:36 CEST] <wm4> anyway, the thing with the maintainer list is mostly a policy/organization issue
[17:32:53 CEST] <atomnuker> jamrial: I hope that was sarcasm, gerrit is far far worse than mailing lists and stuff there gets buried way more often
[17:33:03 CEST] <wm4> basically the maintainer list is usless
[17:33:07 CEST] <jamrial> also that a lot of people mentioned there have long since disappeared
[17:33:21 CEST] <jamrial> atomnuker: yes, it was
[17:33:44 CEST] <BtbN> gerrit makes sense for massive things like Qt or Android that span accross multiple repos
[17:36:56 CEST] <atomnuker> it really doesn't make sense for anything
[17:37:18 CEST] <atomnuker> it hardly works too
[17:37:47 CEST] <BtbN> How else would you manage patch review for something of the scale of Android?
[17:38:47 CEST] <wm4> atomnuker: have you ever use depot-tools
[17:43:10 CEST] <atomnuker> no, but seeing its a google thing for chromium only really means that's all I need to know
[17:44:57 CEST] <wm4> google uses it for everything
[17:45:11 CEST] <wm4> and it's an ultra-clunky POS that forces you to use git in a worse way
[17:59:16 CEST] <Gramner> VGF2P8AFFINEINVQB the x86 mnemonics keep getting better
[18:11:59 CEST] <wm4> kierank: "Test api-band failed. Look at tests/data/fate/api-band.err for details."
[18:12:03 CEST] <wm4> kierank: it was worth it
[18:13:04 CEST] <kierank> :)
[18:13:05 CEST] Action: kierank happy
[18:13:54 CEST] <wm4> I'd rather remove this shitty API though
[18:14:01 CEST] <kierank> draw_horiz_band?
[18:14:12 CEST] <kierank> we are going to use it
[18:14:18 CEST] <wm4> yes... even if someone wants this for low latency or whatever, there ought to be better ways
[18:14:31 CEST] <kierank> it's useful for more than low latency
[18:14:38 CEST] <kierank> it's useful if you need to transform the data when it's fresh in cache
[18:16:43 CEST] <wm4> I know, mplayer had an entire framework around it
[18:16:46 CEST] <wm4> and now it's dead
[18:26:15 CEST] <wm4> fucking wow
[18:26:40 CEST] <wm4> merely calling av_frame_clone on the frame passed to draw_horiz_band and then unreffing it makes it crash
[18:26:43 CEST] <wm4> something about side data shit
[18:27:32 CEST] <wm4> so it's a broken piece of shit, but the theoretical corner case michaelni pointed out is still grounds to rejecting my patch
[18:27:40 CEST] <wm4> michaelni: some well done trolling
[18:29:32 CEST] <wm4> actually no, PECKAC, but I still feel trolled
[18:42:30 CEST] <winegums_> hi all, sorry if this is a dumb question i have been stuck for a long time now and cant figure this out. I am trying to make a static bin of FFmpeg for macOS, however I cant figure out: ld: library not found for -lcrt0.o
[18:50:25 CEST] <wm4> jkqxz: is there a test for the wrapped_avframe decoder?
[18:50:56 CEST] <jamrial> winegums_: what's giving you that error?
[18:51:22 CEST] <winegums_> thats during configure && make, want me to share configure?
[18:51:37 CEST] <winegums_> ill pm it
[18:54:45 CEST] <jkqxz> wm4:  "Try to run kmsgrab".  (There is no standalone test.)
[18:55:47 CEST] <jkqxz> Muhammad Faiz (who is not here, I think?) was interested in using it to simplify some rawvideo stuff too, that could be looked at again.
[18:57:14 CEST] <jamrial> this extralibs commit is really showing how all these libraries we have wrappers for don't properly list all their deps in their pkg-config file
[18:57:34 CEST] <wm4> can't run kmsgrab
[18:58:20 CEST] <jamrial> so many of the breakages have been cases of missing -lpthread, -lstdc++, -lz, -lm...
[19:17:07 CEST] <winegums_> not sure if this relates but that seems to happen to me with x265
[19:17:17 CEST] <winegums_> ld: symbol(s) not found for architecture x86_64
[19:18:02 CEST] <winegums_> thats with using a static build of x265
[19:59:37 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/cuda/dynlink_cuviddec.h;h=4af78a186baa80d57559867d3aebc0b1b3e0e194;hb=HEAD#l725 i wish there was more documentation about this than those few fields
[20:03:07 CEST] <FMatteo101101> Hello,....I wanted to ask if there was someone that could help me develop a certain functionality for a 2 stream merging (one live and one for a translator),....the problem I have is with the translator disconnecting
[20:03:21 CEST] <FMatteo101101> and the whole thing stopping...
[20:23:36 CEST] <wm4> BtbN: oh dear, so you're basically RE'ing their API?
[20:24:07 CEST] <BtbN> The obvious way does not work
[20:24:15 CEST] <BtbN> And I don't really have another idea
[20:25:28 CEST] <Compn> FMatteo101101 : you want to hire a developer ?
[20:25:44 CEST] <Compn> FMatteo101101 : feel free to ask here or on ffmpeg-devel mailing list, if you are offering to pay ...
[20:25:45 CEST] <wm4> do they not have any sort of API trace tool, and some programs that actually use the cuvid filters?
[20:25:59 CEST] <wm4> and why would nvidia not want ffmpeg to be able to use those filters?
[20:26:16 CEST] <Compn> contract that says only nvidia can use technology ?
[20:27:15 CEST] <BtbN> wm4, I'm not aware of any program using cuvid in that way.
[20:27:29 CEST] <BtbN> And when googling for the enum and function names, I think nobody before ever tried
[20:27:52 CEST] <FMatteo101101> Compn: ok I will write to ffmpeg-devel list and here
[20:28:15 CEST] <FMatteo101101> If there is a good ffmpeg developer please write to me
[20:28:32 CEST] <FMatteo101101> I am willing to put some money on the table
[20:30:18 CEST] <wm4> BtbN: possibly such as proprietary nvidia tools or such
[20:30:29 CEST] <wm4> of course only useful if you'd literally RE it
[20:30:42 CEST] <BtbN> Using the cuda filter while decoding is easy and implemented in ffmpeg
[20:30:55 CEST] <BtbN> it is putting raw YUV in and out of if that is a problem
[20:32:41 CEST] <BtbN> I'm not aware of anything that might use cuvid as a pure frame filter
[20:57:28 CEST] <wm4> BtbN: I'm still appalled by how we apparently have no nvidia contact, despite nvidia contributing to ffmpeg (what's even going on)
[21:00:29 CEST] <BtbN> Yogender kind of is I think
[21:09:45 CEST] <jamrial> wm4: you're too fast to get angry. he actually made a suggestion in another (older even) email to that same thread
[21:19:13 CEST] <wm4> I just wrote another post
[21:19:27 CEST] <wm4> I don't see any suggestions
[21:19:34 CEST] <wm4> at least not any that work or that are not stupid
[21:19:39 CEST] <BtbN> Would it really be so horrible to add an internal_opaque_ref? Just to get rid of this annoying discussion?
[21:19:47 CEST] <wm4> why the fuck am I even dealing with this on a friday evening
[21:20:20 CEST] <wm4> BtbN: I'll agree with it if we call the field michaelnis_bullshit
[21:21:08 CEST] <BtbN> I kind of see the potential issue that this is something everyone dealing the API will have to keep in mind at all times, so some seperation there might not be bad. And it really does not seem messy to me to do so.
[21:21:24 CEST] <BtbN> dealing with it internally
[21:21:31 CEST] <BtbN> an API user obviously does not care
[21:21:42 CEST] <wm4> you mean, like having an opaque field?
[21:22:31 CEST] <wm4> the only other way I see is having a AVInternalFrame { AVFrame *frame; InternalState state; } struct
[21:22:43 CEST] <wm4> but I'd like to avoid rewriting 100% of libavcodec
[21:23:05 CEST] <BtbN> I mean just adding a second opaque field right next to the current one (without breaking ABI)
[21:23:30 CEST] <wm4> no because we're not going to add public fields for every internal use case
[21:23:43 CEST] <wm4> and strictly speaking you'd have to allow such fields for external applications too
[21:23:51 CEST] <wm4> can't wait to add a mpv_internal_ref field to AVFrame
[21:24:07 CEST] <wm4> because I need it and I'd like to avoid collision with other opaque_ref uses
[21:24:17 CEST] <BtbN> Is the size of AVFrame part of the ABI?
[21:24:22 CEST] <wm4> no
[21:24:29 CEST] <wm4> not anymore
[21:25:04 CEST] <BtbN> an AVFrameInternal struct that's a member of AVFrame, but not in a public header?
[21:26:28 CEST] <BtbN> I'd expect that to break a lot of application that put AVFrames on the stack or something, but meh
[21:26:33 CEST] <wm4> and how would you use this
[21:26:40 CEST] <wm4> maybe like opaque_ref?
[21:27:04 CEST] <BtbN> Just without the backup-copy you need to put back when returning the frame
[21:27:56 CEST] <wm4> so what happens if within libavcodec, you use another piece of code that wants to use AVFrameInternal for its own purposes
[21:29:28 CEST] <BtbN> The same that would happen with the opaque_ref field right now?
[21:29:51 CEST] <wm4> yes
[21:29:56 CEST] <wm4> you'd have to wrap and unwrap it
[21:30:54 CEST] <BtbN> Unless you make some kind of dict there, but that starts to get messy
[21:31:30 CEST] <wm4> even a dict would be messy
[21:31:46 CEST] <wm4> what if the key is not unique, or you do nested things (consider nested codecs or filters)
[21:32:58 CEST] <BtbN> Could make some kind of opaque_ref stack. And whoever puts something on there, has to make sure it gets put off there again
[21:33:31 CEST] <wm4> that's what the patch does
[21:33:54 CEST] <wm4> it's not an explicit stack, but you get a list of chained AVBufferRefs
[21:37:16 CEST] <BtbN> hm, maybe do that, but in a new opaque_ref_stack field, which is required to just contain that chain, so you don't accidentially cast the wrong type?
[21:38:02 CEST] <wm4> how would that improve anything? you can still "unbalance" the stack accidentally
[21:38:03 CEST] <BtbN> Doesn't even need to be a buffer ref. Just a FrameDecodeData*
[21:38:48 CEST] <BtbN> You don't change semantics of an existing field
[21:39:18 CEST] <wm4> I don't understand
[21:51:03 CEST] <BtbN> just looking through this is already confusing
[21:51:15 CEST] <BtbN> but I'm not sure either solution is less confusing
[21:58:15 CEST] <wm4> it's not confusing - opaque_ref within libavcodec always points to the internal thing
[21:58:27 CEST] <wm4> and on frame output it's removed (and the hwaccel postproc callback is run)
[21:58:54 CEST] <wm4> the main confusing thing is probably that Libav allows the user to set opque_ref in get_buffer2, so it has to be "wrapped"
[22:05:09 CEST] <BtbN> So it just always expects to find a struct there, that, as its first element, has an AVBufferRef*?
[22:06:00 CEST] <wm4> it only expects to find what it put there
[22:06:35 CEST] <BtbN> But how do you make use of that struct? The actual usage adds fields there I guess?
[22:08:07 CEST] <wm4> you mean what it's used for?
[22:09:33 CEST] <BtbN> Yeah, just reading the 3rd patch again
[22:10:47 CEST] <BtbN> Wouldn't just adding an AVFrameInternal internal; field to AVFrame with thise post_process fields work as well?
[22:12:37 CEST] <BtbN> But I guess API misusers would screem then, as you can't have AVFrame on the stack anymore
[22:12:45 CEST] <wm4> yes, but then you'd have a libavcodec-only field in AVFRame
[22:13:05 CEST] <wm4> and it'd break with nested AVCodecContext instances anyway (that was something michaelni complained about with opaque_ref)
[22:13:28 CEST] <wm4> you cant have AVFrame on the stack
[22:15:36 CEST] <BtbN> AVFRame { AVFrameInternal *internal }; struct AVFrameInternal { AVFrameInternal *next; } and AVCodec and AVFilter can have their own AVCodec/FilterFrameInternal, as long as the first element is a *next where they build a stack if they want to add their own data.
[22:17:47 CEST] <BtbN> would also allow for nested decoders/encoders to just put their own stuff in front
[22:18:56 CEST] <wm4> I don't see how this would be more convenient or more robust than just rewrapping opaque_ref as the frame is transferred between boundaries
[22:20:40 CEST] <BtbN> it's roughly equivalent, but does not "abuse" an opaque field that was originally intended to be used by API users
[22:21:15 CEST] <BtbN> And users cannot set it in get_buffer, so safes a bit of code I guess?
[22:21:30 CEST] <BtbN> well, they in theory can, but the resulting crash is their own fault
[22:22:09 CEST] <wm4> the opaque_ref API user in this case is libavcodec too
[22:22:22 CEST] <wm4> opaque_ref has no meaning for AVFRame/libavutil itself
[22:22:34 CEST] <wm4> it's for free use by whatever uses AVFrames to do stuff
[22:22:39 CEST] <wm4> which in this case is libavcodec
[22:22:57 CEST] <wm4> libavcodec does this wrapping stuff merely to not conflict with the user's opaque_ref
[22:23:12 CEST] <wm4> which in turn is _only_ because apparently we support it in get_buffer
[22:23:42 CEST] <wm4> an AVFrameInternal would not change the situation because the user could use it
[22:24:02 CEST] <BtbN> how? It wouldn't be defined in a public header.
[22:24:29 CEST] <wm4> well then libavcodec can't use it
[22:24:59 CEST] <BtbN> libavcodec is not allowed to include non-public headers from libavutil?
[22:26:42 CEST] <wm4> well you could make it some avpriv API or whatever
[22:26:59 CEST] <wm4> still not a solution
[22:27:23 CEST] <wm4> you don't just add dedicated fields to generic data structures for some internal use
[22:27:33 CEST] <wm4> it's enum bool {FALSE, TRUE, FILE_NOT_FOUND} design
[22:28:46 CEST] <winegums_> (in reference to making static ffmpeg on macOS) I have nearly gotten everything working& most libs are now static except for some framework stuff, I compiled ffmpeg on 10.12, it works for 10.12 users but when testing on 10.9 it asks for CoreImage.framework any idea how I can make that static or build for a lower target with make?
[22:31:37 CEST] <winegums_> also is there anyone here insterested in hired work around the audio codecs
[22:34:49 CEST] <Compn> winegums_ : ask on ffmpeg-devel as well, not all devs are on irc
[23:09:40 CEST] <atomnuker> BBB: did you start writing a decoder or are you working on an av1 encoder?
[23:09:54 CEST] <BBB> its sort of the same thing TBH
[23:10:08 CEST] <BBB> but right now its an encoder; I thought you had a decoder?
[23:13:29 CEST] <jamrial_> he wrote a decoder for an old daala bitstream, i think
[23:14:45 CEST] <atomnuker> yeah, that was a long time ago now though
[00:00:00 CEST] --- Sat Oct 14 2017