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

[burek]

[00:01:38 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQEqZ
[00:01:38 CEST] <KGB> 13FFV1/06master 14e9b17db 15Dave Rice: escape underscore
[00:10:46 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQEq7
[00:10:46 CEST] <KGB> 13FFV1/06master 145db2c80 15Dave Rice: bump to wg doc version 00...
[00:59:48 CEST] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-00 at 06master: 02https://git.io/vQEOZ
[02:09:39 CEST] <iive> is there a way for the announce bot to remain in the channel and not join and exit on every message?
[02:10:47 CEST] <atomnuker> yes
[02:11:45 CEST] <atomnuker> but you need to allow external messages in the channel
[02:13:50 CEST] <iive> you mean, to allow the bot to message in the channel without joining it? That sound like horrible idea.
[02:14:16 CEST] <atomnuker> yep
[02:14:20 CEST] <iive> i didn't even thought it is possible to do such thing.
[04:23:47 CEST] <Compn> maybe we can whitelist the bot
[04:23:52 CEST] <Compn> so it can do external messages
[04:23:57 CEST] <Compn> with +t still enabled
[04:24:04 CEST] <Compn> or , let him do /onotice
[12:58:28 CEST] <cone-051> ffmpeg 03wm4 07master:64ecb78b7179: vdpau: do not use buggy HEVC support by default
[13:28:09 CEST] <wm4> man htmlsubtitles.c is another source file where the author's intention seems to be to make life harder for whoever was going to hack on it later
[13:44:48 CEST] <ubitux> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8c3798d2369e4285da44b244638eafe446a8f8a
[13:44:51 CEST] <ubitux> wtfff
[13:47:25 CEST] <kierank> ubitux: arm did the same for java
[13:47:33 CEST] <kierank> and sparc does the same of oracle dbs
[13:47:35 CEST] <kierank> so nothing new
[13:47:40 CEST] <BBB> ubitux: I dont think thats crazy
[13:48:03 CEST] <BBB> the commit message is misleading to bystanders, but it just exposes instructions that are useful for certain purposes
[13:48:12 CEST] <BBB> thats convenient, and probably a good thing
[13:48:27 CEST] <BBB> they could have named it better ;)
[13:48:50 CEST] <ubitux> ok :)
[13:48:56 CEST] <ubitux> still surprising
[13:49:07 CEST] <BBB> its certainly unconventional...
[13:49:17 CEST] <BBB> but hey, theres all kind of crazy stuff out there
[13:50:00 CEST] <BBB> didnt libavformat have a file browser API at some point? </crazy>
[13:50:08 CEST] <BBB> maybe its still there :-o
[13:50:36 CEST] <wm4> what's special about javascript conversions?
[13:50:41 CEST] <wm4> different rounding mode or what?
[13:51:29 CEST] <nevcairiel> maybe it didnt have a instruction for double -> int at all before
[13:51:39 CEST] <nevcairiel> the mention of javascript is just troll bait tho
[13:53:45 CEST] <wm4> well the instruction name/feature identification seems to have J in it?
[13:53:56 CEST] <wm4> "JSCVT"
[14:22:13 CEST] <cone-051> ffmpeg 03Steven Liu 07master:274bd1670b9c: avfomat/hlsenc: support fmp4 format in hls
[14:30:28 CEST] <cone-051> ffmpeg 03Matthieu Bouron 07master:7864e07f4af2: checkasm: add sbrdsp tests
[14:30:29 CEST] <cone-051> ffmpeg 03Matthieu Bouron 07master:0a24d7ca831b: lavc/aarch64: add sbrdsp neon implementation
[17:08:28 CEST] <durandal_1707> atomnuker: finished anything?
[17:10:19 CEST] <atomnuker> no, have to reinstall machine, apt destroyed python during an upgrade and can't install or upgrade anything
[17:10:23 CEST] <atomnuker> gdb is dead because of it
[17:13:10 CEST] <wm4> lol debian
[17:13:25 CEST] <BBB> poor atomnuker 
[17:14:39 CEST] <funman> apt-get install -f ?
[17:15:03 CEST] <atomnuker> "Could not find platform independent libraries <prefix>"
[17:15:40 CEST] <atomnuker> yes, I even removed the problematic packages from the dpkg database but still, the way apt uses python is broken or something
[17:16:01 CEST] <atomnuker> and dpkg since python is used for post/pre install scripts
[17:16:32 CEST] <atomnuker> I'm even more convinced python is a bad choice for anything
[17:26:37 CEST] <J_Darnley> Fuck this shit.
[17:26:57 CEST] <J_Darnley> "Just run the transform on a slice"  "haar is simple"
[17:27:25 CEST] <atomnuker> the decoder's the hard part
[17:29:54 CEST] <J_Darnley> Screw it.  I am dumping 1 slice to see whether it looks anything close to right.
[17:33:10 CEST] <BBB> poor J_Darnley 
[17:33:12 CEST] Action: J_Darnley makes note to not do this in his personal project
[17:36:37 CEST] <kierank> atomnuker: decoder is easy part
[17:40:11 CEST] <atomnuker> the transforms make it the hard part
[17:54:21 CEST] <J_Darnley> WTF?!  Why isn't that stride constant?
[17:54:51 CEST] <atomnuker> it changes between planes?
[17:55:11 CEST] <J_Darnley> No between whatever these strauctures are.  Subbands?
[17:55:49 CEST] <J_Darnley> It halves as they get bigger
[17:57:07 CEST] <J_Darnley> Oh I guess they have to because it "splats" the data back out for the full plane transform.
[17:57:56 CEST] <J_Darnley> No, splat is the wrong term
[17:59:12 CEST] <J_Darnley> Whatever, it throws the data all across the frame
[18:02:17 CEST] <J_Darnley> I think this shit is impossible without writing the decoder from scratch
[18:06:06 CEST] <J_Darnley> The DSP functions need frame properties as arguments
[18:06:18 CEST] <J_Darnley> The coeffs need to red into the right place
[18:06:29 CEST] <J_Darnley> The transform needs to be moved inwards
[18:15:22 CEST] <kierank> Just delete the transform
[18:15:31 CEST] <J_Darnley> I did
[18:15:36 CEST] <kierank> Ah
[18:15:55 CEST] <kierank> You should be able to see the lowest level
[18:17:19 CEST] <J_Darnley> I can see green, lots of green, nothing else though
[18:19:45 CEST] <J_Darnley> although when I disable chroma I do get a little noise
[18:21:13 CEST] <J_Darnley> Woo!  segfault
[18:23:50 CEST] <J_Darnley> Ah ha!  Missing a factor of h and now I see something
[18:25:41 CEST] <J_Darnley> The changes from the digit in testsrc is visible but that's about it
[18:41:07 CEST] <J_Darnley> Well I think that looks something like increasing frequency data
[18:49:41 CEST] <kierank> J_Darnley: can you paste photo
[18:50:11 CEST] <J_Darnley> Probably
[18:55:33 CEST] <J_Darnley_irssi> http://imgur.com/a/SnHIT
[18:55:47 CEST] <J_Darnley> kierank ^
[18:56:04 CEST] <kierank> thanks
[18:57:25 CEST] <J_Darnley> Will crop in future
[18:57:33 CEST] <J_Darnley> 4x neighbour scaling
[19:00:12 CEST] <kierank> i have a 4k screen, idon'tcare :)
[19:01:38 CEST] <J_Darnley> Ah dinner is being cooked without me
[19:01:46 CEST] Action: J_Darnley hurredly commits
[19:04:11 CEST] <J_Darnley> Code is https://gitlab.com/J_Darnley/ffmpeg dirac branch if you want it.
[19:04:14 CEST] Action: J_Darnley afk
[19:18:18 CEST] <wm4> so we're doing some kind of live streaming with HLS (with ffmpeg being on both muxing and demuxing side), which involves a sliding window of active content
[19:18:40 CEST] <wm4> apparently HLS has mechanisms for that, but there's no API that could be used to let the HLS demuxer report the current window start/end to the API user
[19:18:48 CEST] <wm4> any suggestions how that would be done best?
[19:36:56 CEST] <wm4> nevcairiel: ok with pushing libturing?
[19:37:30 CEST] <wm4> you were the last person to comment on it
[19:39:02 CEST] <durandal_1707> how to pass function args to mX registers?
[19:40:01 CEST] <iive> x86asm ?
[19:42:42 CEST] <durandal_1707> yes
[19:43:05 CEST] <durandal_1707> its int and i want just byte part
[19:45:16 CEST] <kierank> movb?
[19:46:31 CEST] <BBB> durandal_1707: pinsrb
[19:46:41 CEST] <BBB> (if its from memory)
[19:46:56 CEST] <BBB> if its from a register, use movd
[20:00:02 CEST] <durandal_1707> BBB: its ugly i call it 16 times
[20:00:13 CEST] <BBB> call what?
[20:04:35 CEST] <kierank> durandal_1707: why
[20:04:43 CEST] <kierank> why do you need to load bytes like that
[20:04:45 CEST] <durandal_1707> pinsrb
[20:05:09 CEST] <durandal_1707> to put each byte into position in mX
[20:05:29 CEST] <atomnuker> couldn't you mova and the pshufb (SPLATB_REG)?
[20:05:34 CEST] <kierank> but you can load and shuffle etc
[20:05:51 CEST] <durandal_1707> i dunmo
[20:10:38 CEST] <durandal_1707> https://pastebin.com/BzXJ2R1x
[20:12:22 CEST] <atomnuker> mova + pshufb
[20:12:43 CEST] <durandal_1707> doesnt work
[20:12:53 CEST] <atomnuker> why not?
[20:13:02 CEST] <durandal_1707> i get errors
[20:13:11 CEST] <durandal_1707> when compilimg
[20:13:22 CEST] <atomnuker> invalid operand or something like that..?
[20:13:27 CEST] <atomnuker> oh, you need minbq
[20:15:10 CEST] <atomnuker> so SPLATB_REG m1, minbq, [splat_table]
[20:16:10 CEST] <atomnuker> and your splat_table would just be splat_table: times 16 0x0
[20:22:43 CEST] <atomnuker> (you could just pxor m2, m2 and use that as your splat table)
[20:25:45 CEST] <BtbN> Can someone with Windows and an Intel-CPU(Shouldn't matter how recent), run this https://btbn.de/files/ffmpeg.exe with this command line: ./ffmpeg.exe -cpuflags 0 -f lavfi -i anoisesrc=r=48000 -t 1:00:00 -strict -2 -c:a opus -b:a 96k -f null -
[20:32:48 CEST] <J_Darnley> BtbN: 46555 UNITS in pvq_search, 8385232 runs,   3376 skips
[20:33:12 CEST] <BtbN> hm, ok. So it's not entirely a Ryzen problem
[20:33:25 CEST] <BtbN> what CPU at what clock is that?
[20:34:37 CEST] <J_Darnley> 17 750 (Nehalem) 2.66GHz (I think
[20:34:46 CEST] <BtbN> hm
[20:34:48 CEST] <J_Darnley> i7 I mean
[20:35:04 CEST] <BtbN> I get 55k UNITS on a 1800X with 3.7GHz
[20:35:50 CEST] <durandal_1707> atomnuker: and how to do same but with words instead of bytes?
[20:36:20 CEST] <BtbN> iive, in case you also want to test ^
[20:38:12 CEST] <iive> BtbN: sure
[20:41:18 CEST] <atomnuker> durandal_1707: same as you do bytes, just change your splat_table to times 8 0x0, 0x1
[20:41:29 CEST] <iive> BtbN: my wine is 32bit only... WOW is a lot more effort and problem. 
[20:41:34 CEST] <iive> in short, can't test it ATM
[20:42:33 CEST] <atomnuker> (SPLATD assumes your word is already loaded and SPLATW also assumes its already loaded in another/the same register, so you have to do a shuffle anyway)
[20:42:44 CEST] <iive> but 46k is quite slow too.
[20:44:29 CEST] <jkqxz> 61450 UNITS.
[20:44:38 CEST] <jkqxz> N3700, Braswell @ 2.4GHz.  Is there a prize?  :)
[20:45:00 CEST] <iive> is that intel of amd?
[20:45:20 CEST] <atomnuker> yes, that of the world's least optimizing compiler (I get 6000 on linux x86 gcc)
[20:45:21 CEST] <jkqxz> Intel low-power.
[20:45:35 CEST] <iive> atom like?
[20:46:30 CEST] <jkqxz> Yeah.  It's current-minus-one generation atom-type.
[20:49:09 CEST] <jkqxz> Ah, I screwed up the command line and set the wrong bitrate when transcribing it to windows.  Actually it's only 41k.
[20:49:42 CEST] <iive> :)
[20:49:54 CEST] <BtbN> hm
[20:49:59 CEST] <BtbN> it's notably better than on Ryzen
[20:50:05 CEST] <BtbN> but still worlds slower than the gcc version
[20:50:13 CEST] <iive> i bet the lrintf is not that slow on intel.
[20:51:02 CEST] <iive> well, at least this settles it as MSVC missing optimization.
[20:53:00 CEST] <wm4> everything silent about libturing, so I guess I'm forced to push it
[20:54:02 CEST] <durandal_1707> atomnuker: thereis no splatw_reg
[20:54:49 CEST] <atomnuker> no, so you use SPLATB_REG
[20:56:18 CEST] <jkqxz> wm4:  Does it actually build and work by default now?
[20:56:35 CEST] <wm4> maybe?
[20:56:43 CEST] <wm4> at least the guy claimed it does
[20:56:56 CEST] <wm4> meh I guess I'll do it tomorrow
[20:58:13 CEST] <jkqxz> If it builds and works for you then just do it, IMO.
[20:58:42 CEST] <wm4> just that building libturing is probably a project on its own and can't just be done in 2 minutes
[20:59:01 CEST] <wm4> but I fully agree that this should be done at least before pushing
[20:59:46 CEST] <durandal_1707> atomnuker: i get wrong output with that
[21:00:18 CEST] <durandal_1707> for w case i fetch words into regs
[21:02:43 CEST] <atomnuker> durandal_1707: hm, maybe I forgot to account for endianess, try times 8 0x1, 0x0
[21:08:14 CEST] <durandal_1707> atomnuker: https://paste.ubuntu.com/25013117/
[21:10:56 CEST] <atomnuker> does it work?
[21:12:46 CEST] <durandal_1707> nope
[21:14:33 CEST] <atomnuker> both versions or only the 16 bit version?
[21:15:19 CEST] <durandal_1707> 8bit works, 16bit doesnt
[21:19:20 CEST] <atomnuker> mova the m1 and m2 regs, RET and see what they have in there
[21:24:17 CEST] <iive> there is SPLATW
[21:27:46 CEST] <durandal_1707> iive: and how im supposed to use it?
[21:29:38 CEST] <iive> movd m1, min
[21:29:45 CEST] <iive> SPLATW m1, m1
[21:31:30 CEST] <iive> maybe you have to add 'dword mind'
[21:32:59 CEST] <iive> not that there would be a problem if it picks 64bit movd.
[21:33:24 CEST] <iive> but that's usually movq
[21:38:46 CEST] <iive> also, SPLATB_REG , the 3'd parameter is immediate value. 0 should work just fine.
[21:39:23 CEST] <iive> no
[21:39:25 CEST] <iive> mybad
[21:47:57 CEST] <ubitux> durandal_1707: s/limiter/clamp/?
[21:48:08 CEST] <ubitux> (typical GL naming)
[21:48:20 CEST] <durandal_1707> ubitux: i prefet vs name
[21:48:37 CEST] <durandal_1707> thereis also alimiter :)
[21:52:26 CEST] <ubitux> ok ok
[22:37:01 CEST] <durandal_1707> atomnuker: regarding new bitstream , how you supposed to handle vlc stuff. its in separate header?
[22:41:08 CEST] <atomnuker> I pasted it in so its just 1 file like get_bits again
[22:45:45 CEST] <durandal_1707> nooo
[22:45:56 CEST] <atomnuker> you'd like it to be separate?
[22:46:07 CEST] <atomnuker> I don't mind
[22:46:15 CEST] <durandal_1707> it is separate
[22:47:05 CEST] <atomnuker> get_vlc2 is in get_bits.h, but in libav its in libavcodec/vlc.h (IIRC)
[22:47:57 CEST] <durandal_1707> atomnuker: just add cache of 64 bits
[22:54:51 CEST] <atomnuker> its not that simple
[22:55:23 CEST] <atomnuker> (but if you think it is go ahead and send a patch, I can't do anything until I finish installing debian again tonight)
[23:43:45 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:6d4a686d4521: lavc/mediacodec: add missing newline on warning
[23:43:46 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:aad79e4323bb: lavc/mediacodec: rescale pts before decoding for both hw and sw buffers
[23:46:00 CEST] <TMM> durandal_1707, sorry for the stupid patch... I actually had corrected that before sending it but ended up reverting it back to the stupid comparison again for some reason? I don't even know...
[00:00:00 CEST] --- Tue Jul  4 2017