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

Wed Dec 6 03:05:03 EET 2017

[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_Specification.pdf 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-for-edge-and-windows-10
[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