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

[burek]

[03:10:36 CET] <mistym> Anyone have advice on prebuffering the audio/video samples in a muxer? I've got a format where I need to know the number of packets in advance in order to be able to write a correctly-sized sample table in the header, but not sure how I could handle that.
[03:12:29 CET] <c3r1c3-Win> mistym: Try a circular buffer. You'll have to Google for the definition and code examples but basically you grab the data from ffmpeg, check if it's big enough to fill the buffer. If so forward the buffer to the process. If not, cycle around again.
[03:14:12 CET] <mistym> c3r1c3-Win: Thanks! Do you know if there are any formats which already do this?
[03:14:37 CET] <c3r1c3-Win> Sorry, I know of none.
[03:14:56 CET] <mistym> OK, thanks anyway
[03:48:39 CET] <jamrial> mistym: ff_interleave_add_packet
[03:49:47 CET] <mistym> jamrial: Thanks! Is there a limit to how many packets I can buffer that way?
[03:50:21 CET] <jamrial> not counting oom, i think not
[03:51:49 CET] <mistym> It's a good thing the format I'm muxing usually maxes out at 320x224, lol
[04:37:28 CET] <jamrial> tmm1: one of your recent patches introduced a memory leak http://fate.ffmpeg.org/report.cgi?time=20171224025547&slot=x86_64-archlinux-gcc-valgrind
[04:43:53 CET] <tmm1> huh i didnt allocate any memory
[04:44:41 CET] <tmm1> oh its an earlier patch
[05:30:52 CET] <TimothyGu> BtbN: where did you get the nvidia headers in https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary?
[05:31:20 CET] <TimothyGu> I downloaded the SDK but the dynlink_cuda.h in the SDK is different from the one you have
[05:32:22 CET] <TimothyGu> from https://developer.nvidia.com/nvidia-video-codec-sdk that is
[05:32:48 CET] <wm4> yes, our headers are modified to include dynamic loading
[05:33:19 CET] <TimothyGu> yeah but like the licenses are different too
[05:33:38 CET] <Compn> iirc we got permission to relicense, but dont quote me on that
[05:33:47 CET] <Compn> when we got the permission to include it in ffmpeg source originally
[05:33:53 CET] <Compn> going to have to go back and read ml
[05:34:03 CET] <TimothyGu> oh heh. would be nice to have that linked in the README
[05:34:12 CET] <Compn> good idea
[05:35:05 CET] <TimothyGu> I have https://github.com/TimothyGu/nvidia-video-codec-sdk which provides a nice-ish way of looking at API differences across SDK versions
[05:35:16 CET] <TimothyGu> but the headers come straight from the SDK
[05:39:11 CET] <Compn> nevcairiel or BtbN should know the license history
[05:39:15 CET] Action: Compn looking at old irc logs
[05:43:05 CET] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=325e56479ff64c884f3bcccf922a7f7163488b89
[05:43:12 CET] <Compn> looks like nvidia changed its headers
[05:43:18 CET] <Compn> er header license a few times ?
[05:43:32 CET] <Compn> TimothyGu  : do the header license change in your repo across different sdk versions?
[05:45:44 CET] <TimothyGu> Compn: no
[05:45:57 CET] <Compn> when did you download the sdk versions ?
[05:46:01 CET] <Compn> over time or all at once ?
[05:46:34 CET] <TimothyGu> Compn: over time but not that long (over 1 year)
[05:47:02 CET] <TimothyGu> actually the commit you linked doesn't say the license changed
[05:47:21 CET] <TimothyGu> it says the relevant parts are still MIT, but just less accessible
[05:47:49 CET] <Compn> https://github.com/TimothyGu/nvidia-video-codec-sdk/blob/v8.0/nvEncodeAPI.h
[05:48:11 CET] <TimothyGu> what about it? it's still MIT
[05:48:12 CET] <Compn> i was looking at irc logs when i saw BtbN say the license changed
[05:48:42 CET] <Compn> so uh, what was the question? sorry its late here and im distracted
[05:48:49 CET] <Compn> relicensing from mit > lgpl ?
[05:49:22 CET] <TimothyGu> No I was wondering where the license in dynlink_cuda.h came from
[05:49:54 CET] <Compn> oh
[05:49:54 CET] <TimothyGu> The SDK has multiple files, some of which are MIT (the ones are published). Others are EULA'd.
[05:50:17 CET] <TimothyGu> dynlink_cuda.h is one of the EULA files in the SDK, yet FFmpeg distributes it with a MIT license header
[05:50:49 CET] <Compn> sorry i was looking at wrong file
[05:53:44 CET] <Compn> is it possible its the same filename but different stuff inside ?
[05:54:40 CET] <TimothyGu> it has mostly the same stuff but there are differences, yes
[05:57:01 CET] <Compn> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199861.html
[05:58:21 CET] <Compn> oh this maybe
[05:58:21 CET] <Compn> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199859.html
[05:58:37 CET] <Compn> philipl maybe knows cuda ? :)
[05:59:06 CET] Action: Compn retreats to cave under his rocks
[06:21:02 CET] <mistym> What's the preferred threading settings for send-email to the ffmpeg-devel list?
[06:25:33 CET] <wm4> mistym: which settings are there?
[06:25:54 CET] <wm4> I'm just using defaults, and it seems so do others
[06:26:07 CET] <mistym> Oh, perfect. I worried my threading was too chaotic and was being annoying
[06:26:13 CET] <mistym> wm4: Main ones I'm thinking of are --chain-reply-to and --thread
[06:26:14 CET] <wm4> sometimes with --cover-letter or --in-replty-to
[06:26:22 CET] <mistym> Yeah, I've been using those two
[06:26:30 CET] <mistym> The reply I sent to you was fine then?
[06:27:37 CET] <wm4> I don't think we use --chain-reply-to, the one you've just sent is the first time I saw that at all
[06:28:25 CET] <wm4> yeah seems --thread --no-chain-reply-to is the default and what we normally use
[06:28:40 CET] <mistym> OK, perfect - I'll make sure I'm using that then. Thanks!
[07:26:10 CET] <mistym> Is 512KB an okay size for a new FATE test file? And are clips from copyrighted material okay? I was asked to contribute tests for a patchset
[07:33:03 CET] <mistym> Oh, looks like there are definitely bigger samples, and clips from copyrighted material, so I should be fine
[08:32:20 CET] <JEEB> mistym: yup
[08:32:28 CET] <mistym> JEEB: Great, thanks!
[08:32:56 CET] <JEEB> the clip should of vourse be as small as possible but no need to get too crazy
[08:33:03 CET] <mistym> My patchset adds support for an audio format to MPEG files, I'm figuring an ffprobe test that makes sure the audio track is recognized should be fine
[08:33:21 CET] <mistym> Yeah, I got a ~512KB clip (from an originally-7MB file) that will be fine
[08:47:08 CET] <JEEB> mistym: reminds me I dhould do something similar :)
[08:47:34 CET] <JEEB> althougg I'll have to check if I have any of my samples around
[09:29:57 CET] <mistym> Yay, my tests passed!
[10:13:41 CET] <nevcairiel> TimothyGu: the cuda header is basically reverse engineered from documentation, and not taken from their sources due to license reasons
[10:18:36 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:175122fcd5e6: avfilter/vf_convolve: fix convolution of borders
[10:19:55 CET] <nevcairiel> it only provides a very minimal subset of functionality which we specifically needed
[12:11:32 CET] <BtbN> TimothyGu, I wrote them.
[12:11:50 CET] <BtbN> the dynloading stuff and the dynload_cuda
[12:12:08 CET] <BtbN> The 3 main headers are from the SDK, but modified to be useable
[12:14:21 CET] <BtbN> The dynload_cuda header is not from the SDK. I wrote it to have a minimal set of CUDA functions, just enough to init cuvid/nvenc.
[12:14:46 CET] <BtbN> And then nvidia themselves kept sending patches to add more functions to it they needed for filters and such.
[12:15:16 CET] <BtbN> dynload_cuda in the SDK is pretty much the entirety of CUDA
[14:49:46 CET] <atomnuker> jdarnley: what happened to your flac asm?
[17:40:09 CET] <jdarnley> atomnuker: It is still in the list.  I think I took care of most of the changes requested so I will send another patch set sometime soon.
[17:40:36 CET] <jdarnley> I was also going to push the avx512 set as an early christmas gift to everyone.
[17:40:42 CET] <atomnuker> do it
[17:48:26 CET] <durandal_17> should we ban nicolas as gift too?
[18:19:07 CET] <kierank> jdarnley: yeah do dit
[18:25:51 CET] <cone-253> ffmpeg 03Paul B Mahol 07master:5533cbfc84ea: avfilter/vf_convolve: fix various issues
[18:26:25 CET] <durandal_17> now i just need to speed it up
[18:26:54 CET] <durandal_17> and also write deconvolve vf
[18:31:07 CET] <atomnuker> can't you deconvolve a convolved video by convolving it with the original convolution input^-1?
[18:35:35 CET] <durandal_1707> atomnuker: nope
[18:36:41 CET] <durandal_1707> actually yes, but with what you can inverse input?
[18:47:38 CET] <atomnuker> a filter?
[18:53:45 CET] <durandal_1707> atomnuker: what it would do? float pixel fornat support is not present in sws
[18:58:12 CET] <atomnuker> yeah, you have a point, it would have to calculate the inverse of a matrix and that's slow
[19:18:30 CET] <thebombzen> atomnuker: if the original matrix is invertible, which in the case of convolution filters is usually not the case
[19:18:43 CET] <thebombzen> seeing as it nearly always has two identical rows or two identical columns
[19:19:44 CET] <thebombzen> if you convolve a filter with a video, and then convolve that with the matrix inverse of the original video, you'll just get the filter matrix back
[19:20:20 CET] <thebombzen> but if you convolve a filter with a video and convolve that with the filter's inverse, you should get the original video back. but it's unlikely that the filter will be an invertible matrix
[19:22:24 CET] <durandal_1707> thebombzen: did you studied math?
[19:22:36 CET] <thebombzen> yes
[19:22:45 CET] <durandal_1707> wow
[19:23:25 CET] <kierank> durandal_1707: did you studied trolling?
[19:24:12 CET] <durandal_1707> kierank: why that, did i made mistake?
[19:24:29 CET] <kierank> is your "wow" sarcasm
[19:25:02 CET] <atomnuker> pretty sure that wasn't sarcasm
[19:25:23 CET] <durandal_1707> kierank: no, sorry, im only sarcastic about mplayer matter and its devs
[19:25:36 CET] <kierank> ok
[19:28:00 CET] <tmm1> how can i run a single valgrind test locally?
[19:28:28 CET] <atomnuker> compile with valgrind enabled and just run fate
[19:28:45 CET] <atomnuker> the test will fail if valgrind finds something
[19:30:00 CET] <durandal_1707> kierank: have you found solution for the problem you asked yesterday?
[19:30:12 CET] <kierank> durandal_1707: I think yes but then i went drinking until 3am
[19:30:24 CET] <durandal_1707> :)
[19:42:59 CET] <tmm1> grr valgrind is useless on macOS 10.13
[21:00:31 CET] <cone-253> ffmpeg 03Aman Gupta 07master:3d95868d1bf2: avformat/hls: fix CID 1426930
[21:00:32 CET] <cone-253> ffmpeg 03Aman Gupta 07master:b33cf735071c: avformat/hls: fix memory leak with non-http segments
[21:33:04 CET] <cone-253> ffmpeg 03Aman Gupta 07master:207e98b4e502: avformat/hls: fix SEGV in previous commit
[22:14:38 CET] <cone-253> ffmpeg 03James Darnley 07master:b7a3d1f249c9: configure: test whether x86 assembler supports AVX-512
[22:14:39 CET] <cone-253> ffmpeg 03James Darnley 07master:8b81eabe5789: avutil: add AVX-512 flags
[22:14:40 CET] <cone-253> ffmpeg 03James Darnley 07master:4783a01c113b: avutil: detect when AVX-512 is available
[22:14:41 CET] <cone-253> ffmpeg 03James Darnley 07master:e2218ed8ce6e: avutil: add alignment needed for AVX-512
[22:14:42 CET] <cone-253> ffmpeg 03James Darnley 07master:8f86e6623811: avcodec: add stride alignment needed for AVX-512
[22:14:43 CET] <cone-253> ffmpeg 03Henrik Gramner 07master:f7197f68dc61: x86inc: AVX-512 support
[22:14:44 CET] <cone-253> ffmpeg 03James Darnley 07master:40d4b13228bf: checkasm: support for AVX-512 functions
[22:16:08 CET] <atomnuker> fuck yes avx512
[22:16:24 CET] <atomnuker> do you get those nice opmasks for free or do they cost extra cycles?
[22:17:15 CET] <jdarnley> Do you mean is "vpaddw m1 {k1}, m2, m3" slower than "vpaddw m1, m2, m3"?
[22:17:20 CET] <atomnuker> yes
[22:18:26 CET] <jdarnley> The Intel docs say it is the same
[22:19:51 CET] <atomnuker> jesus christ
[22:20:17 CET] <jdarnley> There could be some instructions where it isn't but I haven't seen or heard of any.
[22:21:29 CET] <jamrial> the intructions required to fill those opmask regs with something however probably cost a few cycles
[22:23:16 CET] <atomnuker> if you're doing some rdo search on a bunch of coeffs (like the libvpx trellis thing) that cost would be next to nothing
[22:24:03 CET] <atomnuker> the daala loopfilter (with the 3rd weights) does something that opmasks would exactly fit
[22:24:27 CET] <atomnuker> could even use them to write a faster pvq search
[22:46:55 CET] <jdarnley> jamrial: yes
[22:47:19 CET] <jdarnley> if you want to load a constant not in memory then it is two moves.
[22:49:05 CET] <jdarnley> otherwise I think you would usually create them with the compare instructions
[23:38:27 CET] <TimothyGu> BtbN: oh thanks haha
[00:00:00 CET] --- Mon Dec 25 2017