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

Wed Feb 27 03:05:04 EET 2019

[00:31:11 CET] <cone-815> ffmpeg 03Mark Thompson 07master:9d5ca71ec2ef: vaapi_encode: Do not zero access unit structures
[00:41:37 CET] <JEEB> hmm, is this valid? http://up-cat.net/p/0fd0b778
[00:42:08 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f4d7bd6cdbcf: vaapi_encode: Support more RC modes
[00:42:09 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f5eb08937e31: vaapi_encode_h264: Enable support for more RC modes
[00:42:10 CET] <cone-815> ffmpeg 03Mark Thompson 07master:d237b6b549f8: vaapi_encode_h265: Enable support for more RC modes
[00:42:11 CET] <cone-815> ffmpeg 03Mark Thompson 07master:1e0fac76639e: vaapi_encode_mpeg2: Enable support for more RC modes
[00:42:12 CET] <cone-815> ffmpeg 03Mark Thompson 07master:2efd63a3158d: vaapi_encode_vp8: Enable support for more RC modes
[00:42:13 CET] <cone-815> ffmpeg 03Mark Thompson 07master:28e619e268cc: vaapi_encode_vp9: Enable support for more RC modes
[00:42:14 CET] <cone-815> ffmpeg 03Mark Thompson 07master:c4c2c4df76e1: vaapi_encode_vp9: Fix whitespace after previous patch
[00:42:15 CET] <cone-815> ffmpeg 03Mark Thompson 07master:fda6dcd0b0a3: vaapi_encode_mjpeg: Use common quality option
[00:42:16 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f948082e5fc2: vaapi_encode_mpeg2: Add missing marker bit in time_code
[00:57:33 CET] <BtbN> JEEB, yes
[00:59:23 CET] <BtbN> JEEB, VAEncMiscParameterBuffer has a "uint32_t data[];" in it.
[00:59:49 CET] <BtbN> So you are very limited in what you can do with that struct without relying on GNU extensions.
[01:00:36 CET] <nevcairiel> its a linux library, so they probably j ust care that it works on clang and gcc and thats that =p
[01:02:49 CET] <jkqxz> That structure definition is just a disaster more generally.
[01:03:26 CET] <jkqxz> Given the content, it is 4 byte and 4-byte aligned.  But, they then define things which can go in the data which need 8-byte alignment.
[01:04:25 CET] <jkqxz> So you end up having have to make a new structure with an extra 4 bytes of padding before that structure in order to actually use it.
[01:05:13 CET] <jkqxz> And then you have to copy the whole thing to an unaligned version after writing the fields.
[01:26:26 CET] <uau> nevcairiel: the definition of VAEncMiscParameterBuffer is in no way gcc- or clang-specific though
[01:26:34 CET] <uau> it's perfectly standard C
[01:27:38 CET] <uau> only the part using it in the middle of another struct in libavcodec is non-standard
[01:34:14 CET] <uau> jkqxz: if the data can contain some thing (struct?) which requires 8-byte alignment, wouldn't it be easier to just normally declare that struct, and then memcpy it into a VAEncMiscParameterBuffer data part? (instead of any "extra padding" stuff)
[13:41:07 CET] <BradleyS> ping durandal_1707
[13:46:47 CET] <durandal_1707> BradleyS: ?
[13:50:08 CET] <BradleyS> what is the new feature you speak of regarding that handbrake issue?
[13:50:17 CET] <BradleyS> i'm not sure which commits apply
[13:54:49 CET] <durandal_1707> that file needs dhav demuxer
[13:54:58 CET] <durandal_1707> because it have audio
[14:05:54 CET] <BradleyS> ah, thanks
[15:02:46 CET] <j-b> pfff, nvcc is a mess
[15:05:07 CET] <BtbN> I'll probably just go ahead and merge the series after some testing (And releasing the needed new sdk)
[15:05:14 CET] <BtbN> But putting nvcc back into nonfree
[15:05:54 CET] <BtbN> What it primarily does is getting rid of a dependency on the CUDA SDK, which is good nevertheless
[15:11:25 CET] <BtbN> https://github.com/FFmpeg/nv-codec-headers/pull/5/files just, why?
[15:13:51 CET] <j-b> BtbN: I agree with you: you should merge the series.
[15:14:00 CET] <j-b> Unfortunately, that does not make it non-free, IMHO
[15:14:05 CET] <BtbN> Yes
[15:14:34 CET] <BtbN> As long as the only way to build the filter Kernels remains to register with Nvidia, and accepting a full of 3 EULAs to get the SDK... nope
[15:15:07 CET] <BtbN> Even if you use clang to build them (which is possible), that still needs libraries and other stuff from that SDK to succeed.
[15:15:41 CET] <BtbN> I assume you mean non-non-free. Or, well, free.
[15:16:16 CET] <funman> non-non-free as in non alcoholic free beer?
[15:18:09 CET] <BtbN> It's a bit unfortunate that the option is called non-free. So to indicate it's about it.
[15:18:45 CET] <BtbN> Releasing new SDK versions got more annoying with one additional SDK to maintain.
[15:18:53 CET] <BtbN> Wonder at what point I should drop SDK 8.0
[15:19:40 CET] <j-b> BtbN: ofc. :)
[15:19:58 CET] <j-b> BtbN: I don't understand why nVidia is so blocking open source lately...
[15:20:17 CET] <BtbN> I guess I can already drop it, since the oldest still maintained driver by nvidia (that supports the video codec SDK) is the 390 series, which is SDK 8.1 capable.
[15:20:30 CET] <BtbN> I don't feel like anything has changed in a while?
[15:20:51 CET] <BtbN> hm, well. The Video-Codec-SDK used to be freely available for download.
[15:21:08 CET] <BtbN> But you still has to accept EULAs, just didn't need to register.
[15:21:14 CET] <BtbN> *d
[15:29:25 CET] <j-b> It's less shady than this new Matrox stuff
[15:30:08 CET] <durandal_1707> isn't Matrox dead?
[15:46:57 CET] <durandal_1707> i get small artifacts after imdct and overlapping, (seen as spikes of high frequencies in spectrogram), whats causing this? wrong window numbers?
[15:59:42 CET] <ubitux> extract_extradata bsf is nice
[15:59:50 CET] <ubitux> too bad we don't have the same for width/height :(
[16:00:04 CET] <ubitux> seems like h264_metadata doesn't do it either
[16:00:23 CET] <ubitux> (i need avctx->{width,height} at probing, without a h264 decoder)
[16:00:25 CET] <atomnuker> durandal_1707: yeah, definitely a wrong window
[16:00:55 CET] <atomnuker> or lapping in case it isn't exactly 50% (it should be, the window is kbd after all)
[16:18:22 CET] <philipl> BtbN: https://softwareengineering.stackexchange.com/questions/318503/can-i-release-software-under-the-gpl-if-it-must-be-built-with-a-proprietary-comp
[16:20:05 CET] <BtbN> That answer does not look very on point to the question.
[16:20:08 CET] <philipl> But beyond that, there's also the licencing of the kernel source itself. For an MIT licenced kernel, I think the question of whether the compiler is a General Purpose Tool (and surely it is) can be side-stepped.
[16:20:53 CET] <philipl> The LGPL terms can be complied with if the ptx file is distributed for an MIT licenced kernel instead of the original .cu. The rest of the build can complete correctly without nvcc or the sdk
[16:20:59 CET] <nevcairiel> the licence of the kernel doesnt really matter for the final ffmpeg package, it only has one license that applies to the entire binaries in it
[16:21:06 CET] <BtbN> That might be true if it was only about the kernel, but it's about ffmpeg as a whole.
[16:21:16 CET] <philipl> The kernels are separate programs
[16:22:14 CET] <BtbN> I will apply the series (with ammendmends), but keeping cuda_nvcc as non-free. We can then post a patch that does just make it free, and discuss there.
[16:22:20 CET] <philipl> and while in a GPL build, the MIT licenced parts are implicitly distributed under GPL terms, that would not be true for LGPL because the LGPL licence on LGPL files can be complied with even while MIT files are are distributed under MIT, because you can rebuild.
[16:22:48 CET] <philipl> I read your comments, and I'm fine with that, but I'm now trying to have that discussion.
[16:23:07 CET] <BtbN> Right now things are failing because nvcc on Windows uses cl.exe, which expects Windows-paths, wile ffmpeg gives it a /tmp path.
[16:23:17 CET] <j-b> How does that work, sorry, if nvcc is not usable?
[16:24:13 CET] <philipl> As part of the configure check?
[16:24:27 CET] <BtbN> Does configure have some magic, like cygpath, to convert them? How does it work when it's using cl.exe itself?
[16:25:19 CET] <nevcairiel> careful work has been taken to only use relative paths
[16:25:24 CET] <BtbN> yes, test_nvcc is failing, because "nvcc -ptx -c -o /tmp/ffconf.wqnJSKl5/test.o /tmp/ffconf.wqnJSKl5/test.cu" -> c1xx: fatal error C1083: Cannot open source file: 'C:/tmp/ffconf.wqnJSKl5/test.cu': No such file or directory
[16:26:12 CET] <BtbN> test_cc works the same way as test_nvcc, and it works?
[16:26:39 CET] <nevcairiel> i assume your main compiler is gcc in this, so its not  aware that it needs to be especially careful
[16:26:43 CET] <philipl> j-b: was that comment to me? For an LGPL build, if the kernels are not themselves LGPL, then the ptx is a non-original-source form of a non-LGPL part that can be used to enable the rebuild of the LGPL parts, and that is allowed by the LGPL.
[16:27:31 CET] <BtbN> nevcairiel, yeah, probably true.
[16:30:52 CET] <j-b> philipl: but not GPL
[16:32:08 CET] <philipl> j-b: for sure. but i just want to get to lgpl builds with filters. non-free means non-lgpl, not non-gpl in configure
[16:32:27 CET] <j-b> Sorry, but I don't think that it works that way.
[16:32:51 CET] <philipl> What doesn't work that way?
[16:33:48 CET] <j-b> LGPL has upgradibility to GPL, so if it does not work with GPL, it did not work with LGPL.
[16:34:12 CET] <philipl> for source. not for a distributed binary.
[16:34:27 CET] <BtbN> Is it ok to use realpath in configure, given that that part of code will only ever run on Windows and Linux?
[16:34:31 CET] <philipl> clearly, something distributed under lgpl specific terms cannot be distributed under gpl terms.
[16:34:46 CET] <j-b> Also, .cu are LGPL, so why are you saying that the kernels are not LGPL?
[16:35:11 CET] <BtbN> They are MIT
[16:35:15 CET] <philipl> there are three cu files. two are mit licenced and the third is my code that i already posted a diff to relicence.
[16:35:25 CET] <philipl> and which i will apply in due course.
[16:35:43 CET] <BtbN> (I have no idea what's wrong with the patch, but I just can't get it to apply)
[16:35:51 CET] <j-b> vf_yadif_cuda is not based on yadif?
[16:35:59 CET] <philipl> BtbN: i will apply.
[16:36:42 CET] <philipl> j-b: i didn't read yadif to write the kernel. i used a forum post description of the algorithm.
[16:37:04 CET] <j-b> Sorry, but that is very dubious, in the same project that originated yadif
[16:37:26 CET] <nevcairiel> So if I read a GPL algorithm, and write down an explanation of it on a forum, then someone else reads it, then the license is gone?
[16:37:29 CET] <nevcairiel> sounds useful :D
[16:37:43 CET] <philipl> but that's exactly what clean room is.
[16:37:49 CET] <j-b> sure
[16:37:55 CET] <j-b> but there are conditions to do so
[16:38:21 CET] <j-b> but when you commit to the same project, that is very weird and doubtful
[16:39:15 CET] <j-b> but, beside yadif, the other are MIT, and are compiled to ptx asm with nvcc, right?
[16:39:23 CET] <philipl> j-b:right
[16:39:23 CET] <BtbN> yep
[16:40:06 CET] <j-b> and then the ptx is loaded at runtime, right? Like an ARB shader?
[16:40:10 CET] <philipl> yep
[16:40:45 CET] <j-b> but those i****&ts cannot load directly the .cu ?
[16:40:58 CET] <philipl> nope.
[16:41:14 CET] Action: j-b wonders why...
[16:41:18 CET] <nevcairiel> loading source shaders is out of fashion
[16:41:21 CET] <j-b> they are making it painful on purpose
[16:41:26 CET] <j-b> nevcairiel: because?
[16:41:27 CET] <nevcairiel> look at vulkan shaders =p
[16:41:39 CET] <philipl> yeah...
[16:41:51 CET] <BtbN> The nvidia driver just does not come with a C/C++ compiler
[16:41:52 CET] <j-b> why not commit the ptx to the repo?
[16:41:55 CET] <philipl> This is a lot like java and byte code.
[16:42:00 CET] <BtbN> Though it can load OpenCL kernels, which are also essentially C?!
[16:42:10 CET] <philipl> because who wants to write ptx by hand?
[16:42:27 CET] <BtbN> j-b, that's how it initially worked. People hated it.
[16:42:42 CET] <j-b> Sure, but that's the safe way for the *GPL
[16:42:50 CET] <BtbN> It indeed is.
[16:43:02 CET] <BtbN> Just commit .cu and .ptx.
[16:43:10 CET] <philipl> j-b: because it's not original source, I'm not sure it's safe
[16:43:20 CET] <j-b> BtbN: I would do that.
[16:43:24 CET] <j-b> philipl: why not safe?
[16:43:43 CET] <philipl> if you think that using nvcc is non free, then how is it ok to distribute the ptx and say you must do a non-free thing to regenerate it?
[16:43:45 CET] <nevcairiel> plenty projects have "generated" files of some sort,  not always very obvious how to even generate them
[16:43:45 CET] <BtbN> You would have to trust the commiter that that .ptx indeed came from compiling the .cu next to it
[16:44:09 CET] <BtbN> philipl, because you can reproduct the ffmpeg build without needing to sign a Nvidia EULA
[16:44:12 CET] <BtbN> *e
[16:45:19 CET] <j-b> philipl: png vs xcf
[16:45:32 CET] <BtbN> philipl, btw., I made a new ffnvcodec release-set. Will bump the version requirement in configure accordingly.
[16:46:52 CET] <philipl> BtbN: I don't see how that would fly in the sense that the downstream consumer must be able to rebuild from original source, and if you say requiring them to use nvcc breaks lgpl, then it's still broken for an lgpl kernel.
[16:47:08 CET] <philipl> or are you implicitly discussing mit kernels?
[16:47:48 CET] <BtbN> From how I understand (L)GPL, it's more about a user being able to build stuff themselves. Which they can when the .ptx is provided.
[16:48:00 CET] <philipl> yes. i did say that originally.
[16:48:08 CET] <philipl> for an mit kernel.
[16:48:38 CET] <philipl> for an lgpl kernel, you must provide original source, which we would, and they must be able to modify and rebuild and replace it.
[16:49:32 CET] <philipl> which they can, if they use nvcc. but you say we cannot require nvcc and be lgpl compliant.
[16:50:59 CET] <BtbN> yeah, an LGPL kernel might be a problem. But I'm too confused about this license mess anyway.
[16:52:13 CET] <philipl> aren't we all. I remain unconvinced by the argument that a proprietary compiler violates gpl. As noted in that link, the first gpl code could only be compiled with proprietary compilers.
[16:52:36 CET] <j-b> they might modify the ptx manually
[16:52:41 CET] <philipl> the licence is clearly intended to allow for gpl code to be usable on such platforms.
[16:53:19 CET] <philipl> j-b: they can, and that would be fine, but you can't require it vs .cu modification.
[17:08:17 CET] <philipl> OK, so we're all exhausted by that discussion. That seems to be what usually happens. :-)
[17:08:58 CET] <BtbN> I think I fixed nvcc in a portable fashion. Assuming GNU coreutils are available on all platforms where nvcc is.
[17:09:27 CET] <philipl> That seems fine by me.
[17:09:40 CET] <philipl> It works on windows, linux, mac, and the mac case is super obscure.
[17:10:22 CET] <philipl> I'm very happy with saying that checking in ptx files alongside cu files satisfies our lgpl compatibility if that's the concensus opinion. I'm also very happy with a solution where I don't have to try justifying relicencing the yadif kernel.
[17:10:23 CET] <BtbN> configure does not support enabling it on OSX anyway
[17:10:27 CET] <philipl> BtbN: even better.
[17:13:07 CET] <BtbN> I also altered configure a little, so it still support --enable-cuda-sdk but throws a warning at you if you use it.
[17:13:50 CET] <philipl> BtbN: thanks.
[17:14:43 CET] <j-b> philipl: still, I would commit both, sorry.
[17:14:53 CET] <BtbN> Now to making a very long pkg-config check
[17:16:52 CET] <j-b> move to meson
[17:17:48 CET] <philipl> j-b: I don't have a problem with committing both. You don't need to apologise. :-) If that allows us to lift non-free, it's a very small price to pay.
[17:18:34 CET] <BtbN> Dropping support for SDK 8.0. Won't make new releases for it either. 8.1 supports driver 390, which is the oldest still supported nvidia driver with video-codec-sdk support.
[17:18:52 CET] <j-b> philipl: it's complex topics.
[17:18:53 CET] <philipl> BtbN: sounds reasonable.
[17:19:02 CET] <j-b> philipl: however, I will ask nvidia to open source nvcc
[17:19:07 CET] <j-b> at my next call with them.
[17:19:20 CET] <j-b> (while there is life, there is hope)
[17:19:21 CET] <BtbN> It's not so much about nvcc, but about the libs it uses.
[17:19:27 CET] <BtbN> nvcc itself can already be replaced with clang.
[17:19:30 CET] <philipl> j-b: if you can have any influence there, it would be great.
[17:26:53 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master intend to push that later today
[17:29:11 CET] <nevcairiel> is there a reason to drop 8.0 beyond saving a line in configure? if not, it would be nice to keep driver support as broad as possible for some distributions
[17:29:53 CET] <nevcairiel> also i don't think the relative-path hack works if tmp is on a different drive
[17:30:34 CET] <BtbN> hmmm
[17:30:37 CET] <BtbN> true
[17:30:49 CET] <BtbN> So I guess checking if cygpath exists and using it it is?
[17:31:02 CET] <nevcairiel> i believe we use that for some other mingw path shenanigans
[17:31:12 CET] <BtbN> I can't fing cygpath anywhere in configure
[17:31:18 CET] <BtbN> *d
[17:31:56 CET] <BtbN> SDK 8.0 is seriously old now.
[17:31:59 CET] <nevcairiel> or just do what we do for msvc anyway, set the tmpdir to . for windows
[17:32:22 CET] <BtbN> It works fine in a full msvc build
[17:32:26 CET] <BtbN> but it fails in cygwin and msys
[17:32:36 CET] <nevcairiel> yes because tmpdir is absolute
[17:33:56 CET] <BtbN> There is no supported driver that doesn't at least support SDK 8.1 anymore
[17:34:02 CET] <j-b> philipl: I might
[17:57:19 CET] <philipl> BtbN: tree looks fine, although no comment on realpath vs cygpath.
[18:08:49 CET] <BtbN> nevcairiel, https://github.com/BtbN/FFmpeg/commit/0281c22088604465737674fccca4eb10e8bced18
[18:09:03 CET] <BtbN> ignore the second hunk, that needs to be rebased into a different patch
[18:11:43 CET] <nevcairiel> Does that actually work of there by is a drive change involved?
[18:12:29 CET] Action: j-b hints meson
[18:12:50 CET] <BtbN> nevcairiel, why wouldn't it?
[18:13:17 CET] <BtbN> Could throw in a -a to be absolutely safe
[18:13:57 CET] <nevcairiel> Because mingw path translation is peculiar and absolute path with a drive letter look like a parameter it wants to translate
[18:14:16 CET] <nevcairiel> Ie. Try? :)
[18:14:25 CET] <BtbN> Well, it's only ever passed to nvcc
[18:14:34 CET] <BtbN> And it seems to understand C:/...
[18:15:30 CET] <BtbN> cygpath -m /tmp gives me C:/Cygwin/tmp which seems sane and works
[20:26:34 CET] <atomnuker> in case someone hasn't seen it: https://bitbucket.org/multicoreware/x265/commits/878541319ea1375be0e981f6ea5fefdb4d509fbd
[20:27:31 CET] <atomnuker> were they too bothered to write their own encoder or something?
[20:29:48 CET] <JEEB> most likely they just got paid to makei t possible to use x265 interfaces to encode with SVT-HEVC
[20:30:53 CET] <j-b> Yes
[20:31:04 CET] <j-b> it's not touching the encoder, but just the x265 executable
[20:32:51 CET] <atomnuker> still its like x264.c running libopenh264
[20:35:30 CET] <j-b> true.
[20:57:35 CET] <cone-927> ffmpeg 03Justin Ruggles 07master:69fcc093c124: http: Do not try to make a new request when seeking past the end of the file
[20:57:35 CET] <cone-927> ffmpeg 03Justin Ruggles 07master:97f47fd601d0: mov: Fix start_time for streams with empty edits in the middle
[21:00:25 CET] <kurosu_> Justin Ruggles? Now that's a name I haven't in a long time
[22:55:39 CET] <nevcairiel> He works for some big media company now, occasionally still sends patches
[00:00:00 CET] --- Wed Feb 27 2019