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

[burek]

[01:10:08 CET] <BtbN> philipl, can you reply to the crop_cuda thread with what we discussed about integrating it into scale_cuda? Don't want to leave the guy hanging.
[01:10:18 CET] <BtbN> Don't have time to do so myself right now.
[01:18:41 CET] <cone-081> ffmpeg 03Jun Li 07master:c3b517dac2bb: avformat/rtsp: Add https tunneling support
[02:22:10 CET] <damdai> from which ffmpeg version, did  ffmpeg started supporting   Stream #0:0: Audio: dst (DST  / 0x20545344), 352800 Hz, 5.1(side), flt
[05:58:10 CET] <philipl> BtbN: done
[11:17:15 CET] <BtbN> thanks!
[11:23:03 CET] <jya> I'm having a particular weird h264 stream here where the first frame is a single IDR NAL, no SPS/PPS. Is there an actual way to decode that?
[11:23:56 CET] <nevcairiel> are there any sps/pps later on?
[11:24:12 CET] <nevcairiel> because if not, then you are mostly screwed
[11:25:09 CET] <nevcairiel> if there are sps/pps later on, then the extract_extradata bsf might be able to find them and pull them out, so you can feed it to the decoder
[11:25:12 CET] <jya> can't see any. Weird thing is that OpenH264 can somehow decode it. Need to dwelve into that one, maybe openh264 cause an error, and so the server resend it
[11:26:00 CET] <BtbN> The extradata could just be sent out of band in the container?
[11:26:46 CET] <jya> it's a RTP stream
[11:27:30 CET] <jya> though if the SPS/PPS isn't sent with the IDR but later, then we wouldn't detect it (we only look for SPS/PPS if the packet also has an IDR)
[11:35:20 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtpdec_h264.c;h=a785120c230972aecf7f8d59878fee7f67ac38ad;hb=HEAD#l96 looks like RTP does transport extradata out of band
[11:35:53 CET] <jya> yes, it could be pass in the sdp, but I don't see anything here
[11:37:32 CET] <jya> our code doesn't support it anyway (this is a webrtc stream)
[15:01:21 CET] <thardin> kierank: good post re: hardware APIs
[15:02:17 CET] <thardin> I wish more manufacturers realized they're hardware companies
[15:02:33 CET] <kierank> I mean we literally went and built our own hardware in part for this reason
[15:03:42 CET] <atomnuker1> how did blackmagic take it or they couldn't care less?
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:1223696c725a: avcodec/truemotion2: Fix integer overflow in tm2_null_res_block()
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:d92034a06aad: avcodec/dxtory: Check slice sizes before allocating image
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:ff13a92a6f84: avformat/mov: Fix potential integer overflow in entry check in mov_read_trun()
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:4ef27d40729c: avcodec/indeo2: Check input size against resolution in ir2_decode_plane()
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:635067b75fce: avcodec/mpegpicture: Check size of edge_emu_buffer
[15:04:05 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:c0ca67ba4083: avcodec/prosumer: Check decoded size
[15:04:06 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:b8f53a23421b: avcodec/jpeg2000dec: Skip de-quantization of empty areas
[15:23:29 CET] <kierank> atomnuker1: don't care
[15:26:54 CET] <cone-124> ffmpeg 03James Almer 07master:40490b3a6336: avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs
[15:49:39 CET] <BBB> that matrox email is soooooooo self-serving
[15:50:02 CET] <BBB> "we're a hardware company, please give us special treatment, it'll be good for all of us [and we'll make tons of money shhhhhhh]"
[15:51:25 CET] <JEEB> xD
[15:52:30 CET] <thardin> yeah that was kind of funny
[15:57:22 CET] <kierank> BBB: they are just so obsessed with secrecy
[15:57:27 CET] <kierank> as if we can't just buy the ASIC they have bought
[15:58:38 CET] <kierank> it's not as if ffmpeg doesn't implement low level functions for anything anyway, it's not gstreamer
[16:31:03 CET] <Gramner> I don't really understand why hardware vendors don't just release the relevant libraries under liberal open source licenses, all the "secret sauce" is in the hardware itself anyway
[16:32:08 CET] <kierank> Gramner: i've spoken to them at length about this, they think their "value" is in the sdk
[16:32:13 CET] <kierank> they are obsessed about sdk
[16:32:15 CET] <kierank> s
[16:32:33 CET] <kierank> But at the end of the day it boils down to the same thing every time:
[16:32:37 CET] <kierank> They Don't Understand Open Source
[16:33:01 CET] <Gramner> which is weird because nobody cares about the sdk, it's just a means to access the hardware
[16:34:14 CET] <nevcairiel> as a hardware company i dont really understand that obsession, shouldnt they try to make good hardware and sell that
[16:34:18 CET] <nevcairiel> but i guess thats too  hard? :D
[16:36:57 CET] <gnafu> nevcairiel: Whoa, whoa.  Slow down there, buddy.  "Good"?  That's a lot to ask for.
[16:37:29 CET] <gnafu> I'm gonna need you to agree to our SDK's ToS before we can even talk.
[16:57:23 CET] <jamrial> BBB: when you have time, can you look at the av1 frame split bsf patch? i sent an updated version
[16:57:35 CET] <BBB> okiedokie
[16:57:38 CET] <BBB> anything specific it does?
[16:58:04 CET] <BBB> "native av1 decoder" :D
[16:58:13 CET] <jamrial> eventual :p
[16:59:43 CET] <jamrial> it splits all the frames in a temporal units into separate packets, making sure to include frame header and all the tile group obus (or just the frame obu)
[17:00:25 CET] <jamrial> it includes all leading obus with the first frame (seq header, etc), and all trailing obus with the last frame (whatever could be there, like maybe padding)
[17:01:09 CET] <jamrial> if there's only one frame, it just passes it through
[17:35:23 CET] <cone-124> ffmpeg 03Gyan Doshi 07master:9ae8f3cdd330: doc/filters: indicate range for zoom in lavfi/zoompan
[17:42:04 CET] <lotharkript> qq: Should a video filter update the AVframe duration? if not, then there seems to be problem here https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1085 when using filter complex. it updates the AVframe->duration even if we did apply a fps filter in the filter complex.
[17:55:11 CET] <kierank> thardin: Gramner: note how he's gone quiet when I ask him for his chip api
[17:55:21 CET] <kierank> yet he wants us to do everything to accommodate him
[17:59:32 CET] <Gramner> dropping proprietary 3rd party libs from ffmpeg would be an incentive for hw vendors to open source their stuff then, since they obviously do want to be supported in ffmpeg
[17:59:58 CET] <j-b> exactly
[18:00:07 CET] <nevcairiel> Trying to interpret any meaning into a 3 hour silence from a business seems like diluding yourself =p
[18:00:35 CET] <nevcairiel> deluding*
[18:00:42 CET] <j-b> FFmpeg is becoming the core of all multimedia pipelines. We have the power to make things change.
[18:00:44 CET] <kierank> nevcairiel: he spams the list with all his requestes very day
[18:05:40 CET] <j-b> This libmvM264Ffmpeg is very suspicious
[18:09:07 CET] <thardin> Gramner: possibly, yes
[18:10:03 CET] <thardin> kierank: indeed
[18:13:53 CET] <thardin> he also seems to want support for all those weird mxf things for free
[18:15:49 CET] <thardin> ooh a patch for my favorite codec, cinepak
[18:16:41 CET] <thardin> gym first
[18:17:33 CET] <gnafu> Now there are two things I can't relate to: being excited about a Cinepak patch, and going to the gym.
[18:17:36 CET] <gnafu> ;-D
[18:36:51 CET] <JEEB> hmm
[18:37:03 CET] <JEEB> I wonder how many parsers fail at H.264 Level 6.0
[18:40:05 CET] <Gramner> anything hardware-base probably wouldn't be able to decode 6.0 anyway
[18:41:20 CET] <JEEB> my x230 seemed to do it surprisingly well, but AMDs, nvidias and another intel seemed to bork at it
[18:41:39 CET] <Gramner> I'm pretty sure my nvidia card didn't complain, but produces garbage output for large mv:s
[18:41:52 CET] <JEEB> yup
[18:42:00 CET] <JEEB> I was surprised my x230 (ivy bridge?) worked
[18:42:33 CET] <JEEB> as in, I didn't see those artifacts I saw both with a newer intel + nvidia
[18:43:14 CET] <CounterPillow> open-source is the thing where we can con people into doing our work for free, right?
[18:44:11 CET] <j-b> JEEB: what about modify x264 to create z264 codec with larger block sizes?
[18:44:26 CET] <JEEB> lol
[18:44:31 CET] <j-b> most patents for h264 will be out soon
[18:44:39 CET] <JEEB> possibly a fun experiment
[18:44:42 CET] <j-b> JEEB: do you think we can beat x265?
[18:44:53 CET] <JEEB> not sure, since I feel like they share the optimization problem
[18:45:02 CET] <JEEB> unless they have a completely different coding cost calc
[18:45:18 CET] <JEEB> because bigger block sizes usually are something that easily ends up looking like "cheap way to encode"
[18:45:25 CET] <JEEB> but then you suddenly get all that blur
[18:45:49 CET] <Gramner> JEEB: did you try with something containing large mv:s? they rarely happen with most content but levels 6.0 and above increased the maximum allowed mv range and it seemed to cause breakage on nvidia gtx 1080 when I tested it some time ago
[18:46:22 CET] <JEEB> yea, that's why I commented. I happened to render some 2160p60 and just let preset slower rip
[18:46:34 CET] <j-b> JEEB: I'm quite sure we can take some simple ideas from HEVC/VP9 and "backport them to" x264
[18:46:38 CET] <j-b> and improve :)
[18:47:37 CET] <CounterPillow> Notable absence of AV1 in that sentence
[18:47:39 CET] <JEEB> Gramner: and yes, I noticed the artifacts as I opened the clip in something that defaulted to hwdec with nvidia :)
[18:48:21 CET] <JEEB> j-b: sure, it should be possible
[18:48:44 CET] <j-b> H264 is soon out of patents, and that would be nice
[18:48:48 CET] <JEEB> aye
[18:49:07 CET] <CounterPillow> How soon? I thought it was another 10 years off.
[18:49:18 CET] <JEEB> 2013-4 for initial stuff
[18:49:24 CET] <JEEB> uhh
[18:49:25 CET] <JEEB> 2023
[18:49:38 CET] <JEEB> then high profile etc I think was 2006 so 2026?
[18:49:56 CET] <JEEB> or was it earlier?
[18:50:32 CET] <gnafu> "< CounterPillow> open-source is the thing where we can con people into doing our work for free, right?" <-- I mean, that's what I've done all these years.
[18:50:39 CET] <j-b> the patents were earlier
[18:51:33 CET] <gnafu> CounterPillow: Though replace "con people" into "wait for someone else to do it because I can't be bothered".
[18:51:52 CET] <JEEB> also talking of blurring, having stuff with a bokeh sure lowers bit rate requirements :P
[18:53:59 CET] <Gramner> some H.264 patents expire in 2027
[18:54:08 CET] <Gramner> because extentions are apparently a thing
[18:54:47 CET] <Gramner> https://scratchpad.fandom.com/wiki/MPEG_patent_lists#H.264_patents (not sure how accurate it is though)
[18:56:24 CET] <Gramner> 2028 even
[18:56:43 CET] <CounterPillow> heh, a lot of these expire this year.
[18:59:41 CET] <kurosu> I'm looking forward to those expiring on 32nd of May 2023
[19:00:19 CET] <Gramner> it means they will be valid indefinitely of course
[19:01:35 CET] <kurosu> obviously, if we follow the Mickey Mouse doctrine
[19:09:49 CET] <JEEB> Gramner: the first device that outright nope'd at the streams was my TV :)
[19:10:00 CET] <JEEB> I think 5.2 or something might be the biggest it'll take?
[19:11:38 CET] <Gramner> probably either 4.1 or 5.2 according to specs, which may or may not include things slightly above that
[19:13:28 CET] <JEEB> 4.1 is the thing that you need to tell some devices on the browser level what your stream is
[19:13:41 CET] <JEEB> (because so many people forget to update their hwdec level check
[19:13:49 CET] <JEEB> (even if they have a 4K compatible hwdec)
[19:13:55 CET] <JEEB> *cough* chromecast *cough*
[19:14:44 CET] <Gramner> levels 6 is just special in the fact that it also increases mv-range and not just frame size / mb rate, so you can have a stream with a resolution and framerate that fits within lower levels but have mv ranges that do not. that can cause fun issues which very rarely happen
[19:15:00 CET] <JEEB> yea
[19:15:35 CET] <JEEB> I didn't even think they let you do that when I started encoding
[19:16:24 CET] <JEEB> it seems that my 2160p renders are just great for making x264 use those longer MVs :)
[19:23:24 CET] <Gramner> iirc the reference decoder is slightly broken for level 6 streams as well, I think it warns about too large mv ranges because the check is wrong
[19:23:33 CET] <JEEB> :D
[19:23:34 CET] <Gramner> which is funny
[19:24:08 CET] <JEEB> yea, but it kind of makes sense: "why would you have to update the reference software after 13 years?"
[19:24:20 CET] <JEEB> (except they went and changed things)
[19:24:34 CET] <nevcairiel> oh so that level actually allows something fundamental beyond just more bitrate then
[19:25:20 CET] <Gramner> yeah. most levels before 6 have just been basically "decode more macroblock in the same time"
[19:25:57 CET] <Gramner> not sure how useful giant mvs even are, seems like a dubious addition to the spec
[19:26:58 CET] <JEEB> not sure how much I gained from them with the two encodes I did without specifying a level, but they did get utilized :D
[19:29:20 CET] <Gramner> yeah, but how much better than some other shorter mv? probably negligible for anything other than some contrieved edge cases
[19:29:44 CET] <JEEB> quite possible
[19:59:30 CET] <rcombs> macroblock rate, bit rate, frame size, and DPB size
[20:00:36 CET] <rcombs> (and I've never figured out how the VCL bit rate limit is supposed to be applied)
[20:10:22 CET] <kierank> applied using vb
[20:10:23 CET] <kierank> vbv
[20:10:34 CET] <kierank> also mincr is important
[20:10:43 CET] <orlcp440> Hello, I have RTP sending using the UDP muxer and set it up to send packets at a constant rate. How can I make RTP also use the UDP module to receive packets instead of using its own internal udp_read function?
[20:15:06 CET] <orlcp440> The libavformat/rtpproto.c rtp_read() function is getting called instead of the libavformat/udp.c udp_read() function.
[20:15:47 CET] <orlcp440> the rtp_read() function is calling recvfrom() udp directly
[20:16:23 CET] <JEEB> are you the guy who asked about passing those rate control options before
[20:16:29 CET] <JEEB> I think I linked https://github.com/jeeb/ffmpeg/commit/84c3261dd3cff17eb32aea06391bb6646311c6c1 to you?
[20:16:40 CET] <JEEB> so you could maybe test it if it worked for you :P
[20:16:56 CET] <orlcp440> I guess what I really want to know if it is possible to chain demuxers and if it is how I can accomplish that. I want to chain for output RTP -> UDP muxer and for input UDP muxer to RTP muxer.
[20:17:28 CET] <orlcp440> @JEEB: Yup, I am that guy lol
[20:18:11 CET] <orlcp440> I thought that only solved 1 direction but noth both
[20:18:49 CET] <JEEB> you're talking about sending and the UDP protocol does the rate control, no? you just have to be able to set the parameters
[20:19:11 CET] <JEEB> (also the separately threaded writing is I think only under pthreads due to requiring pthread cancel?)
[20:19:26 CET] <orlcp440> plus I want to concat or chain (whatever term is used) the UDP dec Muxer to the RTP dec Muxer
[20:19:55 CET] <JEEB> I don't really understand what that probably means to you
[20:20:08 CET] <orlcp440> @JEEB I got the sending part working but not the receiving part.
[20:20:18 CET] <JEEB> well what's the problem with receiving?
[20:20:44 CET] <JEEB> that is also buffered and reading in a separate thread if you have threading enabled
[20:20:46 CET] <orlcp440> it is not using a separate thread and putting the data in a FIFO for me to grab it
[20:20:55 CET] <orlcp440> that is my problem with the receiving
[20:20:59 CET] <JEEB> then you have managed to build FFmpeg without threading?
[20:21:50 CET] <JEEB> or wait, it might be indeed limited to pthreads on that way as well :P
[20:21:54 CET] <orlcp440> @JEEB: No, what I meant was that the RTP dec muxer is actually calling recvfrom() itself instead of letting the UDP dec muxer do it
[20:21:56 CET] <JEEB> under HAVE_PTHREAD_CANCEL
[20:23:32 CET] <orlcp440> The UDP dec muxer is actually running and receiving using its thread and putting the data in a FIFO but the RTP dec muxer is not calling the UDP dec mux's udp_read but instead calling its own function that does recvfrom() straight
[20:23:44 CET] <orlcp440> straight -> directly
[20:24:40 CET] <orlcp440> @JEEB: Keep in mind I do not even know the whole architecture and how data should flow on this library. I would love to find some documentation about that
[20:26:01 CET] <orlcp440> I would like to know how I can take the output of a dec muxer and use it as an input to another dec muxer and the output of the second dec muxer to be the input of a third dec muxer etc. That is what I meant when I said dec muxer chaining
[20:26:27 CET] <orlcp440> like a pipeline
[20:27:11 CET] <JEEB> there's a difference between a protocol and a demuxer or muxer
[20:27:24 CET] <JEEB> anyways, don't remember the details myself either and I haven't really looked into the RTP stuff
[20:27:36 CET] <JEEB> I just expected it to normally chain stuff
[20:37:04 CET] <orlcp440> It does chain forward from RTP to UDP but not from UDP to RTP
[20:38:04 CET] <orlcp440> @JEEB: Do you know where I can learn all those concepts?
[21:00:12 CET] <llogan> who maintains the ffmpeg page on facebook?
[21:38:05 CET] <orlcp440> I guess I should ask, what is the process a new developer for ffmpeg project takes to learn the whole architecture so that he can contribute to the ffmpeg project? Not as a user of the libraries but as a core developer for ffmpeg?
[21:47:53 CET] <BBB> you just start doing fun things and learn how things work as you go, I think
[21:48:00 CET] <BBB> I doubt many people know everything
[21:48:05 CET] <BBB> most people know just some subsystems
[21:48:08 CET] <faLUCE> I would like to propose some patches to the project, for fixing some issues. How can I start? I downloaded the last git image of ffmpeg. Then, after changing for example file1.c,  how should I propose the commit?
[21:48:11 CET] <BBB> maybe jamrial and michaelni know everything
[21:48:20 CET] <BBB> orlcp440: ^^
[21:48:42 CET] <durandal_1707> i know everything and nobody else
[21:48:50 CET] <BBB> faLUCE: https://www.ffmpeg.org/developer.html#Submitting-patches-1
[21:49:01 CET] <BBB> that's true, durandal_1707 might know most stuff also
[21:51:02 CET] <faLUCE> BBB: how can I test git-send-email? Could I try to use it by sending the patch to my email?
[21:51:15 CET] <BBB> yes
[21:52:15 CET] <faLUCE> BBB: and which is the "object" field, so that I can explain what the patch does?
[21:54:34 CET] <faLUCE> maybe "--compose" ?
[21:55:40 CET] <durandal_1707> JEEB: i got KB2f fully working except deblocking
[21:57:34 CET] <orlcp440> @durandal_1707: Cool, then  you can probably answered the question I was asking @BBB before. Can you help me?
[21:58:06 CET] <durandal_1707> orlcp440: can you compile and run ffmpeg?
[21:58:29 CET] <orlcp440> @durandal_1707: Yes, I can do it right now
[22:00:06 CET] <durandal_1707> orlcp440: then do what you want to do, if you want to do codecs say which want, read similar code to learn new things
[22:00:35 CET] <TD-Linux> Gramner, you really want the mvs to reach across most of the frame. once you do longer reference structures your mvs get bigger
[22:00:57 CET] <TD-Linux> it's obviously sequence dependent but it's a pretty drastic hit when you do run out of mv range.
[22:01:08 CET] <TD-Linux> we had to bump AV1 mvs longer than VP9 because of this
[22:01:35 CET] <durandal_1707> llogan: why you dissapeared?
[22:02:10 CET] <BBB> TD-Linux: nope
[22:02:16 CET] <BBB> TD-Linux: mvs are the same in av1 as they are in vp9
[22:02:25 CET] <TD-Linux> oh I thought we increased them 1 bit :/
[22:02:29 CET] <BBB> TD-Linux: I requested a change to that, it got merged, and then reverted
[22:02:35 CET] <TD-Linux> I missed the revert :9
[22:02:40 CET] <BBB> :(
[22:02:43 CET] <BBB> sorry
[22:02:46 CET] <orlcp440> @durandal_1707: I am already doing that but I am stuck on a high level architectural questions that depending on the answer of that question I will know if what I want to do is possible using the current state of ffmpeg
[22:02:52 CET] <BBB> I wish it had been fixed, it's pretty important at high resolution (4k)
[22:03:15 CET] <TD-Linux> at least it's not level dependent. (unless they changed that too)
[22:03:41 CET] <durandal_1707> orlcp440: do you have exact question?
[22:05:24 CET] <faLUCE> it seems that the "--annotate" field adds an object to the email with the patch... can you confirm that?
[22:05:42 CET] <orlcp440> @durandal_1707: Yes, how do I make the RTP module use the UDP.c module for all its receiving needs? Right now I have the RTP module using the UDP.c module for transmitting RTP. I wanted to do that because the UDP.c module supports pthreads with FIFO buffers and bitrate so I have the UDP.c module sending packets out to the network every 1ms
[22:09:36 CET] <orlcp440> @durandal_1707: I enabled HAVE_PTHREAD_CANCEL to accomplish that
[22:10:08 CET] <durandal_1707> orlcp440: i'm not that much into network and protocol code, sorry 
[22:11:18 CET] <orlcp440> @durandal_1707: :-( Do you happen to know who is?
[22:11:57 CET] <durandal_1707> look at MAINTAINERS file for relevant file you are interested
[22:20:07 CET] <llogan> durandal_1707: i'm still around for now but getting bored of it (computer stuff in general), and too much bickering on mailing list.
[22:23:51 CET] <jamrial> llogan: i assume you had to approve some of the mails on these discussions?
[22:26:36 CET] <llogan> jamrial: I had to approve messages from non-subscribed users, but i recently changed the behavior so users must be subscribed to send a message.
[22:32:02 CET] <orlcp440> @durandal_1707: Damn that is pretty solid advice. I did not know of the existence of that file. However, the only bad thing is that they do not include their email or any way of contacting them in that file
[22:32:53 CET] <llogan> you can cross reference the git log
[22:34:07 CET] <llogan> MAINTAINERS can be outdated. view git log of a file to see who works on it most.
[22:42:09 CET] <jamrial> llogan: i know, i meant that no wonder having to approve message in that and similar threads tired you
[22:45:18 CET] <faLUCE> are there parts of ffmpeg that are compatible with gpl v2 but not compatible with gpl v3 ?
[22:46:31 CET] <nevcairiel> i dont think so
[22:47:12 CET] <nevcairiel> our gplv2 license is specifically upgradable
[22:47:59 CET] <faLUCE> nevcairiel: but there's a note:  "Should you, for whatever reason, prefer to use version 3 of the (L)GPL, then the configure parameter --enable-version3 will activate this licensing option for you. Read the file COPYING.LGPLv3 or, if you have enabled GPL parts, COPYING.GPLv3 to learn the exact legal terms that apply in this case" ... so, does it imply restrictions?
[22:49:36 CET] <nevcairiel> the licenses are different, you should understand the differences between them
[22:49:48 CET] <nevcairiel> but our code is all allowed under v3 as well
[22:50:54 CET] <faLUCE> I see, so, there's compatibility for v3+ but the license will be specifically v3+ if you enable it
[22:50:56 CET] <faLUCE> ?
[22:51:00 CET] <nevcairiel> there is a few external libraries that we can use that are only available under v3
[22:51:24 CET] <nevcairiel> so if you want to use those, ffmpeg itself needs to be  licensed under v3 as well
[22:52:21 CET] <faLUCE> nevcairiel: ok, so, the issue can be if you use v2 instead of v3 (with some v3+ libs), but not vice-versa
[22:52:33 CET] <cone-203> ffmpeg 03Daniel Playfair Cal 07master:6e4202112898: avfilter/vf_lensfun: add scale parameter
[22:52:36 CET] <nevcairiel> correct
[22:52:41 CET] <faLUCE> thanks nevcairiel
[22:53:35 CET] <nevcairiel> All our code is either GPLv2+ or LGPLv2+, any other options only come into play when external libraries are involved that require different licenses
[22:54:25 CET] <faLUCE> right
[22:55:10 CET] <BtbN> Very small parts art MIT
[22:59:06 CET] <j-b> faLUCE: Apache2 + GPLv2+ gives you automatically GPLv3
[22:59:26 CET] <j-b> because GPLv2 is incompatible with Apache2, while GPLv3 is compatible
[23:03:57 CET] <faLUCE> but, is v3 license different than v3+  ?  From what I see, the license doc is "v3"  and the "any later part" must be specified, instead, on the source code
[23:48:02 CET] <lotharkript> who is the right person to talk about difference between filtercomplex and vf ?
[23:51:04 CET] <jamrial> either durandal_1707 or Nicolas George, i think
[23:54:27 CET] <lotharkript> Thanks.. We are seeing some difference between filtercomplex and vf when using fps filter and vsync
[00:00:00 CET] --- Tue Mar 26 2019