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

[burek]

[00:21:16 CEST] <BtbN> philipl, I'll look at it once I get home next week, no time until then. But if that's the case, there's not much to it for ffmpeg.
[00:43:43 CEST] <BtbN> The thing I don't get is why it still happens with librtmp disabled. It's an entirely different codepath
[00:43:50 CEST] <BtbN> Or is the --disable for it just broken? hm
[00:46:13 CEST] <philipl> BtbN: yeah, not clear if the reconfigure is that interesting or not; I guess it helps us support mid-stream format changes more easily.
[00:46:33 CEST] <BtbN> But we already support them just fine? What's new?
[00:46:46 CEST] <philipl> We recreate the decoder to do it?
[02:43:30 CEST] <cone-457> ffmpeg 03Marcin Gorzel 07master:8b710ea5e7b8: swresample: Use channel count in rematrix initialization
[02:43:30 CEST] <cone-457> ffmpeg 03Michael Niedermayer 07master:a37c62026991: avformat/mov: Check default_encrypted_sample before use in mov_read_sample_encryption_info()
[02:43:32 CEST] <cone-457> ffmpeg 03Michael Niedermayer 07master:bce4da85e811: swresample/swresample: Fix input channel count in resample_first computation
[15:12:26 CEST] <durandal_1707> kierank: will you sponsor lavfi improvements?
[15:12:59 CEST] <kierank> Like what
[15:13:56 CEST] <durandal_1707> better interface to users
[15:37:34 CEST] <cone-987> ffmpeg 03Jun Zhao 07master:790cf9518a37: lavf/tcp: add option to setting Maximum Segment Size
[15:37:35 CEST] <cone-987> ffmpeg 03Jun Zhao 07master:a8ce6fb425e0: doc/protocols: documents tcp_mss
[18:17:39 CEST] <durandal_1707> so only michaelni is paid for his hard work?
[18:22:01 CEST] <kierank> durandal_1707: could pay
[18:22:13 CEST] <kierank> need framesync and other nicholas crap gone
[18:31:39 CEST] <atomnuker> framesync is fine, what's your problem with it?
[18:31:46 CEST] <atomnuker> it makes things simpler for filters
[18:32:26 CEST] <atomnuker> I'd really rather not have filters needing to mess with timestamps, framesync does abstract it away nicely
[18:34:05 CEST] <atomnuker> the work nicholas has done on lavfi has been alright
[18:34:38 CEST] <kierank> variable latency, great
[18:34:53 CEST] <kierank> let me know where i can find my time machine
[18:35:31 CEST] <atomnuker> or you can stop having something against the person himself and admit that variable latency is needed in some cases, and in such cases having a simpler api wouldn't work
[18:35:52 CEST] <durandal_1707> atomnuker: how so?
[18:36:15 CEST] <durandal_1707> simpler api should resolve latency issues
[18:36:33 CEST] <durandal_1707> basically you would get all frames from input pads at once
[18:37:06 CEST] <atomnuker> yes, it will, but suppose you have a filter which refs a frame once given, and oututs it when there's a frame on the second stream which matches the held frame
[18:37:23 CEST] <atomnuker> I'm just giving an example of a variable latency multi stream filter
[18:38:04 CEST] <atomnuker> I can't think of why you'd like to do that but my point is that filters can sometimes act like encoders and hold frames for variable amounts of time
[18:38:57 CEST] <atomnuker> and I don't think a simple API which can guarantee latency of X frames can do the same with such filters
[18:39:57 CEST] <atomnuker> I don't mind having a simple API for filters which don't need this, which are just single frame in -> single frame out
[18:40:04 CEST] <atomnuker> that's like 80% of lavfi filters already
[18:40:44 CEST] <atomnuker> but I don't think that we should be removing code and API which breaks the other 20% or however many there are
[18:40:57 CEST] <durandal_1707> this is mainly for overlay filter, which is not single in -> single out
[18:42:07 CEST] <atomnuker> yes, the overlay filter does fit into the former category well, but I don't think people should be demonizing framesync but say, adding a mode where it doesn't check PTS, doesn't hold frames, it just always outputs them
[18:42:53 CEST] <durandal_1707> i was thinking about having additional api, not removing old one
[18:43:23 CEST] <atomnuker> yes, an additional external API is what I was talking about, this is about framesync which is entirely internal
[18:43:35 CEST] <kierank> yes but you can't use avfilter without framesync and all the other stuff right now
[18:43:43 CEST] <kierank> it's a big monolithic thing
[18:43:49 CEST] <atomnuker> so we fix framesync!
[18:43:57 CEST] <atomnuker> I didn't say anthing about removing it
[18:43:58 CEST] <kierank> it's unfixable
[18:44:02 CEST] <atomnuker> it can have a bypass mode
[18:44:06 CEST] <atomnuker> anything can have a bypass mode
[18:44:19 CEST] <atomnuker> and what do you know about lavfi? you haven't written a single filter
[18:45:36 CEST] <kierank> I've tried to use it for real
[18:45:40 CEST] <kierank> and had to use undocumented hack after hack
[18:45:42 CEST] <rcombs> tangentially, I'd still like a "timestamp heartbeat" concept in a lot of places
[18:45:48 CEST] <atomnuker> framesync can let you have frames as soon as they come and not handle variable FPS, synchronous video stream
[18:46:14 CEST] <atomnuker> kierank: internally, not externally, framesync isn't even visible to users
[18:46:39 CEST] <atomnuker> you don't know what it is, you just know its evil, written by a person you don't like, and you'd go to lengths to remove it just because of this
[18:47:10 CEST] <kierank> I do know what it is, and moreso I know it is complely ununderstandable and said person won't allow anyone to touch it
[18:47:33 CEST] <kierank> worse still it is reinvention of things which are well understood in multimedia
[18:48:01 CEST] <durandal_1707> what things? could you name them?
[18:48:14 CEST] <kierank> https://en.wikipedia.org/wiki/Frame_synchronization_(video)
[18:48:16 CEST] <kierank> this is a solved problem
[18:49:46 CEST] <atomnuker> how else would a filter handle variable fps inputs which need to be timed to be overlaid? framesync handles that for you
[18:50:19 CEST] <durandal_1707> simpler api would let user to handle all that framesync stuff
[18:50:39 CEST] <kierank> buffer to infinity
[18:50:41 CEST] <kierank> that's the best way!
[18:50:58 CEST] <atomnuker> yes, I agree, but a more complicated API is needed if you want to have that handled for you
[18:51:33 CEST] <atomnuker> and it isn't a reinvention, its an implementation
[18:51:35 CEST] <rcombs> that sounds& potentially unsustainable
[18:51:51 CEST] <rcombs> what if you never get new input on one of the pads
[18:51:52 CEST] <kierank> ask daemon404 about the number of avfilter OOMs they get a day
[18:52:10 CEST] <atomnuker> I haven't heard anything about that for 2.5 years
[18:52:12 CEST] <kierank> because it just decides to start buffering when it wants
[18:52:14 CEST] <rcombs> say, overlay
[18:52:55 CEST] <atomnuker> kierank: well, how else to handle input with crap timestamps?
[18:52:57 CEST] <rcombs> I think sub2video avoids that by using blank "heartbeat" frames
[18:53:05 CEST] <atomnuker> like I said, a simpler api wouldn't need to think about this
[18:53:13 CEST] <atomnuker> and I'm okay with it
[18:54:53 CEST] <kierank> people who want things to work can actually use it
[18:54:57 CEST] <kierank> everyone else can enjoy OOM
[18:55:31 CEST] <atomnuker> kierank: how would you handle OOMs? have a limit on how much you can allocate!
[18:55:43 CEST] <atomnuker> there's no ideal solution for this problem
[18:55:47 CEST] <kierank> yeah there is 
[18:55:49 CEST] <kierank> drop frames
[18:56:02 CEST] <kierank> If I have n input streams coming as vfr
[18:56:09 CEST] <kierank> I can't just pick the first one as the master
[18:56:12 CEST] <kierank> because if it stops they all stop
[18:56:18 CEST] <kierank> and I can't just jump around between all of them
[18:56:21 CEST] <kierank> because that's fucked
[18:56:29 CEST] <kierank> so what  you do is pick a sane underlying cfr framerate
[18:56:36 CEST] <kierank> but the vfr cultists won't like that
[18:57:02 CEST] <kierank> so we'd rather have a broken framesync doing weird stuff when streams come and go than actually something that works in 99% of cases
[18:57:09 CEST] <atomnuker> no, we won't, because VFR has a place in video, though mostly in computers, not broadcast
[18:57:29 CEST] <atomnuker> 99% of broadcast cases
[18:57:34 CEST] <kierank> noone said anything about broadcast
[18:57:39 CEST] <kierank> you just decided to paint that on me
[18:57:40 CEST] Action: rcombs looks at subtitles, which are "VFR"
[18:57:44 CEST] <atomnuker> you did when you said pick an underlying CFR
[18:57:50 CEST] <kierank> yes because the world is cfr
[18:57:53 CEST] <kierank> monitors are cfr
[18:57:57 CEST] <atomnuker> no they aren't
[18:58:00 CEST] <kierank> yes they are
[18:58:03 CEST] <atomnuker> computer ones aren't
[18:58:05 CEST] <atomnuker> freesync
[18:58:09 CEST] <atomnuker> wayland isn't
[18:58:10 CEST] <kierank> yes they are what planet do you live on
[18:58:12 CEST] <kierank> who has freesync
[18:58:14 CEST] <kierank> a bunch of geeks
[18:58:19 CEST] <kierank> 99% of the world has cfr monitor
[18:58:31 CEST] <rcombs> new iPads are VFR
[18:58:39 CEST] <atomnuker> I'm living on a planet where programs don't refresh their windows at 60fps but only when they need to or are told to
[18:58:57 CEST] <atomnuker> regardless of what the monitor is doing, capturing my screen yields variable fps
[18:58:59 CEST] <kierank> and live pipelines can go back and forwards in time because of variable latency
[18:59:05 CEST] <kierank> then you don't understand multimedia
[18:59:12 CEST] <kierank> you conflate time of capture with time of presentation
[18:59:32 CEST] <atomnuker> time of presentation can be time of capture but with an offset
[18:59:43 CEST] <kierank> no it can't
[18:59:46 CEST] <kierank> then it has noise
[18:59:59 CEST] <atomnuker> not a random offset, but an offset into the future
[19:00:05 CEST] <kierank> then how is it vfr
[19:00:36 CEST] <atomnuker> the timestamps themselves say to present N timebases into the future
[19:00:56 CEST] <kierank> why would N vary
[19:01:22 CEST] <kierank> 1/60 + N where N is a constant is cfr
[19:01:28 CEST] <atomnuker> because maybe nothing has changed, and capturing a frame right now would be useless and just add overhead
[19:01:39 CEST] <kierank> that's orthogonal to capture
[19:01:41 CEST] <atomnuker> the timebase doesn't have to indicate the framerate
[19:01:47 CEST] <kierank> also orthogonal
[19:02:06 CEST] <atomnuker> indeed
[19:02:08 CEST] <kierank> live video is cfr whatever the source
[19:02:27 CEST] <atomnuker> doesn't have to be, could be a slideshow of frames with variable delay
[19:02:45 CEST] <kierank> your monitor still renders them every 60hz
[19:02:57 CEST] <durandal_1707> so send patch, to extend framesync to drop frames if it would buffer too much?
[19:02:59 CEST] <atomnuker> so, whatever, doesn't have to
[19:03:27 CEST] <kierank> durandal_1707: what about fixing variable latency in avfilter pipeline
[19:03:28 CEST] <atomnuker> its the player's responsibility to clock them to whatever the compositor says the framerate of the monitor is
[19:03:34 CEST] <atomnuker> and that could change per-frame
[19:03:43 CEST] <kierank> and if the pipeline has latency that goes forward and backwards how does it know how to bound its latency
[20:15:12 CEST] <BBB> haha https://lwn.net/Articles/760142/
[20:15:19 CEST] <BBB> so were not the only ones complaining about this nnnonsense
[20:15:46 CEST] <BBB> for ocne I appreciate debians stubbornness
[20:26:00 CEST] <durandal_1707> we should allow nn in FFmpeg
[20:28:47 CEST] <jamrial> we already do. we even have like 12k lines of weighs with no way to reproduce them, which is what people dislike
[20:36:18 CEST] <Gramner> what about making the code take weights as a (non-included) input file?
[20:37:08 CEST] <jamrial> it was suggested. nnedi does that, even
[20:37:16 CEST] <jamrial> no idea why it wasn't done for this one
[20:38:15 CEST] <Gramner> since weights are essentially a binary black box, just because you can stuff them into a c array doesn't make it source code
[20:38:39 CEST] <jamrial> it should be reverted and implemented that way, really. i bet the only reason it was commited this way is no one was strict enough to say "don't"
[20:39:20 CEST] <JEEB> yes
[20:42:53 CEST] <atomnuker> I agree as well
[20:43:15 CEST] <atomnuker> we still haven't done a release yet with any NN stuff, right?
[20:44:29 CEST] <jamrial> no, we haven't
[20:45:28 CEST] <durandal_1707> what about all those vlc tables in source code? you do not have ways to reproduce them either.
[20:45:39 CEST] <jdarnley> I wonder how the FSF lawyers would see it?  Perhaps they wouldn't have a problem with it because you can build binary X from source Y.
[20:46:09 CEST] <BradleyS> licensing aside, i can say as a downstream binary size is a concern for handbrake and probably others
[20:46:22 CEST] <BradleyS> one reason we didn't include nnedi back in the day
[20:46:57 CEST] <jdarnley> The avisynth plugin?  Was it that big?
[20:47:04 CEST] <BradleyS> iirc it had something like 12 MiB of weighting information
[20:47:24 CEST] <BradleyS> tritical's nnedi, avisynth was a port of it if i recall
[20:47:49 CEST] <BradleyS> ah nevermind his original was for avisynth
[20:47:57 CEST] <JEEB> yea original was avisynth
[20:48:01 CEST] <JEEB> then there was a vapourynth port
[20:48:05 CEST] <JEEB> and then that got ported to lavfi
[20:49:59 CEST] <atomnuker> so far the only filter I see that we embed DNNs for is srcnn
[20:50:05 CEST] <BradleyS> handbrake has had an eedi2 port for ages, wasn't for lack of interest
[20:50:14 CEST] <atomnuker> it has 5000 lines of weights, not 12k
[20:51:05 CEST] <durandal_1707> there is nnedi based superscaler too
[20:52:05 CEST] <atomnuker> oh, and espcn
[20:52:19 CEST] <atomnuker> DNNModel* ff_dnn_load_model_native(const char* model_filename)
[20:52:21 CEST] <atomnuker> ..........
[20:52:39 CEST] <atomnuker> god damn it, who writes in such a fucked up style
[20:52:45 CEST] <atomnuker> fucking intel code
[20:53:03 CEST] <atomnuker> I'm making a patch to revert everything, this is unacceptable
[20:53:19 CEST] <durandal_1707> what's wrong pal?
[20:53:53 CEST] <BradleyS> that's organizationism :P
[20:55:59 CEST] <durandal_1707> atomnuker: stop!
[20:57:01 CEST] <atomnuker> I'm making a patch and explaining what went wrong and how to fix it, if anything it'll raise a discussion and maybe a patch to fix it without reverting
[20:58:58 CEST] <durandal_1707> atomnuker: please visit nearest shrink asap!
[20:59:19 CEST] <atomnuker> why?
[20:59:34 CEST] <atomnuker> we agree that something must be done
[20:59:51 CEST] <durandal_1707> but let someone else do it
[21:00:03 CEST] <atomnuker> certainly before we make a release, and I don't want a repeat of the 4.0 blocker bugs
[21:00:33 CEST] <atomnuker> who else wants to do it then? I don't mind
[21:14:51 CEST] <jamrial> atomnuker: go ahead and do it
[21:14:53 CEST] <atomnuker> ok, here's the patch if anyone things I should add something to the message: https://0x0.st/sVgR.patch
[21:14:57 CEST] <durandal_1707> atomnuker: just forget about it
[21:15:28 CEST] <atomnuker> I can't unsee the incorrectly placed asterix
[21:15:48 CEST] <jamrial> durandal_1707: stop
[21:16:56 CEST] <jamrial> 1mb patch, hah
[21:17:10 CEST] <jamrial> ~12k lines for dnn_espcn.h alone
[21:18:13 CEST] <durandal_1707> jamrial: please do not tell me what to do
[21:18:32 CEST] <jamrial> atomnuker: remove the "As discussed on IRC" part. it was discussed in the ml as well
[21:19:12 CEST] <atomnuker> oh wow, you're right, 1mb
[21:20:23 CEST] <jamrial> consider just stripping the deleted files to unbloat the patch
[21:20:49 CEST] <jamrial> it wont be git am'able, though
[21:21:41 CEST] <jamrial> but since it doesn't need testing, just agreement, it wont matter
[21:23:39 CEST] <durandal_1707> I will veto this patch!
[21:27:22 CEST] <atomnuker> jamrial: k, patch (actually just the cover letter with stats and a message) sent to the ML
[21:42:25 CEST] <JEEB> anyone remembers aarch64 asm to give any hints on what to do with https://www.irccloud.com/pastebin/wL2sKCW2/ ?
[21:44:41 CEST] <durandal_1707> ask ubitux 
[21:45:42 CEST] <jamrial> JEEB: sounds like an outdated/buggy assembler?
[21:45:56 CEST] <JEEB> NDK r17b clang
[21:49:27 CEST] <jamrial> seems to compile fine with http://fate.ffmpeg.org/report.cgi?slot=aarch64-linux-qemu-ubuntu-gcc-4.8&time=20180720180408
[21:49:40 CEST] <jamrial> we don't have a ndk aarch64 fate client, though
[21:50:23 CEST] <JEEB> yea tje gcc still does
[21:50:30 CEST] <JEEB> (in NDK even)
[21:50:36 CEST] <JEEB> but they're going to be removing that soon
[21:52:14 CEST] <atomnuker> I can test with clang-6
[21:55:07 CEST] <ubitux> JEEB: that's strange, we do already have that kind of op in other part of the codebase
[21:55:10 CEST] <ubitux> libavcodec/aarch64/vp9mc_neon.S:        add             x9,  x6,  w5, uxtw #4
[21:55:17 CEST] <ubitux> does this one compile?
[21:55:48 CEST] <JEEB> lemme see
[21:56:36 CEST] <jamrial> the dup line it complains about may be not "correct", as well
[21:56:49 CEST] <jamrial> it looks different than similar ones in libavcodec files
[21:57:25 CEST] <ubitux> i don't have a working toolchain right now, but what you can do is assemble it with a toolchain that works, and look at the generated assembly
[21:57:27 CEST] <jamrial> maybe it should be "dup v24.4S, v24.S[3]"
[21:57:55 CEST] <ubitux> yup, that might help this one
[21:59:15 CEST] <jamrial> what assembler does clang use? a binutils from the gcc 4.8 era doesn't complain, so really odd
[22:00:02 CEST] <ubitux> for the sub line, the main diff is "w1" instead of "x1"
[22:00:10 CEST] <ubitux> and maybe the fact it's a sub and not a add
[22:00:29 CEST] <ubitux> so you may try changing those, just to test the compilation
[22:01:34 CEST] <JEEB> did you need the vf_ prefix when disabling filters?
[22:02:43 CEST] <durandal_1707> why are you disabling filters?
[22:03:42 CEST] <JEEB> because nlmeans doesn't compile?
[22:03:55 CEST] <durandal_1707> fix it and post patch?
[22:04:12 CEST] <ubitux> JEEB: make libavcodec/aarch64/vp9mc_neon.o
[22:04:13 CEST] <jdarnley> JEEB: no
[22:04:14 CEST] <JEEB> fuck you too, I was just asked to skip it to build avcodec first which has similar SIMD for VP9
[22:04:15 CEST] <ubitux> or make -k
[22:04:26 CEST] <durandal_1707> obviously you only give name
[22:04:27 CEST] <JEEB> jdarnley: thank you
[22:04:42 CEST] <JEEB> I am fucking tired, I just came back home like 1.5 hours ago
[22:04:45 CEST] <JEEB> anything else you want?
[22:04:49 CEST] <JEEB> an ice cream?
[22:06:01 CEST] <JEEB> ok, got my configure line for aarch64 done... let's see
[22:06:15 CEST] <atomnuker> yeah, clang-6 has the same error here on aarch64
[22:06:21 CEST] <ubitux> JEEB:    c:   cb214809        sub     x9, x0, w1, uxtw #2
[22:06:31 CEST] <ubitux> this is how it's supposed to be assembled
[22:06:44 CEST] <ubitux> and jamrial is right
[22:06:46 CEST] <ubitux>   c0:   4e1c0718        dup     v24.4s, v24.s[3]
[22:06:53 CEST] <ubitux> basically, change these instructions like this
[22:06:55 CEST] <ubitux> it should do the trick
[22:07:29 CEST] <JEEB> atomnuker: good to know that it's not just NDK
[22:08:13 CEST] <ubitux> (got those using objdump on the assembled .o)
[22:08:32 CEST] Action: ubitux &
[22:09:21 CEST] <durandal_1707> clang usually use own assembler iirc
[22:09:44 CEST] <JEEB> ok so vp9 seemed to work
[22:10:29 CEST] <jamrial> JEEB: make the changes ubitux detailed above, nlmeans should compile afterwards
[22:10:41 CEST] <JEEB> ok
[22:10:45 CEST] <JEEB> yea I did notice that
[22:10:58 CEST] <JEEB> I was just trying to double-check that the vp9 part was compiling
[22:11:21 CEST] <JEEB> (yup, it did)
[22:11:31 CEST] <wbs> JEEB: 
[22:11:34 CEST] <wbs> oops
[22:12:10 CEST] Action: JEEB removes the disablement of nlmeans and prepares to do the change
[22:12:47 CEST] <jamrial> uppercase UXTW seems to only be used in this file, but google hints it's valid, so i guess clang's assembler is just picky
[22:13:39 CEST] <wbs> jamrial: no, it's not about upper/lower case
[22:13:52 CEST] <wbs> it's about x vs w for the regsiter that the uxtw is applied on
[22:13:54 CEST] <jamrial> so it was the x1 vs w1?
[22:13:56 CEST] <wbs> yes
[22:14:08 CEST] <jamrial> alright
[22:14:14 CEST] <wbs> uxtw means "do unsigned extension from a 32 bit register to 64 bit register by clearing the upper 32 bits"
[22:14:24 CEST] <wbs> but to apply that on a 64 bit register makes no sense
[22:17:10 CEST] <wbs> the llvm built-in assembler is generally much more picky than binutils gas, but it's not really missing any significant features any longer, only more strict about sloppy things that gas allows through
[22:17:34 CEST] <JEEB> which only leaves GOOG picking some weird revision that has bugs for NDK
[22:17:58 CEST] <wbs> uh, what are you implying now?
[22:18:04 CEST] <wbs> there was nothing in what you reported that was a bug in llvm
[22:18:34 CEST] <JEEB> not regarding this issue
[22:19:59 CEST] <JEEB> and that was a roundabout way of me referencing some earlier cases where just NDK clang was broken, not clang in general (either due to source revision being a non-release or due to GOOG's own stuff)
[22:21:09 CEST] <wbs> I don't think they do very much extra stuff of their own, they just pick any svn version and backport fixes on top of that with their own usecase in mind. not significantly worse than any normal release in most cases
[22:21:42 CEST] <JEEB> alrighty
[22:23:12 CEST] <wbs> it's pretty much the same as ffmpeg; latest master _should_ mostly be good, but it can occasionally be bad. public releases may get a bit more external attention, but as long as you run a bunch of tests with your own usecase in mind it should be fine
[22:26:03 CEST] Action: durandal_1707 no, i'm not interested in LinkedIn
[22:28:48 CEST] <JEEB> ok, I can confirm that the asm file now assembled with the following changes: http://up-cat.net/p/926f28a6
[22:28:58 CEST] <JEEB> which is what I gathered from jamrial's and ubitux's comments
[22:33:43 CEST] <durandal_1707> so is it fixed? does lavfi nlmeans denoise anything useful?
[22:34:44 CEST] <JEEB> that's not the point
[22:34:48 CEST] <JEEB> the build was failing
[22:35:03 CEST] <JEEB> so either you disable components or you poke the IRC channel
[22:35:58 CEST] <jamrial> JEEB: fix the alignment of the comment in the dup line and ship it
[22:36:37 CEST] <JEEB> so I parsed the discussion here correctly? I haven't actually tested it on a device yet
[22:37:49 CEST] <wbs> JEEB: anybody with a working build with gas can check that it actually outputs the same disassembly as before, so not much point in testing on a device
[22:37:57 CEST] <wbs> (in case it doesn't work, it's not broken by this change anyway)
[22:38:14 CEST] <JEEB> ok
[22:38:32 CEST] <jamrial> there are no fate tests for nlmean, and if ubitux (the author of the filter) said it's ok, then at most check what wbs mentioned and push
[22:39:09 CEST] <durandal_1707> without review? That is against all rules...
[22:39:44 CEST] <JEEB> no
[22:39:48 CEST] <jamrial> police is on the way
[22:39:49 CEST] <JEEB> I will send-email as usual
[22:40:33 CEST] <JEEB> anyways, will post it in a moment, need to ask first if my .jp folk need something from .fi
[22:48:55 CEST] <JEEB> jamrial: so something like this? https://github.com/jeeb/ffmpeg/commit/a905c5b50c85ec30edd8d651632b0844ea3b5763
[22:49:11 CEST] <JEEB> will compare the asm against gcc
[22:49:38 CEST] <jamrial> yeah
[22:50:26 CEST] <ubitux> 22:38 <jamrial> there are no fate tests for nlmean // not exactly true
[22:50:29 CEST] <ubitux> the asm is tested
[22:51:08 CEST] <jamrial> ah
[22:51:30 CEST] <jamrial> i saw the todo in the c file and assumed it was about the entire filter
[22:51:34 CEST] <jamrial> forgot about checkasm
[22:57:47 CEST] <JEEB> is objdump or something the best to dump the simd? since vbindiff probably isn't going to cut it ;)
[22:59:38 CEST] <wbs> JEEB: objdump -d
[22:59:48 CEST] <JEEB> yeh, I just found that option
[23:00:53 CEST] <JEEB> ok, is exactly the same
[23:01:02 CEST] <JEEB> only the header differs :)
[23:01:09 CEST] Action: JEEB does send-email
[23:02:29 CEST] <wbs> that's usually the best way to handle that kind of issues anyway; assemble with gas and see what the objdump produces, which might often be the canonical form of typing it (altough I guess someone else already said that)
[23:04:35 CEST] <JEEB> anyways, posted on ML
[23:07:29 CEST] <JEEB> yea, sounds like it > testing with gas
[23:07:39 CEST] <JEEB> (and then objdump -d)
[23:08:52 CEST] <sfan5> that makes me wonder, is there nobody doing fate tests on arm64 w/ clang?
[23:09:32 CEST] <JEEB> I don't think on FFmpeg, Libav seems to have one
[23:09:52 CEST] <JEEB> it does sound like a good idea
[23:11:40 CEST] Action: durandal_1707 now getting messages from google employes, someone looked at my github activity
[23:13:00 CEST] <atomnuker> poor you, careful with them, they write bad code
[23:13:07 CEST] <durandal_1707> lol
[23:13:50 CEST] <kierank> durandal_1707: don't join google cult, stay in ffmpeg cult
[23:14:55 CEST] <durandal_1707> kierank: someting about end to end streaming shit...
[23:15:21 CEST] <kierank> durandal_1707: forward me email
[23:15:28 CEST] <durandal_1707> why?
[23:16:00 CEST] <kierank> want to see if technical or bullshit
[23:16:07 CEST] <kierank> sounds like bullshit
[23:53:04 CEST] <BBB> atomnuker: thank you for doing that
[00:00:00 CEST] --- Fri Jul 27 2018