[00:02:48 CET] <philipl> BtbN: so is the submodule idea still on the table? [00:03:36 CET] <philipl> I worry that it's not enough to just have the headers as a bunch of files. Getting a linux distro to package up and include anything is hard enough as it is, and raw headers are not packaging friendly [00:03:49 CET] <philipl> Makefile, pkg-config, versioning, etc, etc. [00:04:37 CET] <wm4> please no submodules [00:12:42 CET] <jamrial> why was this done specifically for nvidia headers anyway? i thought the idea was to move eveything there, including avisynth [00:12:56 CET] <jamrial> so calling the repo codec-headers instead of nv-codec-headers, or whatever [00:16:04 CET] <wm4> isn't that still an open question [00:16:17 CET] <wm4> I'm thinking maybe having specific repos is better [00:16:45 CET] <wm4> to avoid having a repo as literal dumping ground, which would just encourage bad practices such as requiring specific non-standard headers [00:17:01 CET] <wm4> these should be exceptions, not the rule, and having a catch all repo would make it the rule [00:18:19 CET] <jkqxz> There isn't anything else to put in it at all anyway, is there? [00:18:50 CET] <wm4> just nv stuff, and avisynth [00:19:11 CET] <wm4> the AMD headers are obviously already external [00:19:31 CET] <wm4> so yeah I'd argue we should strictly use separate repos for nv and avisynth [00:19:43 CET] <jamrial> but they are not working as is, unless they fixed them during the last few days [00:20:21 CET] <jkqxz> The AMD ones? It got fixed a few days ago. [00:20:33 CET] <jkqxz> At least, I can build an unoptimised build now. Don't know if there are still more problems. [00:20:36 CET] <jkqxz> (Entirely possible.) [00:20:46 CET] <jamrial> ah yes, i see the commit that fixed it now [00:21:37 CET] <wm4> what we definitely should avoid is that we suddenly have to maintain the AMD headers [00:21:49 CET] <wm4> AMD should do that, it's their stuff [00:22:08 CET] <wm4> just like the maintain the drivers backing the headers [00:22:59 CET] <wm4> (and I'd hope nvidia come to their senses and either contribute to the nv header repo, or synchronize their own to it) [00:24:33 CET] <jkqxz> wm4: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221525.html>. I doubt anyone else will comment on this, shall I just apply it? [00:25:43 CET] <wm4> at least that looks like it should be correct [00:28:37 CET] <jkqxz> Translation: "yes"? [00:29:44 CET] <wm4> yes [00:32:19 CET] <cone-856> ffmpeg 03Mark Thompson 07master:9f7cc87baf2c: rkmpp: Add hardware config information [00:32:20 CET] <cone-856> ffmpeg 03Mark Thompson 07master:c490fc9536dc: vaapi_h264: Add named options for setting profile and level [00:32:21 CET] <cone-856> ffmpeg 03Mark Thompson 07master:71421f382f5c: vaapi_h265: Add named options for setting profile and level [00:39:15 CET] <atomnuker> daddesio: lets start off somewhat simple, the celt encoder lacks postfilter support [00:39:23 CET] <atomnuker> *prefilter [00:40:43 CET] <daddesio> Hmm, is the prefilter specified explicitly in the CELT bitstream? (In LPC, usually the prefilter/postfilter is implicitly calculated based on the LPC filter itself.) [00:47:20 CET] <atomnuker> daddesio: yep, the octave, period, gain and tapset [00:47:34 CET] <atomnuker> the encoder supports encoding those just fine [00:47:51 CET] <atomnuker> and it'll also apply the prefilter just fine [00:47:59 CET] <atomnuker> but the code to do the search isn't there [00:51:19 CET] <daddesio> So if I understand correctly, the CELT prefilter/postfilter isn't (just?) for perceptual weighting (emphasizing/de-emphasizing certain frequencies) but also for emphasizing pure tones, since CELT deals with extremely small MDCT windows and suffers from horrible frequency resolution / energy leakage [00:51:34 CET] <daddesio> hence the name "pitch prefilter" [00:52:22 CET] <atomnuker> yep [00:52:49 CET] <TD-Linux> there is also a preemphasis filter [00:53:01 CET] <daddesio> Oooooh, I was confusing it with that [01:05:56 CET] <atomnuker> jamrial: not seeing any uninit var errors when running valgrind here [01:06:34 CET] <atomnuker> do you know where it happens? [01:09:28 CET] <jamrial> atomnuker: no, just that opus-testvector05 and opus-testvector06 are failing [01:16:29 CET] <atomnuker> does it still happen with the latest git master and the latest fate dir? [01:43:35 CET] <jamrial> atomnuker: yes, just reproduced it on ArchLinux x86_64, configuring with --valgrind=valgrind --disable-optimizations --disable-stripping [01:48:18 CET] <jamrial> atomnuker: also, it might have been ce87e630fa instead [01:49:56 CET] <jamrial> i'll do a bisect [01:58:25 CET] <jamrial> atomnuker: it's fe05f93013 [02:01:06 CET] <atomnuker> which variable is uninitialized? [02:03:36 CET] <jamrial> it complains about sqrtf in celt_stereo_merge [02:04:25 CET] <jamrial> you can't reproduce with the above configure options? [02:54:23 CET] <atomnuker> no [02:54:54 CET] <atomnuker> gcc 7.2 with valgrind 3.13 with args --error-exitcode=1 --malloc-fill=0xa2 --track-origins=yes --leak-check=full [02:55:14 CET] <atomnuker> +that string you pasted in the config file [02:55:23 CET] <atomnuker> *configure script arguments [02:56:43 CET] <jamrial> make sure to run the fate tests lettin makefile add the valgrind args set by configure [02:57:16 CET] <jamrial> but in any case, that's weird. i'm using the same versions [03:02:29 CET] <atomnuker> actually running fate I can replicate [03:04:28 CET] <jamrial> that's why i said the two tests that were failing :p [04:19:39 CET] <atomnuker> erm actually IIR, not FIR, libavcodec/iirfilter.h [04:19:49 CET] <atomnuker> (which is what's used during decoding) [04:28:54 CET] <daddesio> going to update the LPC filter in SILK, too [04:39:45 CET] <daddesio> The LPC filter can be replaced with ff_celp_lp_synthesis_filterf. (or is that API too old and we should use the IIR API instead?) [04:40:36 CET] <daddesio> I see a number of codecs that use ff_celp_lp_synthesis_filterf. [04:41:26 CET] <atomnuker> aren't lpc and iir filters different? [04:42:09 CET] <atomnuker> use whatever you think is more convenient, the iir filter is only used for aac encoder psychoacoustic stuff [04:42:17 CET] <daddesio> An LPC filter is a type of IIR filter, whose b coefficients are: [1]. [04:42:53 CET] <atomnuker> use the celp stuff [04:44:58 CET] <atomnuker> can the lpc filter also be used as a low pass filter? [04:45:27 CET] <atomnuker> the iir filter is really big and used by one thing only, would be nice to get rid of it [04:46:02 CET] <daddesio> I think you can design an all-pole low-pass filter, yeah. [04:46:32 CET] <daddesio> An FIR filter is probably better though (since it's guaranteed to be a stable filter) [04:46:59 CET] <daddesio> and FIR is linear phase etc. [04:47:37 CET] <atomnuker> I really doubt it needs to be perfect, its only used to low pass aac encoder input [04:47:41 CET] <daddesio> and most importantly it can be vectorized (since there's no dependency on the previous output sample) [04:47:55 CET] <atomnuker> yep [04:50:36 CET] <daddesio> where is the low-pass filter you're talking about? [04:52:30 CET] <daddesio> are you talking about celt_apply_preemph_filter? [04:52:36 CET] <atomnuker> its called in ff_psy_preprocess() in libavcodec/psymodel.c [04:52:48 CET] <TD-Linux> the dc rejection in libopus is just 2nd order iir. hard to beat that with a fir. [04:52:49 CET] <daddesio> oh, the psy stuff [04:52:55 CET] <atomnuker> no, this is just for aac [04:53:23 CET] <atomnuker> TD-Linux: good thing we have none of that here then, what a waste [04:53:50 CET] <TD-Linux> oh whoops nevermind, somehow read low pass as dc rejection filter :^) [04:54:08 CET] <atomnuker> it takes less energy to yell at the other person to fix their system than for all opus encoders everywhere to dc reject [04:55:19 CET] <TD-Linux> alright now I don't buy that line of reasoning :) [04:55:48 CET] <atomnuker> how is it even possible to get dc directly on the input? [04:56:05 CET] <atomnuker> and still have a functioning conversation [04:56:16 CET] <TD-Linux> emulators and digital synthesizers can easily produce it by accident [04:57:50 CET] <atomnuker> ought to have their outputs filtered then [04:58:44 CET] <TD-Linux> yes they should, especially because removing dc might cause clipping [04:59:43 CET] <TD-Linux> unfortunately it's rare for them to do it right because normally a sound card would just not reproduce the dc anyway, so it goes unnoticed [05:00:56 CET] <atomnuker> what sucks is that if you want to ac couple an output you need either really big caps or really big transformers [05:04:58 CET] <TD-Linux> yeah. most class ab amps in e.g. laptops go for cap coupled outputs [05:05:17 CET] <TD-Linux> you can omit it for class D amps but they don't work for headphones with a common ground [05:06:57 CET] <atomnuker> the xonar u3 I have seems to go another route I think - limit the current by putting 22 ohm or so resistors in series with the output [05:09:33 CET] <TD-Linux> it could also generate a negative voltage rail and dc couple. some cell phone chips now even have an integrated charge pump to generate the negative voltage [05:11:08 CET] <daddesio> atomnuker: So unfortunately, you can't cleanly rewrite any of the "long term" filters which have a long delay T with the iirfilter.c or celpfilters.c stuff, since they're technically a Tth-order filter with T a/b coefficients. [05:11:32 CET] <daddesio> this includes the CELT pitch filter (celt_postfilter_apply) and the SILK LTP filter. [05:13:17 CET] <daddesio> they're technically Tth-order filters that happen to have a lot of zero coefficients in the middle. [05:15:40 CET] <atomnuker> oh well [05:18:03 CET] <daddesio> The de-emphasis filter is a 2nd-order all-pole filter, so you can technically replace it with ff_celp_lp_synthesis_filterf, but that would make the code a bit confusing (since we're not using it for LPC synthesis). [05:18:44 CET] <daddesio> and it would probably be slower (due to all the arguments you have to pass to the function) [05:19:24 CET] <daddesio> guess I'll just replace the SILK LPC filter for now [05:22:33 CET] <daddesio> Oh but the thing is, the SILK LPC filter clamps each y[n] to +/- 1.0f before writing it out. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_silk.c#L722 [05:23:01 CET] <daddesio> I wouldn't change it then, since it's an IIR filter we're talking about. [05:23:45 CET] <daddesio> SILK also has a re-whitening filter which does the same thing (clamps each y to +/- 1.0 before writing it). [05:29:21 CET] <atomnuker> so how did x264 end up with that horrid 444 bug in the first place? [07:31:07 CET] <kierank> atomnuker: spec ambiguity if I understand correctly [10:08:13 CET] <RT|AO> @devs: does ffmpeg work in x86 without SSE? [10:09:22 CET] <durandal_1707> yes, there is always pure c implementation [10:12:17 CET] <nevcairiel> i would really not recommend doing that tho =p [10:15:57 CET] <RT|AO> how can I disable SSE in configure? runtime CPU detection seems not working well with my users' CPU. [10:16:55 CET] <durandal_1707> --disable-asm [10:17:13 CET] <BtbN> without sse? [10:17:24 CET] <BtbN> What the hell do you have there, a real 386? [10:17:39 CET] <nevcairiel> runtime cpu detection should be fine [10:17:51 CET] <RT|AO> a vortex86dx [10:17:53 CET] <BtbN> Well, if the CPU really has no sse, I can see that being an issue [10:18:00 CET] <nevcairiel> so basically its not fully x86 compatible? =p [10:18:37 CET] <RT|AO> a i586-compatible x86 CPU targetting embedded use [10:18:49 CET] <RT|AO> s/a /an /; [10:19:10 CET] <thardin> pc/104 eh [10:19:16 CET] <nevcairiel> the only way to disable it entirely is using --disable-asm, but you also lose mmx then, but thats what you have to pay [10:20:47 CET] <RT|AO> OK I'll try that [10:48:32 CET] <durandal_1707> michaelni: did you answered question regarding yuvj formats yesterday? [10:53:19 CET] <BtbN> jamrial, because it can make sense to use older versions of them, to miss out on features, but keep compatible with older drivers. [10:53:51 CET] <BtbN> And because this way it's more packaging-friendly. philipl, I put a makefile and pkg-config file in there. make install and stuff just works. [10:56:01 CET] <durandal_1707> atomnuker: you dissapointed me very much [10:56:59 CET] <atomnuker> durandal_1707: with what? [10:58:34 CET] <durandal_1707> atomnuker: with audio noise removal filter [11:00:17 CET] <atomnuker> believe it or not, last week I worked on it [11:01:34 CET] <atomnuker> I got some of the code ripped out of rnnoise and functional [11:02:15 CET] <atomnuker> not much, but hey, what can I do, av1's going to be frozen "today" [11:02:40 CET] <nevcairiel> didnt they move that to next year [11:03:20 CET] <atomnuker> that's when it'll be frozen solid, now it'll be frozen as in, bugfixes only so no new features [11:03:54 CET] <atomnuker> but I still need to finish the fucking atomics patches so we can finaly declare the unstable period over [11:04:03 CET] <atomnuker> and remove ffserver and make jamrial happy [11:07:45 CET] <cone-381> ffmpeg 03Jim DeLaHunt 07master:d1266d9fa3e8: doc/developer: revise mailing list section [11:12:58 CET] <ubitux> TimothyGu: thx for going ahead with this [11:14:35 CET] <TimothyGu> ubitux: np [11:20:14 CET] <durandal_1707> atomnuker: so what algo it uses? [11:20:57 CET] <atomnuker> neural networks [11:58:02 CET] <RT|Chatzilla> noob question: can ffmpeg be bult with msvc2013? [11:58:41 CET] <BtbN> I'd recommend to use the latest msvc. [11:58:51 CET] <BtbN> 2015 is also mostly fine. But everything before that is a pain. [11:59:05 CET] <wbs> 2013 isn't too bad either, you don't need c99conv [12:01:27 CET] <RT|Chatzilla> BtbN: because my project uses vc2013 [12:01:45 CET] <wm4> I'm sorry [12:07:10 CET] <nevcairiel> i still have a fate box with 2013, but its currently broken, discussion on ML [13:13:00 CET] <durandal_1707> if i do spectral noise subtraction, how should i name the filter? [13:16:56 CET] <atomnuker> durandal_1707: af_doesntwork [13:17:10 CET] <atomnuker> just wait until I got the time to port rnnoise [13:21:00 CET] <durandal_1707> atomnuker: but it works?! [13:23:11 CET] <atomnuker> durandal_1707: I doubt it works well enough to do much [15:30:12 CET] <michaelni> durandal_1707, sorry was too busy to reply yesterday. to awnser, i dont remember but i think it was that people didnt like the yuvj formats. If that changed and people now like to kee them i certainly wont oppose but i think they are a bit ugly, we also dont have a format for 601/709 and the case is similar to the range [15:57:17 CET] <friki> Hi, since yesterday I'm trying to add some features to libavformat/mxf* . I'm searching for MXF specs documents to understand this fileformat. The most complete document I've found is: https://amwa.tv/downloads/specifications/AS-07_Proposed_Application_Specific... Is it the correct doc? [15:58:29 CET] <JEEB> SMPTE 386M and 377M [15:59:17 CET] <JEEB> 377M is the primary spec I think [15:59:36 CET] <JEEB> then there's additional specs like S429-5 or S429-12 [15:59:41 CET] <JEEB> and S436m [15:59:53 CET] <friki> are them publicaly accessible? [16:00:04 CET] <JEEB> depends, might require googling [16:00:15 CET] <JEEB> granted, check if libmxf already has the feature supported [16:00:29 CET] <JEEB> I kind of wish we could just delegate MXF support to libmxf :) [16:00:38 CET] <JEEB> since they seem to be doing the job nicely enough [16:01:40 CET] <friki> libmxf , i'll take a look! :-) [16:02:27 CET] <JEEB> wow, libmxf still on CVS? [16:02:47 CET] <friki> http://ingex.cvs.sourceforge.net/ingex/ingex/libMXF/ ? [16:03:31 CET] <JEEB> or it's this https://sourceforge.net/p/bmxlib/home/Home/ [16:04:08 CET] <JEEB> yea, it's a git project so sounds much better already :D [16:06:07 CET] <friki> So it make sense to you if I try to put libxml into libavformat/mxf*? "delegate to libxmf" [16:06:58 CET] <thardin> friki: I proposed that a while back [16:07:13 CET] <thardin> it met with quite a bit of resistance [16:08:30 CET] <TimNich> BMXlib is C++ [16:13:17 CET] <thardin> I recall the discussion ending up in something like lavf must have mxfdec on simple principle [16:24:14 CET] <JEEB> TimNich: there's a C one as well if I see correctly [16:24:38 CET] <JEEB> thardin: yet MXF is far from simple :) [16:25:14 CET] <thardin> JEEB: indeed. I'm sure there's plenty of nasty bugs in mxfdec.c [16:25:22 CET] <TimNich> It has a mix of C & C++, istr the C++ is needed for the tiemcode libs [16:25:28 CET] <thardin> and the mxf scene is small enough as it is, that splitting it up over multiple implementations is stupid [16:26:01 CET] <thardin> plus mxf is a purposefully complicated format, for billable hours purposes [16:27:00 CET] <TimNich> ;) [16:29:05 CET] <thardin> or so I've heard! [16:57:24 CET] <BtbN> n [17:22:25 CET] <friki> In my quick preview mxf implementation at libformat isn't ready for "professional usage". I mean lot of TODO: metadata related, data tracks... [19:06:51 CET] <michaelni> durandal_1707, i think you timed-out: <michaelni> durandal_1707, sorry was too busy to reply yesterday. to awnser, i dont remember but i think it was that people didnt like the yuvj formats. If that changed and people now like to kee them i certainly wont oppose but i think they are a bit ugly, we also dont have a format for 601/709 and the case is similar to the range [19:07:41 CET] <durandal_1707> michaelni: where is code that triggers scale filter when pix fmt are different between src and dst? [19:10:55 CET] <durandal_1707> i belive thats main reason why it incorrectly works with fate tests, scale filter is not triggered when it should [19:19:01 CET] <michaelni> durandal_1707, i think libavfilter/avfiltergraph.c but its a while that i touched this [21:25:21 CET] <jrabe> Hi all, first time contributor here. I noticed that ffmpeg eats all of stdin even when converting files (took me a long time to track this issue down). I was wondering if a patch for that is something you're interested in and/or if there's already an open bug for it somewhere. [21:25:44 CET] <BtbN> I don't understand the issue [21:25:50 CET] <BtbN> what else do you expect it to do with the input? [21:26:16 CET] <jrabe> I'm specifying the input file with -i, so ideally nothing at all [21:26:43 CET] <BtbN> ...? [21:26:49 CET] <BtbN> And what is it doing with it? [21:27:22 CET] <jrabe> It's reading all of stdin even though it never uses it [21:27:31 CET] <jrabe> this is what the folks over at #bash sent me: http://mywiki.wooledge.org/BashFAQ/089 [21:28:43 CET] <BtbN> that sounds super weird, why would ffmpeg in that constellation get any input? [21:29:09 CET] <jrabe> I have no idea, that's why it took me forever to figure out it was ffmpeg reading my file list [21:29:26 CET] <jrabe> I had a loop reading multiple filenames and it would always stop after the first iteration [21:29:55 CET] <BtbN> ffmpeg can be controled via keyboard commands, to quit early and some other stuff [21:30:03 CET] <BtbN> so I guess that's what the standard input is used for [21:30:39 CET] <jrabe> I see, that makes sense. No easy fix it looks like then, unfortunately. [21:31:56 CET] <jrabe> Apparently there's a -nostdin flag to disable that. If only I had known before ;) [21:32:04 CET] <jrabe> thanks! [21:34:17 CET] <atomnuker> apparently microsoft added support for opus/vorbis/vp9 in edge using ffmpeg - https://www.neowin.net/news/microsoft-releases-web-media-extensions-package-... [21:34:41 CET] <BtbN> And they removed HEVC from Windows [21:37:37 CET] <nevcairiel> no they didnt, they just changed how its updated/installed [21:38:11 CET] <BtbN> Well, you need to install it from the Store now [21:38:18 CET] <BtbN> so it's not a part of Windows anymore [21:38:29 CET] <BtbN> probably got too expensive [21:38:39 CET] <nevcairiel> thats just semantics [21:38:50 CET] <nevcairiel> and i assume there is a license cap which they'll easily hit anyway [21:46:13 CET] <JEEB> nvidia says it goes payware, but so far it's for free @ store [21:46:33 CET] <JEEB> re: the last sentence @ http://nvidia.custhelp.com/app/answers/detail/a_id/4583 [21:46:39 CET] <JEEB> although it could be that they're just clueless [21:48:06 CET] <jrabe> BtbN, now that I think about it, isn't it quite risky for ffmpeg to read stdin by default in non-interactive operations? Imagine you're only processing one file and then running some other commands using data from stdin; ffmpeg could read and silently ignore a bunch of characters until reading a 'q' and quitting, which would change the meaning of the commands run afterwards (e.g. delete the wrong file). [21:48:19 CET] <jrabe> Of course it's not really an ffmpeg issue (ideally shells wouldn't share stdin by default) but I still think -nostdin for -i would be a better default (possibly a breaking change, sadly). [21:54:27 CET] <BtbN> It's not expected to randomly get stuff there, other than control keys [22:06:52 CET] <jrabe> Yeah, I wouldn't really call it a bug since it's actually using stdin, just a small POLA incompatibility, probably. [22:47:14 CET] <gnafu> j-b: You're on the front page of reddit! [22:49:18 CET] <j-b> gnafu: yeah. Sad! [22:49:34 CET] <gnafu> ;-D [00:00:00 CET] --- Wed Dec 6 2017