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

[burek]

[00:16:56 CEST] <daddesio> BBB: if it's worth adding seeking support to the MicroTalk decoder, then would it be worth adding seeking support to the Electronic Arts demuxer?
[00:19:25 CEST] <daddesio> as in, add a read_seek function in the EA demuxer.
[00:34:14 CEST] <BBB> daddesio: if the format allows for it, yes
[00:34:40 CEST] <BBB> daddesio: I believe mike once talked about why he didnt add it, I believe it was because the video streams in there typically only have one keyframe, so you cannot seek anyway
[00:34:43 CEST] <BBB> iirc
[00:34:44 CEST] <BBB> it was longa go
[01:45:05 CEST] <jamrial> atomnuker: you wondered if the matroska demuxer could be optimized, i just made matroska_parse_frame() 10x faster
[01:46:43 CEST] <atomnuker> oh wow, nice
[04:44:29 CEST] <Compn> someone say vivo ?
[05:36:25 CEST] <atomnuker> jkqxz_: I'm getting jitter when using kmsgrab with a vaapi interop and muxing to mkv, I thought that issue was fixed, wasn't it?
[05:42:16 CEST] <atomnuker> also can anyone else confirm -f pulse -i default is broken? this used to work recently
[13:30:40 CEST] <JEEB> hmm
[13:30:43 CEST] <JEEB> src/libavfilter/f_sidedata.c:72:17: warning: comparison of constant -1 with expression of type 'enum AVFrameSideDataType' is always false
[13:30:46 CEST] <JEEB>       [-Wtautological-constant-out-of-range-compare]
[13:31:01 CEST] <JEEB> clang likes to tell you a comparison is done against a value that's not in the enum
[13:31:38 CEST] <wm4> that's a retarded warning
[13:32:03 CEST] <wm4> or maybe it's not
[13:32:19 CEST] <wm4> it compares with -1 (why)
[13:32:26 CEST] <JEEB> yea
[13:32:36 CEST] <JEEB> if (s->type == -1 && s->mode != SIDEDATA_DELETE) {
[13:33:07 CEST] <JEEB> unless the enum is missing the value which is supposed to be -1
[13:33:14 CEST] <JEEB> but that's a bug in the enum and the code then :P
[13:35:52 CEST] <Icedream> unless there's another warning somewhere else that says something along the lines of "assigning a value that's not in the enum"
[13:36:04 CEST] <Icedream> that'd be just as odd ^ ^ 
[13:36:29 CEST] <jdarnley> That warning sounds like an ffmpeg boolean option: -1, 0, or 1
[14:34:43 CEST] <thardin> can ffmpeg do scene level multithreading?
[14:34:58 CEST] <thardin> a friend of mine is looking into av1, seems all the current encoders are single-threaded
[14:36:01 CEST] Action: jdarnley is having doom9 flashbacks
[14:37:40 CEST] <jdarnley> Also I think the answer to your question is no.
[14:39:00 CEST] <thardin> it strikes me that this is only a problem if you're only coding exactly one video
[16:36:15 CEST] <kepstin> thardin: just wait for the av1 encoder to get better, multithreading is *definitely* in the plans for it.
[16:36:30 CEST] <thardin> of that I have no doubt
[16:36:49 CEST] <thardin> my friend is just wants to get it up and running as fast as possible
[16:37:10 CEST] <kepstin> that said, it should be possible to do the same thing as any other codec, and just divide the input video into segments, encode each separately, then concat
[16:37:41 CEST] <thardin> yep. or run a profiler then some #pragma omp for   in strategic places
[16:38:07 CEST] <kepstin> video coding is.. more complicated than t hat
[16:39:19 CEST] <kepstin> I think the plans with AV1 is to do parallel encoding at the block (superblock? block group? i dunno) level, which means there's a bunch of dependencies due to how the predictors work
[16:40:37 CEST] <kepstin> doing really fine level multithreading would probably slow it down from the extra synchronization, particularly since they've already been doing simd optimization for a lot of the inner loops and whatnot
[16:41:55 CEST] <thardin> ye
[17:03:08 CEST] <cone-031> ffmpeg 03wm4 07master:709e0291d659: avcodec/decode: fix warning when decoding pseudo paletted formats
[17:07:59 CEST] <nevcairiel> Chloe: why did you remove the generated indev/outdev/filter_list.c files from the gitignore when they are clearly still being generated? :)
[17:08:24 CEST] <Chloe> nevcairiel: no reason. They should still be in there. Feel free to re-add them
[17:24:21 CEST] <thardin> kepstin: https://h45h.com/dhbSY9A2KJ0Tq6UyXdatXvephO5TobOsTabYNtB5B1E=  aomenc flamegraph
[17:39:04 CEST] <Chloe> nevcairiel: or i can send a patch if you'd prefer
[17:39:59 CEST] <nevcairiel> not sure when i would get around to sending it, so sure
[18:38:10 CEST] <TD-Linux> nevcairiel, cool, killed annex b
[18:38:24 CEST] <TD-Linux> (in isobmff)
[18:40:52 CEST] <JEEB> \o/
[18:42:34 CEST] <TD-Linux> the main concern was people who wanted to zero-copy rtp packets into mp4. putting the lengths in after the OBU header is more complex than prepending it because you can't zero-copy the whole OBU (only its payload)
[18:42:55 CEST] <wm4> lol
[18:43:10 CEST] <wm4> what a fucking microoptimization that probably won't work out anyway
[18:43:31 CEST] <wm4> also with writev you can source data from multiple places
[18:44:01 CEST] <TD-Linux> :) yeah I think neither firefox or ffmpeg implement zero copy RTP receive (not that ffmpeg is a shining star of RTP)
[18:45:08 CEST] <TD-Linux> but yeah you'll already need to add the lengths so if you use writev for that you can just add one more writev.
[20:05:45 CEST] <cone-031> ffmpeg 03Lou Logan 07master:a2356e509184: doc/developer: update link to "sign-off" info
[20:20:15 CEST] <cone-031> ffmpeg 03Jacob Trimble 07master:b08c132a9c59: avformat/mov: Fix parsing of tfdt when using sample descriptors.
[21:00:49 CEST] <cone-031> ffmpeg 03Valery Kot 07master:67fd8df4197e: avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type
[21:06:29 CEST] <wm4> can we enforce the CoC please
[21:06:33 CEST] <wm4> I'm sick of being attacked
[21:06:47 CEST] <wm4> this is getting personal and goes on my nerves
[21:10:05 CEST] <BBB> I feel for you, but for me its gone too far already, I mostly stay away from the ML
[21:21:05 CEST] <atomnuker> what's going on with cigaes for him to respond like that
[21:21:18 CEST] <nevcairiel> i dont think he has been constructive for months
[21:22:51 CEST] <DJDan>  will NDI FFMPEG work on RPI3 at all?
[21:41:13 CEST] <Chloe> wm4: are you still against the segafilm muxer?
[21:42:31 CEST] <wm4> Chloe: sort of, but no strong feelings
[21:47:58 CEST] <cone-031> ffmpeg 03Martin Vignali 07master:8eb0bb110833: avfilter/x86/vf_blend : reorganize DIFFERENCE macro to reduce line duplication between 8bit and 16 bit version
[21:47:59 CEST] <cone-031> ffmpeg 03Martin Vignali 07master:f3df42e81d36: avfilter/x86/vf_blend : add SIMD for 16 bit version of
[21:48:00 CEST] <cone-031> ffmpeg 03Martin Vignali 07master:595505083a02: checkasm/vf_blend : add test for 16 bit version of
[22:09:51 CEST] <cone-031> ffmpeg 03Martin Vignali 07master:1425114af24d: avcodec/prores_ks : do not call estimate_alpha at each quantification step
[22:28:05 CEST] <Chloe> BBB: what do you use to profile on macOS? The cinepak encoder is encoding 1080p24 at 0.1fps and I can't seem to profile it with instruments
[22:28:15 CEST] <BBB> instruments
[22:28:28 CEST] <wm4> *gasp*
[22:28:30 CEST] <BBB> what is it not telling you?
[22:28:39 CEST] <BBB> you need to compile w/o -fomit-frame-pointer
[22:28:42 CEST] <nevcairiel> wasnt cinepak supposed to be this magically fast thing
[22:28:42 CEST] <durandal_1707> is there a way to force compiler to generate code so output stack variables are in same order as in code?
[22:28:42 CEST] <BBB> and with debug symbols
[22:28:53 CEST] <wm4> nevcairiel: yes
[22:28:57 CEST] <BBB> durandal_1707: -O0
[22:29:14 CEST] <wm4> man we really should fix that ffmpeg requires DCE
[22:29:26 CEST] <Chloe> BBB: it's telling me it spent 388.0ms in ffmpeg over the 40 seconds i profiled it for
[22:29:38 CEST] <durandal_1707> why you profile f**** cinepak?
[22:29:57 CEST] <Chloe> durandal_1707: because it's encoding at 0.1fps and I have no clue why
[22:30:08 CEST] <nevcairiel> the real question is, why do you care
[22:30:25 CEST] <durandal_1707> it is slow for qcif resolutions too
[22:31:02 CEST] <jdarnley> durandal_1707: In addition to what BB said some compilers also have -Og
[22:31:27 CEST] <BBB> Chloe: instruments has many tools, so, which one did you use to measure it?
[22:31:35 CEST] <Chloe> BBB: time profiler
[22:31:41 CEST] <wm4> also -ggdb3
[22:31:44 CEST] <BBB> ok, and then what do you get?
[22:31:46 CEST] <Chloe> maybe that's not the one I'm supposed to use
[22:31:53 CEST] <BBB> no thats the right one
[22:32:00 CEST] <BBB> so you record samples from a running ffmpeg process
[22:32:03 CEST] <BBB> and then what happens?
[22:32:45 CEST] <Chloe> BBB: see https://usercontent.irccloud-cdn.com/file/Ye5NZiug/image.png
[22:33:19 CEST] <BBB> gimme one second :)
[22:33:50 CEST] <nevcairiel> does it even use any cpu while presumably encoding?
[22:34:00 CEST] <nevcairiel> the usage graph doesnt even look all that busy
[22:34:09 CEST] <BBB> so, A) you need -g (debug symbols) and remove -fomit-frame-pointer
[22:34:14 CEST] <BBB> otherwise you dont get call trees
[22:34:15 CEST] <BBB> then
[22:34:20 CEST] <BBB> click Call Tree at the bottom
[22:34:28 CEST] <BBB> remove separate by thread"
[22:34:39 CEST] <nevcairiel> who uses omit-frame-pointers on 64-bit anyway, so many register to waste! /me hides
[22:34:47 CEST] <BBB> select invert call tree"
[22:34:54 CEST] <BBB> nevcairiel: every 1 is 1
[22:35:13 CEST] <BBB> Chloe: and then you should see the functions that are taking cpu time
[22:35:30 CEST] <wm4> nevcairiel: isn't it default
[22:35:46 CEST] <nevcairiel> probably on O3 yes
[22:36:00 CEST] <BBB> Chloe: if with -g and without -fomit-frame-pointer and with invert call tree and without separate by thread you still get garbage let me know and Ill try to help you look further
[22:36:07 CEST] <BBB> O3 is fine, O3 is not the issue
[22:36:13 CEST] <BBB> I get good call trees with O3, and its more real world anyway
[22:36:17 CEST] <Chloe> nevcairiel: yes it's using 100% CPU
[22:36:19 CEST] <BBB> but -fomit-frame-pointer destroys everything
[22:36:31 CEST] <BBB> (in terms of data; its a good option for production)
[22:36:42 CEST] <Chloe> BBB: just `--extra-cflags=-fno-omit-frame-pointer --extra-cxxflags=-fno-omit-frame-pointer` in configure I presume?
[22:36:54 CEST] <BBB> yeah I think so
[22:37:02 CEST] <JEEB> yea, fomit-frame-pointer is good at killing data points
[22:37:34 CEST] <wm4> why can't we have a --enable-debug-mode switch
[22:37:46 CEST] <BBB> nobody said we cant
[22:37:53 CEST] <BBB> Im just being practical in terms of how I do it now
[22:38:04 CEST] <BBB> ideally wed rewrite ffmpeg in python, but thatll take a while
[22:38:16 CEST] <BBB> or rust; I hear at least 7 people on the internet raving about rust
[22:38:18 CEST] <nevcairiel> decoding files would also take a while then
[22:38:19 CEST] <wm4> python doesn't have a debugger
[22:38:39 CEST] <wm4> also I believe you meant rewrite in Rust
[22:38:46 CEST] <wm4> (dunno if that has a debugger)
[22:38:59 CEST] <Chloe> wm4: that just uses normal debuggers afaik
[22:39:00 CEST] <nevcairiel> Rust doesnt need debugging, its a safe language
[22:39:25 CEST] <BBB> so for those who didnt yet figure out I was kidding: AAAAAAAAA
[22:39:42 CEST] <nevcairiel> i like to roll with it, it freaks people out
[22:39:59 CEST] <JEEB> :D
[22:39:59 CEST] <BBB> Chloe: its quite likely itll just tell you that one function is called a lot but it doesnt tell you why, so you still need to diagnoze following what the data tells you
[22:40:02 CEST] <BBB> but thats obvious
[22:40:18 CEST] <BBB> like, prores does an exhaustive quantizer search or so
[22:40:21 CEST] <BBB> which is pretty crazy
[22:40:31 CEST] <BBB> and people wonder why its slow
[22:40:40 CEST] <Chloe> BBB: my main concern is that I'm not seeing anything to do with any of the encoding in the call stack
[22:41:16 CEST] <Chloe> I'm not really too bothered about cinepak performance, but I've never profiled anything else properly so it'd be nice to get it figured out
[22:44:01 CEST] <BBB> I think its below the triangles
[22:44:14 CEST] <BBB> if you invert the call tree, youll see actual cinepak functions at the bottom of the call tree
[22:45:28 CEST] <Chloe> yeah it's just not there
[22:45:48 CEST] <nevcairiel> did you run the un-stripped binary, ie. ffmpeg_g ?
[22:45:54 CEST] <Chloe> yes
[22:46:52 CEST] <Chloe> if I hide system libraries, it's saying it spends 99.1% time in ffmpeg_g (which is 459ms) when I profile it for over 35 seconds. the only visible calls when the call tree is fully expanded are malloc and free calls
[22:47:24 CEST] <nevcairiel> is this a static or dynamic build?
[22:47:43 CEST] <nevcairiel> s/dynamic/shared/ whatever
[22:48:29 CEST] <Chloe> just a normal static build
[22:48:48 CEST] <BBB> is it allocating memory in inner loops?
[22:48:51 CEST] <BBB> that would be expensive
[22:49:22 CEST] <Chloe> but there's 34.5 seconds missing from the call stack
[22:49:47 CEST] <nevcairiel> how much time d oes it show the system  libraries if you show those?
[22:50:01 CEST] <BBB> what happens if you click Top Functions in the Call Tree menu?
[22:50:47 CEST] <Chloe> it shows avpriv_init_elbg which takes 149.4%
[22:50:58 CEST] <Chloe> ??? what
[22:51:21 CEST] <BBB> huh, well
[22:51:24 CEST] <BBB> there is something :)
[22:51:48 CEST] <Chloe> nevcairiel: it spends 0.9% in system libraries
[22:52:51 CEST] <Chloe> I honestly think my computer is just absolutely broken as shit. Sometimes it takes upwards of an hour to compile ffmpeg, sometimes it takes 10 minutes
[22:52:59 CEST] <BBB> I believe elbg doesnt work well for big codebooks
[22:57:28 CEST] <Chloe> nevcairiel: what sizes is cinepak meant to be fast for?
[22:57:38 CEST] <nevcairiel> its super old, so low res i guess
[22:57:49 CEST] <TD-Linux> it was designed for fast decoding only
[22:58:12 CEST] <wm4> Chloe: install a real OS
[22:58:14 CEST] <Zeranoe> So according to https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=42&p=13519#p13519 NewTek is now going to release a build of FFmpeg with their SDK. Something tells me this is a clear violation of the GPL
[22:58:26 CEST] <Chloe> wm4: buy me a new PC
[22:58:26 CEST] <wm4> Zeranoe: yep
[22:58:34 CEST] <BtbN> I think with LGPL you can do that.
[22:58:39 CEST] <nevcairiel> Cinepak is from 1992 or such,  you can imagine what kind of videos would run with that
[22:58:40 CEST] <wm4> Chloe: Real OS can use shitty hw too
[22:58:57 CEST] <wm4> BtbN: I think we consider the SDK non-free
[22:59:16 CEST] <Zeranoe> We talked about this on the ML and it was deemed against the GPL. Unless they forked and did loadlibrary
[22:59:19 CEST] <BtbN> you can make non non-free builds with all the other non-free libs if you don't enable-gpl
[22:59:26 CEST] <BtbN> Yes, it clearly is against the GPL
[22:59:28 CEST] <BtbN> but not LGPL
[22:59:32 CEST] <BtbN> So an LGPL build would be fine
[22:59:35 CEST] <wm4> libndi_newtek is in the non-free list, so it's not redistributable
[22:59:49 CEST] <sfan5> that only applies in combination with --enable-gpl
[22:59:50 CEST] <BtbN> the non-free list only matters if --enable-gpl
[22:59:52 CEST] <Chloe> wm4: my shitty hardware doesn't work with linux, I've tried before. I have some really weird and shit hardware. (and obviously my old af mac doesn't work because *broadcom* and *battery optimisations*)
[23:00:17 CEST] <wm4> sfan5, BtbN: are you sure? I thought it was for all
[23:00:23 CEST] <sfan5> very sure
[23:00:32 CEST] <Zeranoe> so all non-free libraries in FFmpeg can be included within an LGPL build?
[23:00:34 CEST] <amannoder> it matters becaue the lgpl program is linking *to* the non-free thign
[23:00:36 CEST] <wm4> Chloe: damn
[23:00:39 CEST] <sfan5> otherwise ffmpeg being dual-licensed LGPL / GPL would make no sense at all
[23:00:40 CEST] <amannoder> not vice versa
[23:00:53 CEST] <amannoder> dont confuse linkint to lgpl vs linkign from lgpl
[23:01:11 CEST] <sfan5> Zeranoe: according to the login in configure, yes
[23:01:12 CEST] <nevcairiel> sfan5: i always figured the dual-license is to accomodate libraries that are GPL, like x264
[23:01:14 CEST] <sfan5> logic*
[23:01:25 CEST] <sfan5> well that's probably true
[23:01:33 CEST] <Zeranoe> uhhh
[23:01:36 CEST] <BtbN> amannoder, even linking from LGPL it's fine.
[23:01:45 CEST] <nevcairiel> (also a bunch of filters in avfilter are GPL)
[23:01:59 CEST] <wm4> but if nonfree is enabled, it prints that it's unredistributable
[23:02:17 CEST] <amannoder> news to me
[23:02:20 CEST] <BtbN> but you don't need to enable-nonfree if you don't enable-gpl.
[23:02:33 CEST] <BBB> Chloe: do you have the data you need now? :-p
[23:02:40 CEST] <Chloe> BBB: no not at all
[23:02:43 CEST] <BBB> oh
[23:02:47 CEST] <BBB> I thought that was it
[23:02:49 CEST] <BBB> hm...
[23:02:50 CEST] <BBB> ok
[23:02:53 CEST] <BBB> what else do you need?
[23:02:59 CEST] <BBB> it tells you which part is slow, right?
[23:03:06 CEST] <Chloe> no
[23:03:37 CEST] <sfan5> wm4: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3887
[23:03:41 CEST] <nevcairiel> BtbN: its somehow inconsistent, configure allows the ordinary non-free libraries in a LGPL build, but it doesnt allow CUDA
[23:03:42 CEST] <Chloe> I did the original thing I wanted to do (check if the new muxer worked) by downscaling my source to like 40 pixels wide, and encoding 3 seconds
[23:03:52 CEST] <sfan5> configure will not complain about linking e.g. libfdk_aac if you have --disable-gpl
[23:03:59 CEST] <Chloe> but that doesnt change that I can't profile ffmpeg seemingly
[23:04:07 CEST] <Chloe> (which would be helpful for other things)
[23:04:08 CEST] <BtbN> nevcairiel, it should? It's in the same list of libs
[23:04:09 CEST] <Zeranoe> You just lose all the GPL only stuff
[23:04:14 CEST] <sfan5> correct
[23:04:33 CEST] <nevcairiel> BtbN: no there is EXTERNAL_LIBRARY_NONFREE_LIST and HWACCEL_LIBRARY_NONFREE_LIST
[23:05:06 CEST] <Zeranoe> I'll have to look at the NewTek build when it comes out to see they did LGPL. It still frustrates me that they went that route instead of opening up their SDK more.
[23:05:14 CEST] <wm4> uh well, whatever
[23:06:38 CEST] <JEEB> Zeranoe: with anything nonfree that actually comes with a proprietary SDK the licensing of the SDK becomes even more important
[23:06:53 CEST] <cone-031> ffmpeg 03Misty De Meo 07master:187ff5a10864: Add Sega FILM muxer
[23:07:05 CEST] <JEEB> since while you can have random crap in open source projects, closed source stuff can be even worse
[23:07:18 CEST] <JEEB> so while LGPL might not care about it
[23:07:27 CEST] <JEEB> as a distributor of binaries, you might
[23:07:58 CEST] <nevcairiel> hm yeah the GPL/nonfree checks have been like that in configure for ever basically
[23:08:13 CEST] <nevcairiel> i never realized that most of those libs are allowed in LGPL builds
[23:08:14 CEST] <JEEB> also yes, if the NDI crap gets actually open sourced they're actually one step closer to their marketing BS of being a "standard"
[23:08:23 CEST] <JEEB> although a standard is still a standard, and not a "standard"
[23:08:29 CEST] <Zeranoe> They're build is going to be missing loads of GPL only things though, so they'll likely have a good bit of confusion.
[23:08:50 CEST] <nevcairiel> honestly if you dont want x264, then LGPL is perfectly fine
[23:08:55 CEST] <JEEB> pretty much
[23:08:57 CEST] <JEEB> but many do :D
[23:08:59 CEST] <nevcairiel> everything else is just random nonsense
[23:09:30 CEST] <Zeranoe> "random nonsense" lol
[23:09:46 CEST] <nevcairiel> things used by 0.1% of all users
[23:09:53 CEST] <nevcairiel> ie. stuff a build is fine without
[23:10:16 CEST] <Zeranoe> It's really mainly x264
[23:10:33 CEST] <Zeranoe> and x265
[23:12:45 CEST] <Zeranoe> I suppose I could build lgpl too to support some of the nonfree stuff. but I think six builds a night is enough right now.
[23:12:55 CEST] <wm4> some mplayer ported filters are GPL I guess
[23:13:12 CEST] <wm4> though at least one filter is strangely LGPL even though the original author denied LGPL relicensing
[23:13:13 CEST] <nevcairiel> relevant ones like yadif where ported to LGPL
[23:13:17 CEST] <wm4> (funny thing)
[23:13:26 CEST] <wm4> and yadif was properly relicensed
[23:13:30 CEST] <durandal_1707> (lies)
[23:13:41 CEST] <Zeranoe> My tiny VPS actually ran out of space recently, had to remove a bunch of old builds
[23:13:53 CEST] <wm4> durandal_1707: I'm talking about af_pan
[23:14:02 CEST] <Zeranoe> then I get the emails "why isn't my 2017 build downloading anymore"
[23:14:04 CEST] <durandal_1707> af_plan
[23:14:10 CEST] <wm4> supposedly all code has been replaced (which is fine), but he's still listed as copyright holder
[23:14:16 CEST] <nevcairiel> i switched to lgpl builds a while ago because I could, but i forgot why i switched back
[23:14:20 CEST] <nevcairiel> should check the log
[23:14:36 CEST] <jamrial> nevcairiel: probably yadif going lgpl
[23:16:02 CEST] <nevcairiel> that doesnt explain why i went back
[23:16:16 CEST] <jamrial> but yeah, the only things that need GPL are half a dozen libraries, of which x26x are the only relevant ones, a dozen or so filters, and a bunch of asm functions jdarnley wrote
[23:16:25 CEST] <jamrial> also libpostproc
[23:16:39 CEST] <nevcairiel> hrm i failed to add a note why i changed back
[23:16:41 CEST] <nevcairiel> silly past-me
[23:17:33 CEST] <nevcairiel> oh i know,  avisynth shit
[23:17:35 CEST] <Chloe> BBB: Idk I'll look into it more a bit later. I dont really want to fight with this OS anymore
[23:17:45 CEST] <nevcairiel> someone decided it was gpl
[23:17:53 CEST] <wm4> jamrial: heh, jdarnley doesn't want them to be LGPL?
[23:18:11 CEST] <atomnuker> wasn't that someone else's simd?
[23:18:15 CEST] <wm4> also I know one mplayer filter author said he'd allow relicensing to LGPL when ffmpeg and Libav merge
[23:18:33 CEST] <wm4> he seemed to think that's possible (rather than making a "not going to happen" joke)
[23:18:36 CEST] <jamrial> atomnuker: nope
[23:18:49 CEST] <atomnuker> wtf jdarnley
[23:18:53 CEST] <Zeranoe> "when ffmpeg and libav merge"?
[23:19:05 CEST] <jamrial> no idea why he didn't want them to be lgpl
[23:19:07 CEST] <Chloe> wm4: i remember when people thought a libav ffmpeg merge was more likely than brexit
[23:19:09 CEST] <wm4> reconcile, unsplit
[23:19:19 CEST] <Zeranoe> is that happening?
[23:19:23 CEST] <nevcairiel> we merge libav all the time
[23:19:24 CEST] <wm4> no
[23:19:25 CEST] Action: nevcairiel hides
[23:20:10 CEST] <Zeranoe> so you mean commit merging, not project merging
[23:20:12 CEST] <jamrial> nevcairiel: for that matter, why do you keep committing stuff to you lavfilters fork but then don't send it to the ml?
[23:20:19 CEST] <jamrial> not all of them are hacks or matroskadec_haali stuff
[23:20:28 CEST] <Chloe> Zeranoe: nevcairiel does, I didnt
[23:20:41 CEST] <jamrial> like the vp9 10bit support for dxva/d3d11
[23:20:41 CEST] <jamrial> or this new hevc chroma_location patch
[23:21:23 CEST] <nevcairiel> i'm lazy
[23:21:29 CEST] <wm4> Zeranoe: no, project merging
[23:22:03 CEST] <Zeranoe> I see, it fell through
[23:22:08 CEST] <jamrial> stop being lazy :p
[23:22:41 CEST] <wm4> people gave me hell when I tried to use such a ffmpeg fork in that style for mpv
[23:22:48 CEST] <wm4> it was a pretty hot hell
[23:22:56 CEST] <wm4> people freaking out left and right
[23:23:14 CEST] <jamrial> distro maintainers freaked out
[23:23:29 CEST] <nevcairiel> it helps being the sole owner of a project, and the project being for windows, so no distro crazy
[23:23:30 CEST] <jamrial> users complained because they couldn't compile mpv anymore, at least at first
[23:23:37 CEST] <jamrial> then they didn't care anymore
[23:26:38 CEST] <nevcairiel> having to use untouched vanilla ffmpeg would probably make me go crazy =p
[23:27:02 CEST] <nevcairiel> not even mentioning the replacement mkv demuxer i shoved in there
[23:27:06 CEST] <BBB> Chloe: I agree btw that instruments isnt a seasy to use as it could be for our use case; Im guessing most people dont use it like this
[23:28:04 CEST] <wm4> nevcairiel: and people are expecting to be able to use a ffmpeg release too
[23:28:28 CEST] <durandal_1707> why compiling rust stuff with cargo takes cargo cult of time, and than it failed
[23:33:15 CEST] <Chloe> nevcairiel: btw I sent a patch for gitignore to the ML
[23:49:50 CEST] <cone-031> ffmpeg 03Josh de Kock 07master:92fe0bf1e8f8: lavfi,lavd: add gitignore for generated static component lists
[23:52:59 CEST] <Chloe> Has anyone needed to work with video hardware which works natively with macOS (such as DV video cameras) but requires Final Cut Pro to actually access them (or know of someone who needs this)?
[23:53:50 CEST] <Chloe> I have a WIP patch which I'd be willing to finish with some *cough* motivation *cough* for interacting with these as an avdevice
[23:54:40 CEST] <BBB> lol :)
[23:55:10 CEST] <atomnuker> nevcairiel: what is matroskadec_haali?
[23:55:20 CEST] <JEEB> haali's demuxer in lavf
[23:55:27 CEST] <atomnuker> for what purpose?
[23:55:34 CEST] <wm4> haali is the mkv demuxer that mpc-hc used by default since forever
[23:55:34 CEST] <atomnuker> also: who's haali?
[23:55:40 CEST] <jdarnley> atomnuker, jamrial, wm4 : I'd make my contributions AGPL if I thought I could get away with it.
[23:55:44 CEST] <wm4> because it's better than lavf's crappy demuxer
[23:55:51 CEST] <wm4> it also supports ordered chapters and shit
[23:55:59 CEST] <wm4> atomnuker: some developer
[23:56:00 CEST] <JEEB> atomnuker: haali was one of the original matroska implementors
[23:56:11 CEST] <JEEB> not original original level as the videolan person
[23:56:18 CEST] <JEEB> but the one who started doing dshow
[23:56:30 CEST] <JEEB> he also was one of the few to implement various features
[23:56:43 CEST] <JEEB> he also hosts the original codecs.pdf
[23:56:44 CEST] <JEEB> http://haali.su/mkv/codecs.pdf
[00:00:00 CEST] --- Fri Apr  6 2018