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

[burek]

[00:01:57 CEST] <Lynne> https://github.com/obsproject/obs-studio/blob/master/plugins/obs-outputs/ftl-stream.c#L1061
[00:02:47 CEST] <Lynne> if someone had told me that a streaming site NIH'd RTPM just so they could force disable b-frames to reduce latency and throw opus in because they could I wouldn't have believed them
[00:04:48 CEST] <JEEB> Lynne: wait it's RTMP but NIH'd?
[00:04:54 CEST] <JEEB> I thought it was UDP
[00:05:12 CEST] <BtbN> Lynne, they didn't NIH anything. FTL is WebRTC + a few extensions.
[00:10:00 CEST] <Lynne> BtbN: huh, I did see a webrtc string there but I thought an implementation had to be a lot bigger
[00:11:11 CEST] <Lynne> like handle traffic flow, packet loss, bottlenecking etc.
[00:11:33 CEST] <BtbN> They have a whole relatively big library to handle it, so, yeah, it's not light?
[00:11:51 CEST] <JEEB> yea
[00:13:16 CEST] <Lynne> BtbN: that library doesn't seem to be included or linked in obs?
[00:13:30 CEST] <BtbN> iirc they use libftl?
[00:13:44 CEST] <BtbN> Unless they re-implemented it by themselves?
[00:14:30 CEST] <nevcairiel> they have the official ftl sdk as a git module linked in there, so yeah.
[00:14:33 CEST] <Lynne> right, I just saw that
[00:19:34 CEST] <Lynne> how bad do things have to be to extend webrtc to get lower latency than HLS?
[00:20:11 CEST] <BtbN> HLS without hacks has 10+ seconds of delay at the very least
[00:20:24 CEST] <BtbN> Also, this is the _ingest_ protocol
[00:20:33 CEST] <BtbN> I don't think the Websites Player uses WebRTC
[00:20:44 CEST] <nevcairiel> the player is HLS
[00:21:05 CEST] <nevcairiel> HLS cant ingest
[00:22:55 CEST] <Lynne> if its only on the streamer->server side isn't it pointless? it shouldn't have latency advantages over rtmp
[00:23:17 CEST] <JEEB> rtmp is maintained by adobe who no longer maintain it
[00:23:34 CEST] <JEEB> fragmented MP4 over HTTP or TCP or whatever, or something UDP is where it should be going
[00:30:58 CEST] <Illya> anyone have some MPEG-TS samples with PSIP data?
[01:05:33 CEST] <tmm1> Illya: yea i have some, are you looking for atsc or dvb?
[01:11:34 CEST] <Illya> tmm1: atsc (isn't PSIP an atsc only thing?)
[01:22:12 CEST] <tmm1> hm yea i guess the DVB tables are not called psip
[01:23:05 CEST] <tmm1> looks like i have mostly dvb eit samples
[01:23:49 CEST] <tmm1> the psip stuff is a PITA because you have to figure out the pids to listen on first (vs fixed 0x12 for all eit data on dvb)
[01:24:34 CEST] <Illya> those samples might be useful for what I'm doing anyway
[01:33:08 CEST] <tmm1> Illya: https://tmm1.s3.amazonaws.com/dvb-eit/cze-eit.mpg 
[01:33:48 CEST] <tmm1> at the same path: uk-eit-{hd,sd}.ts israel-{dvbt,dvt2-hd,dvbt2-sd}.ts
[01:35:54 CEST] <tmm1> also france-eit.ts
[01:35:56 CEST] <Illya> israel-*.ts seems to 403 but I got the rest
[01:36:56 CEST] <tmm1> try now
[01:37:03 CEST] <tmm1> https://tmm1.s3.amazonaws.com/dvb-eit/israel-dvbt.ts
[01:37:16 CEST] <tmm1> i have one from greece also but its a bigger sample with video included
[01:37:18 CEST] <Illya> Nice thanks got all of them. This should be enough
[01:37:50 CEST] <Illya> Just doing titles from EIT for now
[01:39:27 CEST] <tmm1> decoding the text can be tricky, there is some custom charset used which some (but not all) builds of iconv can decode
[01:39:30 CEST] <Illya> actually I'll do descriptors as well, I guess what I meant is no ETT for now
[01:39:41 CEST] <Illya> tmm1: funnily enough that's why I'm doing this
[01:39:43 CEST] <tmm1> also the uk hd samples use some sort of huffman encoding to scramble the text
[01:40:10 CEST] <tmm1> ah then you probably want the greek one too
[01:41:19 CEST] <Illya> is the custom charset you're thinking of aribb24 because I have a WIP module for it (works with all standard builds of iconv)
[01:41:51 CEST] <tmm1> https://tmm1.s3.amazonaws.com/dvb-eit/greece.ts
[01:42:02 CEST] <Illya> or are there others I need to worry about as well? (I assumed most other things are just UTF-8)
[01:42:07 CEST] <tmm1> no, that one is used in japan or something right
[01:42:27 CEST] <Illya> yes
[01:42:54 CEST] <tmm1> its been a few years let me look up what i'm thinking of
[01:44:11 CEST] <tmm1> unfortunately almost none of them use utf8, its all iso8859 variants and there's a charset identifier in the eit tables that tells you how to decode
[01:44:57 CEST] <tmm1> libdvbpsi does a good job with the tables, then you can use i_iso_639_code field to figure out how to decode the text
[01:45:37 CEST] <Illya> most of those should be convertable with iconv though I'd imagine
[01:50:06 CEST] <tmm1> https://lists.gnu.org/archive/html/bug-gnu-libiconv/2009-09/msg00002.html
[01:51:04 CEST] <tmm1> this is what i was recalling.. vlc had to add ISO6937 itself because glibc iconv didn't have it (but libiconv does?)
[01:56:00 CEST] <Illya> Hmm. Should I just be using libdvbpsi rather than writing EIT decoding myself? Not sure it'll be good to depend on libdvbpsi here for this simple functionality
[01:57:26 CEST] <tmm1> not sure what're you doing.. there was a bit EIT decoding patchset on the mailing list recently too
[01:57:31 CEST] <Illya> also interesting on the iconv issue, we might have to do the same as VLC for this (have an iconv wrapper)
[01:58:17 CEST] <Illya> All I want to do is extract titles and descriptors from EIT
[01:58:38 CEST] <tmm1> "DVB EPG decoder"
[02:00:21 CEST] <tmm1> i think some of the patches were merged actually
[02:00:33 CEST] <tmm1> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247789.html
[02:00:36 CEST] <tmm1> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248692.html
[02:02:13 CEST] <Illya> decoder is the misleading here I think, it just dumps the EIT with the wrong name
[02:04:13 CEST] <Illya> anyway what I want to do with the EIT isn't so complex, I'll do a patch tomorrow or on the weekend and see what people think (maybe it's not useful), then work on aribb24 again.
[02:06:27 CEST] <tmm1> extracting titles into AVProgram sounds like a great idea
[02:06:56 CEST] <tmm1> should be fairly straightforward, i don't think you need all of libdvbpsi for that
[02:08:14 CEST] <Illya> yeah was my thinking, and as marton said on the ML, complex supplementary information stuff (i.e. using libdvbpsi internally) isnt really within scope of the libraries
[11:06:50 CEST] <cone-361> ffmpeg 03Limin Wang 07master:b9d479bac45b: avfilter/vf_scale: cosmetics
[11:06:50 CEST] <cone-361> ffmpeg 03Limin Wang 07master:cde1d70a39ad: swscale/swscale: cosmetics
[12:06:30 CEST] <BtbN> I'm a bit confused regarding the new max reference frame option there in nvenc.
[12:06:47 CEST] <BtbN> maxNumRefFrames already existed, documented as "Specifies the DPB size used for encoding."
[12:07:14 CEST] <JEEB> vOv
[12:07:19 CEST] <BtbN> Now there is numRefL0 and numRefL1, saying "Specifies max number of reference frames in reference picture list L0/L1, that can be used by hardware for prediction of a frame."
[12:07:44 CEST] <nevcairiel> technically you can have a difference between  overall number of kept ref frames, and number of frames used per-frame from said list
[12:08:49 CEST] <nevcairiel> hevc specifically drives that point home even more, since the DPB allows 16 frames, but per-frame you can only use 8 at most  (IIRC)
[12:09:21 CEST] <JEEB> yea
[12:09:31 CEST] <JEEB> that was an interesting difference to AVC
[12:10:04 CEST] <BtbN> hm, so it makes sense to have two separate options for it. But it makes me feel like avctx->refs would have matched better for the new option that was added, but now it's already tied to the DPB size
[12:10:06 CEST] <JEEB> I guess it makes sense since you can keep more refs in your DPB, but usually you don't need so many per coded frame
[12:16:00 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:044167a171d5: avformat/nut: add pcm_s64 support
[12:45:11 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:35a12d2071ef: avformat/g729dec: set packet duration and correctly set timebase info
[13:48:03 CEST] <cehoyos> BBB: Am I completely wrong? Or does the new RGB10 format actually help anybody?
[13:48:14 CEST] <cehoyos> s/does/would
[13:48:17 CEST] <BBB> let me have a look
[13:48:37 CEST] <BBB> the intel format?
[13:48:40 CEST] <BBB> a2rgb10
[13:48:41 CEST] <BBB> ?
[13:48:58 CEST] <cehoyos> Nobody else comments, so it is unclear for me if I just write what everybody thinks or if it is exactly the other way round.
[13:49:05 CEST] <cehoyos> Yes, A2R10G10B10
[13:49:18 CEST] <BBB> it seems like a hw thing to me
[13:49:23 CEST] <BBB> that doesn't mean yes or no
[13:49:40 CEST] <BBB> it just means that we're unlikely to ever see it be used in the more classic ffmpeg libs, like swscale or avcodec
[13:49:44 CEST] <cehoyos> It seems to me that this pix_fmt is only added to be able to connect to vaapi filters with each other
[13:49:48 CEST] <BBB> yes
[13:49:50 CEST] <BBB> exactly
[13:50:08 CEST] <BBB> it's a problem in our design that components can't connect using self-defined pixfmts
[13:50:13 CEST] <cehoyos> Well, one thing is for sure: If the format will be added, then only if swscale (also) supports it.
[13:50:18 CEST] <BBB> in gstreamer, you can have private pixfmts (sort of)
[13:50:27 CEST] <BBB> i think that's a reasonable request
[13:50:34 CEST] <cehoyos> But what is wrong with having the filter output GBRP10, so that other use cases will be supported?
[13:50:42 CEST] <BBB> it requires conversion
[13:50:51 CEST] <BBB> which is exactly what you're trying to not do with hw pipelines
[13:51:02 CEST] <cehoyos> It always requires conversion because nothing in FFmpeg suport RGB10
[13:51:07 CEST] <Lynne> cehoyos: you misunderstand what the format is for and its use, but feel free to ignore me, after all who am I?
[13:51:17 CEST] <BBB> right, but what if the whole app is using hwaccel?
[13:51:18 CEST] <cehoyos> Correct;-)
[13:51:36 CEST] <BBB> i agree that you need conversion to go in from avcodec
[13:51:44 CEST] <cehoyos> But why can't the hw support GBRP10, aren't they controlling the drivers?
[13:51:47 CEST] <BBB> but from then on, all intel hw components can use their internal private format
[13:51:50 CEST] <BBB> which is great for intel
[13:51:57 CEST] <BBB> (...)
[13:51:58 CEST] <cehoyos> Or is my assumption that the hw could do it if they want it, simply wrong
[13:52:03 CEST] <BBB> but yes, swscale conversion would be great
[13:52:14 CEST] <BBB> i don't think hw can do tht for free
[13:52:16 CEST] <cehoyos> That sounds like an even stronger reason to reject the patch, no?
[13:52:26 CEST] <BBB> it's like asking x264 to input ... say, yuyv
[13:52:27 CEST] <cehoyos> Not even for nearly free?
[13:52:36 CEST] <BBB> i don't think so, i think it'd require actual effort
[13:52:51 CEST] <cehoyos> As in: gpu time or developer time?
[13:52:55 CEST] <BBB> it's cheaper than sw conversion, sure
[13:53:02 CEST] <BBB> but it requires electricity, yes
[13:53:05 CEST] <BBB> power
[13:53:08 CEST] <cehoyos> ok
[13:53:16 CEST] <BBB> so i think they'd like to prevent it if they can
[13:53:20 CEST] <BBB> this is all built for scale
[13:53:29 CEST] <BBB> but yes, swscale conversion is a must, i agree
[13:53:36 CEST] <BBB> other than that i see no big issue
[13:53:39 CEST] <BBB> it's quirky, yes
[13:53:44 CEST] <BBB> but lots of hw things are quirky
[13:54:20 CEST] <cehoyos> My suggestion was to add the conversion in the filter to avoid a format that has no other use case but if that's not true, the conversion if of course a solution.
[13:56:25 CEST] <BBB> yeah i think it's ok... it obviously relies on people doing lots of hw filter chainings
[13:56:33 CEST] <BBB> i don't know if that's a thing that's likely to happen
[13:56:40 CEST] <BBB> but that's obviously what they're going for here
[13:56:51 CEST] <BBB> (and then show minimal power consumption: see, hw is better than sw!!!112)
[13:57:23 CEST] <BBB> i certainly agree with you that having an incompatible hdr pipeline for intel hw vs. the rest of ffmpeg is illogical
[13:57:29 CEST] <BBB> we need to be able to convert from one to the other
[13:57:38 CEST] <BBB> otherwise it's meaningless and we become just another corporate middleware
[13:57:42 CEST] <BBB> screw that
[13:58:14 CEST] <BBB> but there will likely be hw filters that only exist in hw and for which no sw alternative exists... not conversion, but certain types of specialized filters
[13:58:21 CEST] <BBB> that's unfortunate, but i dont know how to solve it :(
[14:02:03 CEST] <BtbN> Hardware works very different from software, and they often use weird pixel formats.
[14:02:26 CEST] <BtbN> nvenc and cuvid have such conversion to more standard pixel formarts built in, but it does cost some performance, because it does convert back and forth in a shader
[14:02:32 CEST] <BtbN> The native nvidia pixel format is tiled
[14:02:41 CEST] <BtbN> And I'd expect it to be something similar for Intel
[14:11:49 CEST] <durandal_1707> someone pushed invalid code about not ignoring invalid index in lavf
[14:12:06 CEST] <durandal_1707> please REVERT IMMEDIATELY!!!!!!!
[14:13:47 CEST] <cehoyos> Thank you!
[14:26:19 CEST] <durandal_1707> forcing demuxer to always return packets with valid index is not friendly
[14:26:41 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:bb697f30ab28: avformat/dhav: fix demuxer since recent breakage
[14:28:37 CEST] <BtbN> cehoyos, I can't really think of any sane way to add a compatiblity shim for this. Using avctx->refs for the new option would be in line with how libx264 uses it though, and with what most users most likely expect. So I'm not too opposed to breaking it.
[14:28:54 CEST] <BtbN> The only issue is, setting that option on older drivers and pre-turing cards will cause a failure.
[14:29:16 CEST] <cehoyos> I really believe that we are (sometimes) using the "api" argument in the wrong way.
[14:29:29 CEST] <cehoyos> I can only comment that:
[14:29:31 CEST] <BtbN> Well, the ffmpeg cli arguments are also an API
[14:29:39 CEST] <cehoyos> Not everybody has a turing card and (but)
[14:29:58 CEST] <cehoyos> The options that work for x264 encoding with ffmpeg should also map to other encoders if possible
[14:30:11 CEST] <BtbN> Yes, exactly why I think that breaking existing scripts with this change is not ideal
[14:30:35 CEST] <cehoyos> I mean: We broke "api" in the past arguing it was not api (or other explanations), we should really brake it to increase usability
[14:30:50 CEST] <cehoyos> Why does it not work on older infrastructure
[14:30:51 CEST] <cehoyos> ?
[14:30:57 CEST] <BtbN> x264 also has the equivalent of the what nvenc currently uses the -refs option for, "i_dpb_size". But libx264.c does not appear to set it
[14:31:19 CEST] <BtbN> Because the option is not supported on pre-Turing, and setting it to anything but 0 there will cause nvenc init to fail
[14:31:20 CEST] <cehoyos> Doesn't this indicate that it simply doesn't have to be set?
[14:31:29 CEST] <cehoyos> if turing - else - ?
[14:31:39 CEST] <BtbN> There is no sensible way to determine that from nvenc.c
[14:31:49 CEST] <cehoyos> if (ret<0) ?
[14:32:10 CEST] <BtbN> Well, the entire initialization will fail. It's not a single call to set just that parameter.
[14:32:20 CEST] <cehoyos> Or does the driver assert on valid options? ;-)
[14:33:00 CEST] <cehoyos> How does it work with the suggested patch applied for old hardware?
[14:33:15 CEST] <BtbN> If you set the new option and have old hardware, init will fail.
[14:33:22 CEST] <cehoyos> Wow
[14:33:25 CEST] <BtbN> But existing commandline won't change behaviour.
[14:33:33 CEST] <BtbN> There is a ton of options in nvenc that work like that.
[14:34:01 CEST] <cehoyos> This sounds broken to me but if existing command lines fail users can easily adapt, no?
[14:34:22 CEST] <BtbN> Generally, the new option is MUCH closer to what a user would expect -refs to do
[14:34:34 CEST] <BtbN> The very limited hardware and driver support is unfortunate
[14:34:36 CEST] <cehoyos> Then change it imo, but ask on the mailing list...
[14:34:59 CEST] <BtbN> The old option is equivalent to x264 i_dpb_size: https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c14575d7d39eb8fadb97f/x264.h#L333
[14:35:06 CEST] <BtbN> which ffmpeg does not even care to implement
[14:39:25 CEST] <cehoyos> Which imo indicates that the option is not super-useful (but who knows)
[14:39:52 CEST] <cehoyos> The logger missed the creation of the ticket but not my edit?
[14:40:46 CEST] <BtbN> It's an option primarily used in interactive encoding sessions, where the player can signal the encoder that it didn't receive a certain frame, and the encoder can then react and exclude that frame from being used as a reference.
[14:41:00 CEST] <BtbN> So, exposing it via the ffmpeg cli ist mostly useless
[14:42:07 CEST] <BtbN> I also wonder what caused them to use an enum for this... http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=blob;f=include/ffnvcodec/nvEncodeAPI.h;h=77012108139e2f3f9c90e34f9d553f5873520f76;hb=HEAD#l721
[15:39:54 CEST] <cone-361> ffmpeg 03James Almer 07master:f96a8b015f2f: avcodec/mpeg4audio: add avpriv_mpeg4audio_get_config2()
[15:39:55 CEST] <cone-361> ffmpeg 03James Almer 07master:d582cc17e1f6: avcodec: use avpriv_mpeg4audio_get_config2()
[15:39:56 CEST] <cone-361> ffmpeg 03James Almer 07master:35bbaa665246: avformat: use avpriv_mpeg4audio_get_config2()
[15:51:24 CEST] <cone-361> ffmpeg 03James Almer 07master:75c7484fcb18: avcodec/mpeg4audio: fix doxy for ff_mpeg4audio_get_config_gb()
[15:51:25 CEST] <cone-361> ffmpeg 03Jun Zhao 07master:333109f46961: lavc/mpeg4audio: add chan_config check to avoid indeterminate channels
[16:49:27 CEST] <durandal_1707> libavcodec/utils.c:1437:42: warning: adding 'unsigned long' to a string does not append to the string [-Wstring-plus-int]
[16:49:30 CEST] <durandal_1707>     return LICENSE_PREFIX FFMPEG_LICENSE + sizeof(LICENSE_PREFIX) - 1;
[16:49:32 CEST] <durandal_1707>            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
[16:49:35 CEST] <durandal_1707> libavcodec/utils.c:1437:42: note: use array indexing to silence this warning
[16:49:38 CEST] <durandal_1707>     return LICENSE_PREFIX FFMPEG_LICENSE + sizeof(LICENSE_PREFIX) - 1;
[16:49:40 CEST] <durandal_1707>                                          ^
[16:49:43 CEST] <durandal_1707>            &                             [                       ]
[16:50:25 CEST] <mkver> One would have to use array indexing to silence this warning:
[16:52:35 CEST] <mkver> return &(LICENSE_PREFIX FFMPEG_LICENSE)[sizeof(LICENSE_PREFIX) - 1];
[16:53:13 CEST] <mkver> The parentheses are unnecessary if I am not mistaken, but they won't hurt.
[16:58:31 CEST] <cehoyos> Aahh
[17:48:17 CEST] <BtbN> Does anyone know what the correct restrictions of blurays are? The bluray_compat option of nvenc clamps avctx->refs to 0-6. Does it actually mean the dpb_size, or the number of references per frame?
[17:50:40 CEST] <BtbN> ok, it's dpb_size: https://github.com/mirror/x264/blob/master/encoder/encoder.c#L997
[17:53:44 CEST] <cone-177> ffmpeg 03Zhong Li 07master:0686651aab1d: lavu/qsv: remove redundant version query
[17:59:53 CEST] <taliho> is the AV_OPT_FLAG_EXPORT flag used for anything? 
[18:00:01 CEST] <taliho> I can't see it used anywhere except for writing the value of the flag in opt.c:1217 
[18:01:59 CEST] <taliho> reason I'm asking is that I'd like to make ts_packetsize in mpegts.c a user settable parameter
[18:02:26 CEST] <mkver> git grep says it is used un libavformat/http.c and libavformat/flvdec.c
[18:02:44 CEST] <taliho> at the moment it's AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY are set 
[18:07:41 CEST] <taliho> mkver: that's true, the flag is set there
[18:08:11 CEST] <taliho> I'm trying to find how the flag is used something like flag & AV_OPT_FLAG_EXPORT
[18:47:02 CEST] <cehoyos> What is "hdv"?
[18:47:05 CEST] <cehoyos> Ticket 8295
[18:47:11 CEST] <cehoyos> Ticket 8205
[18:48:00 CEST] <gnafu> Does it relate to this? --> https://en.wikipedia.org/wiki/HDV
[18:48:07 CEST] <nevcairiel> the guy obviously has no idea what he is talking about
[18:48:26 CEST] <nevcairiel> throwing around marketing names instead of actual technical formats
[18:48:55 CEST] <nevcairiel> basically all he mentions are mpeg2 transport stream variants
[18:51:11 CEST] <cehoyos> It's also possible that he knows but does not speak English...
[18:52:05 CEST] <durandal_1707> nope, just close stupid tickets
[18:54:51 CEST] <cehoyos> gnafu: Thank you, a sample is in 6271
[19:00:17 CEST] <nevcairiel> you dont need to know english to know the difference between "mpeg2 transport stream" and "bluray"
[19:13:55 CEST] <BtbN> Can anyone think of a situation that intentionally makes an nvenc function fail? I want to test the new GetLastError function, but everything that comes to mind is caught ahead of time.
[19:15:11 CEST] <jamrial> BtbN: arguments outside the option's internall allowed range?
[19:15:27 CEST] <BtbN> Those are all caught by capability checks
[19:15:46 CEST] <BtbN> At least the ones that actually would cause a failure
[19:17:04 CEST] <BtbN> I don't understand what Sami32 is asking at all.
[19:17:28 CEST] <nevcairiel> I don't think he does
[19:18:11 CEST] <BtbN> I'm just gonna throw ridiculous options at it until it gives up
[19:20:02 CEST] <BtbN> yep, works. Told it to encode a 1080p stream with level 1.3: [h264_nvenc @ 000000000c1e0540] InitializeEncoder failed: invalid param (8): Invalid Level.
[19:54:58 CEST] <cone-177> ffmpeg 03Ross Nicholson 07master:460f74495fa9: libavformat/rtsp: return error if rtsp_hd_out is null instead of crash
[19:55:26 CEST] <j-b> Who cared about the decklink headers license? Was it you, BtbN ?
[19:56:41 CEST] <BtbN> I cared about getting newer headers to build for coverity, but I'm not overly concearned with the license otherwise.
[19:59:49 CEST] <j-b> Do you remember who did?
[19:59:54 CEST] <j-b> kierank: ^^?
[20:00:10 CEST] <kierank> carl i think
[20:00:16 CEST] <kierank> it's the mismatch between the eula and the headers
[20:00:18 CEST] <j-b> besides carl
[20:00:18 CEST] <kierank> and which takes priority
[20:00:20 CEST] <kierank> that old chestnut
[20:00:27 CEST] <j-b> Yes, I think I fixed that during IBC.
[20:01:22 CEST] <kierank> j-b: how did you fix it?
[20:01:42 CEST] <j-b> kierank: by screaming on their booth, until the general dev relation manager came.
[20:01:50 CEST] <kierank> I have asked them before to change it
[20:01:52 CEST] <kierank> years ago
[20:01:54 CEST] <kierank> but they didn't
[20:02:13 CEST] <j-b> I got the email now, where they "want to fix this issue"
[20:03:47 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:e929b2f248a9: avcodec/nvenc: switch to dedicated dpb_size option
[20:03:48 CEST] <cone-177> ffmpeg 03Roman Arzumanyan 07master:567b5e33d9d7: avcodec/nvenc: add multiple reference frames support
[20:03:49 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:51a23343d9c7: avcodec/nvenc: pass CUstream to nvenc when available
[20:03:50 CEST] <cone-177> ffmpeg 03Timo Rothenpieler 07master:ab0ef1abdf53: avcodec/nvenc: make use of new GetLastErrorString function
[20:06:04 CEST] <cehoyos> Regarding the decklink headers: It was a misunderstanding / mistake to ever mention the headers. The library that exchanges data structures with FFmpeg is non-free and not gpl-compatible.
[20:07:36 CEST] <j-b> Nope, they have a driver and the library to talk to the driver is fully free now.
[20:07:42 CEST] <j-b> or at least at the next release.
[20:08:38 CEST] <cehoyos> I don't think we should declare a closed-source driver for an additional hardware gpl-compatible, especially since it appears FFmpeg developers are more strict now than they were in the past.
[20:08:39 CEST] <BradleyS> i guess the question is whether various members of the open source community will forgive the old sins and let them back in
[20:08:42 CEST] <BradleyS> or demand restitution
[20:09:08 CEST] <j-b> drivers are part of the OS
[20:09:27 CEST] <cehoyos> Yes, graphic card and network drivers
[20:09:33 CEST] <j-b> else, you don't have nvdec, vdpau, or any hardware, besides vaapi
[20:09:47 CEST] <j-b> decklink is like a graphic card
[20:10:07 CEST] <cehoyos> FFmpeg developers argue that graphic card drivers are system drivers, the drivers for an additional card like a Matrox encoding card are not system drivers
[20:10:11 CEST] <BradleyS> it's an hardware peripheral, the licenses make no distinction between graphic cards and other pcie cards
[20:10:32 CEST] <kierank> in fact the api for hdmi is much better than anything linux provides
[20:10:37 CEST] <BradleyS> they should back that up with the text of the license then
[20:10:56 CEST] <j-b> yeah, I've never seen anyone argue that some drivers are not system drivers
[20:10:56 CEST] <cehoyos> The gpl makes a distinction between system drivers that normally come with a system and other software, the Matrox and decklink drivers are not system drivers.
[20:11:45 CEST] <JEEB> I don't remember exactly but at least for me the Matrox was mostly going off the scale regarding "general usefulness compared code added", not "it's not hardware"
[20:12:20 CEST] <cehoyos> Sorry, but this is a horrible argument wrt FFmpeg, we support (even for writing) all kind of "useless" formats (and I am very happy about it)
[20:12:27 CEST] <cehoyos> But the Matrox is certainly not a system driver
[20:12:34 CEST] <cehoyos> Neither the decklink driver
[20:15:59 CEST] <BradleyS> my understanding is kernel modules distributed in binary form do not need to be gpl compatible as long as they use the kernel through a well-defined interface and are not part of the kernel (compiled in)
[20:16:14 CEST] <cehoyos> Your understanding of the opinion of the FFmpeg developers?
[20:16:45 CEST] <BradleyS> my understanding of the current norm in linux device driver development as encouraged by linus and so far unchallenged in court
[20:17:38 CEST] <BradleyS> i'm not saying i agree with it ethically, just saying many binary device drivers are distributed this way and most people except the hardliners are fine with it
[20:18:23 CEST] <BradleyS> to say that some drivers are different than others based on their application, as opposed to how they are loaded by / access the kernel, seems unsubstantiated by the license
[20:18:26 CEST] <cehoyos> Can you point me to the repository of the decklink driver?
[20:18:51 CEST] <cehoyos> You mean unsubstantiated by the word "system drivers"? I tend to disagree.
[20:19:51 CEST] <cehoyos> Or to say it differently: You claim that the Decklink developers have found a way to circumvent the incompatibility of their driver with the gpl and we should honor this achievement?
[20:20:42 CEST] <BradleyS> i don't think anyone is suggesting honoring their work in this regard
[20:21:18 CEST] <BradleyS> i for one am merely suggesting that if they're distributing a driver as a binary kernel module, by most current definitions that does not demand gpl compliance
[20:21:29 CEST] <BradleyS> of course there is great debate on this still
[20:21:33 CEST] <cehoyos> Nobody claimed that (afaict)
[20:21:56 CEST] <BradleyS> [14:07:36] @j-b:	Nope, they have a driver and the library to talk to the driver is fully free now.
[20:22:18 CEST] <BradleyS> this would seem to be a binary kernel module and an open source library to talk to it
[20:22:27 CEST] <j-b> yes, that is my understanding
[20:22:30 CEST] <j-b> and that is NEW.
[20:22:35 CEST] <cehoyos> Can you point me to the repository of the decklink driver?
[20:23:29 CEST] <j-b> BradleyS: it is installed through DKMS, like all the other drivers.
[20:23:49 CEST] <j-b> and loaded with modprobe
[20:24:00 CEST] <BradleyS> thanks for clarifying, then it would indeed seem to at least align with the majority case in the wild
[22:12:52 CEST] <cone-177> ffmpeg 03Lou Logan 07master:419e5e794285: doc/ffmpeg: -timelimit is in user time
[22:29:37 CEST] <Lynne> durandal_1707: "There is not such function." -> vector_fmac_scalar(dst, src, 1.0, len)
[22:31:39 CEST] <durandal_1707> Lynne: that is inefficient
[22:32:23 CEST] <Lynne> it isn't, but feel free to just ignore me like everyone else
[22:33:41 CEST] <durandal_1707> Lynne: lol, i will bench it, but it can be used almost anywhere
[22:34:06 CEST] <durandal_1707> and adding LOCAL ALIGNED macros hurts my brain cells
[23:09:15 CEST] <durandal_1707> Lynne: most of time is lost in compute_gru
[23:30:17 CEST] <cehoyos> durandal_1707: What is wrong with ticket 6939?
[23:32:14 CEST] <durandal_1707> cehoyos: --patch is unrecognized
[23:32:19 CEST] <durandal_1707> *path
[23:33:22 CEST] <cehoyos> true, should be fixed
[23:47:53 CEST] <durandal_1707> cehoyos: what should be fixed?
[00:00:00 CEST] --- Sat Sep 28 2019