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

[burek]

[00:00:24 CEST] <phisch> kepstin: that could explain it, but default behavior should be that background tasks don't receive the sigint afaik
[00:00:34 CEST] <phisch> don't know why this should be different for me
[00:01:34 CEST] <kepstin> but that would explain the behaviour - if ffmpeg receives *two* SIGINT, the first starts a clean exit, but the second aborts that and exits immediately
[00:02:11 CEST] <phisch> yeah, but i don't know how i could check/prevent this
[00:03:05 CEST] <phisch> i think this is very ffmpeg related
[00:05:28 CEST] <kepstin> I explained ffmpeg's behaviour ^^
[00:06:31 CEST] <phisch> do you know if there is a way to disable this behavior then? :P
[00:07:12 CEST] <phisch> or could you run the script, hit ctrl+c and tell me your output? just to make sure that this is not some messed up stuff related to my system
[00:07:14 CEST] <kepstin> I'm really not familiar enough with how the process group stuff in the shell works to give a suggestion :/
[00:07:26 CEST] <kepstin> this is the expected behaviour with your script, i think.
[00:11:06 CEST] <phisch> no, i expect that when my script receives a sigint (either by `kill -INT [PID]` or `ctrl+c`) the sigint trap handles gracefully killing background processes
[00:23:20 CEST] <kepstin> hmm. i really dislike working with signal handling. I can't even get that working when just running 'sleep' instead of ffmpeg :/
[00:25:53 CEST] <kepstin> phisch: you might have better results if you remove the 'wait $FFMPEG_PID' from the signal handler
[00:26:48 CEST] <phisch> i need to wait until it's completely done though
[00:27:05 CEST] <kepstin> don't wait in the signal handler :/
[00:27:46 CEST] <phisch> i have to, since i want to run the script via a shortcut and kill it with another one
[00:28:22 CEST] <kepstin> not sure what you mean. you shouldn't need to wait in the signal handler, you're already waiting at the end of the script
[00:32:21 CEST] <phisch> you hit a shortcut, select a screen area with slop, it records that screen area with ffmpeg, once the process is killed via another shortcut the trap sends a sigint to ffmpeg and then waits until the process has fully exited, then takes the video and makes a gif out of it
[00:33:16 CEST] <kepstin> ah, the issue is that the signal handler interrupts the wait at the bottom of the script and it doesn't get resumed :/
[00:33:40 CEST] <phisch> yes, thats why i need the wait in the signal handler
[00:34:28 CEST] <phisch> and everything works for my use-case, but i'd really like to also be able to use this from a terminal directly and having it work with hitting ctrl+c
[00:34:42 CEST] <phisch> but as we have seen the ctrl+c somehow sends 2 sigints to ffmpeg
[00:34:55 CEST] <phisch> because ffmpeg does some magic or whatever
[00:39:01 CEST] <kepstin> just to confirm, you want to run some other commands in the same script after ffmpeg exits?
[00:41:48 CEST] <kepstin> probably the easiest solution is to run the ffmpeg command under nohup (like `nohup ffmpeg <args> &`), that'll make all the signals work the way you expect. Note that nohup by default sends the command output to a file named nohup.out.
[00:42:27 CEST] <kepstin> (bit of a big hammer for this, since you probably would want ffmpeg to be killed if you close the terminal, but it'll work)
[00:44:46 CEST] <phisch> yeah, detaching with nohup seems like something worth trying
[00:45:21 CEST] <phisch> and yes, i want to run more commands, my example is just a stripped down version to illustrate the problem without unnecessary stuff
[00:47:01 CEST] Action: kepstin has confirmed that it works - if you still want the command output in the terminal, `nohup ffmpeg ... | cat &` is a hilarious way of doing it.
[00:47:35 CEST] <kepstin> i assume there must be a way to do this without nohup, but..? :/
[00:48:02 CEST] <phisch> yeah, without would be perfect
[01:49:30 CEST] <kevinnn> does anyone know if vlc streams rtsp using UDP by default?
[01:49:43 CEST] <kevinnn> and if it does how can I set it to use TCP?
[03:10:12 CEST] <memelover> I'm attempting to transcode some FLACs to ALAC. The specific command I'm using is "ffmpeg -i song.flac -acodec alac -map 0:0 song.m4a. This seems to preserve most of the tags, but not all. For example, the "total tracks" tag does not appear in the m4a.Is there some gotcha that I'm missing?
[03:11:52 CEST] <memelover> It also appears to gut the replaygain data.
[03:17:21 CEST] <klaxa> there is a -map_metadata flag, maybe look into that?
[03:18:10 CEST] <klaxa> https://ffmpeg.org/ffmpeg.html#Advanced-options
[03:21:40 CEST] <memelover> Hmm. It says that if not included, it defaults to including all metadata.
[03:24:53 CEST] <klaxa> -map 0:0 excludes everything but track 0 from file 0 though
[03:25:05 CEST] <klaxa> not sure if that also excludes metadata, but maybe?
[03:25:15 CEST] <klaxa> but if you tried and it didn't help, guess not
[03:33:18 CEST] <memelover> Well, my reason for doing that is that track 1 sometimes contains an mjpeg album cover, which ffmpeg really doesn't like. It cannot seem to process it at all, so my plan is to add it back in after transcoding.
[03:34:27 CEST] <memelover> And it looks like the replaygain data isn't actually metadata, but information inside the audio track. Even -fflags keepside doesn't seem to help with that.
[03:41:03 CEST] <phisch> kepstin: wait, how did you get nohup to work?
[06:25:59 CEST] <damdai> anybody know what it means by "fragmented" and "cbcs" ?  http://download.opencontent.netflix.com/?prefix=AV1/Chimera/
[07:29:16 CEST] <damdai> what is wrong with ffmpeg devs?
[07:29:29 CEST] <damdai> they closed my bug report for no reaosn
[07:32:13 CEST] <damdai> dongs you there?
[08:39:15 CEST] <pkunk> Does "-use_wallclock_as_timestamps 1" work with mpegts streams?
[08:40:44 CEST] <pkunk> I sometimes get "non-monotonous" packet errors on output. So tried this option, but with this I instead get "DTS discontinuity in stream 1" errors as the mpegts packets sometimes come in out of order over http
[08:42:03 CEST] <pkunk> Or is there any other way to "fix" the timestamps on mpegts streams so I can avoid the dreaded "non-monotonic" errors on av_interleaved_write_frame()
[10:04:33 CEST] <JEEB> pkunk: if it's wrap-around that's standard in MPEG-TS in theory libavformat has wrap-around handling but that only seems to work once. ffmpeg.c then attempts to do it again in a separate piece of logic.
[10:05:15 CEST] <JEEB> for that specific option what it does is it overrides the timestamp in libavformat's utils
[10:05:28 CEST] <JEEB> in other words if you have b-frames etc it will just bork
[10:05:31 CEST] <JEEB> pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, st->time_base);
[10:06:18 CEST] <JEEB> so yes the option will "work" for MPEG-TS input, but I think of this as something that an API client would handle rather than the framework (I like the way upipe has three timestamps)
[10:06:43 CEST] <JEEB> (in upipe each packet has three timestamps: original coded, coded+wrap-arounds etc handled, receipt time)
[10:07:41 CEST] <JEEB> that way the API client can still know the original timestamps but attempt to normalize the stream in case the input timestamps are actually broken
[11:50:12 CEST] <pkunk> JEEB: Thanks JEEB . I'm using the console ffmpeg right now, modified to do parallel open of all input streams
[11:51:57 CEST] <pkunk> Excuse the additional nickname, Will have a look at what "upipe" is . First time I've heard of it
[11:57:44 CEST] <cartman412> Hi there! I've been making a gif maker using ffmpeg and I noticed that for some reason, when I try to add padding the final output quality seems to lower drastically. Here are the commands I use (no padding/padding): https://pastebin.com/3rrAJ0df /  https://pastebin.com/uYg8PZuq and a screenshot of the resulting gifs (no padding/padding): https://pasteboard.co/I9CCPmr.png / https://pasteboard.co/I9CD8xK.png
[11:58:20 CEST] <cartman412> Also note how the padding color seems to leak into the actual video on the left side
[11:58:28 CEST] <cartman412> Any ideas of what I might be doing wrong?
[11:58:49 CEST] <JEEB> pkunk: it's a more broadcast-oriented multimedia framework that has modules for decoding through FFmpeg etc
[11:58:55 CEST] <JEEB> it has some nice ideas
[11:59:11 CEST] <furq> cartman412: you probably want to pad before calling paletteuse
[11:59:56 CEST] <cartman412> that was what I was thinking, thanks for confirming it :) I'll try this now!
[12:08:08 CEST] <cartman412> furq your suggestion fixed the quality and pad color leaking into the actual image, but now the padding color seems to be affected instead
[12:08:41 CEST] <furq> yeah it sounds like the problem is that the pad color isn't in the generated palette
[12:08:41 CEST] <cartman412> https://pasteboard.co/I9CJAB7.png
[12:08:59 CEST] <cartman412> so I should add padding when generating the palette as well?
[12:09:05 CEST] <furq> that should work
[12:09:22 CEST] <cartman412> awesome, thanks for the quick answers :)
[12:16:48 CEST] <cartman412> furq: it worked! https://pasteboard.co/I9CMJz4.png thank you so much! :)
[13:19:01 CEST] <Atlenohen> Any idea what this does in ffmpeg's config? --extra-cflags='-MT -IWindowsInclude -GS-'
[13:19:18 CEST] <Atlenohen> Build config
[13:22:24 CEST] <furq> they're just extra arguments to your c preprocessor/compiler
[13:22:26 CEST] <pink_mist> sets flags for the C compiler
[13:22:31 CEST] <pink_mist> yeah, or preprocessor
[13:22:58 CEST] <pink_mist> what exactly they do to your C preprocessor or compiler, you'd haveto read its documentation or ask on its support forums
[13:24:40 CEST] <furq> if this is msvc then -MT uses the static runtime library and -GS disables buffer security checking
[13:24:57 CEST] <furq> i assume -I is the same as gcc (sets a header include directory)
[13:39:20 CEST] <King_DuckZ> hi, anyone knows what the -profile:v 3 option would be set in code? I'm using the library directly
[15:05:22 CEST] <th3_v0ice> Why would avformat_find_stream_info() fail for a same file that FFmpeg reads properly? Both are from the same version 4.0.
[15:34:56 CEST] <pranayvshah> How can I get ass->shaping to hold a value of 1 that is "shaping complex" in here https://github.com/FFmpeg/FFmpeg/blob/release/4.1/libavfilter/vf_subtitles.c#L152
[15:35:57 CEST] <JEEB> pranayvshah: set the shaping option to the value "complex"
[15:36:27 CEST] <pranayvshah> That option works for the ass filter. I need it to work for the subtitles filter
[15:36:28 CEST] <JEEB> oh, that is specific to the ass filter
[15:36:30 CEST] <JEEB> right
[15:36:43 CEST] <JEEB> just noticed the name of the struct that defines the option :)
[15:37:00 CEST] <pranayvshah> Yeah :P
[15:37:24 CEST] <JEEB> wonder why it was added as ass-only
[15:37:59 CEST] <pranayvshah> I nevertheless tried the same option on the subtitles filter, did not work :D
[15:39:28 CEST] <JEEB> ok, sounds like you could try moving the option from ass_options to COMMON_OPTIONS
[15:40:04 CEST] <JEEB> if it really works as an option for the other filter that you're utilizing
[15:40:05 CEST] <JEEB> :)
[15:40:58 CEST] <JEEB> which would effectively make ass_options into COMMON_OPTIONS and then nullptr
[15:41:09 CEST] <pranayvshah> As a workaround, I simply set removed the ass->shaping argument and replaced it with 1. That's a lot simpler for me since I know libass is compiled with harfbuzz
[15:41:36 CEST] <JEEB> if the option works then we might want to move it into the common options
[15:41:48 CEST] <JEEB> if you think that's a useful change and it isn't specific to the ass filter
[15:42:42 CEST] <pranayvshah> This does work for me - ass_set_shaper(ass->renderer, 1);
[15:43:06 CEST] <JEEB> ok, might post a patch on the mailing list moving the option into the common one
[15:43:09 CEST] <JEEB> *common list
[15:43:16 CEST] <pranayvshah> I was hoping to not have to use my own compiled version
[15:53:57 CEST] <bencoh> 41
[16:08:09 CEST] <Atlenohen> Does this still hold true? http://www.ffmpeg-archive.org/ffvhuff-codec-improvement-td4661530.html  FFV1 doesn't operate on per-frame level? And the force intra-frame only is not a 100% workaround?
[16:11:29 CEST] <furq> what does "operate on per-frame level" mean
[16:12:27 CEST] <DHE> and this is talking mostly about pixel formats
[16:12:47 CEST] <DHE> oh, this bit about precise and fast seeking I assume...
[16:35:33 CEST] <Atlenohen> Yeah,
[16:36:18 CEST] <furq> what makes you think setting the gop size isn't a workaround
[16:36:39 CEST] <Atlenohen> I was about to mention that, if the GOP size has anything to do wiht it
[16:37:09 CEST] <Atlenohen> I guess good then
[16:37:29 CEST] <furq> i mean i don't know that it is
[16:37:33 CEST] <furq> i just didn't see that in the thread
[16:37:51 CEST] <furq> it ought to work fine with a gop size of 1
[17:03:36 CEST] <HickHoward> uhhhhhhh
[20:50:11 CEST] <HickHoward> uhh
[20:50:57 CEST] <HickHoward> how can i encode a mpeg2 video file with a custom intra quantizer matrix?
[20:52:57 CEST] <HickHoward> wait a second
[20:53:00 CEST] <HickHoward> nevermind
[21:17:05 CEST] <HickHoward> anyways i'm having a bit of a problem with this filter
[21:17:06 CEST] <HickHoward> file:///H:/ffmpeg/doc/ffmpeg-filters.html#toc-il
[21:17:32 CEST] <HickHoward> so, with ffmpeg's current version i'm supposed to just use "-vf 'il'" or something?
[21:18:46 CEST] <HickHoward> i say this because i tried other options 'il' has in offer like chroma_mode and interleave but none of them work
[21:18:48 CEST] <HickHoward> like this
[21:18:57 CEST] <HickHoward> "-vf "il=chroma_mode=interleave""
[21:21:12 CEST] <durandal_1707> pastebin full command and ffmpeg output
[21:21:24 CEST] <HickHoward> wait
[21:21:33 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf 'il=chroma_mode:interleave' openingW.avi
[21:21:35 CEST] <HickHoward> no
[21:21:38 CEST] <HickHoward> sorry
[21:21:47 CEST] <HickHoward> you meant pastebin
[21:22:06 CEST] <HickHoward> https://pastebin.com/TaQKq8VD
[21:23:09 CEST] <durandal_1707> HickHoward: il=chroma_mode=interleave
[21:23:45 CEST] <HickHoward> pastebin edited
[21:23:48 CEST] <HickHoward> doesn't work for me either
[21:24:29 CEST] <durandal_1707> HickHoward: you forgot to paste and ffmpeg output of command
[21:25:02 CEST] <HickHoward> just the ffmpeg output of command
[21:25:11 CEST] <HickHoward> okay
[21:26:02 CEST] <HickHoward> pastebin updated
[21:29:25 CEST] <durandal_1707> HickHoward: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode:interleave" openingW.avi
[21:30:28 CEST] <HickHoward> done
[21:30:31 CEST] <HickHoward> pastebin updated
[21:36:50 CEST] <durandal_1707> HickHoward: Sorry, use: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode=interleave" openingW.avi
[21:37:55 CEST] <HickHoward> okay, *now* it works
[21:39:53 CEST] <HickHoward> well, i feel like i haven't communicated my idea with this yet
[21:40:00 CEST] <HickHoward> so, the source file looks like this
[21:40:01 CEST] <HickHoward> https://i.boring.host/WS8WD5U.png
[21:40:21 CEST] <HickHoward> what you're seeing here is *two* frames being combined into one
[21:40:33 CEST] <HickHoward> and the frame rate is halved
[21:40:36 CEST] <HickHoward> because of this
[21:41:08 CEST] <HickHoward> (as in, the original frame rate of this source file is 29.98 fps)
[21:41:16 CEST] <HickHoward> *29.97 fps
[21:42:31 CEST] <durandal_1707> use weave/doubleweave
[21:42:38 CEST] <HickHoward> okay
[21:44:40 CEST] <HickHoward> tested it, all that ever did was double the horizontal screen size of the output file
[21:44:55 CEST] <HickHoward> *all that ever did => all that weave/doubleweave
[21:49:10 CEST] <durandal_1707> HickHoward: il=1:1:1
[21:49:25 CEST] <HickHoward> hold on
[21:49:27 CEST] <durandal_1707> HickHoward: il=1:1:1,separatefields
[21:49:42 CEST] <HickHoward> okay, testing now
[21:54:26 CEST] <HickHoward> tested, now the frame organization is wrong as all hell(first frame is bottom, second frame is top, and so on until the end of video) so i had to put setfield=tff before separatefields
[21:57:45 CEST] <durandal_1707> HickHoward: so it works? if not upload first 20 frames somewhere
[21:57:54 CEST] <HickHoward> yes
[22:16:15 CEST] <HickHoward> okay, now i've done this
[22:16:17 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=1:1:1,setfield=tff,separatefields" -vcodec rawvideo -pix_fmt bgr24 openingW.avi
[22:16:36 CEST] <HickHoward> and now i want the output video to remain its input resolution(640x448)
[22:19:06 CEST] <cptnhmr42> Does anyone know if there are any patches out there for dealing with AV sync issues when converting RTMP to HLS / MPEG-DASH?
[23:08:34 CEST] <faLUCE> Hello. If a GPL non-commercial library uses ffmpeg/x264, does it have to contact/pay something to MPEG LA ?
[23:09:46 CEST] <faLUCE> it seems that MPEG LA's license doesn't talk about FOSS projects, and requires a fee only for big commercial ones
[23:11:42 CEST] <JEEB> software licensing is unrelated to patent licensing due to distributing binaries
[23:12:30 CEST] <faLUCE> JEEB: and what does this cause?
[23:13:24 CEST] <JEEB> that whether something is open source or not doesn't matter. you look if <patent licensing for thing X> is applicable to you (maybe consult a lawyer if you care enough) regardless
[23:14:25 CEST] <JEEB> I don't know your laws and whether such licensing is applicable in your country to begin with
[23:14:51 CEST] <faLUCE> JEEB: for example, in France?
[23:15:07 CEST] <JEEB> VideoLAN seems to be on the stance of middle fingering
[23:15:15 CEST] <JEEB> given that they are not paying for VLC distribution
[23:16:02 CEST] <faLUCE> JEEB: but what if a library doesn't provide binaries?
[23:16:13 CEST] <JEEB> then at least with MPEG-LA you have no problems
[23:16:17 CEST] <JEEB> they license binary distribution
[23:16:32 CEST] <JEEB> at least according to a quote from donald graft on doom9 ages ago
[23:16:51 CEST] <JEEB> if you start caring about patent licensing of course, then there's way more than just MPEG-LA :P
[23:17:46 CEST] <JEEB> it's a messy thing if you really want to start looking into it
[23:18:03 CEST] <faLUCE> JEEB: yes, I tried to understand but it's too messy
[23:18:19 CEST] <faLUCE> after reading several posts I did not get any conclusion
[23:18:22 CEST] <JEEB> well, the MPEG-LA rules in general are pretty simple
[23:18:25 CEST] <JEEB> for H.264 at least
[23:18:55 CEST] <faLUCE> which are them?
[23:19:00 CEST] <JEEB> https://www.mpegla.com/wp-content/uploads/avcweb.pdf
[23:19:08 CEST] <JEEB> this is the brief overview
[23:19:43 CEST] <JEEB> for example for encoders you pay nothing if you distribute 0-100k binaries :P
[23:20:04 CEST] <faLUCE> JEEB: where is the word "binary" in that doc?
[23:20:29 CEST] <JEEB> "Products sold to end users" is basically binary distribution to end user
[23:20:46 CEST] <faLUCE> JEEB: in this case thekeyword is "sold", not "binary"
[23:21:05 CEST] <JEEB> yes, but you can sell it for $0. it's made for businesses that generally don't set the price at $0 :P
[23:21:11 CEST] <JEEB> of course
[23:21:17 CEST] <JEEB> nothign stops you from *asking* MPEG-LA
[23:22:17 CEST] <faLUCE> JEEB: but why a library is not a "product" ?
[23:22:25 CEST] <JEEB> ?
[23:22:36 CEST] <JEEB> I don't think whether it's a library or not matters
[23:23:18 CEST] <faLUCE> so, it's not clear if open source code is not a "product sold to end user"
[23:23:25 CEST] <faLUCE> (encoder)
[23:23:31 CEST] <JEEB> I will have to find the quote
[23:23:39 CEST] <JEEB> but MPEG-LA has said that they don't care about *source*
[23:23:40 CEST] <durandal_1707> faLUCE: you need to pay for any non-foss codec usage as user to my address
[23:24:26 CEST] <faLUCE> durandal_1707: yes, in fact I understood that MPEG LA wants to be payed for non FOSS
[23:24:37 CEST] <faLUCE> durandal_1707: but where is it specified in their license?
[23:24:47 CEST] <faLUCE> it doesn't talk about foss or non foss
[23:25:16 CEST] <JEEB> https://forum.doom9.org/showthread.php?t=156599
[23:25:34 CEST] <JEEB> yea, MPEG-LA does not care if the distributed software (binaries) is OSS or not
[23:26:32 CEST] <durandal_1707> OSS is irrelevant to them, they count only implementations
[23:27:06 CEST] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps)
[23:27:13 CEST] <JEEB> or well, it would be stupid to go after them
[23:27:43 CEST] <faLUCE> [23:27] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps)  <--- this is true, but tehy could, if they want
[23:28:08 CEST] <JEEB> yes
[23:28:16 CEST] <JEEB> if they would want to enforce it they 100% could attempt to
[23:28:25 CEST] <JEEB> whether such patent licensing is valid in your country is the key
[23:28:29 CEST] <JEEB> > Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing.
[23:28:42 CEST] <JEEB> this is the quoting from MPEG-LA
[23:29:40 CEST] <faLUCE> JEEB: so, if a library wraps ffmpeg, there are not binaries or "products"
[23:29:56 CEST] <JEEB> faLUCE: until someone produces a binary and distributes it to users, yup
[23:30:05 CEST] <JEEB> source code only is something that MPEG-LA does not care about
[23:30:41 CEST] <JEEB> or at least this was the case in 2010
[23:31:01 CEST] <faLUCE> JEEB: in case MPEG LA cares about source code, it would stop/break projects like vlc,ffmpeg, mplayer and tons of other stuff downloaded by million of users
[23:31:20 CEST] <faLUCE> this would be absurd
[23:31:25 CEST] <durandal_1707> really?
[23:32:13 CEST] <faLUCE> durandal_1707: so this is the reason for which they don't do anything
[23:32:30 CEST] <faLUCE> ?
[23:34:01 CEST] <durandal_1707> sometimes they ask authors to remove source code implementing certain codecs
[23:34:22 CEST] <faLUCE> durandal_1707: which codecs for example?
[23:34:59 CEST] <durandal_1707> any random one =p
[23:36:06 CEST] <faLUCE> durandal_1707: but they asked that to ffmpeg too?
[23:36:42 CEST] <durandal_1707> yea
[23:37:03 CEST] <faLUCE> and did ffmpeg remove the code?
[23:37:45 CEST] <durandal_1707> nope
[23:38:06 CEST] <faLUCE> durandal_1707: and they (MPEG LA) did not do anything else?
[23:38:43 CEST] <durandal_1707> uhg, i dunno about MPEG LA, I was talking about other companies
[23:39:29 CEST] <faLUCE> durandal_1707: so there's a fight between companies and ffmpeg
[23:40:33 CEST] <durandal_1707> more like fight with authors of certain REd code
[23:41:06 CEST] <HickHoward> gotta protect my codecs!
[23:41:23 CEST] <faLUCE> durandal_1707: but do they have really power to begin a legal action against ffmpeg ?
[23:42:01 CEST] <durandal_1707> dunno, anything can change
[23:43:31 CEST] <faLUCE> then it's a very obscure situation :-(
[23:44:36 CEST] <faLUCE> JEEB: from what "ryan" of the linked discussion say, that companies could not do anything
[23:46:32 CEST] <faLUCE> let's ask to x264 channel too...
[23:47:08 CEST] <durandal_1707> x264 is encoder, while i mainly talked about decoders
[23:47:36 CEST] <faLUCE> durandal_1707: what's the difference, in terms of legal stuff?
[23:48:50 CEST] <durandal_1707> dunno, for important legal stuff ask lawyers
[23:49:50 CEST] <durandal_1707> short story: if you make money on ffmpeg, they will come after you...
[23:50:01 CEST] <faLUCE> durandal_1707: this is not my case
[23:50:11 CEST] <faLUCE> and I understood that
[23:51:11 CEST] <faLUCE> durandal_1707: but I wondered if is there anything in their licens/docs that assures that if you DON'T provide binaries and DON'T make money , you won't have probles
[23:51:16 CEST] <faLUCE> problems
[23:51:32 CEST] <JEEB> of course not, why would they write that :D
[23:52:05 CEST] <JEEB> but at least the binary distribution is a requirement for *MPEG-LA*
[23:52:12 CEST] <faLUCE> JEEB: for completeness
[23:52:16 CEST] <JEEB> so it doesn't matter for MPEG-LA if you're OSS or not
[23:52:27 CEST] <JEEB> if you don't distribute binaries you're not distributing to end users
[23:52:34 CEST] <JEEB> that's an early exit :P
[23:52:46 CEST] <JEEB> (not legal advice but that's how a lot of people read it)
[23:53:05 CEST] <faLUCE> JEEB: it seems more a "common thought" that the reality
[23:53:35 CEST] <JEEB> faLUCE: for you, not for MPEG-LA or any other licensor. for the licensor it is much better if there are cases where someone is unsure, and thus they are more likely to license
[23:53:46 CEST] <JEEB> for possible licensees it is of course worse
[23:53:47 CEST] <JEEB> :P
[23:54:09 CEST] <JEEB> thus it becomes a legal thing and the only ones that can advise you on that are lawyers
[23:55:21 CEST] <JEEB> or if you want MPEG-LA's opinion, ask them
[23:55:32 CEST] <faLUCE> but in the case they want to require license from one of these GPL non-commercial products, they would have to do that for all of them
[23:56:04 CEST] <JEEB> dunno, I don't know if there are such requirements in laws
[23:56:14 CEST] <JEEB> I Am Not A Lawyer (IANAL)
[23:56:43 CEST] <faLUCE> JEEB: anyway, "Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing."  <-- it doesn't quote ryan's words
[23:56:50 CEST] <JEEB> true
[23:57:00 CEST] <JEEB> he did leave ryan's contact though
[23:57:09 CEST] <JEEB> feel free to request a new quotable thing
[23:57:23 CEST] <JEEB> if you want MPEG-LA's opinion on things
[00:00:00 CEST] --- Fri Apr 12 2019