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

[burek]

[01:21:44 CEST] <kierank> J_Darnley: atomnuker: I would guess it's best doing the interpolation on stack
[01:21:48 CEST] <kierank> or in a scratch buffer
[01:23:10 CEST] <J_Darnley> Yay!  Just what it needs.  More buffers and pointers to buffers.
[01:24:36 CEST] <kierank> J_Darnley: i'm not sure if there's a better way
[01:24:44 CEST] <kierank> we can have this discussion now if you want
[01:25:05 CEST] <J_Darnley> Nah.  Tomorrow.
[01:25:46 CEST] <kierank> J_Darnley: do you know if the extrapolation (not interpolation technically) stuff is in the spec?
[01:26:02 CEST] <J_Darnley> I don't recall seeing it
[01:26:31 CEST] <J_Darnley> But wasn't the low latency thing added later as some sort of extension?
[01:26:46 CEST] <kierank> that's orthogonal I think to the issue
[01:27:07 CEST] <kierank> i believe dirac has always had the property that you could do a transform on the entire plane or per slice and you'd get the same result
[01:27:15 CEST] <kierank> as a result of the extrapolation parameters they chose
[01:27:24 CEST] <kierank> but maybe a discussion for #dirac
[03:05:34 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:a82468514048: avcodec/ivi: Use av_image_check_size2()
[05:34:00 CEST] <atomnuker> durandal_1707: seems like enabling the cached bitstream reader in flac.h segfaults
[05:34:43 CEST] <atomnuker> made 2 tests, utvideo went from 43x realtime to 53x realtime, vorbis went from 483x to 487x
[05:35:20 CEST] <atomnuker> gonna test on an arm now
[05:51:40 CEST] <atomnuker> *now == after I wake up because it takes that long to do a fresh compile
[11:50:33 CEST] <wm4> jkqxz: do you have a git repo with your drm hwcontext changes?
[13:22:47 CEST] <durandal_1707> can somebody push dolby e?
[13:58:05 CEST] <wm4> did something with h264 hwaccel regress recently? if I enable threads, sw_pix_fmt is set to -1
[13:58:11 CEST] <wm4> in get_format
[14:05:41 CEST] <cone-814> ffmpeg 03Ricardo Constantino 07master:0bf857a13fd5: configure: use pkg-config for libgme, if available
[14:28:05 CEST] <RiCON> wm4: thanks
[14:34:50 CEST] <cone-814> ffmpeg 03Kieran O'Leary 07master:264f6c6f9537: movenc: Add 'keywords' metadata
[14:56:03 CEST] <jdarnley> Gah!  Where is this rubbish data coming from?
[14:56:36 CEST] <jdarnley> I think it obviously comes from an overread because the slice extends byond the edge of the frame
[14:57:00 CEST] <jdarnley> But why isn't it in the picture from master?
[15:42:38 CEST] <jdarnley> WTF is this this?  Why is this encoding odd sized slices?
[15:49:21 CEST] <jdarnley> That can't be right.  You can't put 33 lines into a 32 pixel tall slice.
[16:36:29 CEST] <jdarnley> I'm sure you people will love this...
[16:36:32 CEST] <jdarnley> "Slice subbands can change dimension by 1 from one slice to another"
[16:37:26 CEST] <jdarnley> WTF am I supposed to do then?  Fudge my slices because they are supposed to change size?
[16:40:56 CEST] <kierank> shouldn't matter afaik
[16:41:56 CEST] <jdarnley> But if am supposed to output the same data I need to code "random" slice sizes
[16:42:20 CEST] <jdarnley> rather than uniform
[16:42:30 CEST] <kierank> the same data as what?
[16:42:38 CEST] <jdarnley> What it does now
[16:42:49 CEST] <kierank> why do you say that
[16:42:54 CEST] <kierank> at the moment it uses fixed slice sizes
[16:43:11 CEST] <jdarnley> NO IT DOES NOT!  THEY CLEARLY CHANGE SIZES!
[16:43:11 CEST] <kierank> and after it uses fixed slice sizes with edge extension
[16:43:21 CEST] <kierank> jdarnley: then it's a bug
[16:43:37 CEST] <kierank> atomnuker: are you aware of this?
[16:44:13 CEST] <kierank> jdarnley: so with "nice" slice sizes like 32x8 it changes slice size?
[16:44:31 CEST] <kierank> slice dimension to be more precise
[16:44:36 CEST] <jdarnley> If you try to encode a not mod-8 height yes
[16:44:37 CEST] <nevcairiel> poor jdarnley, driven to insanity after a few days of vc2
[16:44:48 CEST] <jdarnley> Or a not mod-32 width
[16:44:59 CEST] <jdarnley> A few days?
[16:45:04 CEST] <jdarnley> This nearly 2 weeks in
[16:45:44 CEST] <jdarnley> Or a week?  I forgot when I started
[16:48:57 CEST] <kierank> jdarnley: well yeah, don't encode weird heights
[16:49:31 CEST] <kierank> use 1920x1080, those numbers are niceish
[16:49:54 CEST] <jdarnley> 720p is a weird height?
[16:50:05 CEST] <kierank> 720p ain't mod 32
[16:50:09 CEST] <kierank> 1280 isn't i mean
[16:50:32 CEST] <jdarnley> I know you want to use 32x8 does that mean I should ignore obvious corruption with 32x32?
[16:51:01 CEST] Action: jdarnley goes to print widths too
[16:52:18 CEST] <kierank> no please fix 32x32
[17:54:26 CEST] <atomnuker> jdarnley: that's completely normal too
[17:55:05 CEST] <atomnuker> the amount of coefficients varies depending on which slice is being encoded/decoded
[17:55:55 CEST] <jdarnley> This format sucks!
[17:56:21 CEST] <jdarnley> How can that be posible?  How can they call that a slice?
[18:00:56 CEST] <jdarnley> Fudging it is then!
[18:01:09 CEST] <JEEB> :D
[18:06:18 CEST] <atomnuker> jdarnley: just copy the code from the decoder to determine how many coefficients to encode
[18:07:04 CEST] <atomnuker> and ask for more than the slice size amount of pixels to encode
[18:07:19 CEST] <jdarnley> The encoder in master probably gets it right but I will check
[18:08:03 CEST] <atomnuker> it does get it right, it'll encode crazy dimensions and pixel formats
[18:08:22 CEST] <atomnuker> yes, it even supports full range and ycocg
[18:08:28 CEST] <jdarnley> Yeah, so I just need to fudge my slices like it does
[18:08:49 CEST] <atomnuker> its not a fudge
[19:20:09 CEST] <wm4> ok so not only did master regress with hwaccel + threads>1, also videotoolbox never worked properly with threads>1...
[19:27:32 CEST] <wm4> I suspect it's because AVHWAccel.end_frame for videotoolbox mutates the AVFrame (the reference and data pointer, not just the "contents")
[19:27:58 CEST] <wm4> and then those changes don't get propagated to some other worker threads which might need them
[19:28:11 CEST] <wm4> but I'm not really sure if that makes sense at all
[19:34:32 CEST] <wm4> wait that doesn't even make sense, first because it doesn't make sense, and second because you never pass surfaces to videotoolbox (it manages them on its own)
[19:35:48 CEST] <wm4> another possibility would be that ffmpeg tries to output an allocated but uninitialized frame (but it decodes fine with software decoding)
[19:39:58 CEST] <jdarnley> I hate specs.  I hate whitepapers.  They all speak about decoders as if streams appear out of thin air with the wave of a wand.
[19:40:23 CEST] <wm4> can't you just buy expensive reference stream samples?
[19:41:07 CEST] Action: jdarnley shrugs
[19:44:00 CEST] <durandal_1707> kierank: buy it, you sleep on moneys
[19:44:11 CEST] <kierank> buy what
[19:44:15 CEST] <kierank> i can't buy imaginary files
[20:19:35 CEST] <atomnuker> jdarnley: that's why encoders exist
[20:20:11 CEST] <BBB> :D
[20:20:22 CEST] <jdarnley> Yeah.  That's the magic wand.  You wave them about and streams come out.
[20:20:38 CEST] <jdarnley> Nobody knows how they work.
[20:21:01 CEST] <jdarnley> Voldemort killed 1 of the 2 people who knew and the other retired.
[20:21:30 CEST] <atomnuker> be thankful encoders are not specified
[20:21:37 CEST] <atomnuker> be very thankful they're not
[20:22:47 CEST] <jdarnley> Yeah.  We'll just create them like wands.  Make thousands and try them out one at a time until we find one that works.
[20:25:18 CEST] <tdjones> Is there a widely preferred benchmarking tool when submitting perfomance-related changes to the ML, or is anything that is accurate acceptable?
[20:25:49 CEST] <jdarnley> If the code is supposed to run a for fixed duration everytime: timer.h
[20:26:05 CEST] <ubitux> what are you trying to bench?
[20:26:49 CEST] <ubitux> if it's ASM SIMD, you can use the START/STOP_TIMER from timer.h as suggested by jdarnley, or you could use checkasm --benchmark if you have checkasm FATE tests for your functions
[20:27:19 CEST] <ubitux> otherwise... you have ffmpeg -benchmark(_all)
[20:27:25 CEST] <tdjones> These are C changes in the vorbis encoder, not asm.
[20:27:45 CEST] <ubitux> try ffmpeg -benchmark -i ... -f null -
[20:28:17 CEST] <ubitux> -benchmark_all is more helpful i suppose
[20:28:37 CEST] <jdarnley> In that case I would suggest run time recording (like -benchmark or /usr/bin/time) and an average.
[20:29:25 CEST] <tdjones> I've been running under callgrind and just referencing instruction references, but I'll do that. Thanks!
[20:30:03 CEST] <atomnuker> better use perf
[20:30:25 CEST] <atomnuker> if you need function level overhead measurements, otherwise -benchmark
[20:42:41 CEST] <BBB> <jdarnley> Voldemort killed 1 of the 2 people who knew and the other retired. <<< ??? :D
[20:43:46 CEST] <BBB> Im pretty sure theres more than 2 people in the world knowing how to write encoders?
[20:54:16 CEST] <cone-884> ffmpeg 03Rostislav Pehlivanov 07master:035c755b4ef3: opusenc: use float_dsp for transient mdcts
[21:04:51 CEST] <iive> you can benchmark C functions with START/STOP_TIMER, not just asm
[21:12:02 CEST] <atomnuker> durandal_1707: on an rpi 1 for utvideo: before - 60.860s, after - 71.420s
[21:12:37 CEST] <atomnuker> I think changing the cache size wouldn't result in a performance regression
[21:13:06 CEST] <durandal_1707> atomnuker: so that means one need to enable this only on x64
[21:13:38 CEST] <atomnuker> yes, so just put it under the have_fast_64 bit define rather than its own
[21:13:50 CEST] <durandal_1707> BBB: i just wrote one it was easy peasy
[21:13:51 CEST] <atomnuker> I failed to measure a regression on 64 bit systems with it
[21:26:11 CEST] <iive> durandal_1707: you might get better speed if you do aligned read on arm.
[22:03:50 CEST] <alphabitcity> Is there a creation timestamp stored on RTP packets? If so, is it possible to access that timestamp from filter_frame (e.g. on the AVFrame obj)? Thanks!
[22:10:38 CEST] <alphabitcity> Or, put another way, is it possible to get a frame's capture time in a custom filter?
[22:13:24 CEST] <jamrial> durandal_1707: can you look at the vf_limiter patch?
[22:14:07 CEST] <durandal_1707> jamrial: i dont have x86,  do you have?
[22:14:18 CEST] <jamrial> yes
[22:14:42 CEST] <durandal_1707> so just push it if it works
[22:15:18 CEST] <jamrial> give me a command line example to test it, since there's no fate test
[22:15:33 CEST] <jamrial> using testsrc or whatever
[22:24:04 CEST] <durandal_1707> -vf limiter=50:110
[23:32:48 CEST] <cone-884> ffmpeg 03James Almer 07master:823cc7e25f97: checkasm: add a g722dsp test
[23:32:49 CEST] <cone-884> ffmpeg 03James Almer 07master:6f205a42d76a: checkasm: add hybrid_analysis_ileave and hybrid_synthesis_deint tests to aacpsdsp
[23:32:50 CEST] <cone-884> ffmpeg 03James Almer 07master:5688fd77b57f: x86/vf_limiter: make limiter functions work on x86_32
[00:00:00 CEST] --- Fri Jul 14 2017