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

Thu Feb 27 02:05:02 CET 2014

[00:04] <J_Darnley> Is fate.sh supposed to prepend $target_path onto $target_samples?
[00:05] <J_Darnley> It keeps making R:/fate/build/Z:/fate-samples/audio-reference/luckynight_2ch_44kHz_s16.wav as an input file
[03:15] <cone-265> ffmpeg.git 03Carl Eugen Hoyos 07master:96fc2908f0c0: Read bits_per_coded_sample from V_MS/VFW/FOURCC mkv files.
[08:54] <plepere> ubitux : in VP9, for the 2D filters in the MC, do you call 2 1D filtes ?
[08:54] <plepere> *filters
[08:55] <plepere> yeah, seems so. found it in the dsp_init.
[09:10] <ubitux> michaelni: careful when merging compand btw
[09:10] <ubitux> they switch from double to float because they didn't have a clip function for double
[09:10] <ubitux> but i'm not sure of the float being accurate enough given how much add & friends done in the filters
[09:12] <ubitux> also, they replace av_strtok with strtok_r (because it wasn't available in their tree), but of course they just had the portability problem we had a while ago; so all the parsing part should be the same
[09:12] <ubitux> i'd say the merge should be mostly void, given than andrewrk submitted a patch
[09:12] <ubitux> for the memory corruption problem
[09:13] <ubitux> maybe there are other relevant changes; andrewrk can you comment?
[09:13] <plepere> ubitux : do you know if my patches have been reviewed / accepted /rejected ?
[09:14] <ubitux> plepere: did you honor all the comments and sent a new version?
[09:15] <plepere> the ones I had in the week-end, yes
[09:15] <andrewrk> ubitux, here's the diff from ffmpeg to libav: http://paste.ubuntu.com/6998627/
[09:15] <plepere> but I've got nothing on the last patch I've submitted on monday
[09:15] <ubitux> plepere: can you send the ffmpeg-devel archives? i'm lost in all the iteration
[09:16] <plepere> ubitux, http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154897.html
[09:16] <andrewrk> ubitux, it also changed the token from " " to "|"
[09:16] <andrewrk> so the options are incompatible between libraries
[09:16] <andrewrk> there is some additional error checking
[09:17] <ubitux> arh
[09:17] <ubitux> so there are some actual random changes
[09:17] <ubitux> i see changes in the options
[09:17] <ubitux> like default strings
[09:18] <andrewrk> my hands were tied. I didn't suggest those changes
[09:18] <ubitux> for separator we need to change the if to support both char
[09:18] <andrewrk> looks like the change to using av_frame_get_buffer instead of av_samples_alloc_array_and_samples is a good one
[09:20] <andrewrk> ubitux, they had me switch it from double to float not because of the missing clip function but because they thought double was overkill
[09:20] <andrewrk> how possible do you think it would be to have a civil discussion with them and agree on whether it should be float or double?
[09:22] <ubitux> i don't care what they use
[09:22] <ubitux> it's not a compatibility problem
[09:22] <ubitux> maybe just a potential source of bugs, but it's not even confirmed
[09:22] <andrewrk> ah. I assumed it was. any differences in implementation make merging patches trickier
[09:22] <ubitux> i'm just playing safe here
[09:30] <ubitux> plepere: will look
[09:32] <ubitux> plepere: please don't add those "+////////////////////////////////////////////////////////////////////////////////"
[09:32] <plepere> ubitux, ok.
[09:32] <ubitux> diff is more readable btw, that's cool :)
[09:33] <ubitux> (no need to resend a version now, drop it for the next iteration)
[09:33] <plepere> ubitux, yes yes. I'm already working on loop unrolling anyways. :)
[09:34] <ubitux> plepere: do you mind if i comment here or you prefer on the ml?
[09:34] <plepere> you can comment here. :)
[09:34] <plepere> I'll take written notes
[09:51] <ubitux> plepere: last nit style; don't comment the code, drop it ("// s->hevcdsp.put_hevc_qpel[my][mx] ..."), and align vertically the arguments with the ( when breaking lines
[09:52] <ubitux> there are settings to do that automatically in most editors
[09:55] <plepere> in which files ?
[09:55] <ubitux> second patch
[09:55] <ubitux> all the function call you changed basically
[09:58] <ubitux> plepere: in the asm, you can use the cglobal to name local variables
[09:58] <ubitux> so you don't have to pick random numbers for the registers
[09:58] <ubitux> and actually gives some meaning to them
[09:59] <plepere> so I can name parameters + variables directly ?
[09:59] <ubitux> yep
[09:59] <plepere> neat
[09:59] <ubitux> see in libavcodec/x86/vp9lpf.asm
[09:59] <ubitux> cglobal vp9_loop_filter_h_%1_16, 5,10,16, 256, dst, stride, E, I, H, mstride, dst1, dst2, stride3, mstride3
[09:59] <ubitux> args stop after the H
[09:59] <plepere> ok. :)
[09:59] <ubitux> mstride & friends are extra regs
[10:00] <ubitux> 5 = 5 args, 10 = 5args+5extra reg
[10:00] <plepere> got it. :)
[10:02] <ubitux> mov               r9, 0  like with simd pxor, you can use xor here
[10:02] <ubitux> but well you're probably gonna unroll anyway
[10:02] <ubitux> i'll comment on that part after it's changed
[10:03] <ubitux> the loops are clumsy as they are anyway
[10:05] <plepere> the unrolled single loops are better. :)
[10:06] <ubitux> +%macro MC_PIXEL_COMPUTE8_8 0
[10:06] <ubitux> +    MC_PIXEL_COMPUTE2_8
[10:06] <ubitux> +%endmacro
[10:06] <ubitux> what's the point of this?
[10:06] <ubitux> maybe use %define?
[10:06] <plepere> yes, %define is more logical in this case. :/
[10:07] <ubitux> you can probably move the cglobal and RET into the macros themselves
[10:07] <ubitux> i think i already raised that, maybe you answered..
[10:08] <plepere> well there is no big macro now
[10:08] <plepere> since the unrolling makes the functions quite different now
[10:08] <ubitux> ok
[10:08] <ubitux> #if ARCH_X86_64
[10:09] <ubitux> include that in the if itself
[10:09] <ubitux> if (ARCH_X86_64 && ...)
[10:09] <plepere> which if ? it's there so it doesn't compile in 32bit
[10:10] <ubitux> it will, the linker optim will prevent from trying to find the inexisting symbols
[10:10] <ubitux> see the if above
[10:10] <ubitux> we use that method everywhere, don't worry
[10:12] <ubitux> i'll comment on the unrolled version of the patch
[11:25] <ubitux> michaelni: i'd like to have compand properly merged before 2.2; if you or paul aren't that motivated i can help
[11:26] <ubitux> michaelni: also, #3131 looks important
[11:26] <ubitux> but i can't comment much on it
[11:26] <ubitux> anything you think is blocking?
[11:27] <nevcairiel> some people reported that remuxing the stream solved the issue as well, so must be some odd interaction between demuxer parser and decoder
[11:31] <michaelni> ubitux, do you have a test command line for our compand filter ?
[11:32] <ubitux> michaelni: not really, maybe the one is the ticket
[11:32] <ubitux> which triggers the crash with that particular sample
[11:33] <michaelni> ubitux, iam talking about the audio filter not 3131
[11:33] <ubitux> me too
[11:34] <ubitux> michaelni: there is command in #3383
[11:36] <michaelni> thx
[12:02] <cone-124> ffmpeg.git 03Andrew Kelley 07master:738f83582a3a: lavfi: add compand audio filter
[12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5d166de25853: Merge remote-tracking branch 'qatar/master'
[12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:22307f170ffc: avfilter/af_compand: whitespace changes from af_compand_fork
[12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:1df1a1fe6120: avfilter/af_compand_fork: avoid strtok_r() so as not to break build
[12:39] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:86a191e25bc5: avfilter/af_compand: merge avframe code from af_compand_fork
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:66ad3292eb45: avfilter/af_compand: add Andrew Kelley to the copyright
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5c78fe08b0a6: avfilter/af_compand: cosmetics and doxy comment from libavfilter/af_compand_fork.c
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:4b8797514732: avfilter/af_compand: pts init code from libavfilter/af_compand_fork.c
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:e509df4bc8eb: avfilter/af_compand: error checks from libavfilter/af_compand_fork.c
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:619d6b8f55ce: avfilter/af_compand: "use local variable for channels" from libavfilter/af_compand_fork.c
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5e02ff3e3d15: avfilter/af_compand: switch defaults to libavfilter/af_compand_fork.c
[13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:05412f4cd41e: avfilter/af_compand: cosmetics from libavfilter/af_compand_fork.c
[13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:c62d83a5e7dd: avfilter/af_compand: more cosmetics from libavfilter/af_compand_fork.c
[13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:8f946ac8ea10: avfilter: remove af_compand_fork
[16:00] <durandal_1707> andrewrk: s/libav/Libav in license of compand
[16:01] <Compn> shouldnt it be s/libav/FFmpeg ?
[16:01] <durandal_1707> i talk about cosmetics flaws in Libav code
[16:08] <ubitux> haha
[16:09] <Compn> lol
[16:09] <Compn> durandal_1707 : the libav logo on libav.org is uncapitalized :P
[16:11] <durandal_1707> they should finally decide, are they going to be named Libav of libav
[16:11] <durandal_1707> s/of/or ^&*^*&
[16:15] <ubitux> LibAV seems trending
[16:18] <beastd> i would always spell it Libav or LibAV or whatever. Plain libav is just too misleading...
[16:20] <ubitux> i think carl like to call them "avconv"
[16:20] <ubitux> because it's less confusing
[16:45] <Daemon404> who wants to take bets
[16:46] <Daemon404> im going to encode 600 4k frames with vp9 on placebo
[16:46] <Daemon404> on a 24-core xeon
[16:46] <Daemon404> how many days? bets welcome.
[16:46] <Daemon404> not that cores matter for vpx
[16:48] <ubitux> mmh
[16:48] <ubitux> 20 hours
[16:48] <ubitux> you only have 600 frames after all
[16:49] <Daemon404> for 4k?
[16:49] <Daemon404> damn that will be faster than x265 with 24 threads
[16:49] <Daemon404> lol.
[16:49] <ubitux> ah
[16:49] <nevcairiel> 0.5 fpm or so i would guess
[16:49] <nevcairiel> seems not too far fetched
[16:50] <Daemon404> i want to do proper testing but every encoder except x264 is so goddamn slow
[16:50] <Daemon404> i need to like
[16:50] <ubitux> x265*?
[16:50] <Daemon404> run a figgen mapreduce on our servers
[16:50] <Daemon404> ubitux, no
[16:50] <ubitux> ah sorry
[16:50] <ubitux> derp reading sorry
[16:50] <ubitux> i have 63% of the ETV raw
[16:50] <Daemon404> maybe i can hijack our hadoop servers and run trancodes
[16:50] <Daemon404> hurr hurr hurr
[16:50] <ubitux> i'll probably make the new encodes next week
[16:50] <ubitux> and the next week i'll have them in vp9
[16:51] <Daemon404> i have some 4k clips if you want
[16:51] <Daemon404> but im already doign encodes with them
[16:51] <ubitux> i want to retry with the raw instead of the x264 encode for etv
[16:51] <Daemon404> yeah im using beyondhd test clips
[16:51] <ubitux> to check if that's why x264 won at high bitrate
[16:51] <Daemon404> raw 10-bit 4:4:4
[16:51] <Daemon404> (well, rgb)
[16:52] <Daemon404> oh, i wanted to ask
[16:52] <Daemon404> is tehre a good resource on using newton' method in a practical manner
[16:52] Action: Daemon404 was avoiding readig all teh calculus on the wiki page
[16:55] <kierank> x1 = x0 - f(0)/f'(0)
[16:55] <kierank> f(x0) I mean for both
[16:55] <kierank> use a central difference for the derivative
[16:56] <Daemon404> >central difference
[16:56] <Daemon404> its been too long and i dont remember wtf this is
[16:56] <Daemon404> ive never had to do derivativs manually in code, somehow
[16:57] <kierank> f'(x) ~= f(x+epsilon) - f(x-epsilon) / 2e 
[16:57] <Daemon404> from wiki, i cant see:
[16:57] <Daemon404> a) where e comes from
[16:57] <kierank> it's just a width
[16:58] <Daemon404> http://upload.wikimedia.org/math/0/3/0/03003621f1d1c21db25c422bac0c580e.png
[16:58] <kierank> literally deltay / delta x
[16:58] <Daemon404> wiki has no e at all
[16:58] <kierank> they use h
[16:58] <Daemon404> oh i see why im confused
[16:58] <Daemon404> you wrote out epsilon twice
[16:58] <Daemon404> then used 'e'
[16:58] <Daemon404> which i took to be the constant, e
[17:00] <kierank> yeah should be epsilon :)
[17:01] <Daemon404> ive literally never had to do calculus in code
[17:01] <Daemon404> i dont think ive done central difference since highschool
[17:02] <Daemon404> and only for like week there, until we got to the ways the rest of the world does it
[17:02] <Daemon404> :V
[17:02] <Daemon404> oh well
[17:04] <kierank> why do you need calculus
[17:05] <Daemon404> kierank, ... >derivatives
[17:05] <ubitux> huh, what's this license change.
[17:05] <Daemon404> how is that not calculus?
[17:05] <kierank> Daemon404: for what
[17:05] <Daemon404> newton-pahson?
[17:05] <Daemon404> raphson*
[17:06] <kierank> why do you need newton raphson
[17:06] <Daemon404> because many encoders have shit ratecontrol
[17:07] <Daemon404> actually i have numpy and R installed (and matlab elsewhere)
[17:07] <Daemon404> maybe ill just have them do it for me
[17:07] <Daemon404> im sure they have less annoying ways
[17:22] <Daemon404> it's really goddamn annoying to compare encoders when x264 is literally the only one that can get anywhere close
[17:22] <Daemon404> re: rc
[17:29] <Daemon404> kierank, scipy.optimize.newton works wonderfully
[17:29] <smarter> ubitux: consider trying without --aq-mode=1
[17:30] <ubitux> yeah i'll do 2 encodes
[17:30] <ubitux> smarter: do you know when libvpx is going to get faster?
[17:30] <smarter> it's getting faster all the time :p
[17:31] <smarter> though cpu-used=0 is still pretty damn slow
[17:31] <ubitux> i mean faster enough to get usable
[17:31] <smarter> I think that SATD-based RDO would help, but that's a big undertaking
[17:31] <smarter> I might experiment with that if I get the time
[17:32] <ubitux> you think we can consider doing some vp9 encodes in about 6 month?
[17:32] <smarter> no idea really
[17:33] <smarter> (concerning --aq-mode=1, in my tests it made SSIM worse with blurry/noisy content, I had a fix but I couldn't see any difference visually, and it made aq-mode=1 less useful in other cases, so I didn't bother applying it)
[17:34] <ubitux> speaking of this, was the double-bitrate issue raised?
[17:34] <smarter> create an issue in the bug tracker maybe?
[17:35] <ubitux> erh, :eff
[17:35] <ubitux> this reminds me i wanted to check an issue with vp8 encoder in libvpx
[17:36] <smarter> I also suspect that this is because of aq-mode=1, but it would require making the first pass much more complex I think
[17:36] <ubitux> http://trac.ffmpeg.org/ticket/3137
[17:36] <ubitux> this bug is extremely annoying ^
[17:37] <ubitux> but i guess i have to reproduce with libvpx directly
[17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:a2e4b4e96836: avfilter/af_compand: some more cosmetics to decrease difference with qatar
[17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9f2a3bcee7bc: avfilter: remove superflous lines
[17:40] <durandal_1707> i cant belive it, i fixed that spell mistake.. but it keep going in
[17:41] <ubitux> ?
[17:46] <durandal_1707> and why they added shuffleplanes filter its functionality is extremly limited
[17:46] <durandal_1707> mergeplanes can do what it does and much more ....
[17:47] <ubitux> considers you happy they didn't name it the same
[17:47] <ubitux> yourself*
[17:47] <saste> durandal_1707, nih syndrome
[17:55] Action: Daemon404 jabs saste to review a weeks-old example code patch he sent
[17:57] <durandal_1707> andrewrk: you gonna send af_ladspa to libAV?
[17:57] <saste> Daemon404, name of patch?
[17:58] <Daemon404> [PATCH] examples/demuxing_decoding: Fix invalidd API usage
[18:01] <ubitux> nice
[18:01] <ubitux> libvpx seems to create broken webm files :(
[18:01] <ubitux> oh well, whatever
[18:06] <durandal_1707> and naming filter shuffleplanes would just add confusion with same function from VS
[18:10] <Daemon404> ubitux, with ivfenc?
[18:10] <Daemon404> oh webm
[18:50] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9d297641ee0b: avformat/sdr2: h264 stream needs parsing
[19:21] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:bdadf05ec853: avcodec/parser: put lost comments back
[19:21] <cone-124> ffmpeg.git 03Timothy Gu 07master:baa650cc7946: configure: use pkg-config to detect libbluray
[19:56] <Daemon404> we should add a copyright header in allcodecs.c for everyone who has ever touched it
[19:56] <Daemon404> riff.c too
[20:03] <iive> why only them? let's put everybody everywhere.
[20:27] <Compn> Daemon404 : simple stuff like that isnt copyrightable ? :P
[20:27] <Compn> at least the tables
[20:27] <Compn> not the other code in there :P
[20:29] <cone-124> ffmpeg.git 03Peter Ross 07master:1524b0fa68e0: libavcodec/rawdec: avoid memcpy when performing 16-bit samples shift
[00:00] --- Thu Feb 27 2014